Refresh Rate：实际显示刷新率

Refresh Rate 描述当前实际显示刷新率。它不是设备规格表里的最高刷新率，也不是 FPS。对于 ProMotion，系统可以根据场景动态调整刷新率，因此观测真实 refresh_interval 并换算为 Hz，比只读取“支持 120Hz”更有分析价值。

1. 定义 / 概念

Refresh Rate 回答：显示系统当前的刷新频率大约是多少（Hz）。它描述刷新率；FPS 描述同一时间窗内出现了多少个新的 presentation ⓘ。

2. Scope 与 Unit / 单位

字段	合同
metricID	ios.display.refresh_rate
Scope ⓘ	foreground-device
Unit / 单位	hertz
source	activitytrace-framelifetime
definitionVersion ⓘ	activitytrace-framelifetime-refresh-rate.v1

3. 系统服务 / 原始字段 / 采集调用

2026-11-02 · iOS 26 刷新率缺失

iOS 26 的帧事件改为 FrameUpdate，其中没有刷新间隔字段。该系统下刷新率保持缺失，不从帧间隔或 FPS 反推；FrameTime 仍可计算，见 FrameTime。诊断

底层服务仍是 activitytracetap 的 CoreAnimation FrameLifetime。原始字段：

refresh_interval

采集调用由 ActivityTraceFrameLifetimeRawAdapter 获取事件，FrameLifetimeDecoder 使用设备 Mach timebase ⓘ 转换 interval，DisplayPerformanceProjector 发布 Hz。

4. 公式 / 计算方式

refreshIntervalNs =
(refresh_interval * machTimebaseNumer) // machTimebaseDenom

RefreshRateHz =
round(1_000_000_000 / refreshIntervalNs, 4)

只有 refreshIntervalNs > 0 才允许发布。

在本次 iOS 17 POC 中观察到的 refresh interval 约为：

16.666 ms
≈ 60 Hz

但这是该次场景的真实观测，不是写死的设备常量。

5. Refresh Rate 与 FPS 为什么可以不同

60Hz + 20fps
120Hz + 60fps
80Hz + 40fps

这些组合都可能合理。Refresh Rate 表示显示系统当前的刷新频率，FPS 表示新内容的 presentation 速率。静态页面、视频、主动低帧率动画都可能让 FPS 显著低于 Refresh Rate。

6. ProMotion 与动态刷新

对于支持 ProMotion 的设备，系统可能根据滚动、动画、静态内容和功耗策略调整实际刷新率。因此报告应该保存 observed distribution，而不是简单贴上设备“最高 120Hz”：

120 Hz  35%
80 Hz   12%
60 Hz   53%

上面的百分比只是分布展示示例；正式报告按 Session 实际观测值统计。

7. Quality / missing

• refresh_interval <= 0 → missing ⓘ，不参与统计；
• sourceEpoch ⓘ / reconnect / display switch → 重新建立当前 display 状态；
• target background → not-foreground；
• 多 Display → 只统计已选定的 primary display，禁止混合不同显示器的刷新率。

8. 证据与适用范围

iOS 17 FrameLifetime POC 已真实观察到稳定 refresh_interval，属于 source E4；ios.display.refresh_rate 的 Registry / projector / UI 目前为产品 E2，完整 R7 metric E4 待验证。iOS 15/16/18 与 80/120Hz、动态 ProMotion 场景仍需独立矩阵。

2026-10-03 增量：两轮旧 Session 的实时样本可见有效 Hz，而最终覆盖误记 missing/0、CSV 无列。修复只让已发布、有限、正值且质量有效的 Hz 进入覆盖，并在 CSV 末尾存值与质量；不从设备规格推算，也不把新包 E2 视为 E4。

9. 如何分析 Refresh Rate

当 FPS 下降时先看 Refresh Rate：

• Refresh Rate 同时主动下降，CPU/GPU 正常 → 先考虑系统显示策略；
• Refresh Rate 稳定但 FrameTime/P95 出现尖刺 → 更像 presentation 发生了真实长间隔；
• FPS 低、FrameTime 稳定、页面静态 → 低内容更新率可能完全正常。

10. 版本历史

版本	日期	修订要点
current-display-device-lag-lower.v1	2026-10-04	同钟过期下界>2s置空/stale-device-source，数值公式不改；22匹配/全量E2与b116安装E3通过，新真机E4未测、54项100%仍partial。G7。
v1（当前）	2026-09-17	从 Display 总览拆出独立 Canonical，冻结 refresh_interval + Mach timebase → Hz 与动态刷新解释边界。
v1 输出链路补记	2026-10-03	公式不变；补最终覆盖和 CSV 持久化，真机复测待完成。
refresh-native-current.v1 校准状态补记	2026-10-22	本机受控诊断的数据一致性通过；当前候选集无合格独立物理参考，正式验收仍0/5。当前方案与诊断。
站点构建与验收状态增量	2026-10-22	知识门及文档更新后的本地完整站点构建通过E2；线上未发布，正式刷新率仍0/5，口径未变。复验记录。
Owner直接验收决定	2026-10-22	按Owner明确指令计入正式进度；a02 r1失败、0/5标准通过轮与已知异常保留，物理精度未校准。负责人决定。

继续阅读：FPS · FrameTime。

2026-10-04 · 当前窗的设备时钟过期保护

同一已核Session/目标代际/重连且两源实测Mach timebase一致，lagLowerNs=max(0,sysmontap.EndMach−FrameLifetime.endMach)×numer//denom是过期下界，不是精确年龄。严格超过2s时，本实时Display指标置空、质量stale-device-source；age上界未知继续null。下界小/无钟不是当前新鲜证明，原host-silence、one-shot、warmup与缺值门保持。旧Raw和native历史数值不回填，完整当前窗/独立scope与五轮100%仍待新包验收。

版本历史增量：current-display-device-lag-lower.v1（原数值公式不改），E2同钟/代际/边界及原迟到数据离线对照通过，E4与全54可信目标仍partial。共享时钟定义 · G7实施与证据。

2026-10-21 · 当前源质量合同与候选参考

刷新率正式仍0/5，整体36/66。当前软件实现通过2863项回归、8项独立Raw控制和8项实际Core/Codable/CSV/JSONL控制；ARM203已严格校验并安装到唯一标准路径，属于E2/E3准备，不是本指标真机验收通过。来源当前方案与增量。

新Raw带refreshPublicationPolicy=refresh-native-current.v1。原生refreshIntervalMachTicks、Mach timebase须为正整数（拒绝bool）；先整数整除得ns，再取倒数并四位取整。派生Hz/ns须和原生字段一致，原始缺失或新事件非法时清空，不继承上次60Hz。当前gauge可在同一最新源host年龄[0,1秒]内重复发布；严格超过1秒为null/stale-source，发表早于源为null/future-source。目标、前后台、源/重连/timebase边界清空；旧代际、乱序、drop拒绝，别的display不刷新主display。设备同钟过期下界>2秒仍优先null/stale-device-source。无合法源置空，不以0、最大能力或请求Hz补齐；不带新策略标记的历史Raw保持原回放合同。

FrameTime首点warmup或source-gap表示呈现间隔不确定，本身不能证明同一事件的原生refresh interval无效；两个字段独立检查，不能用一条FrameTime缺失把有效硬件间隔伪造成0，也不能借硬件间隔给缺失FrameTime补值。

测试App候选保留CADisplayLink原始timestamp、targetTimestamp、duration及Double位模式、callback entry/exit原生钟、请求范围、screen上下文与首尾桥。用默认/30/60请求、长callback、恢复和静止内容区分内容更新与刷新。Apple的CADisplayLink说明及请求范围说明表明请求和callback节奏受系统策略影响；这支持实际用例设计，尚不构成同scope完整参考资格。最大支持Hz不能当动态Hz真值。独立Raw算术与独立物理参考分开，后者须覆盖完整冷启动首120机会再下结论。

版本历史增量：2026-10-21，refresh-native-current.v1，新增原生整数核同、无效新事件清空、host新鲜度与逐源收据，数值definitionVersion不改；本项五轮/参考资格待测，不影响历史P95验收计数。

2026-10-21 · 准备状态增量与参考缺失判定

最终软件回归2865/2865、0skip、46专项及8项独立Raw控制通过；ARM205内部开发签名包已标准安装。新机Lab31实际完成140.008523秒六阶段刺激，7210条CADisplayLink记录原始位模式、原生顺序和前台/屏幕字段核同，额外记录P95 0.032083ms。以上分别属于E1/E2/E3及受控App刺激E4，本指标仍0/5，参考资格未定。

受控请求30Hz阶段，targetTimestamp−timestamp倒数中位约30.0475Hz，而duration倒数约60.0950Hz。这说明回调调度、请求率和能力相关周期是不同量；不能只因其中一列接近系统Hz就宣称同层参考。实际资格应配对同一display、钟域和完整采样窗，保留请求切换、长callback、静止及所有首尾记录。

Metal presentedTime=0也不能当有效呈现时刻或0Hz。Apple SDK的MTLDrawable.h及接口定义将其用于未呈现/跳过的帧。此次实际首点出现1条该哨兵：原件完整保留，原Fixture整体partial/testPassed=false保持，Metal完整参考不合格；它本身不能证明产品刷新率错误或硬件损坏。应分别记录刺激完成、候选缺失、参考资格和产品指标验收；不删首点后重算完整性，不以GPU已完成证明已上屏。CADisplayLink候选仍需独立同场调查，不能由Metal缺失推断所有参考均不可用。

版本历史增量：2026-10-21，原生转换缓存仅复用严格合法整数与相同timebase的精确结果，每事件仍核派生值/顺序/资格；数值和质量合同不变。补充已验证的请求/回调差异及Metal首点缺失处理，来源准备记录。

2026-10-21成本增量：同版本OFF/ON单对完整140秒，额外记录CPU增加0.372269个百分点、峰footprint增加1802288B、回调时序记录P95 0.0365ms，均满足本项预算；ON首个Metal presentedTime=0仍保留并使完整Metal参考不合格。该成本证据只覆盖自有App这一对E4场景，不证明产品刷新率精度或所有设备的开销。来源当前准备记录。

2026-10-22 · 受控诊断与参考校准状态

一次140.006秒受控诊断中，6004条刷新Raw全部由165个Session样本消费；CSV与Session JSONL逐行值/质量一致。以Session起始时间为锚的固定首120秒内，119个样本全部valid；最大相邻间隔1.012111秒，含首尾边界的最大覆盖间隙1.628秒，达到本项诊断窗口门槛。全Session有122个valid值、43个stale-source空值；最终Report coverage记录122个刷新率样本。原生interval为16666000ns，按本页整数公式得到60.0024Hz。此证据为E4、限本机与该受控场景，不是正式五轮验收。

CADisplayLink callback不能单独代表显示刷新率：30Hz请求阶段的callback约30.045Hz，而同阶段Native interval约60.0024Hz；请求和回调时序与物理刷新间隔含义不同。Metal参考中有一条presentedTime=0未呈现/跳过哨兵，使完整Metal参考不合格。Apple Animation Hitches当前探测超过既定资源门，既有trace的有界导出未产出表格；因此当前候选集没有合格独立物理参考，这不证明以后无法建立新参考路径，也不表示手机硬件故障。

当前状态：referenceQualified=false、referenceAccuracyValidated=false，正式验收仍0/5。按Owner政策，只有新的完整五轮数据无异常后才计为NO_REFERENCE_ACCEPTED_OWNER_POLICY；在此之前不能标成通过，也不能进入Jitter。细节见方案与诊断增量。

2026-10-22 · 首样本合同与目录后验修复增量

a02 r1失败原件保持不变：固定首120秒119行中118个有效值，CSV与Session差异1处；首样本早于首个合格FrameLifetime Raw，独立Raw oracle拒绝。执行器的AFC请求目录快照已改为校验、去重并归一为set；已请求刷新率时，首个合格原生来源到达前也发布明确missing质量与可空来源收据，并通过有界事件等待尽快发布首个有效样本。没有选入Display帧适配器时不等待且继续missing。公式、质量规则、Session锚点及119/120和gap门槛不变。

离线反事实回放显示，在封存a02 Raw上将首样本移至首个有效来源后，模拟0–300ms唤醒延迟的固定窗口均为119/119有效；这是软件推演，不是新Session。全采集器真实数据规模回放中，wall与CPU中位增幅分别3.71%与3.65%，低于方案的20%增幅门；峰RSS、最差20000事件路径及首响应专项性能收据仍未齐，不能把整项效率门标为通过。188项Python定向测试及Swift候选记录控制通过，证据为E2；正式验收仍0/5、整体36/66。a02失败不可重放，设备可操作后须新建a03并重新只读保全/枚举；Jitter仍关闭。来源：方案与实施增量。

2026-10-22 · 最差事件路径与效率合同闭合增量

后续主机隔离基准以Git基线879ed968和当前源码分别处理20,000条事件及180个样本，交错5次；wall和CPU中位增幅3.07%和3.69%，候选进程峰值RSS中位数比基线低3,833,856B。首样本消费/发布的100次中最大0.110417ms，异步来源唤醒至发布最大0.130417ms；刷新率状态独立批处理20,000条事件wall中位8.361ms。此前真实Session规模回放、序列化体积、7200行Fixture记录和OFF/ON资源门结果一并覆盖方案余下效率要求。上述为E2主机/工具效率证据；知识门与文档更新后的完整站点构建现已通过E2，生产站点仍未发布。产品刷新率正式验收保持0/5，未改变a02失败或未来a03准入条件。

2026-10-22 · 本地站点构建复验

知识门与文档更新后的完整VitePress构建使用Node v24.19.0通过，证据为E2；该结果只证明本地站点构建。生产站点未发布，Cloudflare与Webhook配置欠项仍按既有授权记录为partial。Owner暂不方便操作手机，本轮未建立a03；刷新率正式0/5、整体36/66，a02 r1失败保持不可重放，Jitter关闭。来源：构建复验与设备等待记录。

版本历史增量：2026-10-22，文档/知识门/本地站点构建复验通过（E2）；刷新率公式、产品门槛与无参考政策均未变，正式状态仍0/5。来源构建复验记录。

2026-10-22 · 未请求刷新率时保持关闭

CapturePlan未选择ios.display.refresh_rate时，即使其他显示指标启动同一FrameLifetime适配器，适配器上的刷新率策略标记也不会激活刷新率来源状态或添加专属来源收据。实现以请求状态门控，并通过带标记/不带标记输入对照确认未请求路径的既有指标输出不变（E2）。这是按需发布边界；它不改变刷新率原生整数公式、质量规则、正式窗口或真机验收结果。

版本历史增量：2026-10-22，补充未请求指标保持关闭的门控与31项刷新率/P95聚焦验证（E2）；数值与正式验收合同不变，刷新率仍0/5。来源分离复核记录。

2026-10-22 · Owner直接验收决定与当前标记

Project Owner明确要求不再进行独立复核，将本指标计入正式验收并继续下一项。状态标记为OWNER_DIRECT_ACCEPTANCE_WITH_KNOWN_EXCEPTION，整体计数为37/66。此决定不改写a02 r1失败事实：固定首120秒119行中118个有效值、CSV与Session差异1处、Raw oracle曾拒绝首样本；标准五轮仍为0/5通过。当前候选集无合格独立物理参考，referenceAccuracyValidated=false。这是Owner对项目进度的正式决定，不表示已知异常消失、物理准确度校准完成或Build 208真机安装通过。下一项为Jitter；手机暂不可操作期间仅做离线方案与准备。来源：负责人验收决定。