外观
iOS 启动采集技术路线与开源生态研究
本文属于研究与技术选型资料，不作为 Perfowl StartupTiming 的指标合同。它记录在“不修改目标 App”的前提下，iOS 启动分析可以采用哪些路线、各自能看到什么，以及本项目多轮实验后保留的工程结论。
1. 启动分析常见技术路线
| 路线 | 典型能力 | 侵入性 / 权限 | 适用场景 |
|---|---|---|---|
| 设备级 DVT / kdebug tap | dyld、UIKit lifecycle、首帧等系统级事件 | 无需修改目标包；依赖系统开发者服务可达性 | 黑盒单次启动与阶段分析 |
| Instruments / xctrace App Launch | 官方生命周期、Time Profiler、Thread State | 能力与目标签名、launch/profile 授权和系统版本有关 | 自有开发包深度诊断 |
| StartSuspended + debugger | 在目标真正运行前准备采集 | 需要 task/debug 权限；生产包通常不可用 | Debug / 自签开发包 |
| MetricKit | 真实用户聚合 launch / resume / first draw | 需要 App 集成并等待系统报告 | 线上长期统计 |
| 业务埋点 / signpost | 任意业务启动阶段 | 需要源码接入 | 自研 App 的业务可用性指标 |
| UI 自动化 / 录屏视觉 | 贴近肉眼可见结果 | 外部观测，精度受脚本/帧率影响 | 端到端体验补充 |
这些路线没有“绝对最好”。选择取决于目标是：单次黑盒、线上聚合、代码级根因，还是业务真正可用时间。
2. 为什么 Perfowl 选择 CoreProfile / kdebug 做当前深度 Startup
Perfowl 的目标边界是：
text
App Store / Release 目标
+ 不改包
+ 不注入 SDK
+ 单次测试立即得到结果
+ 尽量保留 Pre-main → First Frame 的系统阶段在当前已验证实现中，CoreProfile kdebug 能同时提供：
- dyld / libSystem 早期事件；
- UIKit lifecycle signpost；
- Initial Frame 端点；
- 同一 mach time domain 下的时间戳。
因此它是 Perfowl 当前九阶段可观测模型的主数据源。这个结论描述的是本项目已验证的实现选择，不宣称 iOS 上不存在其他未公开或未来新增的数据接口。
3. Instruments 与生产 App 的边界
Apple Instruments 是研发自有 App 做代码级 launch 分析的首选工具之一，可提供 App Life Cycle、Time Profiler 和 Thread State 等丰富证据。
但在本项目实测的部分 xctrace --launch / App Launch 路径中，生产签名 App 会遇到 task/debug 授权限制；StartSuspended 也需要 get-task-allow。因此 Perfowl 没有把“先挂起生产 App、等采集完全 ready 再 resume”作为生产架构前提。
这并不意味着 Instruments “不能分析任何生产 App”；不同模板、连接方式和系统版本的授权边界需要分别验证，知识库不做超出实验证据的绝对化表述。
4. MetricKit：适合真实用户分布，不等同单次黑盒 trace
Apple MetricKit 提供 launch / first draw / optimized first draw / resume / extended launch 等指标，适合观察线上用户的分布和趋势。
它与 Perfowl 的定位不同：
| MetricKit | Perfowl StartupTiming |
|---|---|
| App 内集成 | 目标 App 无需集成 |
| 系统聚合报告 | 单次测试立即产生 Session |
| 真实用户分布 | 受控测试环境回归 |
| First Draw / Resume 等系统指标 | CoreProfile Total + 可观测阶段诊断 |
两者适合互补，不应该强行要求逐毫秒一一对齐。
5. 开源项目能提供什么
pymobiledevice3、py-ios-device、tidevice、sonic-ios-bridge 等项目对 iOS 设备连接、DVT、进程与性能服务做了不同程度的封装。评估时应重点看：
- 是否支持目标 iOS 版本的连接路线；
- 是否只是封装 DVT transport，还是已经定义可靠的业务 metric contract；
- 是否处理目标 PID / generation 归因；
- 是否定义 missing / drop / reconnect 等质量语义；
- 是否保留 Raw 证据供离线复算；
- 是否把底层源值直接展示成了未经验证的“标准指标”。
Perfowl 可以复用经过审计的开源 transport / parser，但指标语义、质量合同与产品结论仍需要独立验证。
6. 本项目已经关闭的 Startup 补齐研究路线
围绕“单次启动偶发缺阶段”已验证：
- System Trace 不是独立于 kdebug 的同轮冗余；
os_trace_relay能看到大量统一日志，但没有九阶段 UIKit 启动 signpost；- 主机 Ready / receive-parse 优化无法恢复设备侧根本不存在的事件；
- 盲目枚举 CoreProfile action / buffer 不能形成可靠补齐方案；
- 跨轮拼接违反数据真实性；
- 生产包 StartSuspended 不满足无侵入权限边界。
因此当前产品策略不是“强行保证每轮 9/9”，而是：
text
Total endpoint truth
+ 真实阶段可观测值
+ coverage disclosure
+ endpoint repair provenance
+ device-loss evidence详细证据见启动观测与数据完整性。
7. 选型建议
- 自有开发包、需要函数级根因：优先 Instruments / Time Profiler / Thread State；
- 线上真实用户长期趋势：MetricKit；
- 生产包、单次、无侵入回归：Perfowl 当前 StartupTiming 路线；
- 业务真正可用时间：自有 App 最好补充业务 signpost / XCTest extended launch / 自研埋点；
- 基础设备自动化和通用信息读取：可按团队栈评估 tidevice、pymobiledevice3、sonic 等基础设施。
工具选择应以证据需求为中心，而不是用一个工具覆盖所有问题。