startup-timing-demo

1. 实验目标

用最小 Android 实现验证冷启动打点（对应 docs/07-performance-testing-debug/04、07）：

• attachBaseContext / onCreate / onWindowFocusChanged / reportFullyDrawn 四个关键时间点
• 计算"进程启动 → 首帧可交互 / 首屏绘制完成"的近似耗时
• 结合 adb shell am start -W 测量冷 / 温 / 热启动对比

2. 工程要点

• companion object 静态变量记录时间锚点，避免进程内多次 Activity 创建互相污染
• reportFullyDrawn()：官方"内容绘制完成"上报点，供 APM / FrameMetrics 采集
• onWindowFocusChanged(hasFocus=true) 近似"首帧可交互"（TTFD 客户端近似）

3. 运行方式

cd labs/android/host
./gradlew installDebug

设备/模拟器打开 Android Host → 打开启动耗时实验室（页面会显示各打点相对进程启动的毫秒数）。

adb 精确测量：

# 冷启动（先 force-stop）
adb shell am force-stop com.shayn.engineeringreviewlab.androidhost
adb shell am start -W -n com.shayn.engineeringreviewlab.androidhost/.MainActivity
# 输出里 TotalTime / WaitTime 即系统口径的启动耗时

4. 预期现象

• 页面显示三行日志：attachBaseContext +Xms / onCreate +Xms / onWindowFocusChanged +Xms / reportFullyDrawn +Xms
• am start -W 输出 TotalTime（本次启动总耗时）与 WaitTime（含系统调度）

5. 常见误区

误区	实际情况
首帧 = 启动完成	首帧只是"画出来了"，首屏内容真正可用要等数据加载（FullyDrawn 更接近用户感知）
冷 / 温 / 热启动耗时一样	冷启动（进程重建）最慢；温启动（Activity 重建）次之；热启动（后台复用）最快
只在 onCreate 里打点就够	要区分"进程创建"（Application/attachBaseContext）与"Activity 创建"，否则漏掉 Application 初始化耗时

6. 对应知识库文档

• 理论主文档：应用启动性能优化实战（拓扑排序、异步初始化与首帧治理）
• 进程启动全流程：Android App 进程启动全流程 (Zygote → ActivityThread → 首帧)

7. 关键源码

• StartupTimingDemoActivity.kt