先把结论放在前面:启动优化不是"让Application.onCreate变快",而是让"用户点击图标到首屏可感知内容出现"这条链路上每一段都落在预算内。这条链路可以切成五段:进程创建、Application 初始化、首帧渲染、启动动画、首屏数据。任何一段超预算,整体都会慢;而整体慢的时间往往不是各段之和——动画阶段会掩盖前面的耗时,让"看起来"的耗时被拉长。
面试里这题属于"启动专题的总纲"。答得浅的是"Application里不要做耗时操作";答得深的是能说清五段各自的耗时来源与典型优化手段、Displayed与reportFullyDrawn的差异、启动动画与首屏的互相遮蔽,以及为什么"包体积与类加载数"会直接影响冷启动。
冷启动的五个阶段与预算
冷启动的定义要明确:进程不存在,需要 Zygote fork、Application 创建、首帧渲染、启动动画播放。热启动则是进程仍在,从后台切回,只需要重建 Activity 与重绘。
| 阶段 | 典型耗时(中端机) | 主要开销 | 优化方向 |
|---|---|---|---|
| 进程创建 | 200~400 ms | Zygote fork、类加载、内存初始化 | 减少 d |