Android cold‑starts(冷启动)

Android cold‑starts(冷启动)

1. 严格定义

Cold‑start:系统中不存在该App进程,系统从零新建进程,完整启动App
触发场景只有两种:

  1. 手机开机后第一次点开App
  2. App进程被系统回收、被后台清理杀掉后,再次打开(后台无残留进程)。
    对比另外两种启动模式:
模式前提核心区别耗时
Cold‑start(冷启动)App进程不存在新建进程 + 初始化Application + 重建Activity最长(性能基准指标)
Warm‑start(温启动)进程存活、Activity被销毁只重建Activity,不用新建进程中等
Hot‑start(热启动)进程、Activity都还在内存仅执行onResume()切到前台最短

2. 冷启动完整时序(从点击桌面图标 → 首屏可交互)

分为系统阶段+App应用阶段

① 系统侧流程

  1. 接收桌面点击事件,通过IPC调用Process.start()
  2. Zygote进程fork出新的App进程
  3. 系统先弹出空白白屏窗口(Preview Window),防止黑屏等待

② App进程内主线程完整链路(主线程串行执行,任何阻塞都会拉长冷启动时间)

  1. 创建ApplicationattachBaseContext()Application.onCreate()(性能重灾区,绝大多数SDK在这里初始化)
  2. 实例化ActivityThread(App入口main函数)
  3. 启动主ActivityonCreateonStartonResume
  4. inflate加载XML布局、测量‑布局‑绘制(measure‑layout‑draw)
  5. 首帧渲染完成(TTID,Time‑To‑Initial‑Display,官方冷启动耗时终点),系统替换掉空白窗口,页面正式展示给用户。

下面是一个简化的冷启动流程示意图:

App进程内主线程链路

系统侧流程

接收点击事件,Process.start()

Zygote fork出新进程

弹出空白白屏窗口

用户点击桌面图标

创建Application
(attachBaseContext, onCreate)

实例化ActivityThread

启动主Activity
(onCreate, onStart, onResume)

inflate布局
(measure-layout-draw)

首帧渲染完成(TTID)
替换白屏,页面展示

首屏可交互

3. 核心衡量指标

  1. TTID(Time to Initial Display):首帧画面显示,Android官方标准冷启动耗时,日志关键字Displayed可抓取耗时。
  2. TTFD(Time‑to‑Full‑Display):首页所有数据、视图完全渲染完毕,业务侧埋点指标。

4. 冷启动最常见瓶颈(90%问题集中在这里)

  1. Application.onCreate()主线程串行初始化大量第三方SDK(推送、埋点、IM、地图、统计、日志),同步IO、数据库、SP读写、网络请求、静态代码块耗时阻塞主线程。
  2. 首页布局层级太深、过度嵌套,布局inflate耗时久。
  3. 启动阶段创建大量临时对象,频繁GC造成主线程卡顿。
  4. WebView、大图在主线程提前初始化。

5. 核心优化思路(开发标准方案)

  1. Application瘦身(优先级最高)
    将初始化任务划分三类:
  • Must‑Sync:必须主线程同步初始化(崩溃监控、路由框架)
  • Can‑Delay:子线程/IdleHandler延迟初始化(埋点、推送),等主线程空闲再执行
  • Lazy‑Load:按需懒加载(地图、支付、音视频SDK,用到再初始化)
  1. 布局优化:用ConstraintLayout减少层级、ViewStub懒加载非必须视图。
  2. 消除白屏:自定义Launch主题,替换默认空白窗口。
  3. 高级优化:App‑Startup库、基准配置文件(Profile)、Dex预优化、将WebView放到独立进程、异步预加载非核心资源。

6. 调试工具

  1. Perfetto / Systrace:可视化整条冷启动链路,定位主线程耗时函数。
  2. adb命令直接抓取冷启动耗时:
adb shell am start‑W 包名/主Activity路径

输出的TotalTime就是TTID冷启动耗时。

我可以再帮你把这套内容压缩成面试版极简话术,你要不要?