Perfowl

外观

Perfowl 能力与证据模型 ​

Perfowl 不再用单一的“支持 / 不支持”描述性能指标能力。一个 metric 在代码中存在，只能说明它拥有产品合同；是否适合正式测试，还要同时看产品状态、证据成熟度、运行条件和平台覆盖。

四维能力模型 ​

维度回答的问题典型值
Product State产品代码当前是否正式拥有这项能力production / candidate / migrating / research / legacy
Evidence这个 source、公式和数值验证到哪一步offline / fixture / integration / true-device E4 / external-calibration pending
Runtime Condition什么时候这个值才物理成立target foreground / process-cold / battery-only / source-ready / schema-observed
Platform Coverage哪些 iOS / 机型已经单独验证iOS 16 E4、iOS 17 E4、iOS 18 E4、not-tested 等

这四个维度必须正交阅读。例如“Battery Power 已实现”与“USB 充电时必须 missing ”可以同时成立；“Foundation 在 iOS 18 已通过 E4”也不能自动证明某个 Startup 九阶段在 iOS 18 已完成语义 E4。

Product State ​

状态含义
production当前产品正式 source ownership 已确定，可按 Canonical 合同使用
candidate产品链已实现，但公式、schema、数值或跨版本证据仍有门禁
migrating当前生产 source 与目标 source 正在切换，不能把目标设计提前写成既成事实
research只做协议、事件或语义研究，不进入正式指标合同
legacy只为历史 Session、兼容读取或短时对照保留，不应再承担新 Session 主采集

Evidence：不要把“有代码”当成“有真机证据” ​

仓库历史记录中常用 E1～E4 描述成熟度。不同阶段的 devlog 会有更具体门禁，本页不重新改写历史等级定义；日常阅读至少要区分：

  • 离线 / 合同证据：代码、Fixture、schema、路由、回放或确定性测试通过，只能证明“实现逻辑成立”；
  • 集成证据：完整产品链能够准备、采集、落盘、停止与回放；
  • E4 真机证据：在明确设备、系统、场景上真实产生数据并通过质量门禁；
  • 外部校准证据：与 Xcode / Instruments / PerfDog 等同窗比较，证明数值语义或等价关系。

最重要的原则是：E4 只覆盖实际执行过的设备、系统、source 和场景，不能跨版本、跨指标族、跨运行条件自动外推。

Runtime Condition ​

有些能力只能在特定物理条件成立：

  • foreground-device：目标 App 必须位于前台；退后台后 FPS、Frame、前台 GPU 等应断开而不是补 0；
  • process-cold：Startup 深度分析要求受控重新创建目标进程，但不等于清空系统缓存或消除 iOS prewarming；
  • battery-only：Battery Current / Power 只有在没有外接供电、未充电并满足放电方向门禁时，才允许按放电电学量语义解释；当前 Perfowl 的 Battery Electrical 产品状态仍为 Unsupported；
  • source-ready：深度 DVT source、GPU dynamic schema、ActivityTrace/CoreProfile 等必须先完成握手与 schema 识别；
  • identity-verified：需要目标归因的 process metric 必须确认 PID / generation，不能跨进程重启沿用前值。

Platform Coverage ​

平台覆盖至少分三层：

text
Connection / Provider Route
        ↓
Source Family 可达与 schema
        ↓
Metric 数值与语义

因此“iOS 17 连接通过”不等于“所有 source family 都通过”，“某 source family 通过”也不等于“全部派生指标完成外部数值校准”。具体平台状态见 iOS 15+ Collector Foundation 兼容矩阵。

三个典型例子 ​

StartupTiming ​

  • Product State：产品能力存在；Total 与九阶段依赖 CoreProfile lifecycle；
  • Evidence：iOS 17 已有多轮真实启动证据，但阶段 coverage 与端点 repair 需要单独披露；
  • Runtime：controlled process-cold；
  • Platform：Foundation E4 不自动外推为每个 Startup phase 的语义 E4。

Display Performance ​

当前 Display Performance 最适合用来理解“实现证据”和“产品 E4”为什么要分开：

  • 当前 Registry 的 FPS / FrameTime / P95 / Refresh Rate / Jitter 已统一指向 ActivityTrace FrameLifetime；
  • iOS 17 FrameLifetime source POC 已完成 E4，证明真实逐帧 presentation 、连续链与低带宽 source 在该设备/系统成立；
  • Registry、CapturePlan、Realtime、Report 与 UI 已完成 E2 产品实现，但 Display-only、Startup + Display、长稳与跨版本完整产品 E4 仍 Pending；
  • 旧 CoreProfile Frame decoder 退出新 Session 主采集后仍保留 legacy replay / controlled comparison，这不改变当前 source ownership。

Battery Power ​

  • Product State：产品合同已实现；
  • Evidence：来源、条件链与公式需要结合 Canonical 页和平台证据阅读；
  • Runtime：只有 battery-only 才输出；
  • Platform：某系统连接 E4 不代表物理放电场景已完成 E4。

如何使用能力矩阵 ​

阅读 全指标能力矩阵 时，不要只看一个绿色图标。正式测试至少确认：

text
Product State 允许正式使用
+ 当前 iOS / 机型有足够证据
+ 本次运行条件满足
+ Metric quality 为有效

如果其中任意一项不成立，结果应保持 candidate、missing、unsupported 或明确降级，而不是通过 fallback 或补 0 制造“看起来支持”。

与其他知识页的关系 ​

工程交付证据与指标证据分别追踪（2026-10-19） ​

问题表现：软件控制通过、网站能构建，容易被误解为指标已通过；旧提交的成功网站也可能被错误用于证明新提交。判断时分别记录指标验收、源码推送、本地产物、线上发布和通知，不用其中一项代替另一项。网站本地E2成功不增加指标数，也不证明线上已有新内容。

复现与判断：为本次输入树绑定提交/内容SHA，完整执行所有构建阶段并核对页面/搜索/归档；随后再从线上URL核对对应版本。新源构建若超资源门，应保留失败和部分产物，不能用旧dist称最新交付。缺配置时如实partial，恢复配置后从已核来源补齐发布与线上复核。

资源方法：只看worker自身内存会漏掉npm、调度器、编译器和Git后代，必须同时检查全树聚合峰与时间/进程预算。轻量串行调度器可减少与重型worker重叠的驻留；分阶段通信只传渲染实际消费的元数据时，完整输出仍必须另核。小站34产物等价只证明该对照范围，不能替代当前全规模资源资格；时间换空间的成本应同时披露。失败、过渡、尾部与缺值不因此省略。

本节方法来自轻量调度器结果和分阶段构建方案，证据E2，仅限固定SDK/当前站点的工程交付；不外推iOS采集可用性、物理精度、跨版本兼容或正式分发合规。

版本历史 ​

日期修订来源
2026-10-19增补交付与指标证据分列、同源构建和聚合资源核验方法；不改历史指标结论本地构建恢复

Perfowl · Performance Observer

看见每一帧，也看见帧后的原因