今まで外部ライブラリやフレームワークを使って開発を行ってきたが、そんな中Static, Dynamic Linkingについての概念が出てきたため、ここにメモを残す。
リンクとは?
- そもそもリンク(Linking)とは多様なコードの結びつけを行うことである。ここでいうリンクは、ライブラリやフレームワークをプロジェクトと結びつけることである。
ライブラリとフレームワークの違い
- ライブラリとは?
- RxSwiftなどの単純な外部ライブラリのこと
- フレームワークとは?
- ライブラリより広義な意味であり、ライブラリの中に存在するいろんなリソースなどを含めてそれらを指す。(Info.plistなど)
- Dynamic Framework → Dynamic Library
- Static Framework → Static Library
Static linkingとは?
- プログラムとライブラリやフレームワークを結びつける方法の一つである。
- そもそもStaticとは静的という意味である。日本語に訳すと静的に結びつけると言う意味。
- Static Linkingはライブラリやフレームワークを事前にビルドし、その時に必要な部分だけプログラム本体に埋め込む結びつけ方である。
- 例えば、RxSwiftがライブラリとして必要となった際に、RxSwiftを事前にビルドし、あるファイル内で
.map
とDisposeBag()
だけ必要ならばそれらの機能だけをそのファイルに埋め込んでくれる。
- 例えば、RxSwiftがライブラリとして必要となった際に、RxSwiftを事前にビルドし、あるファイル内で
Dynamic linkingとは?
- プログラムとライブラリやフレームワークを結びつける方法の一つである。
- そもそもDynamicとは動的と言う意味であり、日本語に訳すと動的に結びつけるという意味である。
- Dynamic LinkingはStatic Linkingとは違い、事前にビルドを行うのではなく、アプリをコンパイル時にプログラムに埋め込む結びつけ方である。
メリット、デメリット
-
Static LinkingもDynamic Linkingもただの結びつけ方であるが、それぞれの結びつけ方によってプロジェクトへの影響がある。
-
Dynamic Linking
- Dynamic Linkingの場合だと、フレームワークをプロジェクト外に置いておく必要がある。なぜなら、アプリ起動時に結びつけが起きるからだ。
- そのため、アプリサイズが大きくなりがちである。
-
Static Linking
- Static Linkingの場合だと、必要なファイルに必要なことだけを結びつけることができる。(先ほどの
map
の例など) - そのため、結果的にアプリサイズが小さくなる。
- Static Linkingの場合だと、必要なファイルに必要なことだけを結びつけることができる。(先ほどの
どうやって使い分けるか?
- StaticとDynamic Linkingの概念を把握した上でこれをどう使い分けるかが重要である。
- それはターゲットによって決まってくる。
- 具体例でいうと、あるアプリにおいてWatchOSのプロジェクトも必要だし、単純なiOSも必要だった場合に、Static Linkingを使って、フレームワークとの結びつけを行うか?それともDynamic Linkingを使うか?の選択がある。
- この場合は、後者の方がアプリサイズが小さい。
- なぜなら、仮にどちらのターゲットにもRxSwiftを導入していた場合に、Static Linkingで事前ビルドし、どちらのターゲットにもRxSwiftを結びつけるとすると、RxSwiftは2つのターゲットで使われているため、単純に2倍の結びつけが事前に必要となる。
- しかし、Dynamic Linkingの場合だと、コンパイル時に動的に結びつけてくれるため、RxSwiftフレームワークひとつ置いておけば良いので、アプリサイズが結果的に小さくなる。
Appleはどちらを推奨している?
- Appleとしては現在Static LinkingとDynamic Linkingを適切に使い分けることを推奨しているとのことだ。
- 実は数年前まではStatic Linkingを推奨していたのだが、ここ数年でDynamic Linkingによって引き起こされていたアプリ起動にかかる時間の問題が大きく改善された。
- 確かにアプリサイズ的には時としてDynamic Linkingの方が大きくなってしまう場合もあるが、その場その場に適した選択をしていくことをAppleは推奨している。