iOS 性能观测模型

Perfowl 的所有指标最终都来自 iOS 已经存在的系统事实。理解知识库之前，先建立三个基本认识：观测对象不同、原始事实类型不同、一个最终指标通常不是某个字段的简单改名。

图：Transport、Raw Adapter、标准化事件与指标计算是不同职责层；任何一层的缺失都不能用 0 填补。

1. 三类观测对象

• 目标进程（process）：CPU、内存、线程、进程网络、启动生命周期等可以明确归到目标 App 的数据。
• 整台设备（device）：TotalCPU、可用内存、整机网络、电池与温控等设备环境数据。
• 前台显示环境（foreground-device）：FPS、FrameTime、Refresh Rate 和前台 GPU 等与“用户当前看到的屏幕”相关，但事件本身不一定由目标 PID 发出。

工程合同里把这类范围称为 scope。它首先决定一个数值能不能被归给目标 App，再决定后续公式是否有意义。

2. iOS 性能事实常见形态

原始事实形态	典型含义	例子
Gauge ⓘ	当前时刻的一个状态值	CPU、Memory、GPU Utilization
Counter	从某个起点累计增加的计数	Disk Bytes、Context Switch
Interval	明确时间区间里的数量	Network interval bytes
Event	某件事情在某个时刻发生	Startup lifecycle、FrameLifetime
Trace / Raw stream	高频系统事件流	CoreProfile / KDebug ⓘ 等深层诊断流

因此“采样频率”“UI 刷新频率”和“事件真实发生频率”不能混为一谈。

3. 从系统事实到产品指标

System / Device Fact
→ Transport / Service
→ Raw Adapter
→ Normalized Domain Event
→ Metric Projector
→ Product Sample
→ Report / Replay

例如 Display FrameTime 当前链路是：

CoreAnimation FrameLifetime signpost
→ ActivityTrace
→ FrameLifetime Decoder
→ continuity gate
→ FrameTime
→ Display Performance panel / report

CPU 则可能更接近：

sysmontap gauge
→ process identity gate
→ unit / scope contract
→ APP CPU

4. 为什么需要标准化事件层

底层协议格式会变，产品指标不能每次都跟着重新解释二进制数据。Perfowl 把 Raw 先转换成具有明确语义的领域事件，例如 Display Frame、Startup span、Network interval，再由上层计算 FPS、FrameTime、Launch Total、Network Rate 等指标。

这样才能做到：source 迁移时尽量保持产品语义稳定，同时让历史 Session 仍按原始 definitionVersion ⓘ 回放。

5. 时间是性能指标的一部分

Perfowl 同时会遇到设备 Mach clock、source-native ⓘ timestamp 和 Host monotonic。任何差值只有在同一个时钟域或明确允许的 bridge 中才成立。

例如 FrameTime 必须来自设备 presentation ⓘ 时间链；Host monotonic 可以帮助推进 FPS 滑动窗口，却不能合成一个不存在的 FrameTime。

深入见 数据流、时钟与连续性。

6. 0、没有数据和算法尚未准备好不是一回事

一个合法的 0 表示系统事实确实为零；missing 表示事实不足；warmup 表示 source 已工作但前值或窗口还没建立；not-foreground 表示这个前台显示指标当前不能归给目标 App。

完整语义见 数据质量与 0 值判定。

7. Perfowl 的长期边界

Perfowl 的目标不是把所有能抓到的系统字段都变成产品指标，而是保持：

真实系统事实
+ 明确的归因范围
+ 可复核公式
+ 诚实的 missing / quality
+ 可追溯原始证据

接下来可以继续阅读 指标计算与窗口模型，或直接进入你关心的性能领域。