ios-launch-performance

iOS の起動パフォーマンス

アプリの起動要求から、最初に表示される UI と起動直後の応答性までの経路を確認するには、このスキルを使用します。

次のタイミングで行われる処理に注目します。

• main より前
• UIKit または SwiftUI の起動中
• UIApplicationDelegate、UISceneDelegate、または SwiftUI App 内
• ルート UI の作成中
• 最初のフレームが表示される前
• 最初の意味のある操作が行われる前
• 起動直後のユーザーが感じる準備状況に影響する処理中

これは iOS のパフォーマンス全般を扱うスキルではありません。問題が起動に特化している場合、またはコードが起動経路上で実行される場合にのみ使用してください。

基本モデル

起動を、次の個別フェーズから成るパイプラインとして捉えます。

1. プロセスの作成とシステムの準備
2. dyld の読み込み、バインド、修正、ランタイム登録、静的初期化
3. UIKit または SwiftUI のランタイム起動
4. UIApplicationDelegate、UISceneDelegate、または SwiftUI App 内でのアプリレベルの初期化
5. 起動のオーケストレーションと依存関係のセットアップ
6. ルート UI の構築、レイアウト、描画、最初のフレームのコミット
7. 応答性に影響する起動直後の処理
8. その後の機能固有の処理やメンテナンス処理

やみくもに最適化しないでください。まず、どのフェーズに時間がかかっているかを特定し、その特定の処理を移動、削除、遅延読み込み、並列化、直列化、または計測する変更を提案してください。

このスキルを使用する場面

次のようなタスクで、このスキルを使用します。

• アプリの起動が遅い
• 起動時のパフォーマンス低下
• コールド起動、ウォーム起動、または事前ウォームアップされた起動
• 再開と起動の混同
• 最初のフレームが表示可能になるまでの時間
• 起動後の初期応答性
• main より前または dyld の処理
• Objective-C の +load、+initialize、コンストラクター関数、または静的初期化
• AppDelegate または SceneDelegate の起動処理
• SwiftUI の @main App、WindowGroup、ルートビューのセットアップ、または環境の注入
• 起動時の依存コンテナーのセットアップ
• 起動オーケストレーターまたは順序指定された起動ステップ
• 起動時のサードパーティ SDK の初期化
• 起動コストが疑われる場合のフレームワークのリンク戦略
• Instruments、XCTest、MetricKit、または Xcode Organizer による起動メトリクス

次のような場合には、このスキルを使用しないでください。

• 一般的なスクロールパフォーマンス
• 起動に関係しないメモリリーク
• 最初のフレームに関係しない描画の最適化
• 起動時以外のネットワークパフォーマンス
• アーキテクチャが起動経路に影響しない場合の広範なアーキテクチャレビュー

起動シナリオの分類

アドバイスを行う前に、何を計測しているかを分類します。

• コールド起動：アプリのプロセスが常駐しておらず、起動関連の状態もほとんど温まっていません。
• ウォーム起動：新しいプロセスでアプリが起動しますが、システム状態、キャッシュ、またはページの一部がすでに温まっている可能性があります。
• 事前ウォームアップされた起動：ユーザーが明示的にアプリを開く前に、システムが起動経路の一部を準備している可能性があります。
• 再開／実行中のアプリへの復帰：アプリのプロセスがすでに存在し、バックグラウンドまたは一時停止状態から復帰します。
• 初回インストール／初回実行／アップデート後の起動：移行、キャッシュの作成、権限設定、アカウントやブートストラップの処理、バージョン固有のセットアップなど、追加のセットアップを含みます。
• 不明：計測の設定で、上記のケースが明確に区別されていません。

コールド起動、ウォーム起動、事前ウォームアップされた起動、初回実行時の起動、アップデート後の起動、再開を、単一のメトリクスとして比較しないでください。

タスクでフォアグラウンド復帰の遅延を明示的に扱っていない限り、再開は起動全体の調査には該当しません。

調査ワークフロー

1. 起動経路を特定する

最初のフレームが表示される前、または最初の意味のある操作が行われる前に実行されるコードを特定します。

次を調査します。

• アプリデリゲート
• シーンデリゲート
• SwiftUI App
• ルートシーンの構築
• ルートビュー／モデルの作成
• 依存コンテナーのセットアップ
• グローバル／静的初期化
• 起動オーケストレーター
• SDK の起動処理
• リンクされたフレームワークの初期化
• 初回画面のルーティングと状態の復元

2. 遅いフェーズを分類する

修正を推奨する前に、遅延が発生している可能性の高いフェーズを分類してください。

• dyld／main 前
• Objective-C または Swift のランタイム／静的初期化
• アプリデリゲートの起動
• シーンデリゲートの起動
• SwiftUI アプリ／ルートビューの初期化
• 起動のオーケストレーションまたは依存関係のセットアップ
• ルート UI の構築と最初のフレームのレンダリング
• 起動直後の応答性
• 測定上の曖昧さ

利用可能な証拠だけではフェーズを分類できない場合は、その旨を伝え、次に行う測定手順を推奨してください。

3. 起動時の処理を必要性で分類する

起動時の各タスクを、次のいずれかに分類してください。

• 最初のフレームの前に必須
• 最初の操作の前に必須
• 起動後すぐに必要
• 認証／セッション状態の判明後にのみ必要
• 後続機能でのみ必要
• バックグラウンドでの保守処理

最初のフレームまたは最初の操作の前に必要でない処理は、正確性に関わる理由がない限り、起動を妨げるべきではありません。

4. 依存関係を把握する

起動に順序付けられた手順、SDK のセットアップ呼び出し、サービス登録、または起動オーケストレーターがある場合、次の点を特定してください。

• 最初に表示される UI に本当に必要な手順
• 最初の意味のある操作の前に必要な手順
• 独立して実行できる手順
• 順序を維持する必要がある手順
• メインスレッドまたは共有可変状態に触れる手順
• 起動を妨げる必要がある障害
• 最長のクリティカルパスを形成する依存関係チェーン

コメント、脆弱な順序依存、組織内でのみ共有される知識はリスクとして扱ってください。呼び出し順に依存するより、明示的な依存関係を優先してください。

5. 隠れた先行処理を調べる

次の箇所に隠れた起動処理がないか確認してください。

• Objective-C の +load
• Objective-C の +initialize
• C／C++ のコンストラクター関数
• コンストラクターを持つ C++ のグローバルオブジェクト
• Swift のグローバル変数または静的プロパティ
• 先行初期化されるシングルトン
• 依存関係グラフの構築
• SDK の自動登録
• 動的フレームワークの起動
• 同期ファイル I/O
• データベースのオープンまたはマイグレーション
• キーチェーンに関わる負荷の高い処理
• ネットワーク通信またはリモート設定
• 大規模なデコード／解析
• メインスレッド上のブロッキングロック、セマフォ、ディスパッチグループ、または同期的な待機

測定によってそうでないと証明されるまでは、隠れた初期化を起動に不可欠な処理として扱ってください。

6. 対象を絞った変更を推奨する

起動経路を直接短縮または妨げの解消につなげる変更を優先してください。

• 不要な起動処理を取り除く
• 機能固有のサービスを遅延ロードする
• 表示される UI の後、または最初の操作の後まで、重要度の低い処理を延期する
• 起動に不可欠な状態とアプリの二次的な状態を分離する
• 起動時の依存関係を明示する
• 隠れた静的初期化を、明示的な初期化または遅延初期化に置き換える
• 安全かつ有効な場合にのみ、ブロッキング処理をメインスレッドから移す
• 依存関係、共有状態、分離性、障害時の動作を監査した後にのみ、上限のある並列処理を使う
• 証拠から main 前または dyld のコストが示された場合にのみ、リンク戦略を見直す
• 表示前にアプリケーション全体のグラフを初期化するのではなく、最初に利用可能な範囲を小さくする

小規模な変更で起動経路を安全に改善できる場合は、大規模な書き直しを推奨しないでください。

7. 検証を必須とする

推奨する変更にはすべて、検証手順を含めてください。

次を使用してください。

• フェーズ単位の診断には Instruments App Launch
• 起動経路の CPU 負荷が高い場合には Time Profiler
• main 前の処理が疑われる場合には dyld 関連ツールまたはログ
• アプリ固有の起動フェーズには os_signpost または同等のマーカー
• 再現可能なローカルまたは CI の回帰チェックには XCTest の起動メトリクス
• 本番環境の配布には MetricKit または Xcode Organizer

リリースに近いビルド、実機、安定したテストデータ、繰り返しの実行、およびサポート対象の古いハードウェアを優先してください。

価値の高い判断ルール

• 最初のフレームが表示されるまでのおよそ 400 ms は、積極的なユーザー体験の目標として扱い、ウォッチドッグのしきい値や、main 前だけに割り当てる時間として扱わないでください。
• デフォルトで dyld を原因と決めつけないでください。起動の遅さは、main 前の処理、アプリの初期化、起動のオーケストレーション、ルート UI の作成、最初のフレームのレンダリング、同期 I/O、起動直後のブロッキングによって生じることがあります。
• +load、コンストラクター関数、副作用のある静的初期化は、計測で問題がないと確認されるまでは、起動に不可欠な処理として扱ってください。
• load 時のフックに隠れた処理より、明示的なセットアップ、遅延初期化、またはスコープを限定した一度限りの初期化を優先してください。
• +initialize を万能の解決策として提示しないでください。一部のレガシーな Objective-C コードでは役立つ場合がありますが、モダンなコードでは通常、明示的な初期化や遅延初期化のほうが明確です。
• すべてのモジュールを静的リンクに変換することを推奨しないでください。起動コスト、ビルド時間、バイナリーサイズ、シンボルの重複、リソースのパッケージング、SDK の配布、デバッグ、マージ可能なライブラリーを考慮してください。
• フレームワーク数に恣意的な上限を設けないでください。動的フレームワークが増えると起動時の処理が増えることがありますが、実際のコストは計測する必要があります。
• 依存関係、共有状態、アクター分離、メインスレッド要件、失敗時の動作が明確になるまでは、起動手順を並列化しないでください。
• 並列化した起動処理を待つ間にメインスレッドをブロックしないでください。ただし、コードが安全で、処理時間に上限があり、起動を続ける前に完了が必要だと証明されている場合は除きます。
• ローカルのベンチマークが改善した場合でも、安全でない並列処理は正確性のリスクとして扱ってください。
• 個々の起動処理のうち最も大きなものだけでなく、必須の依存関係チェーンのうち最も長いものを最適化してください。
• メインキューに非同期で処理を登録すれば、最初のフレームの後に必ず実行されると考えないでください。
• SwiftUI の .task が常にレンダリング後に実行される、または影響がないと考えないでください。これはライフサイクルに結び付いた非同期処理であり、起動直後の応答性に影響することがあります。
• 起動パフォーマンスの評価に、Debug ビルド、シミュレーターのみでの実行、または新しいデバイス 1 台だけに頼らないでください。
• 本番環境の起動ヒストグラムだけで、ローカルのボトルネックを特定しないでください。優先順位付けと傾向の検証に使用してください。

コードレビューのチェックリスト

起動に関係するコードをレビューするときは、まず次の領域を確認してください。

main 前の処理とランタイムの初期化

+load、コンストラクター関数、C++ のグローバルコンストラクター、コストの高い Swift のグローバル変数／静的変数、先行実行されるランタイムフック、Objective-C カテゴリーを多く含むモジュール、起動時初期化処理を持つ動的フレームワークを探してください。

この領域が該当する場合は、references/pre-main-dyld-and-static-initializers.md を読んでください。

起動のオーケストレーションと依存関係グラフ

順序付けられた長い起動シーケンス、暗黙の依存関係、必須の順序を示す起動時のコメント、同期的に構築される依存関係コンテナー、安全でない並列処理、待機によるブロッキング、不明確な失敗時の動作、アプリケーショングラフ全体の準備完了を前提とする最初の画面のコードを探してください。

この領域が該当する場合は、references/launch-orchestration-and-dependency-graph.md を読んでください。

AppDelegate、SceneDelegate、最初のフレーム

同期的な依存関係のセットアップ、条件を問わない SDK の初期化、データベースのオープンや移行、キーチェーンへのアクセス、同期ネットワーキング、負荷の高いルートビューモデルの構築、アプリとシーンのセットアップの重複、コストの高い最初の画面のレンダリングを探してください。

この領域が該当する場合は、references/appdelegate-scenedelegate-and-first-frame.md を読んでください。

SwiftUI App の起動

App.init、ルートの Scene の構築、ルートビューの初期化、先行生成される監視対象モデルの作成、環境への値の注入、.task、.onAppear、scenePhase、@UIApplicationDelegateAdaptor に含まれる負荷の高い処理を探してください。

この領域が該当する場合は、references/swiftui-app-launch.md を読んでください。

サードパーティ SDK

起動時に開始するすべての SDK について、最初のフレームが表示される前、または最初の操作が行われる前に実行する必要がある理由を明確にしてください。

SDK を、起動に不可欠、最初の操作に必要、最初のフレーム表示後でも問題なし、機能固有で遅延実行、バックグラウンドのみ、に分類してください。

一律に遅延させることには注意してください。クラッシュレポート、セキュリティ、ディープリンク、アトリビューション、プッシュ通知のルーティング、リモート設定、機能フラグには、正確性に関する要件がある場合があります。

この領域が関係する場合は、references/third-party-sdks-at-launch.md を読んでください。

計測

計測値にばらつきがある場合は、以下を明確にしてください。

• デバイスのモデルと OS のバージョン
• Debug 構成か Release/Profile 構成か
• シミュレーターか実機か
• コールド／ウォーム／事前ウォームアップ済み／再開の分類
• 初回インストール、アップデート後の起動、または既存ユーザーの起動
• ネットワークとアカウントの状態
• アプリデータのサイズ
• 認証済みか未認証か
• テストの反復回数とばらつき

計測の設定や解釈が関係する場合は、references/metrics-instruments-xctest-metrickit.md を読んでください。

参照資料の使い分け

追加の詳細が必要な場合にのみ、参照ファイルを使用してください。

• コールド／ウォーム／事前ウォームアップ済み／再開という用語、最初のフレームの目標、初回インストール／アップデート後の起動分類、または計測の設定が関係する場合は、references/launch-taxonomy-and-targets.md を読んでください。
• dyld、pre-main、+load、+initialize、コンストラクター関数、Objective-C カテゴリー、ランタイム登録、または静的初期化が関係する場合は、references/pre-main-dyld-and-static-initializers.md を読んでください。
• 動的フレームワーク、静的ライブラリ、マージ可能なライブラリ、モジュール化、起動時のリンクに関するトレードオフ、バイナリのレイアウト、または order file が関係する場合は、references/linking-strategy.md を読んでください。
• 起動手順、クリティカルパスのモデリング、明示的な依存関係、安全な並列処理、競合／デッドロックのリスク、エラー処理、または最長チェーンの最適化が関係する場合は、references/launch-orchestration-and-dependency-graph.md を読んでください。
• UIApplicationDelegate、UISceneDelegate、依存関係の設定、ルート UI の作成、最初のフレームを表示できる状態、またはメインスレッドでの起動処理が関係する場合は、references/appdelegate-scenedelegate-and-first-frame.md を読んでください。
• SwiftUI の App、WindowGroup、ルートビューの設定、監視可能な状態、.task、.onAppear、scenePhase、@UIApplicationDelegateAdaptor、または環境の初期化が関係する場合は、references/swiftui-app-launch.md を読んでください。
• アナリティクス、クラッシュレポート、広告、アトリビューション、リモート設定、プッシュ通知、機能フラグ、セキュリティ SDK、またはベンダーの初期化戦略が関係する場合は、references/third-party-sdks-at-launch.md を読んでください。
• Instruments、Time Profiler、サインポスト、XCTest の起動メトリクス、MetricKit、Xcode Organizer、CI のベースライン、または本番環境のモニタリングが関係する場合は、references/metrics-instruments-xctest-metrickit.md を読んでください。

デフォルトですべての参照資料を読まないでください。

出力形式

コードのレビューや起動レポートの診断を行う場合は、以下のセクションを返してください。

起動の分類

問題がコールド起動、ウォーム起動、事前ウォームアップ済みの起動、初回インストール／アップデート後の起動、再開、または不明のいずれに該当するかを示してください。

計測に曖昧な点があれば記載してください。

推定されるフェーズ

最も可能性の高いフェーズを特定してください。

• pre-main
• 静的初期化
• アプリデリゲート
• シーンの設定
• SwiftUI ルートの設定
• 起動のオーケストレーション
• 最初のフレームのレンダリング
• 起動直後の応答性
• 計測／設定の問題

クリティカルパス

十分な情報がある場合は、必要な起動処理の連鎖を特定してください。

最適化を安全に行う妨げとなる、隠れた順序、暗黙の依存関係、不明な依存関係があれば記載してください。

調査結果

コード、アーキテクチャ、メトリクス、またはトレースで見つかった具体的なリスクを列挙してください。

証拠と結び付かない一般的なアドバイスは避けてください。

推奨される変更

推奨事項を優先度別にまとめてください。

1. 高い確度で起動パスを改善できる変更
2. 依存関係／オーケストレーションに関する変更
3. 必要な計測またはインストルメンテーション
4. 任意のアーキテクチャ上の整理

検証

変更をローカル環境および本番環境で検証する方法を説明します。

改善が期待されるメトリクス、トレース領域、または起動フェーズを含めます。

対象外

以下にはこのスキルを使用しないでください。

• 一般的なスクロールのパフォーマンス
• メモリリーク
• アプリの起動に関係しない描画の最適化
• 起動時以外のネットワークパフォーマンス
• 起動に関係しないアプリのアーキテクチャ全般のレビュー
• 起動、最初のフレーム、または初期の応答性に影響しない、一般的な SwiftUI のレビュー