外观
Build48 启动时间与采集曲线恢复
结论
Build48 修复了两个独立回归：性能曲线不再被未验证的可见性/等值门控清空，并且在启动首尾端点完整时恢复 App Launch Total candidate。内部九阶段仍独立 fail-closed：未验证映射不猜测，缺失不补 0，整体 trace 仍可以是 partial。
设备 A / 目标 App A 三轮命令级真机采集均得到 24 个非空性能样本，App Launch Total 为 1895.326 ms、1863.244 ms 和 2023.438 ms，三轮 CoreProfile bridge 均无覆盖/丢包。这证明采集数据和启动首尾端点已进入产品数据链；由于原生 UI 自动化表面未提供可用 App 窗口，曲线的像素级可见性仍单独记为开放门禁。
根因与修复
- CoreProfile 可能以 binary plist 返回 kperf 锁冲突；旧路径把它当作非空 metadata，误报 readiness。现在对不超过 64 KiB 的 plist 做有界识别，立即失败并向客户端显示“启动分析数据源正被另一项采集占用”。
- 旧 v3 把“任一必需内部阶段缺失”扩大为“Total 必须清空”。v4 分离 Total endpoint gate 与 phase coverage gate；Total 仍只使用 System Interface BEGIN 到与 Initial Frame BEGIN 配对的 END 的 Mach tick 差。
- 实时 CoreProfile 消费路径不再重复全量排序生命周期记录；最终回放只保留归因记录和生命周期 class，且仅在报告时排序一次。
- 图表保留 60 秒有界窗口、200 ms 显示合并和 8192 事件上限；固定图表高度 156 点，移除错误的离屏/等值抑制。
效率对比
在同一份 165 MiB、2,585,115 条真机原始记录上，启动回放从 32.32 s / 1.77 GB 峰值 RSS 降到 4.09 s / 497 MB：耗时降低 87.3%，RSS 降低 72.0%。复杂度从终端 marker 反复全量重建收敛为 ingest O(N) + 保留记录单次 O(K log K) 排序，内存 O(K)。
真机上设备 stop 后仍连续返回大块数据，2 s 有界 drain 三轮均为 timeout。对照把最大等待恢复到 6 s 后仍未静默，post-stop chunk 增至 46，解码记录增至 16.3M，launch finalizer 增至 19.7 s；因此保留后续低延迟批次的 2 s 上限，并如实标记 Session partial。点击停止到 capture_stopped 确认三轮均小于 0.1 ms，不被后续 drain/finalization 阻塞。
验收
| 项目 | 结果 | 证据 |
|---|---|---|
| Python | 300/300 | E2 |
| Swift | 130 项，127 通过 / 3 项显式基准跳过 | E2 |
| 真机性能样本 | 3/3 每轮 24 个非空样本 | E4 命令级 |
| 启动 Total | 3/3 candidate；必需阶段覆盖 1/3；完整 trace 0/3 | E4 partial |
| CoreProfile bridge | 3/3 ring overwrite 0 / live drop 0 | E4 |
| 有界 drain | 0/3 达到静默，均明确 timeout | E4 partial |
| 原生 UI | 应用进程可启动，自动化表面无 App 窗口 | E3，像素验收开放 |
| Build48 | x86_64、Developer ID + hardened runtime、严格验签/独立解包通过；SHA-256 a66727893f3a1cdc122e20638fda1f21327f52138909dc930c93b29fe4ee710d | E2 |
| Gatekeeper/公证 | 未配置 notarytool profile，无 stapled ticket | blocked |
下一阶段与整体进度
Build48 已形成内部测试包，本次“无启动时间/曲线消失”的代码修复和命令级真机数据链已完成。下一阶段是关闭三项独立门禁：原生 UI 长时滚动/停止/Review 可见性，CoreProfile stop 后无穷 chunk 的协议边界，以及完整报告小于 2 s。对外发布仍另受公证/stapling 和 GPL-3.0 法务结论门禁约束。