快启动数据很好看，用户还是觉得慢：HarmonyOS 7 冷启动、温启动和可交互时间怎么分
监控显示启动只要 300ms，用户却说点开后要等两秒才能操作。继续压缩进程创建时间没有明显改善，因为团队测的是温启动首帧，用户等的是数据加载后的可交互状态。HarmonyOS 7 的快启动能力需要配套正确的测量口径，否则数字越漂亮，排查方向越偏。
验证范围：官方页面用于确认 HarmonyOS 7/API 26 的能力方向；文章代码只验证应用侧状态、预算或一致性模型。当前电脑是 API 24 SDK，且没有连接 HarmonyOS 7 真机，所以下面的断言不是 API 26 编译、设备性能或线上效果证明。
先给三种启动状态贴标签
分别在进程不存在、进程存活但页面销毁、页面仍在后台三种状态启动 30 次。记录点击、进程创建、首帧、关键数据可用和首次操作响应。若只取首帧，就会把空壳页面当成完成。
案例一：内容首页以首个可操作列表为终点
骨架屏出现不是完成。列表可滚动、首个条目可点击且错误状态已确定，才是用户真实可交互时间。
案例二：扫码或相机页以能力就绪为终点
预览框先显示但相机尚未可用，点击按钮会失败。终点应包含权限、会话和第一帧预览，而不是页面布局完成。
首帧和可交互不是同一个终点
冷启动、温启动和热启动的系统路径不同；首帧、内容就绪和可交互又是不同业务终点。混在一个平均值里，任何优化都可能被更快的样本稀释。
typeTrace={kind:'cold'|'warm'|'hot';firstFrame:number;interactive:number};functionpercentile(values:number[],p:number){consta=[...values].sort((x,y)=>x-y);returna[Math.ceil(a.length*p)-1];}constcold:Trace[]=[{kind:'cold',firstFrame:300,interactive:1200},{kind:'cold',firstFrame:340,interactive:1500}];if(percentile(cold.map(x=>x.interactive),.95)!==1500)thrownewError('P95 口径错误');这段模型用确定输入验证“按启动类型计算真正可交互终点的分位数”。它适合先发现边界错误，但不会冒充平台接口或设备性能测试。
如何选择优化终点
| 方案 | 适用范围 | 主要风险 |
|---|---|---|
| 只看首帧平均值 | 动画演示 | 掩盖空白或不可操作阶段 |
| 冷温热分组 | 常规性能治理 | 仍需业务终点 |
| 分组加可交互 P95 | 正式发布验收 | 埋点设计成本更高 |
发布验收采用冷温热分组，并为每个核心页面定义可交互终点；看 P50 了解常态，看 P95 抓长尾。首帧只作为中间阶段。
建立启动事件账本
封装统一启动追踪器，页面注册firstFrame/contentReady/interactive三类事件，并自动带上启动类型、网络和设备档位。
发布报告不能只放平均值
- 每条样本都有冷温热标签。
- 首帧后按钮不可用的时间被单独记录。
- 关键页面使用业务可交互终点。
- 报告同时展示 P50 与 P95。
- 对照实验的设备和数据条件一致。
快启动的目标不是让某个时间点变小，而是让用户更早完成第一件事。测量口径先对，性能优化才不会追错数字。
官方资料
- 2026 年 8 月开发者月刊：应用快启动
- HarmonyOS 7 新能力
- HarmonyOS 应用开发指南
