2026-10-28 · 第二轮对照试用增量

本轮区分三种对象：产品1Hz有效点均值、Graphics兼容FPS、CoreProfile已记录帧片段汇总。后两者不与FrameLifetime默认公式混标。启动后恢复既有单tap串行rotate-to-frame-only有界交接，不创建并行tap或无限重启；handoff缺口、最终continuation状态与真实片段时长保留。持续采集策略启用不等于全场帧已取得，结果需看实际覆盖。设置可关闭实时截图预览，下次Session冻结；若用户同时选择截图保存，仍执行截图采集/保存，所以完全截图OFF对照必须同时取消保存。该配置写入Session storagePolicy与capturePlan，不暗改业务App。

正式55/66、11项暂停不变。本批软件/主机证据不是新增真机验收。第二轮方案与实现。

Display Performance 总览

Display Performance 关注的是系统显示管线记录的画面呈现事实。它不从“CPU 高不高”或“GPU 忙不忙”反推流畅度，而是先建立显示事实：一段时间里产生了多少新 presentation ⓘ、相邻画面间隔多久、长尾是否恶化、显示器当前刷新率是多少、帧节奏是否稳定。

当前实现状态

数据源 POC：ActivityTrace / CoreAnimation FrameLifetime 已在 iOS 17 真机完成 E4 验证。
产品代码集成：R0-R6 与 R7-Fix-A~F 已完成 E2 闭环，当前 Swift Registry ⓘ 的五个 Display 指标都已指向 activitytrace-framelifetime。
完整产品真机链：R7-Fix-G 及后续长稳门禁仍待执行，因此不能把 iOS 17 的 source POC 外推成所有系统、所有产品场景均已 E4。

1. 一帧画面如何到达显示呈现端点

图：Display Performance 站在链路末端观察真实 Presentation，而不是把 CPU/GPU 工作完成时间当成屏幕事实。

这里最重要的边界是：App 完成一段渲染工作，不等于系统已经记录了这帧的 Display Presentation。 CPU、Render Server、GPU 都可能影响最终结果，但 Display Performance 以显示管线末端的 presentation 事实作为基础；它不是“光子到眼”的物理测量。

2. 五个基础指标分别回答什么

指标	核心问题	当前计算模型
FPS	最近一段时间实际产生了多少个新 presentation	trailing 1s 有效 presentation 计数
FrameTime	相邻有效 presentation 相隔多久	end_time - prev_frame + Mach timebase ⓘ
P95 FrameTime	最近窗口中较差长尾帧有多慢	最近 10s valid FrameTime 的 P95
Refresh Rate	显示器当前实际刷新率是多少	refresh_interval 转换为 Hz
Frame Pacing Jitter	帧间隔是否稳定	最近 10s P95 - P50

它们来自同一条逐帧事实流，但不是同一个数的不同写法。

图：五个指标共享逐帧事实源，但窗口、统计量和质量语义各不相同。

3. Perfowl 当前怎样取得 Display 事实

当前新 Session 的主链路已经切到：

com.apple.instruments.server.services.activitytracetap
→ onlySignposts
→ subsystem = com.apple.coreanimation
→ category  = IOMFBServer
→ name      = FrameLifetime

FrameLifetime 真机样本可稳定解析的核心字段包括：

begin_time
end_time
prev_frame
refresh_interval
frame_seed
buffer_count
skip_request
display_id
surface_id

Perfowl 的处理链：

图：Raw Adapter、Decoder、质量门禁和 Projector 分层，避免把传输成功误写成指标有效。

系统服务 / 底层服务通过 DTX ⓘ 打开 activitytracetap；采集调用由 Perfowl 的 ActivityTraceFrameLifetimeRawAdapter 基于 pymobiledevice3 ActivityTraceTap 建立，指标计算由 DisplayPerformanceProjector 完成。

4. 为什么这些指标属于 foreground-device

FrameLifetime 事件来自系统 compositor ⓘ，而不是目标 App PID 私有事件。因此它的 Scope ⓘ 不是 process，而是 foreground-device：只有确认目标 App 位于前台时，当前显示活动才可以作为这次测试的画面事实。

targetForeground == true
→ 发布 Display Performance

targetForeground == false
→ FPS / FrameTime / P95 / Refresh / Jitter = null
→ quality = not-foreground

这样可以避免 App 退后台后，把 SpringBoard 或其他 App 的画面活动错误归给目标 App。

5. 当前数据源为什么重要

旧 CoreProfile Presented Frame 的时间戳本身具有诊断价值，但长期采集会伴随大量与目标帧无关的 KPerf/KDebug 流量。受控真机实验中：

CoreProfile exact Presented Frame ≈ 18.76 MiB/s
ActivityTrace FrameLifetime      ≈ 0.03696 MiB/s

约降低 507×
约降低 99.80%

3 秒连续性复测中：

FrameLifetime rows               60
adjacent pairs                   59
prev_frame == previous.end_time  59/59
mismatch                         0

因此 ActivityTrace FrameLifetime 同时满足“真实逐帧 presentation 链”和“长期低带宽”两个关键条件。完整实验过程见 Display Performance 技术演进与实验。

6. 五个指标应该怎样组合看

FPS 低，不一定有性能问题

静态页面没有新内容需要 presentation 时，FPS 低甚至 0 都可能完全正常。此时需要先确认业务是否应该持续更新。

P95 上升，比平均值更能暴露少量长尾

如果典型 FrameTime 没明显变化，但 P95、Jitter 明显升高，常见含义是大多数帧仍正常，少量长帧正在破坏节奏。

Refresh Rate 变化需要先理解显示策略

ProMotion 会动态改变实际刷新率。120Hz 是设备能力上限之一，不代表屏幕始终工作在 120Hz。

真正确认“卡顿”以后再找 CPU / GPU / I/O

Display Performance 异常
→ Frame Experience 判断损害程度
→ 对齐 CPU / GPU / I/O / Screenshot
→ 更深 Trace / 栈 / 可复现实验确认因果

详见 卡顿诊断与渲染归因。

7. 常见误区

• FPS ≠ Refresh Rate：内容更新速率和显示器刷新率是两个概念；
• FrameTime ≠ GPU Render Time：FrameTime 描述 presentation 间隔，不是某一个 pipeline 阶段耗时；
• FPS 不是 1000 / 当前 FrameTime：FPS 是窗口吞吐，FrameTime 是相邻事件间隔；
• 跨多个 refresh interval ≠ 自动等于 Dropped Frames：应用可能主动以 20/30fps 更新；
• Perfowl Jank ≠ Apple Hitch：二者必须按各自公式和事件语义解释。

8. 连续性与质量

依赖上一帧或滚动窗口的 Display 算法遇到以下边界必须重新建立状态：

source start
sourceEpoch change
reconnectGeneration change
foreground → background → foreground
display_id change
prev_frame chain mismatch

质量语义至少区分：

valid
warmup
discontinuity
not-foreground
missing
unsupported-schema

0、missing、warmup 不能互相替换。完整规则见 数据质量与 0 值判定。

9. 当前适用范围与尚未关闭的验证

当前可以明确确认：

• iOS 17 某真机上的 ActivityTrace FrameLifetime source POC：E4；
• 5 秒吞吐、3 秒连续链、动态 Mach timebase 解析：E4 source evidence；
• Swift Registry、Python Source Contract、CapturePlan、Realtime、Report、UI：E2 产品实现。

仍需独立关闭：

• iOS 15 / 16 / 18 source 与完整产品 E4；
• Display-only、Startup-only、Startup + Display 的真实 start/stop 门禁；
• 5–20 分钟长稳；
• 前后台切换、重连与多 Display；
• 60 / 120Hz 与 ProMotion 动态刷新场景。

因此知识库不会把“iOS 17 source POC E4”写成“Display Performance 全平台 production E4”。

10. 当前知识合同分工

Display Performance 总览只负责建立显示事实模型和五个指标之间的关系。各指标的正式公式、质量规则、证据与版本历史已经分别迁移到独立页面：

• FPS
• FrameTime
• P95 FrameTime
• Refresh Rate
• Frame Pacing Jitter

精确 metricID / scope / unit / source / sourceKey / definitionVersion 的机器合同镜像仍由 Registry 指标合同索引 维护；术语含义可查 技术术语速查。

11. 继续阅读

• FPS
• FrameTime
• P95 FrameTime
• Refresh Rate
• Frame Pacing Jitter
• Jank、Stutter 与帧体验
• 卡顿诊断与渲染归因
• Display Performance 技术演进与实验
• 渲染诊断研究候选

2026-10-04 · 显示指标来源新鲜与E4边界

持续收到host事件并不证明设备事件当前：固定五轮140s捕获仅处理20.669–22.166s的设备帧时轴，原host-silence质量门无法识别一直到达的旧时间段；CSV有值/Raw无队列drop/最终封存均不是完整当前窗覆盖。来源时轴与独立自身Metal呈现参照应分列，单surface不能冒充全部foreground-device。

Perfowl自身adapter对pinned11.3.1原row builder只做每tap 64类有界数据类型缓存；不缓存帧值、不改公式、不放宽long-gap/one-shot/白名单，原协议解码指令保留。E2同输入20字段×1000行×5解析wall为原0.027392倍，原缓存生成成本降低不直接意味着E4数据已可信；新包五轮来源覆盖/同轴与逐指标独立准确仍待。方案/实施与失败证据边界。

版本历史增量：2026-10-04，解析类型缓存v1（指标公式版本不变），已证离线效率与字段保真；当前窗迟到/校准仍partial。

2026-10-04 · 缓存修复后的限定真机来源观察

b115固定五轮140s捕获的原生设备帧跨度139.443–139.474s；旧b114同合同五轮仅20.669–22.166s。此受控场景来源处理吞吐/相对时轴跟进改善已观察；原始discontinuity/warmup继续真实保留，单surface呈现不等于全部foreground-device。sysmontap EndMach水位与host elapsed仅提供帧源年龄的下界，没有交付时延上界就不能据低下界认证当前新鲜；首尾host/source跨度差为相对滞后变化，不是绝对延迟。原固定bin与独立校准仍未过，全54项可信/100%未达，candidate状态不提升。固定五轮结果/源码与边界。

2026-10-04 · 同设备时钟过期下界（G7先行定义）

新场景140s主机采集中，native设备帧仅29–35s，较已收到的同设备sysmontap EndMach落后约105–112s；这证明持续到达也可能是旧帧，不以host queue无drop声明覆盖。

在本Session已核唯一设备/目标代际/重连绑定中，仅当两源均有明确一致的实测Mach timebase，设S为此前收到的sysmontap EndMach水位、F为最新有效FrameLifetime endMach水位。lagLowerNs = max(0,S-F) × numer // denom（向下整除纳秒，是保守下界）；不加主机elapsed、不假定接收延迟上界。严格lagLowerNs > 2,000,000,000时，新实时五项Display字段置空、质量stale-device-source，ageUpperBoundNs=null。下界不超门或无依据均不证明当前新鲜，原host-silence/one-shot/质量门继续并列；旧Raw无钟时仅额外unknown，不补时间戳。

PID/代际/重连不合、旧epoch、错钟、负/boolean/无实测timebase均不入锚点；单源epoch advance清双方比较，不能跨重启沿用水位。原Raw/native源时间值保留，离线历史源统计不是完整当前窗证据。修复只防已证过期被当当前有效，连续性/来源吞吐与独立scope校准仍须新包E4；未提前提升校准。G7合同。

版本增量：current-display-device-lag-lower.v1；原native FPS/FrameTime/P95/Refresh/Jitter数值公式不变。

2026-10-06 · G63 独立呈现事件输入（E2；未校准）

自有Surface日志可逐submission核drawable/可空IOSurface，原G58 7201对核过；只以原presentedTime作间隔，回调mach与requestedFPS不能代呈现或实际刷新率。未呈现必须分段、不补帧。surface-stop没有字节footer，因此已见对完整不证明写盘完整；单Surface/whole-file统计不代全foreground-device、产品固定窗或滚动10s。28控制与219工具回归通过，全54正式仍0/54，原帧容差规范冲突不变。实现与限定。

2026-10-06 · G64 自有参考文件关闭凭据（E2；未部署/未校准）

默认OFF；显式schema2的成功关闭凭据须与实际SHA/计数/字节/限额、fsync/close交叉核对，缺失或失败不能宣称参考写盘完整。schema1原无封口语义保留。19实际writer控制与233工具回归通过；只证该自身日志文件，不证全foreground-device、产品固定窗或物理/API精度，全部54与原五轮/误差门保持。结果。原帧指标公式版本未变。

G64收尾自复核发现最终receipt写后fsync/close失败未完整fail-closed，19已测控制不覆盖此情形；参考升级暂停，修复前不将此工具当正式参考。该风险不改变已装Mac b122或帧公式。开放门。

2026-10-06 · G65 凭据失败关闭（E2；未部署/未校准）

G64最终凭据写后fsync/close失败仍可能成功JSON的问题在冻结源码host复现；现pending完整写/同步/显式关闭后才非覆盖提交最终名，失败pending不入参考。消费者用最终提交basename准入且仍全SHA/计数绑定，名称不证明身份或数据对应。30真实控制/235工具回归/iOS编译E2通过；目录掉电持久性与手机运行未测，不证产品native窗/数值精度/全部foreground scope。原指标公式/54/五轮与误差门保持。结果。

版本历史增量：2026-10-28，第二轮内部试用口径、来源及报告边界更新；E2/E3与待测E4分列。第二轮方案与实现。