モバイルアプリの起動時間最適化

なぜ「起動が速い」の定義から揃える必要があるのか

起動時間最適化は「アイコンタップから画面が出るまでを削る」という単純な話に見えて、実装対象を誤ると効果が出ません。原因は、OSが管理するプロセスの生存状態によって、そもそも実行される処理量がまったく異なるからです。プロセスを新規に立ち上げるのか、既存プロセスを使い回すのか、画面だけ作り直すのかで、最適化すべき層が変わります。まず起動を3種類に分解します。

コールド・ウォーム・ホットスタートの違い

コールドスタートが重いのは、OSのプロセス管理から見て「何もない状態」から積み上げる必要があるからです。実行ファイルをディスクからロードし、動的リンクを解決し、ランタイム（iOSならObjective-C/Swiftランタイム、AndroidならART）を起動し、アプリ固有の初期化コードを走らせ、最初のUIを描画して初めて操作可能になります。ウォームスタートはこの積み上げの大部分（特にランタイム初期化と動的リンク）を省略できるため大幅に短縮され、ホットスタートはOSのバックグラウンド遷移をそのまま巻き戻すだけなので実質的に初期化を伴いません。

iOS: dyld共有キャッシュとバイナリ起動の内部

iOSのコールドスタートは、dyld（dynamic linker）がバイナリを実行可能にするまでの工程に大きく支配されます。アプリのMach-Oバイナリは通常、単体では動かず、UIKitやFoundationなど多数の共有ライブラリに依存します。この依存解決を都度ディスクから行うと遅いため、iOSは主要システムライブラリをあらかじめリンク・レイアウト済みの単一ファイルにまとめたdyld共有キャッシュをOSイメージに焼き込んでおき、起動時はこれをメモリにマップするだけで済ませます。

dyldが行う工程はおおよそ次の順序です。

1. 実行可能ファイル（Mach-O）をロード
2. 依存ライブラリを解決
   - システムライブラリ → 共有キャッシュを mmap するだけ（高速）
   - アプリ埋め込みのフレームワーク → 個別に mmap しシンボル解決（低速）
3. Rebase / Bind（ASLRオフセット適用、シンボルの実アドレス確定）
4. 各ライブラリの初期化子（+load、C++コンストラクタ等）を実行
5. main() 呼び出し

ここで実務上効くのが「埋め込みフレームワークの数を減らす」という施策です。共有キャッシュに載っているシステムライブラリはmmapのみで済みますが、アプリが独自に埋め込む動的フレームワーク（サードパーティSDKなど）は共有キャッシュの恩恵を受けず、個別にロードとシンボル解決が発生します。フレームワーク数が増えるほどdyldのbind処理が線形に近い形で伸びるため、静的リンクへの統合やフレームワークの削減が直接効きます。加えて、+loadメソッドやグローバルC++オブジェクトのコンストラクタはmain呼び出し前に強制実行されるため、ここに重い処理を書くとプロファイラ上で「main前」の時間として計上され続けます。

Android: App Startupとバイトコード最適化

Androidのコールドスタートは、Zygoteからのプロセスfork後、Applicationと最初のActivityが生成され初回フレームが描画されるまでの区間です。ここで効いてくる要因は大きく2つあります。

第一に、初期化処理の直列実行です。多くのライブラリは自前のContentProviderをマニフェストに登録して自動初期化を行いますが、ContentProviderのonCreate()はApplicationの生成直後、メインスレッド上で登録順にすべて同期実行されます。ライブラリが増えるほどこの直列処理が積み上がり、Application#onCreate()に到達する前に時間を消費します。Jetpack App Startupはこの問題への対処で、Initializerインタフェースに依存関係を明示させることで、個別ContentProviderの乱立を1つのContentProviderに集約し、かつ依存グラフに基づいてトポロジカルソートした順に初期化を実行します。ライブラリの数だけ生成・登録されていたContentProviderのインスタンス化コストを1つ分に抑えつつ、初期化順序を制御可能にする点が要です。

第二に、バイトコードの実行方式です。AndroidのアプリはDEXバイトコードとして配布され、これをネイティブコードへ変換する方式が起動時間を左右します。

現行のART（Android Runtime）はJITとAOTを併用するハイブリッド方式で、インストール直後はインタプリタ／JIT主体で動き、デバイスがアイドルかつ充電中になったタイミングで使用頻度の高いメソッドをまとめてAOTコンパイルする、というプロファイルガイド最適化（Profile-Guided Compilation）を行います。つまり「同じアプリでもインストール直後の初回起動は遅く、数日運用後の起動は速くなる」のはART側の最適化が進行するためです。アプリ側でできる対策としては、起動経路のクラス数・メソッド数を減らす（不要な依存の削減、リフレクション多用の回避）ことが、インタプリタ／JIT段階の実行コストを直接下げます。

起動時間計測の指標

体感速度を正しく扱うには、「画面が出た」と「操作できる」を区別する指標が要ります。

TTIDはOSが自動計測でき、AndroidのlogcatにはDisplayed行として、iOSでも同種の初回描画タイミングが取得できます。しかしTTIDだけを最適化目標にすると、「枠だけ一瞬で出るがローディングスピナーが延々回る」画面でも指標上は高速と判定される落とし穴があります。AndroidのMacrobenchmarkライブラリが提供するreportFullyDrawn()はこの区別のためにあり、アプリが「本当に使える状態になった」タイミングを明示的にOSへ報告してTTFDとして計測させます。

まとめ

起動時間最適化は、まずコールド・ウォーム・ホットのどれを縮めようとしているのかを見極めるところから始まります。実質的な最適化余地があるのはコールドスタートで、iOSではdyldによる動的リンク（特に埋め込みフレームワークのbindコスト）とmain前後の切り分けが、AndroidではApp Startupによる初期化の一本化とARTのAOT/JITプロファイルが、それぞれ起動時間の下限を決める内部要因です。そして施策の効果を正しく検証するには、初回描画のTTIDと操作可能になるTTFDを区別して計測することが欠かせません。プロセスやランタイムの生成コストそのものは/os/が扱うプロセス管理の話題と地続きで理解すると立体的になります。