Foundation 01 · Non-invasive iOS Testing
无侵入底层能力已确认，下一步进入基座验证
本文件回答使用什么底层能力、每项能力能提供什么、哪些指标仍需真机证明。用户已确认 pymobiledevice3 主链与 xctrace 增强方向；Host、Session、云端与 UI 的新版设计见 Mac + Cloud 基座方案。
Decision first
底层能力选择
已确认：Perfowl 首版技术组合为 pymobiledevice3 主采集 + Apple xctrace 按需增强。
pymobiledevice3 负责设备、App/进程、DVT 实时指标、日志、Crash、截图和 iOS 17+ tunnel；xctrace 只在用户主动发起深度诊断时采集 Apple Trace。该组合不改包、不注入、不嵌 SDK。
前置门禁：pymobiledevice3 授权与交付形态审查。
pymobiledevice3 为 GPL-3.0。技术选型不能替代授权判断；Perfowl 若计划闭源商业分发，必须先明确独立进程调用、随包分发、修改后分发或库级集成的义务。审查未完成时暂停商业打包，不在产品中临时加入第二套运行时。
这是“选型收敛”，还不是“指标准确性验收”。
开源 API 和已有工程样本证明能力入口存在；CPU、内存、GPU、能耗、Network、Frame/Jank 的单位、归属与版本行为仍需 Gate F0 真机对照。验收前必须显示 Experimental/Unsupported，而不是把缺值写成 0。
Primary
pymobiledevice3 · 正式主采集
Deep
xctrace · 用户按需启用
1 Stack
不交付第二套运行时
算法参考
py-ios-device、Codesign4QC 用于核对字段处理、重绑、FPS/Jank 与采集生命周期，不直接作为产品真值。
明确排除
Extension、Probe、重签、注入、Hook、内嵌 SDK、越狱路径，以及默认运行 WDA/XCTest Runner。
Product boundary
Perfowl 对“无侵入”的定义
允许的系统侧操作
- 通过 USB 或受控网络连接设备，完成 Pairing/Trust。
- 启用 Developer Mode，挂载系统开发镜像，建立 RSD tunnel。
- 调用 iOS 开发服务读取设备、进程、性能、日志、Crash 与截图。
- 按需启动或终止目标 App；这是控制操作，不修改 App。
- 用户主动开启 Apple xctrace 深度诊断并保留原始
.trace。
不进入本产品主路径
- 修改源码、重签、重打包、dylib/Framework 注入。
- Hook、Swizzle、内存修改、嵌入性能 SDK 或 Probe。
- Root/Jailbreak 和依赖越狱服务的指标。
- 把 WDA/XCTest Runner 作为默认性能测试依赖；其额外进程需另立“自动化伴随模式”评估。
- 通过截图轮询伪装逐帧真值，或用宿主机网络流量冒充 App HTTP 事务。
边界说明：无侵入不等于零开销。Sysmontap、Graphics、日志、截图、Core Profile 与 xctrace 都会占用设备或 Host 资源，必须分别测量并显示开销等级。
Foundation stack
底层能力总表
| 底层/项目 | 在 Perfowl 中的定位 | 主要能力 | 默认状态 | 当前证据 |
|---|---|---|---|---|
| pymobiledevice3 | 正式主采集运行时 | Lockdown、RSD、DVT、App/进程、日志、Crash、截图、诊断 | 主链 | GPL-3.0；技术方向已确认，待 F0 与授权交付审查 |
| Apple xctrace | 按需深度诊断 | Time Profiler、Animation Hitches、Allocations、Game Performance、Trace 导出 | 可选 | Apple 工具 + 本机冒烟；待真机 Trace fixture |
| go-ios | 历史调研对照，不进入正式产品路线 | 单二进制、设备/tunnel、App/进程、FPS、Network、日志与 Crash | 研究归档 | MIT；当前没有对主性能链不可替代的增量指标，不随产品内置，也不进入 F0 |
| py-ios-device | 算法/协议参考 | FPS/Jank、Network、Thermal、Lifecycle、Core Profile、GPU Counter 示例 | 研究 | 开源实现；公式与原始事件需复核 |
| 历史 DTX 项目 | 协议考古 | JMInstrument、dtxmsg、ios_instruments_client 等用于理解消息和旧版本行为 | 参考 | 不承担正式运行时 |
| Probe / Extension | 本轮排除 | 可提供 App 内逐帧与业务语义，但需要改包或嵌入 | 排除 | 违反当前无侵入定义 |
为什么只选一个主运行时：设备生命周期、tunnel、DTX 会话、时间戳、错误语义和版本兼容必须由同一条链路统一管理。首版同时正式维护 Python 与 Go 双栈，会增加差异而不会增加指标真值。
Official deep diagnosis
xctrace 是什么，能提供什么
xctrace 是 Apple 官方工具。
它随完整 Xcode 提供，是 Instruments 的命令行入口，不是第三方 DVT 封装，也不是 iPhone 内的常驻服务。当前本机
xcrun xctrace version 返回 16.0 (17F113)；帮助页提供 record、import、export、remodel、symbolicate、list 等命令。| 能力 | 能回答的问题 | 输出/使用方式 | 边界 |
|---|---|---|---|
| Time Profiler | CPU 时间主要消耗在哪些线程、函数和调用栈 | 按时间采样调用栈；生成 .trace，有符号时可定位到函数/源码 | 缺少 dSYM 时符号不完整；是采样分析，不是业务实时指标流 |
| Animation Hitches / Hangs | 主线程提交、渲染、GPU、Frame Lifetime 哪个环节造成卡顿或无响应 | Apple 的 Hitch/Hang 时间线与关联事件 | 模板、设备和系统版本存在兼容差异；开销高于基础监控 |
| Game Performance | 游戏/Metal 场景的线程调度、系统调用、虚拟内存、Display、GPU、Metal 资源与热状态 | 多 Instrument 组合 Trace，可选性能计数器 | Counter 是否可用取决于设备、模板和权限；不是每台设备都有同样字段 |
| Allocations / Leaks | 内存在哪里分配、哪些对象仍存活、是否存在泄漏线索 | 分配记录、调用栈、对象/类别聚合 | 数据量和开销较高；不能代替 General 模式的低频内存趋势 |
| Energy Log / System Trace | 能耗活动、线程调度、系统阻塞与 I/O 等深层背景 | Apple 模板产生的 Trace | 具体模板随 Xcode/平台变化；相对活动不等于物理电流真值 |
| 录制控制 | 对哪个设备和目标、采集多长时间 | --device、--attach、--launch、--all-processes、--time-limit、--window | 连接、开发者模式、目标权限和 Xcode 环境必须满足条件 |
| Trace 后处理 | 如何保留真值、抽取结构化数据和补符号 | export --toc、XPath XML、HAR、symbolicate、remodel | 不同 Xcode 的 Trace Schema 会变化，解析器必须按版本维护 |
对 Perfowl 的价值：pymobiledevice3 告诉我们“什么时候 CPU/FPS/内存异常”，xctrace 帮助回答“异常时哪个线程、调用栈、渲染阶段或系统事件造成问题”。它是深挖原因的证据工具，而不是持续画实时曲线的主底座。
Combination contract
xctrace 与 pymobiledevice3 如何结合
1 · Generalpymobiledevice3 持续采集 CPU、Memory、FPS/GPU、Network 与状态
2 · Trigger用户或规则标记异常区间，保存 target、device、PID generation 与 Host 时间
3 · DeepPerfowl Host 单独调用 xctrace，按模板 attach/record，基础采集降频或暂停
4 · Artifact原始
.trace 不可变保存；导出 TOC/XML，并记录 Xcode/模板版本5 · Correlate通过统一时钟、设备、Bundle ID、PID generation 和 Marker 关联两条证据链
正确的结合方式
- 由 Perfowl Host 编排两个独立工具，不把 xctrace 嵌进 pymobiledevice3。
- pymobiledevice3 负责发现设备和目标状态；Host 将目标设备与 PID/进程名传给 xctrace。
- xctrace 使用 Xcode/CoreDevice 自己的连接路径；不复用 pymobiledevice3 的进程内 userspace RSD 地址。
- Session 只保存共同身份和时间映射，原始 DVT 数据与
.trace分开保存。
需要 F0 证明的冲突
- 两者同时连接 Instruments/DVT 服务时是否互斥、断流或改变采样频率。
- xctrace 开启后对 CPU、FPS、GPU 和 Host 资源的额外影响。
- PID 重启、冷启动 attach 时机和 xctrace 启动延迟。
- 不同 Xcode/iOS 下模板名、Schema、XPath 和符号化行为。
首版默认策略
General 模式保持低开销连续观察；进入 Deep 模式时，暂停非必要 DVT 通道或降到 Lite，仅保留会话心跳、目标生命周期和 Marker。只有 F0 证明并发无冲突且开销可接受后，才开放完整并行采集。
App Store boundary
xctrace 对商店 App 的无侵入能力边界
结论：可以无修改地观察部分系统侧信息，但不能承诺完整附加和深度分析任意商店 App。
从 App Store 安装的 App 是生产分发构建，通常不含允许调试附加的
get-task-allow，测试方也通常没有匹配 dSYM。xctrace 的 --attach / --all-processes 表明工具具备附加或系统范围录制形式，但 Apple 文档没有给出“任意第三方商店 App 的所有 Instrument 均可用”的保证。| 能力层级 | 商店 App 预期 | 典型限制 | Perfowl 承诺 |
|---|---|---|---|
| 进程存在与系统侧统计 | 可能通过系统范围录制识别进程并获得部分 CPU、线程、调度、Display/GPU 等数据 | 字段是否可按目标进程归属取决于 Instrument、设备与系统版本 | 实验性 必须逐模板真机验证 |
| 直接 Attach | 对生产签名进程可能被系统拒绝 | 缺少 get-task-allow 或对应调试权限；不能通过改包来规避，因为产品定义为无侵入 | 不保证 |
| Time Profiler 调用栈 | 即使获得采样，也可能只看到系统符号、地址或有限的 App 帧 | 没有商店构建对应 dSYM，无法完整映射自有函数和源码 | 有限诊断 |
| Allocations / Leaks / SwiftUI 等进程内 Instrument | 通常依赖更深的目标进程访问，商店 App 更容易不可用或为空 | 生产签名、调试权限、运行时支持和 Instrument 自身要求 | 不纳入商店包承诺 |
| Animation Hitches / Game Performance | 系统级轨道可能有数据，目标 App 的详细栈、Marker 和进程内语义可能缺失 | 模板由多个 Instrument 组成，部分可用不代表整个模板完整 | 按 Track 判定质量 |
商店包可以保持无侵入
- App 仍由 App Store 正常安装和启动。
- 不重签、不解密、不修改 Bundle、不注入 Framework/SDK。
- xctrace 只从 Mac 侧请求 Apple 开发服务录制。
- 失败时报告权限或能力不支持，不改变目标 App。
完整深度分析需要什么
- 开发者自己可调试的 Release/Profile 构建。
- 与目标二进制 UUID 匹配的 dSYM。
- 允许 Instruments 附加的签名与设备环境。
- 固定 Xcode/iOS/设备/模板组合的可复现实验。
产品路线：如果 Perfowl 的承诺是“测试任意已安装商店 App”，General 主链应依靠经 F0 验证的 DVT 进程/系统指标；xctrace 仅作为能力探测后的增强项。如果测试对象是团队自有 App，则提示用户提供 Profile/Release 测试构建和 dSYM，才进入完整 Deep 模式。
Runtime comparison
pymobiledevice3 与 go-ios 的差别
| 维度 | pymobiledevice3 | go-ios | 对 Perfowl 的判断 |
|---|---|---|---|
| 实现/集成 | 纯 Python；CLI + 公开 asyncio API；服务类可直接组合 | Go；CLI + Go module；官方设计强调 JSON 输出 | 快速验证、解析动态 payload：Python 更灵活；稳定独立 Sidecar：Go 更简洁 |
| 分发 | 需要封装 Python 运行时与依赖，并验证 arm64/x86_64、签名和离线运行 | 目标是静态、小型、跨平台单二进制 | go-ios 在安装、升级、冷启动和故障面上有先天工程优势，但资源占用需实测 |
| 开源授权 | GPL-3.0 | MIT | 闭源商业交付场景下 go-ios 风险更低；pymobiledevice3 必须先过授权审查 |
| iOS 17+ tunnel | 当前文档：macOS 优先无管理员权限 native remoted；其他环境可进程内 userspace；17.0–17.3.1 例外 | 当前 README：需要以管理员权限运行 ios tunnel start 守护进程 | 当前 macOS 用户体验 pymobiledevice3 更好；必须按目标系统版本实测 |
| DVT 性能表面 | 显式覆盖 Sysmontap、Graphics、Network、Energy、ActivityTrace、CoreProfile、Screenshot 等；Sysmontap 动态发现全量属性 | 仓库显式覆盖 Sysmontap、Graphics/FPS、Network、Notifications、DeviceInfo、ProcessControl、Screenshot 等 | pymobiledevice3 对性能产品所需的深度与动态字段更完整 |
| 当前 Sysmontap 封装 | 异步迭代原始行，动态获取进程/系统属性，包含 CPU/physFootprint 配置 | 当前公开接收结构主要映射 System CPU total；虽然请求动态属性和 physFootprint，产品所需进程字段仍要扩展/验证 | 这是 pymobiledevice3 作为正式主采集的关键能力基础 |
| FPS | Graphics 流及更多 GPU 候选字段 | 实现了 CoreAnimationFramesPerSecond 流 | 两者都只能先承诺 FPS 趋势；目标归属、GPU 字段和 Jank 均需 F0 |
| 自动化能力 | 设备服务、WebInspector、进程控制等范围广 | XCTest/WDA、Accessibility、设备条件、网络模拟等 CLI 更突出 | go-ios 对未来“自动化伴随模式”有优势，但 WDA/XCTest 不进入默认无侵入性能模式 |
| 运行时可控性 | 可直接保留 raw Python 对象和快速适配 Apple 动态字段 | 强类型 Go 结构、goroutine/channel，编译期约束更强 | 探索期 pymobiledevice3 更快；字段稳定后 go-ios 更利于长期 Sidecar 工程化 |
| 共同风险 | 两者都不是 Apple 官方性能 API，核心 DVT/DTX/RemoteXPC 行为会随 iOS/Xcode 漂移。 | 必须 Adapter 隔离、保存 raw fixture、建立版本矩阵；不能把开源库输出直接视为产品真值 | |
No runtime fallback
修正决策：go-ios 不作为产品运行时备选
用户判断成立：没有不可替代的功能补充，就没有必要增加第二套产品运行时。
在 Perfowl 当前“无侵入性能测试”范围内，go-ios 的 Sysmontap、FPS、Network、进程、日志和 Crash 与 pymobiledevice3 主能力重叠；而 pymobiledevice3 还显式覆盖 Energy、ActivityTrace、CoreProfile 等入口。因此 go-ios 不应被描述成运行时补充或故障自动回退。
不构成功能补充
- Sysmontap、FPS、Network、Notifications、进程、截图、日志和 Crash 均与 pymobiledevice3 重叠。
- XCTest/WDA、Accessibility、设备条件和网络模拟属于自动化/环境控制，不属于当前默认无侵入性能主链。
- 单二进制、MIT、JSON 和 Go 并发模型是工程/授权优势，不是新增测试指标。
- 交叉验证只服务调研，不足以证明应该把第二个运行时交付给用户。
当前最终定位
- 只保留仓库链接与已有对比结论，作为历史研究证据。
- 不进入 Gate F0，不做同场主候选竞赛。
- 不进入 App 包体、安装流程、自动回退或 Session Schema。
- pymobiledevice3 出现授权、分发或兼容阻断时，先暂停对应交付并重新形成独立决策。
执行规则
只验证和交付 pymobiledevice3；不打包 go-ios、不设计运行时自动切换、不维护双 Schema，也不把它作为 F0 备用实现。
Capability A
设备连接与开发服务
| 底层能力 | 直接提供 | Perfowl 可形成的功能 | 限制/处理 |
|---|---|---|---|
| usbmux + Lockdown | USB 设备发现、Pairing、设备值、经典服务通道 | 设备上线/离线、信任状态、UDID/型号/iOS 信息、连接诊断 | 信任未完成、设备锁定、线缆抖动必须分别报状态 |
| RemoteXPC / RSD tunnel | iOS 17+ Developer/DVT 服务入口 | 为 Sysmontap、Graphics、Network 等建立可控会话 | 17.0–17.3.1 与 17.4+ 路径不同；tunnel 生命周期属于 Session |
| DDI / MobileImageMounter | 开发镜像查询、挂载与状态 | 准备设备、检测服务可用性、给出明确缺失原因 | DDI 版本/Personalized Image 行为随系统变化，不能假定一次挂载永久有效 |
| Capability snapshot | 服务是否可打开、动态属性与系统版本 | 会话开始前列出 supported / experimental / unsupported | 以运行时探测为准，不只按 iOS 大版本硬编码 |
当前版本路径
iOS 16 及更早的开发服务走传统 Lockdown/usbmux 路径；iOS 17+ 的 DVT 需要 tunnel-backed provider。pymobiledevice3 当前文档说明：macOS 优先复用 Apple
remoted 的无管理员权限路径；iOS 17.0–17.3.1 默认仍需要 tunneld；17.4+ USB 可使用无管理员权限路径。进程内 userspace tunnel 地址不能交给其他进程使用。Capability B
App、进程与目标身份
| 底层能力 | 可提供功能 | 产品使用 | 必须守住的边界 |
|---|---|---|---|
| InstallationProxy | 已安装 App、Bundle ID、版本和元数据 | 目标 App 选择、版本快照 | 返回字段因 App 类型/系统而异，缺字段保留 unknown |
| DVT ApplicationListing | 应用与可执行信息 | 将 Bundle ID、可执行名和进程候选关联 | 不单独依赖显示名称或模糊进程名 |
| DeviceInfo / OsTrace process list | 运行进程、PID、路径等候选信息 | 绑定目标 PID、检测启动/退出/重启 | PID 是瞬时身份，复用后不能接续旧累计量 |
| ProcessControl | 启动、终止与观察进程 | 可选的“冷启动采集”与受控结束 | 操作必须显式；启动失败不伪装成采集失败 |
| PID generation | 由 Perfowl 派生的身份代次 | App 每次重启生成新 generation，隔离 CPU/IO/Network 累计值 | 这是产品语义，不是系统原生字段 |
Capability C
Sysmontap：CPU、内存与系统统计
| 指标族 | 可读取的原始/候选字段 | 首版可提供 | 口径边界 |
|---|---|---|---|
| App CPU | 进程 CPU usage 与相关样本字段 | 目标进程 CPU 趋势、均值、峰值、时间窗统计 | 原值可能是多核口径；首样本可能缺前一窗口；归一化规则待 F0 |
| System CPU | 系统 CPU 快照、load 等候选字段 | 整机负载背景，辅助解释 App 峰值 | 与 App CPU 分开展示，不能互相替代 |
| Memory | physFootprint、resident、virtual、compressed 等动态字段 | 目标进程内存趋势、增量、峰值与告警候选 | 首要显示口径先定 physFootprint 候选；字段/单位需逐设备协商 |
| 线程/唤醒 | thread count、wakeups、context switch 候选 | 高 CPU 辅助诊断与变化趋势 | 仅在字段存在且含义确认后展示 |
| 磁盘 IO | read/write 累计量候选 | 按真实采样间隔差分出的吞吐趋势 | 进程重启、计数回绕、缺样本都要切段 |
| Power score | 系统提供的相对评分候选 | 同设备同场景的相对趋势 | 不是瓦特、电流或物理能耗，不以物理单位命名 |
字段策略：先保存动态属性列表和原始值，再做版本化映射。任意字段缺失都输出 unsupported 或 missing，不写入数值 0。
Capability D
Graphics：FPS 与 GPU 趋势
| 能力 | 可以提供 | 现阶段不作的承诺 | 开销 |
|---|---|---|---|
| FPS | 秒级/窗口级 FPS 趋势、均值、低值区间、Marker 对齐 | 不等于逐帧 FrameTime；不直接推导 PerfDog 同名 Jank/BigJank | 待测 |
| GPU utilization | Device/Renderer/Tiler 等系统渲染利用率候选趋势 | 未证实为目标 App 独占；原值单位/缩放未通过 F0 前标 Experimental | 待测 |
| Frame experience | 先保留 FPS 异常区间，关联截图、日志和后续 Trace | 无逐帧事件源与可复现公式前，不发布 FrameTime、Jank、BigJank、1% Low 真值 | 后置 |
关键判断
“有 FPS 曲线”只证明 Graphics 流可读，不证明目标 App FPS 归属、动态刷新率适配或卡顿算法准确。F0 必须覆盖 60/120Hz、前后台切换和人工卡顿场景。
Capability E
NetworkMonitor：连接与流量
| 可提供 | 可形成的产品能力 | 边界 | 状态 |
|---|---|---|---|
| 接口与连接发现、PID、connection serial | 按目标 PID 关联连接生命周期 | PID 重绑与连接关闭必须切段 | F0 |
| Local/Remote 地址、协议候选 | 连接清单、远端聚合、时间线 | 地址不等于域名/业务接口 | F0 |
| 收发包/字节累计量 | 上下行流量与速率趋势 | 按实际时间差分；处理重置、丢样和系统代发流量 | F0 |
| RTT、重传等候选字段 | 弱网与网络异常辅助指标 | 字段可用性和覆盖协议待设备验证 | 实验 |
NetworkMonitor 是连接/流级能力，不自动等同 HTTP 事务分析。HTTPS 请求 URL、状态码、DNS 分阶段耗时等若没有独立、无侵入且可证明的数据源，不进入首版承诺。
Capability F
Energy、Thermal 与设备诊断
| 底层 | 可提供 | 产品用途 | 限制 |
|---|---|---|---|
| DVT EnergyMonitor | Energy Impact/相对能耗候选数据 | 同设备、同系统、同场景的相对比较 | 无物理单位证明前不显示 mA、mW 或 Wh |
| Diagnostics / IORegistry | 电池、热状态、设备诊断候选字段 | 会话环境快照、热降频背景、异常说明 | 字段权限与系统版本可变；不保证连续采样 |
| Condition/thermal controls | 部分工具可设置设备条件 | 未来可控实验 | 改变设备状态，不属于默认“观察”路径；本轮不启用 |
Capability G
截图、日志与 Crash 证据
| 底层能力 | 可提供 | Perfowl 功能 | 证据边界/开销 |
|---|---|---|---|
| DVT Screenshot | 当前屏幕单帧图像 | Marker 手动截图、峰值触发截图、低频定时截图 | 有采集开销；默认不高频轮询；不当作视频/逐帧数据 |
| OsTraceService | syslog/os_log、PID/进程信息 | 按目标过滤日志，和性能时间线关联 | 设备日志时钟需映射；缺日志不等于无异常 |
| CrashReportsManager | Crash 列表、拉取、watch | 会话终止后拉取报告，关联 PID generation 与测试区间 | Crash/IPS 才能证明终止类型；普通 lifecycle 日志不单独确认崩溃原因 |
| ActivityTraceTap | 活动跟踪事件候选 | 未来增强时间线证据 | 事件语义与开销未验证，首版默认关闭 |
Capability H
Core Profile 与 xctrace 深度诊断
| 能力 | 可回答的问题 | 交付物 | 默认策略 |
|---|---|---|---|
| CoreProfileSessionTap | CPU 栈、线程状态等底层事件候选 | 原始事件 + 版本化解析结果 | 研究模式 高开销，先做 fixture |
| xctrace Time Profiler | CPU 热点在哪个线程/调用栈 | .trace、TOC、结构化导出 | 按需 依赖 Xcode 与符号 |
| Animation Hitches / Game Performance | 卡顿、渲染与游戏性能深层原因 | Apple Trace + 可解释摘要 | 按需 先固定版本 Schema |
| Allocations | 分配趋势、存活对象与内存增长线索 | Apple Trace + 导出 | 按需 不替代 Sysmontap 实时内存 |
| GPU Counter 候选 | 更细 GPU 工作负载 | 设备/模板支持时的实验结果 | 研究 兼容和含义先验证 |
xctrace 的稳定事实是“可录制 Trace 并导出”，不是“提供跨 Xcode 版本稳定的实时 JSON”。因此它只做按需诊断链，不承担 General 实时主链。
Commitment matrix
首版能力承诺分级
| 等级 | 能力 | 进入条件 | 失败行为 |
|---|---|---|---|
| 默认基础 | 设备发现/信任、设备信息、App/进程、PID generation、会话生命周期 | 支持矩阵内稳定通过 F0 | 阻止开始并给出具体状态，不创建伪会话 |
| 默认指标候选 | App/System CPU、physFootprint 候选、FPS、GPU、基础 Network | 口径/单位/归属/开销全部过 F0 | 显示 Experimental 或 Unsupported，不补 0 |
| 可选证据 | 截图、syslog、Crash、Energy/Diagnostics | 独立开销与时钟关联验证 | 增强通道失败不终止基础采集 |
| 按需深度 | xctrace、Core Profile、Hitches、Allocations、GPU Counter | 固定 Xcode/iOS fixture 与解析版本 | 保留原始 Trace，暂停不可信的结构化解读 |
| 暂不承诺 | 逐帧 FrameTime、Jank/BigJank、1% Low、App HTTP 事务、物理能耗 | 找到无侵入原始数据源并与真值对照 | 不使用近似值冒充同名指标 |
Gate F0
底层能力验收清单
- 连接矩阵
在首版目标 macOS、Mac 芯片、iOS 16、17.0–17.3.1、17.4+、18+、USB/Wi‑Fi 组合上记录发现、Pairing、DDI、RSD 建链时间、失败状态和重连。
- 正式主链单栈验收
验证 pymobiledevice3 的字段完整度、时间戳、断连、App 重启、并发通道和 60 分钟 Host/Device 开销。go-ios 不进入本轮实验，任何失败都按 capability、route、版本或交付门禁归因。
- CPU/内存/GPU/FPS 真值
用可控 App 制造空闲、CPU 峰值、内存增长、动画和人工卡顿；同场保存 DVT raw、Instruments/Xcode Gauge 与 PerfDog 样本，确定单位、归属和 UI 名称。
- 累计量与重绑
覆盖首样本、丢样、时钟跳变、计数回绕、目标 App 退出/重启和 PID 复用，验证每个 generation 的速率差分不会跨段。
- Network 与 Energy 边界
分别构造上传、下载、短连接、长连接、前后台与热状态场景；确认字段覆盖范围，无法证明的物理单位与 HTTP 语义保持关闭。
- 开销分层
比较不采集、Sysmontap、+Graphics、+Network、+日志、+截图、Core Profile、各 xctrace 模板；每层多轮记录设备和 Host 影响。
- 深度 Trace fixture
固定 Time Profiler、Animation Hitches、Game Performance、Allocations 的
.trace、TOC、导出命令、Xcode/iOS/设备/符号状态与已知事件时间。 - 分发可行性
验证 pymobiledevice3 sidecar 在 arm64/x86_64、干净用户目录、源码目录移走、离线启动、签名/哈希与可诊断版本信息下可运行。
- 授权与交付形态
明确 Perfowl 是否闭源/商业分发、pymobiledevice3 是否随包分发/修改/库级集成/独立进程调用，并完成 GPL-3.0 方案审查。审查结果必须先于 App/DMG 正式交付。
- 商店 App 能力矩阵
选取自有商店版与对应可调试测试版，在同一设备上分别验证 Time Profiler、Animation Hitches、Game Performance、Allocations 的 attach、系统轨道、App 轨道、符号、错误信息与开销；任何模板不得以“启动成功”代替数据完整性证明。
F0 通过条件
主运行时无阻断性缺口；默认能力在支持矩阵内可重复；每项指标都有 source、raw unit、canonical unit、归属、采样方法、开销等级和 unsupported 行为；所有失败均可解释且不伪造数据。
已建立可执行的 《Perfowl Gate F0 真机能力与指标校准计划 v1》，将本清单落到设备矩阵、F0-00 至 F0-12 实验、误差门槛、证据产物和 Pass/Stop 条件。
Next decision
底层确认后的下一步
底层方向、新版架构和 F0 执行已于 2026-09-01 由用户批准。
A 批次静态门禁结论为 Conditional Pass；B 批次 iOS 16 USB 只读冒烟已达 E2，F0-01/F0-02 均为 Partial。下一步完善并安装 Fixture，补齐动态 Route/PID generation 重绑。完成全部 F0 后再申请 M0 产品工程骨架开发；原《产品成熟方案 v1》仍为已暂停历史草案。
当前仍只新增和修订文档。没有新增采集器、桌面端、Sidecar、数据库、后端、Web 或产品构建产物，也没有连接真机。
Sources
依据与证据等级
- pymobiledevice3 · DVT API — DvtProvider、ProcessControl、DeviceInfo、ApplicationListing、Screenshot、Sysmontap、NetworkMonitor、EnergyMonitor、Graphics、ActivityTraceTap 与 CoreProfileSessionTap 的当前入口。
- pymobiledevice3 · iOS 17+ tunnels — RemoteXPC/RSD、macOS native tunnel、userspace tunnel 与 17.0–17.3.1 边界。
- pymobiledevice3 · Python API — Lockdown/RSD 选择、异步服务模型、OsTrace、InstallationProxy、Diagnostics、Crash 与 ImageMounter。
- go-ios — 单二进制/JSON 设计、iOS 17+ tunnel、App/进程、FPS、Network、日志、Crash 等对照能力。
- go-ios · Instruments implementations — DeviceInfo、Graphics/FPS、Network、Notifications、Sysmontap、ProcessControl 与 Screenshot 当前实现面。
- go-ios · Sysmontap source — 当前动态属性配置、physFootprint 请求与公开 CPU 接收结构。
- pymobiledevice3 · Sysmontap source — 动态发现系统/进程属性、异步原始样本和 physFootprint 配置。
- py-ios-device — iOS 性能指标和 DVT/Core Profile 算法参考；不直接视作指标真值。
- Apple · Xcode command-line tool reference、Improving app responsiveness、Metal app performance 与 Apple Instruments 专项调研 — xctrace、Animation Hitches、Game Performance 与本机命令证据。
- Apple · Enabling Developer Mode、Diagnosing a running app 与 Apple Developer Forums · attach permission explanation — Developer Mode、运行中进程附加及生产软件调试权限边界。商店 App 模板可用性仍以 F0 真机结果为准。
- pymobiledevice3 LICENSE 与 go-ios LICENSE — GPL-3.0 与 MIT 的授权差异；具体产品义务仍需按交付形态审查。
- Codesign4QC 性能采集专项分析 — 约 1 Hz DVT、iOS 17+ tunnel、重绑、质量与落盘的本地工程证据。
证据说明：官方/开源文档与源码属于静态能力证据；本地项目记录属于已有工程证据；本轮没有新增真机运行证据。所有“待 F0”项均未被表述为已准确。