起動レイテンシを改善する
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
起動レイテンシは、1 日のアクティブ ユーザー数を保持し、最初の操作からシームレスなユーザー エクスペリエンスを確保するための重要な指標です。これは、パフォーマンスとのトレードオフが考慮される可能性のある低 RAM 環境で特に当てはまります。ただし、アプリの起動を改善する前に、起動そのものに寄与する根本的な側面を理解することが重要です。
ベスト プラクティス
ベースライン プロファイルを一緒に配布する
ベースライン プロファイルで、含まれているコードパスの解釈とジャストインタイム(JIT)のコンパイル手順を回避することで、初回起動からコード実行速度が約 30% 向上します。アプリでベースライン プロファイルを配布することで、Android ランタイム(ART)は、事前(AOT)コンパイルによって含まれるコードパスを最適化し、すべての新規ユーザー、すべてのアプリ更新でパフォーマンスを向上できます。
積極的初期化を避ける
アプリの起動シーケンスで必要のない可能性のある積極的作業を回避します。アプリがプロセスを開始する可能性が最も高いシナリオは、アプリの起動によるものです。ただし、WorkManager、JobScheduler、BroadcastReceiver、バインドされたサービス、AndroidX スタートアップ ライブラリが、バックグラウンドでアプリプロセスを開始することもあります。可能であれば、Application
クラスで不必要に積極的に初期化することを回避します。多くのライブラリにはオンデマンドの初期化があるため、必要な場合にのみ呼び出すことができます。
UI スレッドからバックグラウンド スレッドへタスクを移動する
時間がかかり、メインスレッドをブロックしているタスクがある場合は、それらのタスクをバックグラウンド スレッドに移動するか、WorkManager を使用して効率を維持します。長い時間枠を占有するオペレーションや、想定以上に時間がかかるオペレーションを特定します。これらのタスクを最適化すると、起動のレイテンシを大幅に改善できます。
重大なディスク読み取りの競合を分析して修正する
StrictMode は、UI オペレーションが受信され、アニメーションが発生するアプリのメインスレッドでの誤ったディスクやネットワーク アクセスの使用を検出できるデベロッパー ツールです。ツールで改善の可能性がある領域を検出したら、アプリを自動的に終了するか、違反をログに記録して、後でさらに検査できます。
同期 IPC を避ける
Android のプロセス間通信(IPC)メカニズムであるバインダー呼び出しが原因で、アプリの実行が長時間一時停止することがよくあります。Android の最近のバージョンでは、これが UI スレッドの実行が停止する大きな原因になっています。バインダー呼び出しを行う関数の呼び出しを避けるのが一般的な対処です。避けられない場合は、値をキャッシュするか、作業をバックグラウンド スレッドに移動する必要があります。詳細については、スレッド スケジューリングの遅延をご覧ください。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[null,null,["最終更新日 2025-07-27 UTC。"],[],[],null,["# Improve startup latency\n\nStartup latency is an important metric to retain daily active users and ensure\na seamless user experience from the first interaction. This is especially true\nin low-RAM environments where performance tradeoffs might be considered.\nHowever, before beginning to improve app startup, it's important to understand\nthe underlying aspects that contribute to startup itself.\n\nBest practices\n--------------\n\n### Ship with a Baseline Profile\n\nBaseline Profiles improve code execution speed by around 30% from the first\nlaunch by avoiding interpretation and\n[just-in-time (JIT)](/about/versions/nougat/android-7.0#jit_aot) compilation\nsteps for included code paths. By shipping a Baseline Profile in an app,\n[Android Runtime (ART)](https://source.android.com/docs/core/runtime)\ncan optimize included code paths through Ahead of Time (AOT) compilation,\nproviding performance enhancements for every new user and on every app update.\n\n### Avoid eager initialization\n\nAvoid doing eager work that may not be necessary in your app's startup sequence.\nThe most likely scenario for your app starting a process is through the\nlaunching of the app. However,\n[WorkManager](/reference/androidx/work/WorkManager),\n[JobScheduler](/reference/android/app/job/JobScheduler),\n[BroadcastReceiver](/reference/android/content/BroadcastReceiver), bound\nservices, and the [AndroidX startup library](/topic/libraries/app-startup)\ncan also start app processes in the background. If possible, avoid unnecessarily\ninitializing anything eagerly in your `Application` class. A lot of libraries\noffer on-demand initialization, which lets you invoke them only when necessary.\n\n### Move tasks from UI thread to background thread\n\nIf there are tasks that are taking longer and blocking the main thread, move\nthem to a background thread or use WorkManager to ensure efficiency.\nIdentify operations that occupy large time frames or consume more time\nthan expected. Optimizing these tasks can help drastically improve startup\nlatency.\n\n### Analyze and fix severe disk read contention\n\n[StrictMode](/reference/android/os/StrictMode) is a developer tool that can\nhelp detect the use of accidental disk or network access on the app's main\nthread, where UI operations are received and animations take place. Once the\ntool detects a possible area of improvement, you can automatically terminate\nthe app or log the violation for further inspection at a later time.\n\n### Avoid synchronous IPCs\n\nOften long pauses in your app's execution are caused by binder calls,\nthe inter-process communication (IPC) mechanism on Android. On recent versions\nof Android, it's one of the most common reasons for the UI Thread to stop\nrunning. Generally, the fix is to avoid calling functions that make binder\ncalls; if it's unavoidable, you should cache the value, or move work to\nbackground threads. For more information, see\n[Thread scheduling delays](/topic/performance/vitals/render#thread_scheduling_delays)."]]