TG咨询测启动耗时，先要说清楚“启动完成”指什么：应用进程创建、首帧出现，还是主要内容可用。安卓实例冷启动与热启动耗时的测量方法，关键在于统一起止点和运行条件，而不是只记一次秒数。
先区分冷启动、温启动和热启动
冷启动是应用进程尚不存在，需要创建进程并启动首个 Activity；温启动通常是进程仍在，但 Activity 需要重新创建；热启动则多为已有 Activity 从后台回到前台。不同工具和团队可能对“热启动”定义略有差异，测试报告应写明前置状态，避免把不同场景放在一起比较。
还要区分两个结束点：TTID（首帧显示时间）反映界面何时开始出现；TTFD（完全显示时间）反映主要内容完成绘制的时间。若应用调用 reportFullyDrawn()，可以将它作为完全显示的标记；否则应说明采用的替代判断标准。启动页很快出现，不代表内容已经可用。
用可重复的工具记录时间
优先采用 Macrobenchmark
AndroidX Macrobenchmark 提供冷、温、热启动模式，并可通过 StartupTimingMetric 记录启动指标。适合在实体设备上对比不同构建版本或代码改动。尽量使用接近发布状态的构建，按测试配置启用可分析能力；调试构建、断点和额外日志都可能改变耗时。
用 ADB 做快速核对
- 连接设备并确认目标包名：运行
adb shell pm list packages，从结果中找到应用包名。 - 测冷启动前执行
adb shell am force-stop 包名，再运行adb shell am start -W -n 包名/完整Activity名。记录输出中的启动时间字段，并保留命令、设备和构建信息。 - 需要热启动时，先打开应用、按 Home 让它进入后台，再从最近任务或固定的启动入口返回。重复操作前确认 Activity 确实还在任务栈中。
- 每类状态分别测约 10 至 20 次作为起步样本，报告中位数和高分位数；样本少时明确标注，避免把单次最快值当作结论。
am start -W 适合快速观察启动过程，但它的返回值不一定等同于用户看到完整内容的时间。需要定位首帧、卡顿和阶段耗时时，可结合 Perfetto 跟踪系统调度、进程启动及主线程活动。
控制变量，减少测量误差
- 固定设备与软件：记录手机型号、Android 版本、应用版本和构建类型；不同设备之间不要直接比较绝对耗时。
- 控制环境：保持电量、屏幕刷新率、网络状态和后台任务尽量一致。设备发热后可能降频，建议分批测试并留意温度变化。
- 确认启动状态：
force-stop会结束应用进程，但不会清除应用数据或缓存。因此它通常用于测进程冷启动，不等于首次安装后的首次运行。 - 固定交互路径：使用相同入口、账号状态和页面内容；若启动必须请求网络，分别记录网络依赖与离线表现，避免把服务器波动误算为本地启动成本。
- 谨慎处理动画：系统动画会影响肉眼感受，但不应只靠关闭动画来代表真实使用。基准测试条件与用户体验测试条件应分开记录。
一套可靠的安卓实例冷启动与热启动耗时的测量方法，应同时给出启动定义、指标、设备环境、重复次数和统计口径。比较版本时先看同一设备上的中位数变化，再检查高分位数是否恶化；若差异接近设备自身波动，就增加样本并用 Perfetto 找原因，不要只凭一次测试下结论。
常见问题
清除应用数据才算冷启动吗？
不一定。测进程冷启动通常结束进程即可；清除数据测试的是首次运行或数据重置场景，应单独命名。
只记录首帧够不够？
若关注界面出现速度，TTID 有用；若关注用户何时能看到主要内容，还应记录 TTFD 或说明内容就绪判据。
模拟器能用于最终结论吗？
模拟器适合开发阶段排查和重复验证。最终性能结论优先使用实体设备，因为模拟器的硬件、图形和调度条件可能与真机不同。