外观
P2 Startup CoreProfile Sampling Trigger v1 方案
已确认事实
- 冻结的 py-ios-device 2.4.25 App Lifecycle 示例对
coreprofilesessiontap的同一次setConfig:调用发送两个 DTX auxiliary:第一项是bm/rp/tc主 trace 配置,第二项是tsf/ta/si/tk/uuidsampling trigger。 - 冻结的 pymobiledevice3 11.3.1
DTXChannel.invoke(method, *args)与DTXService.invoke(method, *args)已原生支持同 selector 多参数;每个参数独立进入 DTX auxiliary 列表。因此无需引入第二 DTX socket,也无需让 py-ios-device 成为运行时 transport owner。 - iOS 17 九轮与 iOS 18 修正前基线均证明:普通 control marker 可落入 CoreProfile 窗口,但 300ms 单变量延迟存在高概率
outside-core-window。单独切换bufferMode=0没有消除该问题。
实现边界
保持 pymobiledevice3 为唯一 DTX owner,并继续复用其
CoreProfileSessionTap解码与消息队列。仅在 Startup trace 开启时,通过同一 service/channel 调用:
textsetConfig:(mainTraceConfig, samplingTriggerConfig)sampling trigger 固定为冻结上游证据中的结构:
texttsf = [65537] ta = [[0], [2], [1, 1, 0]] si = 5,000,000 ns tk = 1 uuid = per-session random UUID配置事实写入每条 CoreProfile raw payload:
samplingTriggerEnabled、samplingIntervalNs、samplingTriggerVersion;随机 UUID 不进入公开证据。非 Startup CoreProfile、普通 FPS/FrameTime 路径不增加该 trigger。
编码、ack 或源协议异常时 fail closed,启动指标保持
null/—,不回退到推断值。
公式与质量门禁
业务耗时公式保持 StartupTiming v9 不变。本批新增的是源配置同质性门禁:
text
samplingTriggerCompatible =
allSessions.samplingTriggerEnabled == true
AND allSessions.samplingIntervalNs == 5_000_000
AND allSessions.samplingTriggerVersion == "py-ios-device-app-lifecycle.2.4.25"
fixtureEvidencePassed = samplingTriggerCompatible
AND clockBridgePassed
AND delayErrorMs <= toleranceMs启用和未启用 sampling trigger 的 Session 只做修正前后对照,不混合计算 control/delayed median。
验收顺序
- E1:证明 pymobiledevice3 多 auxiliary 编码保持参数顺序,且 Startup 才发送第二配置。
- E2:Python 针对性测试覆盖单 owner、双 auxiliary、raw 配置事实和关闭路径。
- E4:iOS 17、iOS 18 分别执行 control、willFinish 300ms、didFinish 300ms 短 Session。
- 只有两种系统的 marker 均在窗口内、identity verified、drop=0 后,才重跑 3×3 因果批次。
- 若 trigger 仍不能覆盖完整 marker,保持 mapping candidate,不提升正式 decoder;下一修正优先检查 stop/drain,而不是缩短 Fixture 延迟来规避门禁。
回滚
关闭 samplingTriggerEnabled 即恢复单 auxiliary 主 trace 配置;历史 raw Session 通过配置字段可区分,不回写旧证据。