昨日MediumでCarthageでStatic FrameworkとしてビルドしてiOSアプリの起動時間を短縮するという記事を書きました。この記事ではサンプルプロジェクトでの起動時間の計測だったのですが、今度は実際に私が仕事で作成しているアプリの起動時間を短縮してみようと思います。
まずは計測
以前から社長に起動時間を短縮して欲しいといわれてまして、まぁ遅いわけです。その起動時間を確認してみます。実行環境は記事と同じくiPhone 6 / iOS 11.0です。
Total pre-main time: 4.5 seconds (100.0%)
dylib loading time: 1.9 seconds (41.7%)
rebase/binding time: 200.17 milliseconds (4.3%)
ObjC setup time: 557.89 milliseconds (12.1%)
initializer time: 1.9 seconds (41.7%)
記事ではmillisecondsという単位でしたが、アプリではsecondsの単位。4.5秒、これでは起動時間短縮を指示されるわけです。
どのライブラリをStaticフレームワークにするか
早速Staticフレームワークにしていきましょう。といっても言語や画像などのリソースを持つフレームワークはStaticフレームワークにしにくかったりできなかったりするので、一つ一つ選別しなければいけません。
Cartfileで指定しているフレームワークを一つ一つ確認して23個Staticフレームワークにできそうです。
Staticフレームワークに再ビルドする
ld.pyスクリプトとCarthageでStaticビルドするスクリプトを設置して再ビルドコマンドを実行しました。
一つビルドが失敗するフレームワークがあったのでそれはDynamicのままにしておきました。それ以外すべてStaticでビルドして実行してみると…アプリのビルドに失敗。
failed to import bridging header '/Path/to/Hoge-Bridging-Header.h'になってしまいました。これはもしかしたら一つずつ再ビルドしてその度にアプリも実行してみる必要があるのでは…と思い、しかたないので初めに戻って一つずつ再ビルドすることにしました。しかし初期の状態でアプリをビルドしても同じエラーが。Cleanしてみるとエラーが消えました。どうやらStaciフレームワーク化をするとこのエラーが発生し、クリーンにより解決するようでした。
また、RealmやSDWebImageなどがStaticフレームワークとしてビルドしたにも関わらずDynamicフレームワークのままでした。
再計測
お楽しみの再計測です……………
Total pre-main time: 2.2 seconds (100.0%)
dylib loading time: 1.4 seconds (63.0%)
rebase/binding time: 153.40 milliseconds (6.7%)
ObjC setup time: 129.07 milliseconds (5.6%)
initializer time: 560.55 milliseconds (24.5%)
なんと4.5秒が2.2秒まで短縮されました。その差2.3秒
ただし実際のアプリの起動はもう少しかかります。ストップウォッチで計測すると、Dynamicフレームワークでは約5秒、Staticフレームワークでは4秒台後半でした。ほぼ誤差。これは骨折り損だったのか…
ふと、2回目以降の起動だったのでキャッシュされて起動が速くなっているのではないかと思いつき、iPhoneを再起動してから計測し直しました。すると初回起動においてDynamicでは約12秒、Staticでは約9.5秒という結果に。これはStatic化して高速化された秒数と近いことが分かります。ということは、キャッシュされていない状態での実際の起動でも順当な高速化がされたという結果が得られたことになります。つまり初回起動やキャッシュがない状態では確実に速くなると思われます。
以上のように、CarthageでStaticフレームワークとしてビルドすることでiOSアプリの起動の短縮が可能だということが分かりました。具体的な作業手順はCarthageでStatic FrameworkとしてビルドしてiOSアプリの起動時間を短縮するに記述してありますので、参考にしてみてください。