Skip to content

P2 Startup xctrace App Launch 增强通道阶段结果 ​

本页是 2026-09-07 的增量结果;此前已发布的 CoreProfile 实验数字与结论保持不变。

本批结论 ​

  1. Startup 深度主源从未知私有 CoreProfile 生命周期映射切换为 Apple 官方 xctrace App Launch。
  2. 冻结 life-cycle-period 的目标进程筛选、九阶段聚合和 App Launch Total 公式,算法为 xctrace-app-launch.v1。
  3. 产品链已接通:Mac 客户端先记录官方冷启动 trace,成功启动后 Collector Core 只做 passive attach,避免二次启动;xctrace 失败时缺值保持 missing。
  4. 设备 A 的 control / willFinish / didFinish 各 3 次全部通过;设备 B 的 control / willFinish 各 3 次通过,didFinish 在 1/3 后设备离线。
  5. 当前阶段状态为 implemented · partial:产品与单测完成,跨系统最后 2 个 didFinish 样本尚未关门。

完整指标定义、命令、公式和质量语义见 StartupTiming 权威页。

架构变更 ​

text
用户选择 StartupTiming
  → Collector Sidecar 调用 Apple xctrace App Launch
  → 本地 Session 保存 .trace / TOC / lifecycle XML / report / SHA-256
  → fail-closed parser 生成 App Launch Total + 九阶段
  → xctrace 已启动目标 App:pymobiledevice3 Collector passive attach
  → 常规 CPU / Memory / Network / FPS 等继续由唯一 DTX owner 采集

CoreProfile 仍用于 Frame Time 与逐帧流水线;它不再承担产品默认 Startup 九阶段。py-ios-device 仍只作历史 selector/schema 研究参考,不进入运行包。

实现范围 ​

层变更
Python Core新增官方 trace capture、TOC/lifecycle 导出重试、树哈希与匿名 capture wrapper
Parser校验单 run、App Launch 模板、iOS platform、launched process/exit;解析 XML id/ref 并拒绝悬空/循环/类型错
CLI新增 startup-xctrace-capture 产品子命令
Swift Core新增 xctrace capture client、官方 report 解码、Session 事件持久化和 passive attach 分支
Registry/UI十个深度 Startup metric 的 source/definitionVersion 切到 xctrace-app-launch.v1;添加指标说明改为 Xcode 条件能力
可靠性xctrace 录制完成与导出之间设置静默窗口;导出使用独立临时路径;空文件不计入样本

E4 因果矩阵 ​

单变量 Fixture 在 willFinish 或 didFinish 中加入 300 ms 延迟。通过规则:每组至少 3 个完整九阶段样本,且中位数增量相对 300 ms 的误差不超过 60 ms。

样本controlwillFinish +300 msdidFinish +300 ms状态
设备 A3/33/3;增量 301.583 ms;误差 1.583 ms3/3;增量 302.900 ms;误差 2.900 ms两组通过
设备 B3/33/3;增量 308.827 ms;误差 8.827 ms1/3;单轮增量 302.672 ms设备离线,尚缺 2 轮

所有计入样本均为九阶段完整的 candidate,典型 spanCount=14;多于九条是因为 System Interface、UIKit Scene Creation 等阶段允许出现多行,不是重复填值。

验证结果 ​

项目结果证据
Python185/185E2
Swift81/81E2
FixtureRelease/iphoneos arm64 无签名构建通过E2
Foundationcollector-foundation.1.9-beta x86_64 冻结包生成;289 个清单文件;SHA-256 63386725…f3E2
Mac App1.0.0 (28) x86_64 构建,包内 pmd3 11.3.1 / Foundation 1.9-beta,ad-hoc strict verify 通过E2
站点VitePress build 通过,0 报错、0 死链E2
xctrace Parser完整、缺阶段、模板/platform/exit、悬空引用、XML 损坏全部覆盖E2
产品结构官方 report 可在无 KDebug thread/debugID 字段时被 Swift 解码E2
设备 A两组 3×3 因果均通过E4
设备 Bcontrol/will 3×3 通过;did 1/3E4 partial

未关门门禁 ​

  1. 重新连接设备 B,补 didFinish 2 个九阶段完整样本并重新计算中位数门禁。
  2. 完整重跑 Python、Swift、Fixture build、Mac App 最终构建/签名与站点 build。
  3. 生成不含设备标识、设备名、Bundle ID、PID 的匿名 E4 汇总。
  4. 处理 AGENTS.md 中“docs/ 冻结只读”与“批次完成时写入 docs/ 归档 HTML”的冲突后,才能关闭归档联动门禁。

Update 2026-09-07 · 设备 B didFinish 补录与跨系统关门 ​

设备 B 重新连接并登录后,补录 didFinish +300 ms 两轮。新增两轮均为完整九阶段 candidate,spanCount=14:

补录didFinish 阶段值App Launch Total结果
设备 B · 第 2 轮302.965 ms495.538 ms完整
设备 B · 第 3 轮302.852 ms487.042 ms完整

设备 B didFinish 最终统计:

text
controlValuesMs = [0.339708, 0.408499, 0.298124]
delayedValuesMs = [303.011791, 302.965374, 302.851791]
controlMedianMs = 0.339708
delayedMedianMs = 302.965374
observedDeltaMs = 302.625666
delayErrorMs = 2.625666
toleranceMs = 60
passed = true

四个因果门禁现已全部通过:设备 A willFinish / didFinish 误差分别为 1.583 / 2.900 ms,设备 B 分别为 8.827 / 2.626 ms。跨 iOS 17 / 18 的 Startup 官方九阶段 3×3 因果门禁关闭,证据等级 E4。

匿名机器可读证据:下载 JSON。证据仅使用“设备 A / 设备 B”别名,不包含设备标识、设备名、Bundle ID 或 PID。

最终回归与交付产物:

项目最终结果证据
Python冻结 CPython 3.12 / pymobiledevice3 11.3.1 环境 185/185E2
Swift81/81E2
FixtureRelease / iphoneos arm64 无签名构建通过E2
Foundationcollector-foundation.1.9-beta x86_64;289 个清单文件;SHA-256 90aa973a…a2aadE2
Mac App1.0.0 (28) x86_64;包内 pmd3 11.3.1 / Foundation 1.9-beta;ad-hoc codesign --verify --deep --strict 通过E2
站点VitePress 生产构建通过,0 报错、0 死链;匿名 E4 JSON 已进入产物E2
真机iOS 17/18 共 18 个完整九阶段样本,4/4 因果审计通过E4

归档联动仍单独等待 AGENTS.md 内 docs/ 规则冲突的用户裁决;不影响上述代码、数值与 E4 因果结论。

Perfowl · Performance Observer