Perfowl · 2026-10-23 · Jitter 3/5 · 整体37/66 · 未通过指标验收
--- type: devlog kind: plan title: Jitter Display 原生 DVT 冷启动资格方案 date: 2026-10-23 status: approved stage: P4 evidence: E3 metric: ios.frame.pacing_jitter --- # Jitter Display 原生 DVT 冷启动资格方案 ## 当前判断 Jitter `ios.frame.pacing_jitter`正式为 **3/5**，整体 **37/66**。r4 固定 Metal 参考窗为6/7且阶段方向门失败，不计轮次；`referenceAccuracyValidated=false`、`referenceUnavailableConfirmed=false`、`formalFiveRoundsPassed=false`。不进入r5、下一指标或磁盘读取率。 先前设备级 Display `--all-processes` attempt-06 a01 收到真实record-start，但唯一 `devicectl --payload-url` 调用因远端连接超时失败。错误处理发送中断，Trace未在5秒停止门内自然结束，剩余Trace只有53,248 B / `RunIssues.storedata`，不能导出Display事件。该attempt没有新Fixture run、设备文件写入或Workbench Session。故障定位为投递/结束流程未完成；不能据此判定Display来源、设备或产品异常。 CoreDevice配对恢复attempt-07 a01仅 `manage pair` 返回成功；详情与App服务查询仍超时。另一方面，13份当前安装版本已接受的P95冷请求都绑定同一个、与签名包一致的源码摘要；独立审查也核验了请求/intent字节及旧请求树。原生pymobiledevice3 USB/DVT读通道可查询安装身份、稳定进程生命和设备时钟，`ProcessControl.launch` 是此包中受支持的原生App启动方法。由此采用冷请求队列与DVT启动，完全绕过失败的 `devicectl` URL调用。已接受历史请求仅是协议来源证据；本次只创建新的nonce、run和证据。 本资格测试不改产品代码、公式、质量门、Fixture或历史数据，不创建Perfowl Workbench Session，也不清除现存203张内存预览。它只判断Display Trace是否产生可用的逐帧候选事件，不能直接通过Jitter或参考精度门。 ## 独占attempt与执行步骤 使用新的私有根目录 `/Users/qiance/Perfowl-NewHost-Recovery/20261023-jitter-display-dvt-cold-start-08/` 和新run名 `jitter-displayqual-20261023-c01`。attempt文档、选择快照、脚本、日志、请求、Trace、Lab原件、保全与独立复核均写入此私有根目录，私有凭据与设备身份不进Git。 1. 在任何手机写入前执行新鲜只读守卫：核对已选设备与已安装Fixture身份、USB/Lockdown/DVT通道、进程生命、P95 run旧目录及所有文件SHA/字节/终态/workload释放、P95冷请求与gate目录SHA、导出集合、当前run前缀无冲突、Mac活动Session、实际枚举设备容量及宿主空间。保持全部旧证据和失败Trace。新鲜守卫或独立复核不通过即停止。 2. 验证Display-only模板的SHA及唯一仪器类型。通过DVT原生只读服务复核目标Fixture进程身份与生命；若它正在运行，只对该稳定自有进程发送一次SIGTERM并连续确认两次缺席，以建立冷启动条件；若本就缺席，则复核两次缺席。其他进程、身份漂移、复活或DVT断连均使attempt停止，不重试。 3. 从已签名Fixture包的 `FixtureLabBuild.json` 绑定当前版本与源码摘要，使用设备实时钟和新UUID nonce构造唯一冷请求：`recipe=p95-tail-v1`、`referenceEnabled=true`、`purpose=qualification`、`cancelAfterSeconds=35`、run名为 `jitter-displayqual-20261023-c01`。只写一次 `/Documents/PerfowlLabP95Requests/pending.json.part`，逐字节读回后原子重命名为 `pending.json`；确认队列仅新增该请求，不删除、覆盖或重放任何既有文件。 4. 启动唯一一条Display-only `xctrace record --all-processes --time-limit 40s`，先收到真实record-start通知，再用原生DVT ProcessControl对唯一已验证Fixture执行一次 `launch(..., kill_existing=false, start_suspended=false)`。不执行 `devicectl`、URL scheme或人工点屏。Fixture `onAppear`会消费P95冷请求；5秒准入窗内没有自动进入P95用例、请求未被唯一claim/intent或出现多run时，停止新动作并完整保全。 5. 让Trace自然运行至40秒自动结束，覆盖35秒资格负载和至少5秒收尾，不为请求失败主动中断录制。45秒observer仍监测xctrace及支持进程的总RSS和输出；只有硬资源门触发时才执行一次资源保护停止并将Trace标成partial。若45秒未干净结束，保留Trace原件、停止本attempt且不重录。 6. 用AFC只读取唯一新run的 `summary.json`、manifest、events、requests、presented、gate原件；确认工作负载已释放、设备回到idle、冷请求只被claim一次且原字节完全一致、没有遗留pending/part、旧run与请求SHA未变、只新增一个run。独立导出Trace目录表；必须有覆盖资格run的逐帧Display事件、可重算单调时钟、无歧义显示身份/唯一显示证明，才与 `presented.json` 按既有100µs端点界做连续唯一配对。 ## 停止门、资源与效率 - 仅一个旧进程正常退出（若需要）、一次冷请求写入/原子rename、一次DVT启动、一次40秒Trace、一次35秒Fixture run。无任何重试、第二nonce、第二run或Trace重录。请求过期、启动失败、连接错误、Trace异常结束、身份/容量/SHA漂移或新前缀冲突均保留已产生原件并终止。 - 手机可用空间两次均须满足 `max(10 GiB, 2 × 136,314,880 B)`，设备Data/Disk总容量一致；Mac同样不少于10GiB且至少为预计新增量两倍。运行前后记录设备真实可用空间、旧/新数据量及实际run清单。未满足即不写请求或启动Trace。 - 总时间预算：只读守卫最多45秒；单次设备连接/API操作8秒，受控等待按各自上限；冷请求有效期90秒，App自动准入5秒；Trace 40秒，observer绝对上限45秒。全流程目标小于3分钟（含封存与只读回收），超时即partial，不延长等待。 - 旧证据SHA核对时间为O(n)且一次流式读取；run与请求文件枚举按文件数O(n)；observer每200ms有界采样、最多225点，计算O(m×(p+f))，其中m≤225、p为被监测进程数、f为Trace文件项。CSV/XML导出按实际行流式解析，硬限120秒/192MiB。没有产品代码变化，不声称前后性能回归；记录Wall、CPU、RSS、输出、I/O，缺少可靠采样的字段保持unknown。 - Mac/设备数据仅新run和一份Trace，手机payload≤20KiB，Lab run payload≤2MiB，trace/probe目录<134,217,728 B，xctrace树峰RSS<805,306,368 B。达到任意硬门则保全并停止。 ## 结果解释与顺序门 仅当Trace自然封存、Display逐帧事件存在、时钟/身份可复核、与Fixture `presented.json`成功连续唯一配对且独立复核通过，才另立r4正式五轮方案。候选资格不计轮次，也不通过指标。 若这次DVT冷启动路径或Display候选失败，结论只覆盖本attempt的具体路径/字段，不能确认所有参考不可用或归因硬件/产品缺陷；将结果标为partial并按Owner已确定的无可比参考规则处理之前，须先确认确实没有其它可用参考来源。发送率待验保留原标记，不影响Jitter门禁。网站与Webhook缺口沿用先前partial授权；公证继续暂缓，仅内部测试。 ## Plan Amendment · 2026-10-23 · 冷请求仅在 Trace 开始后写入 为避免Trace启动失败时留下有效期内的 `pending.json`，执行顺序调整如下，并优先于上文第3、4步中的队列写入时点：Trace启动前只在主机准备请求模板、唯一nonce和输出路径；先启动Display Trace并等待真实record-start通知；随后读取设备实时钟，创建新的90秒内有效P95 envelope，单次写入/核读/原子重命名到手机，再以DVT启动Fixture。若Trace未启动，手机不写请求；若队列写入或DVT启动失败，不重试，并等待Trace自然结束。此修订不改变run名前缀、数据格式、预算、资格条件或无Workbench Session边界。 ## Validation Update · 2026-10-23 · c01 传输中断，不准入 私有 attempt-08 c01 收到 record-start 通知、完成一次冷请求写入/读回/原子重命名，DVT 返回一次启动结果并消费唯一 claim/intent。`xctrace` 最终返回 0，但其原始日志明确报告设备断连；资源观察持续 12.086811 秒，低于冻结的 40 秒窗口。系统日志同时记录 usage assertion 获取失败及 `kAMDNotConnectedError`。对已保存 Trace 导出的七类 Display 表查询共返回 0 个事件行，因此不能做时钟/身份/100µs唯一配对。Capture JSON 把 exit code 0 误标成自然结束；本条独立复核以原始日志、观察时长和导出表为准，结论为失败。 首次后验在 Fixture 尚未写完全部六个文件时提前退出。后续只读回读确认该唯一 run 最终完整封存，35.008158 秒后按预期以 `user-cancelled` 结束，`workloadReleased=true`、`idleRestored=true`、1499条record；旧 run、旧请求、旧gate均保持原SHA，请求队列无pending/part。该修复性回读不补齐已经中断的 Trace，不能使 c01 准入。正式轮次不变：Jitter 3/5、整体37/66；`referenceUnavailableConfirmed=false`、`referenceAccuracyValidated=false`，不进入r5或下一指标。 日志与当前打开的直连 DVT/AFC 服务在时间上重叠，提示可能存在设备服务占用冲突；这只是待证假设，不能归因硬件、Perfowl或手机断连。Lockdown/AFC 后续读回成功也不能排除短暂链路断开。详细原始日志、Trace、Fixture run和独立收据留在私有 attempt-08。 ## Plan Amendment · 2026-10-23 · c02 隔离 Instruments 与直连设备服务 建立全新私有 attempt-09 和 run `jitter-displayqual-20261023-c02`，不复用 c01 请求、Trace、run 或守卫。针对 c01 日志中的占用/未连接现象，下一次先在无直连 USB/Lockdown/DVT/AFC 会话的状态下启动 `xctrace`。修订步骤如下： 1. 新鲜只读守卫重新核对当前设备、安装包、进程生命、所有旧 run/请求/gate SHA、活动 Session、实际容量、宿主空间及 c02 前缀；独立复核通过后才可执行。先只读检查当前 Fixture 进程，但保持它运行。 2. 关闭守卫期间打开的所有直连服务并确认关闭，再启动唯一 Display-only 40 秒 Trace。若真实 record-start 未收到，立即停止本 attempt，不向手机发信号或写请求。 3. 收到 record-start 后才重连 Lockdown/DVT/AFC，复核设备、版本、进程生命、旧请求队列及实际容量；仅对相同且稳定的自有进程正常结束一次，连续两次确认缺席。随后写入唯一 c02 envelope，逐字节读回、一次原子重命名，由原生 DVT 启动 Fixture 一次；观察期内只允许一个 claim 和 intent。确认启动生命后关闭所有直连服务，让 Instruments 独占后续录制时间。 4. 对 c02 设置严格自然结束门：xctrace 退出码须为0，录制墙钟至少39.5秒，原始日志不得出现设备断连/`kAMDNotConnectedError`，资源观察不得触及硬门。exit code 0 本身不再等同自然完整。任一条件失败，Trace只记partial；不重试、不写第二请求。若Trace提前退出，等待已启动的唯一35秒Fixture run在最多45秒内终态封存，再进行只读后验，以避免读取半写文件，但该等待不补救Trace资格。 5. 后验必须按新鲜AFC读取确认恰好六个run文件、35秒取消终态、工作负载释放、idle恢复、请求唯一消费且无pending/part、旧目录完整manifest重算一致、容量及活动Session门通过。独立导出的Display表必须有覆盖资格run的逐帧事件及可配对时间/显示身份，否则候选仍不准入。 该调整只改变服务连接时序、录制完整性判定和半写run的有界封存等待；不改变P95配方、35秒负载、40秒目标录制、资源/容量门、无重试原则或正式五轮验收标准。占用冲突仍是待验证假设；即使c02失败，也只拒绝本次具体通道，不能自动确认所有参考不可用。 ## Validation Update · 2026-10-23 · c02 完整保全，Trace 未准入 **E4结果：c02不准入，Jitter仍3/5、整体37/66。** 新鲜只读守卫及21项离线预检复核通过；旧23个run/138文件共23,541,042 B、68个请求文件、32个gate文件与冻结c01基线一致。随后仅执行一次SIGTERM、一次新请求写入/原子rename和一次DVT启动，关闭所有直连服务后等待录制结束。Owner已授权自主清理测试数据；为释放Perfowl持有的DVT预热连接，在确认95个Session全终态后退出Perfowl，203张未保存内存预览随之清除，已保存Session/Raw不变。 xctrace退出码为0，但进程墙钟仅14.967967秒；TOC实际录制时长为**0.343416秒**、结束原因`Device disconnected`，原始日志有断连、usage assertion失败及`kAMDNotConnectedError`。录制观察器6.935520秒、峰RSS420,200,448 B、probe峰2,593,388 B，字节/RSS未超界但覆盖不足，资源门不能通过。Trace183文件/2,588,143 B保留；Display定向导出2,475 B，在1.612960秒内成功且导出峰RSS106,168,320 B。 首次离线复核确认源保全通过、资格失败。随后发现联合XML导出节点未必重复schema，补按TOC真实表序号独立校核：共两行，分别为`time-info`和`device-display-info`各1行；11类其它选定表均0行，**逐帧显示事件0**。时钟和显示元数据不能计作参考帧。原复核脚本/结果保留，追加校核不覆盖它们。原Capture字段`recordStartMonotonicSeconds`保存的是进程启动时刻，真实通知时刻没有独立收据；不得用该字段证明服务动作与最初连接错误的精确先后关系，服务占用根因仍未证实。 Trace结束后有界等待32.034483秒，唯一Fixture run以35.005945秒、1,502条record按预期取消，六件239,883 B完整封存，workload释放、idle恢复。后验与离线复核确认旧run/request/gate字节SHA均未变；仅新增该run，当前24个run/144文件共23,780,925 B、70个请求文件/36,266 B、33个gate文件，无pending/part，Mac活动Session0。手机实枚举Data/Disk总容量121,545,928,704/128,000,000,000 B，可用76,949,647,360 B；主机后验可用78,822,273,024 B，空间门通过。全手机文件系统写入保持unknown，不把受管数据写入计数外推为全设备写入。 后续只读诊断发现CoreDevice有线隧道connected，实际详情和App服务查询成功且绑定同一设备、当前Fixture安装；这只证明当前服务查询恢复。下一步按[恢复后无控制动作短录制方案](/devlog/p4-jitter-display-channel-smoke-plan-2026-10-23)建立新attempt，先验证无并行设备动作的2秒录制健康，不重放c02、不新建Fixture run。未确认所有参考不可用，不计正式轮次。批准方案原字节已按原SHA冻结于私有attempt-09，失败Trace、请求、Fixture原件及两份复核均保留；本批网站未发布，交付欠项继续partial。