IOSでの静的ライブラリの使用

IOSでの静的ライブラリの使用
iOSライブラリに関する概念
ライブラリ:コンパイルされたバイナリコードで、ヘッダファイルを加えるとを使用できます.
ライブラリの分類:オープンソースライブラリとクローズソースライブラリの形式
オープンソースライブラリ:AFNetworkingのように、ソースコードは一般的にバージョン管理ライブラリに配置されます.
多くの人が直接オープンソースコードをダウンロードし、関連ファイルのcopyを自分のプロジェクトに直接使用します.欠点は、オープンソースライブラリのバージョンが更新された後、手動でcopyを1回行うことです.面倒です.gitを使用したsubmodule,現在一般的に使われているのはcocoapodsで、コマンドでオープンソースライブラリをインポートし、オープンソースライブラリの依存に関心を持つ必要はありません.cocoapodsの本質は、共通ライブラリを静的ライブラリにコンパイルし、この静的ライブラリに所有者エンジニアリングを依存させることである.

クローズドソースライブラリ
用途:一部のコードは他の人に使用する必要があるが、ソースコードを見せたくないので、ライブラリの形式でカプセル化する必要があり、ヘッダファイルだけを露出する必要がある.
いくつかの大きな変更を行わないコードに対して、私たちはコンパイルの時間を減らしたいと思って、ライブラリにパッケージすることができて、ライブラリはすでにコンパイルしたバイナリファイルなので、コンパイルする時Linkはすぐにできて、コンパイルの時間を浪費しません.


ライブラリLinkを使用する方法によって、閉ソースライブラリは静的ライブラリと動的ライブラリに分けることができます.
静的ライブラリ:(.aまたは.framework)コンパイル時に直接copyされ、ターゲットプログラムにコピーされます.コンパイルが完了すると、ライブラリファイルは実際にはあまり役に立たなくなります.ターゲットプログラムは外部依存せず、直接実行できます.欠点は(ターゲットプログラムの体積が大きくなる)です.
.a形式の静的ライブラリは、一般的に使用する場合に提供する必要がある.h .a .bundleファイルは、静的ライブラリプロジェクトを作成するときにコンパイルされた静的ライブラリが特定のハードウェアアーキテクチャアーキテクチャアーキテクチャのみをサポートするため、汎用静的ライブラリを生成する必要がある場合は、lipoコマンドを使用して複数の静的ライブラリを統合する必要があります.
.framework形式の静的ライブラリ、frameworkは最終的に1つのbundle(1つのフォルダ、中は規定のディレクトリ構造方式のファイル)にすぎないが、XCodeにとってこのようなtargetには真偽(Real/Fake)の区別があり、XCodeマスターエンジニアリングが依存を追加した場合にのみこの共通ライブラリプロジェクトのframework上昇のtarget を選択することができる.
ダイナミックライブラリ:コンパイル時にcopyにターゲットプログラムを盗まれず、ターゲットプログラムはダイナミックライブラリへの参照のみを格納し、プログラムが実行されるまでダイナミックライブラリが本当にロードされません.ターゲット・プログラムのボリュームには影響しませんが、パフォーマンスの損失の一部をもたらします.アップルは自家製ダイナミックライブラリをappstore にラックすることを許さない.

iOSでaスタティックライブラリの作成
新しいXCodeのlib工事は下図の通り:静的ライブラリをサブプロジェクトとして他のプロジェクト注に参照する:静的ライブラリを参照するプロジェクトのTarget DependenciesとLink Binary With Librariesはいずれも追加する必要がある.aスタティックライブラリはスタティックライブラリのプロジェクトを参照し、Header Search Pathsにスタティックライブラリプロジェクトのヘッダファイルのパスを追加する必要があります("."上位ディレクトリに戻ることを示す)作成した静的ライブラリに分類が追加された場合、静的ライブラリを参照するエンジニアリングはOther linker Flagsに-objC を追加する必要がある.
静的ライブラリのコンパイル
静的ライブラリプロジェクトのすべてのファイルのコンパイル:静的ライブラリプロジェクトの一部のファイルのコンパイル:注意:一部のファイルをパッケージ化する必要がある場合は、静的ライブラリをパッケージ化するプロジェクトでパッケージ化する必要はありません.mファイルのTaget MemberShipのチェックを外すと、このファイルは静的ライブラリにパッケージ化されず、自分がパッケージ化した静的ライブラリにlipoコマンドを使用できるファイルが含まれているかどうかを確認します.

Lipoコマンドの使い方
静的ライブラリに含まれるスキーマの表示

1

lipo -info lib.a

シミュレータライブラリファイルとネイティブライブラリファイルのマージ

1

lipo -create -output lib.a lib-armv6.a lib-i386.a

指定したスキーマの静的ライブラリを解凍

1
2
3

lipo -extract_family armv7 -output lib-armv7.a lib.a
  
lipo lib.a -thin armv7 -output lib-armv7.a

a形式の静的ライブラリをoファイルに解凍する、すべてを解凍することができる.oファイル

1

ar -x lib.a

oファイルをaファイルにマージ

1

libtool -static -o lib.a *.o

静的ライブラリでの注意事項
静的ライブラリに依存するdylibまたはframeworkは、最終的に静的ライブラリを使用するプログラムもを参照する必要があります.
静的ライブラリはバイナリコードであり、プロセッサタイプを区別し、lipo-create-outputを使用してマルチプロセッサをサポートする静的ライブラリを作成することができる.
静的ライブラリで使用するオープンソースコードは、静的ライブラリを参照するエンジニアリングで使用するオープンソースコードと同時に衝突する.
解決1:静的ライブラリは関連するオープンソースコードをパッケージ化せず、依存するオープンソースライブラリとそのバージョンを静的ライブラリ使用説明ドキュメントにリストする.
解決2:静的ライブラリオープンソースをパッケージングする場合、オープンソースのクラスの名前を変更し、3文字以上の接頭辞を付ける(推奨しない)パッケージ済みの静的ライブラリについては、lipoコマンドを使用して静的ライブラリの1つをパケット解除し、競合が発生する.oファイルを削除し、lipoコマンドで再パッケージし、各プロセッサフレームの.aファイルは繰り返し操作し、最後にlipoは静的ライブラリを再結合し、元の静的ライブラリを置き換える.

a.静的ライブラリ内のクラスのネーミングは、静的ライブラリを参照するエンジニアリングのクラスのネーミングと同時に重複定義とみなされる(OCにネーミングスペースがないため)
解決:静的ライブラリのクラス名に3文字以上の接頭辞を付ける

スタティックライブラリでCategoryを使用すると、Categoryで追加したメソッドで名前が重複してもエラーは報告されませんが、いずれかのメソッドが別のメソッドを上書きしている場合があります.
解決:categoryに追加する方法に接頭辞を追加することを推奨します.

グローバル変数の重複は必然的にコンパイルに失敗します
解決:静的ライブラリで使用されるグローバル変数に接頭辞を付ける

静的ライブラリではdebugを使用してlogを開き、releaseはlogを閉じ、Appstoreにパブリッシュされたアプリケーションはデバッグされたlogを印刷すべきではないため、静的ライブラリをパッケージ化する際にBuild ConfigurationをReleaseとして選択すると、一般的に多くのオープンソースライブラリのlogを削除することができ、静的ライブラリ使用者が開発時にlogを見ることを望んでいる場合、この場合は見えなくなる
解決:debugとreleaseを別々に打つパッケージ
参照
iOS常用静的ライブラリ操作コマンド
iOS静的ライブラリのピット