缩短启动延迟时间
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
启动延迟时间是一项重要指标,有助于保持日活跃用户数并确保用户在首次互动时就获得顺畅的用户体验。在可能考虑性能权衡的低 RAM 环境中,这一指标尤为重要。不过,在开始改进应用启动之前,请务必先了解对启动本身有影响的基础方面。
最佳实践
分发基准配置文件
基准配置文件可以略过所包含代码路径的解译和即时 (JIT) 编译步骤,从而使代码执行速度在首次启动时即可提高约 30%。通过在应用中分发基准配置文件,Android 运行时 (ART) 可通过预先 (AOT) 编译来优化包含的代码路径,从而针对每位新用户以及每项应用更新提升性能。
避免急于执行初始化
避免在应用的启动序列中执行不太必要的急切任务。应用启动一个进程时,最有可能的情景是通过启动应用来实现。不过,WorkManager、JobScheduler、BroadcastReceiver、绑定服务和 AndroidX 启动库也可以在后台启动应用进程。请尽可能避免在 Application
类中急于执行不必要的初始化任务。许多库都提供按需初始化,以便您仅在必要时调用它们。
将任务从界面线程移至后台线程
如果有耗时更长的任务阻塞主线程,请将其移至后台线程,或使用 WorkManager 来确保效率。找出占用大量时间或耗时比预期更长的操作。优化这些任务有助于大幅缩短启动延迟时间。
分析并解决严重的磁盘读取争用问题
StrictMode 是一种开发者工具,可帮助检测在接收界面操作或播放动画的应用主线程中意外使用磁盘或网络访问权限的情况。一旦该工具检测到可能需要改进的方面,就可以自动终止相应应用或记录违规行为,以便日后进行进一步检查。
避免同步 IPC
应用执行过程中的长时间停顿往往是由 binder 调用(Android 上的进程间通信 [IPC] 机制)引起的。在较新的 Android 版本中,这是导致界面线程停止运行的最常见原因之一。一般来说,解决方法是避免调用进行 binder 调用的函数;如果不可避免,则应该缓存相应值,或将工作转移到后台线程。如需了解详情,请参阅线程调度延迟。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[null,null,["最后更新时间 (UTC):2025-07-27。"],[],[],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)."]]