Skip to content

iOS 15+ Collector Foundation 兼容矩阵 ​

判定方式 ​

每个系统版本都按同一套 9 Gate 验收:设备发现、User App 枚举、PNG 截图、版本正确的 Provider 路线、目标身份闭环、六个实时 Adapter、至少 3 个有序 sample、raw 质量、停止与五层收口。实际设备完整执行才是 E4;兼容通过不等于与 PerfDog 数值一致。

Foundation 2.6 Beta 矩阵 ​

iOS family请求路线连接实现当前匿名证据结论
15.xlegacy-usbusbmux-lockdown路由 Fixture E2;本批未提供设备not-tested
16.xlegacy-usbusbmux-lockdown9/9 Gate;4 sample / 224 raw;identity 100%;unknown/drop 0validated · E4
17.0–17.3usb优先 macOS native remoted,独立 tunneld 为回退9/9 Gate;6 sample / 273 raw;identity 100%;unknown/drop 0;73 个 User App;有效 PNGvalidated · E4
17.4–17.xusbmux同上路由 Fixture E2;本批没有该小版本设备not-tested
18.xusbmux优先 macOS native remoted,独立 tunneld 为回退9/9 Gate;6 sample / 266 raw;identity 100%;unknown/drop 0;38 个 User App;有效 PNGvalidated · E4
26.xusbmuxnative remoted 优先,userspace/tunneld 为现有回退iOS 26.5 已完成设备发现、39 个 User App、有效截图、单 Provider 与基础服务入场;目标启动失败且设备随后离线,指标 Session 未建立E2 candidate · E4 partial
27.xusbmuxnative remoted 优先,userspace/tunneld 为现有回退平台合同、路由参数、63/63 source contract 与 Startup candidate Profile 通过离线门禁E2 candidate

连接质量语义 ​

  • iOS 17+ 先复用 macOS remoted 的原生隧道,不触发第二次用户配对;原生路径不可达时才进入独立 tunneld 回退。
  • tunnelManagerPort=null 在 iOS 17+ 明确表示 native remoted,不表示缺失;Collector Core 收到 --native 并持有隧道 assertion 到 Session 关闭。
  • 设备级 sideband 与 kernel trace 没有目标 PID 是预期语义;身份覆盖只统计需要目标归因的事件。
  • 缺失值保持 missing ,拒绝配对记录 blocked,不外推成系统不兼容。

当前校准状态 ​

连接、User App、截图、实时六 Adapter、停止与交付哈希在 iOS 16、17.0 和 18.2 三个实际设备版本达到 E4。iOS 26.5 已取得连接、User App、截图、modern Provider 与基础服务入场 E4,但目标启动失败后设备离线,9 类源、63 项当前 Registry 数值与停止链均未验证;iOS 27 仍只有 E2。两者都不继承 iOS 18 的 E4 结论。iOS 15、iOS 17.4–17.x、iOS 26/27 完整真机、机型规模、长时稳定性与 PerfDog 同窗校准仍开放。

iOS 15.x 逐指标确认 · 2026-11-04 ​

设备 B(iOS 15.3.1,60 Hz,iPhone 11),内部包 259/260,目标为 PerformanceProbeFixture(iOS 15 版)。连接走 legacy-usb / usbmux-lockdown,调试组件由 Xcode 挂载。详见 分版本能力确认记录。

指标组结论证据
CPU、内存、线程、上下文切换、中断唤醒、磁盘、网络、GPU 利用率、电池温度、能耗(总 / CPU / GPU / 网络 / 定位)有值,口径与其他版本相同E4(两轮会话,>94% 样本有值)
启动 9 个阶段有值,阶段覆盖完整E4(CoreProfile)
帧耗时、FPS、P95、Jitter、实时卡顿曲线有值(需内部包 260 及以后)E4
卡顿 4 项用 iOS 15 专用规则 perfowl-hitch.ios15.candidate.v1(需内部包 261 及以后),见 卡顿时间比校准 E4 原始数据 + E3 离线判定
刷新率、GPU Counter、热状态、启动 observed_running / foreground_ready无值,原因待查E4(缺值)
电池电流 / 电压 / 功率外接电源时不出数,不是故障E4

iOS 15 的 ActivityTrace:两个坑 ​

  1. 行解析中断
    • 表现:订阅 activitytracetap 后只收到 1–2 条消息,随后整条流结束,帧类指标全空,采集统计 totalMessageCount=0。
    • 原因:pymobiledevice3 11.3.1 的 _handle_end_row 用 struct.unpack("<I") 读取 process、thread,只取 4 字节;iOS 15 有一部分行的这两个字段是 6 字节,于是抛出 unpack requires a buffer of 4 bytes,迭代器随之终止。
    • 处理:Perfowl 不改上游代码,只在行构建器的私有 globals 里换一个 struct,遇到长于 4 字节的值时整体按小端读取。
    • 判断方法:12 秒探测,修复前收到 0–2 条,修复后约 2,800 条,其中 FrameLifetime 约 57/s(60 Hz)。
  2. FrameLifetime 字段不同
    • iOS 15 的格式串是 begin_time / frame_seed / refresh_interval / buffer_count / end_time / prev_frame / skip_request,没有 display_id 与 surface_id。Perfowl 按主屏 0 处理,与 iOS 26 FrameUpdate 的约定相同。
    • iOS 15 没有渲染开始时刻,卡顿只能给出时长,不能区分提交阶段与渲染阶段。

iOS 15 帧数据的形态 ​

  • FrameLifetime 是整屏合成帧。静止时屏幕仍以 20 Hz 合成(每帧间隔 50 ms,帧种子每次 +2),所以“没有新帧”很少出现。
  • App 主线程卡住时,屏幕不会停在原帧,而是落回同样的 20 Hz 节奏,单看一帧与静止无法区分。GPU 跑满时,屏幕可以十几秒完全不合成。
  • FrameLifetime 与 Core Animation 提交事件用的是同一时钟(signpost 时间)。App 用 mach_absolute_time 记录的时间与它相差设备累计休眠时长(推测,设备 B 上约 8,233 s),对齐时要用帧节奏的特征,不能直接相减。

版本历史 ​

  • v17(2026-11-04):新增 iOS 15.x 逐指标确认(设备 B,iOS 15.3.1),包括 ActivityTrace 行解析与字段差异的修复、iOS 15 帧数据的形态,以及卡顿改用 commit 规则。来源:分版本能力确认记录。

  • v16(2026-09-08):追加 iOS 26.5 首轮 E4 入场证据;连接与基础服务通过,目标拉起/指标 Session 未通过,状态保持 partial。来源:iOS 26 E4 首轮。

  • v15(2026-09-08):Foundation 2.6 Beta 新增 iOS 26/27 独立 E2 candidate 平台合同;明确不继承 iOS 18 E4。来源:iOS 26/27 E2 结果。

  • v14(2026-09-08):迁移为唯一 Canonical 页面;历史 v2~v13 由 Git/devlog/archive 承接,连接与指标结论不变。

  • v13(2026-09-05):新增 iOS 17.0、iOS 18.2 匿名 9 Gate E4;冻结 native remoted 优先、tunneld 回退语义。来源:CORE-18。

  • v12(2026-09-05):新增 9 Gate 工具与 iOS 16 E4,已被本页取代。

Perfowl · Performance Observer