外观
跨指标诊断与证据升级：从观察到可确认的因果层级
先看结论
- Perfowl 是无侵入观测工具，多数场景下能把证据推进到 Level 1～3（用户可见症状 + 同窗资源相关性 + 部分系统/线程级证据），不能单独达到 Level 4～5（代码级证据、可复现实验验证因果）。
- 同一时刻多个指标同时出现异常，只能说明"相关"，不能直接写成"确诊"或"根因"。 时间相关性是缩小排查范围的起点，不是终点。
- 本页的"候选模式"表格描述的是历史上观察到的典型症候群组合，用于帮助你更快缩小排查范围；它们不是判定树，不能替代 Instruments、调用栈或代码审查。
在真实的性能测试工作中，孤立地看单一指标容易被表象误导：FPS 掉到 20 帧不一定是 GPU 负载或图形管线能力不足；手机发烫不一定是 CPU 密集运算；应用突然消失且日志中没有 Crash 堆栈，可能与 Jetsam 相关，但仅凭这一现象不能直接确诊。跨指标同窗对齐可以把候选范围收窄，但收窄到什么程度，取决于你实际拿到了第几层证据。
1. 证据层级模型（Level 0～5）
text
Level 0 数据质量
该窗口内参与比较的指标是否 valid/candidate？有没有 missing 被当成 0、warmup 期或 counter-reset 未被识别？
→ 任何跨指标结论都必须先确认这一层，否则后续层级都不可信。
Level 1 用户可见症状
FrameTime 飙升、应用闪退、界面卡死、发热——测试人员或用户能直接观察到的现象。
Level 2 同窗资源相关性
在同一个时间窗口内，哪些指标也出现了异常波动（APP CPU 冲高、Disk Read 尖峰、Device Network 异常等）。
→ 这一层只能证明"同时发生"，不能证明因果方向，也不能排除巧合。
Level 3 系统级 / 线程级证据
Thread Count、Context Switch Rate、Per-Core Usage 等指标能提示"压力落在哪一类系统资源"，
但 Per-Core、Device 级指标是 device scope，不能单独证明是目标 App 的哪个线程。
Level 4 Instruments / Trace / 代码级证据
Time Profiler 调用栈、Allocations、GPU Frame Debugger、系统 Trace、崩溃日志堆栈——
Perfowl 当前的无侵入 source 大多不能单独提供这一层，需要额外工具介入。
Level 5 可复现实验验证因果
通过受控变量（如关闭某个功能、替换某段代码）反复复现并观察指标变化，才能真正验证因果关系。Perfowl 的多指标同窗采集与统一时间轴能显著加速 Level 0～2 的排查效率，Level 3 视具体指标而定（process scope 指标能到线程/进程粒度的部分证据，device scope 指标不能单独归因到目标 App），Level 4～5 通常需要结合 Xcode Instruments、调用栈符号化或代码审查等额外证据源。
2. 跨指标排查的推荐步骤
- 确认数据质量（Level 0）：检查当前采样点是否处于启动预热（Warmup ）、重置（Reset/Discontinuity ）、插着 USB 导致电池字段为
missing、或应用退入后台导致 GPU/FPS 字段合法缺失。不要把这些质量状态误当作"异常"参与后续比较。 - 锁定时间窗口（Level 1 → Level 2 的桥梁）：用 Session 时间轴精确圈定症状出现的 elapsed 区间（如
00:45.200~00:46.800）。 - 同 Scope 内纵向观察（Level 2）：在该窗口内，先看 process scope 指标（APP CPU、Disk Read、Process Network）是否也出现异常。
- 跨 Scope 横向对照（Level 2 → Level 3）：对照
Process与Device是否出现背离——例如 APP CPU 很低但 Device Total CPU 很高，提示系统噪声干扰的可能性较大，但不能就此"确诊"与被测 App 完全无关，因为同窗内其他因素也可能间接受影响。 - 判断当前证据能到第几层，决定是否需要升级证据：如果只到 Level 2～3，且问题需要精确定位到代码，应该建议接入 Time Profiler / GPU Frame Debugger 等 Level 4 工具，而不是直接在报告里写"确诊"或"根因"。
3. Scope 分层：数据对齐的黄金准则
text
┌─────────────────────────────────────────────────────────────────────────────┐
│ [前台设备级 · 屏幕呈现] (Foreground-Device) │
│ FPS / FrameTime / Jank / Stutter / GPU Renderer / GPU Tiler │
│ ► 用户眼睛能感知到的视觉流畅度与屏幕像素交付负荷 │
└──────────────────────────────────────┬──────────────────────────────────────┘
│ 相关但不等于因果
┌──────────────────────────────────────▼──────────────────────────────────────┐
│ [进程级 · 目标专属] (Process Scope) │
│ APP CPU / Physical Footprint / Thread Count / Wakeups / Disk I/O / Net I/O │
│ ► 被测应用自身线程/进程产生的资源开销，比 device scope 更接近"归因"， │
│ 但仍不能定位到具体代码路径 │
└──────────────────────────────────────┬──────────────────────────────────────┘
│ 相关但不等于因果
┌──────────────────────────────────────▼──────────────────────────────────────┐
│ [设备级 · 整机环境] (Device Scope) │
│ Total CPU / Per-Core Usage / AvailableMemory / Battery Power / Temperature │
│ ► 整机环境与物理约束层，不能单独归因到目标 App │
└─────────────────────────────────────────────────────────────────────────────┘不要把这三层的箭头理解成"因果传导链"——它们只是作用域从大到小排列，跨层背离提示需要交叉验证的方向，不是自动推导出的因果。
4. 常见候选症候群组合（Level 2～3 证据，需继续升级确认）
以下模式是历史上观察到的典型组合，每一条的结论栏都只是候选方向，不是确诊；能确认到什么层级、还需要什么证据才能进一步确认，已在表格中如实列出。
| 候选模式 | 常见复合特征（Level 1～2） | 候选方向 | 继续确认需要什么（Level 3～4） |
|---|---|---|---|
| 主线程计算阻塞候选 | FrameTime 突发长帧（数十至上百 ms）；APP CPU 短时冲高；CPU Core Usage 显示某单核持续高位，其余核心较低；GPU Renderer 处于低位 | 提示主线程可能被耗时同步计算占满（如复杂布局求解、深度递归、正则回溯） | 需要 Time Profiler 调用栈确认具体函数，不能仅凭波形组合定位到代码 |
| GPU 片元负载候选 | FPS 持续低迷，FrameTime 稳定在偏高区间；APP CPU 处于低位；GPU Renderer Utilization 持续偏高，Tiler Utilization 正常 | 提示可能存在像素渲染压力（如多重实时模糊、大面积半透明叠加） | 需要 Xcode GPU Frame Debugger 确认具体图层与 Overdraw，不能仅凭利用率确诊 |
| 主线程同步 I/O 候选 | 画面短时定格；APP CPU 与 GPU 利用率均很低；同窗观察到 Disk Read 出现明显尖峰 | 提示可能存在主线程同步磁盘 I/O | 需要调用栈或代码审查确认是否真的发生在主线程，不能仅凭同窗相关性确诊 |
| 长稳发热与性能下降候选 | 长时间高负载后 FPS/FrameTime 出现阶段性下降；Battery Temperature 呈上升趋势；Battery Power（仅在 battery-only 且字段有效时）较高 | 热压力、CPU/GPU 高负载或其他资源竞争都可能参与 | Thermal Status（证据可信时）只能提供系统热状态线索；温度、Thermal Status 与性能下降都不能单独证明 CPU/GPU 已发生具体降频，需要冷却复测或更直接的系统证据 |
| Physical Footprint 持续增长候选 | 反复进出同一功能模块后 Physical Footprint 呈阶梯状增长；应用在无明显报错的情况下退回桌面 | 提示可能存在内存持续增长，若接近系统压力阈值可能与终止事件相关 | Physical Footprint 增长本身不等于泄漏，也不是 Jetsam 的唯一判据；需要结合系统终止证据与重复实验（N+1 循环法）确认，不能仅凭内存曲线和"消失"这一现象直接确诊为 Jetsam |
| 主线程长时间无响应候选 | 界面持续无响应；APP CPU 长时间维持高位；应用随后退出 | 提示可能是主线程被长时间阻塞（死循环/死锁/超时同步调用），达到系统响应性保护机制介入的可能性；具体多长时间会被系统判定超时，不同生命周期事件的阈值不完全相同，且非本项目验证过的数字 | 需要结合系统崩溃日志（若可获取）与调用栈确认，Perfowl 当前证据不能单独确认是否命中了系统看门狗机制 |
| 环境噪声污染候选 | Device Total CPU 或 Device Network 异常高位；被测 App 的 APP CPU 与 Process Network 处于低位；未观察到与被测 App 对应的资源压力 | 提示可能存在系统或其他 App 的后台活动干扰（如系统同步、系统更新下载） | 建议清理后台环境后复测对比，同窗相关性不能证明"与被测 App 完全无关"，只能提示噪声可能性较高 |
5. 规范 Bug 提单模板示例（诚实标注证据层级）
markdown
【性能观察】[主线程 I/O 候选] 点击本地草稿箱触发约 520ms 卡顿，同窗观察到磁盘读取尖峰
- 被测设备：设备 A (iPhone 14 Pro, iOS 17.5)
- 测试版本：目标 App A (v4.5.0, Release)
- 测试场景：点击「我的」→「本地视频草稿箱」进入列表
- 预期指标：流畅切换，FrameTime ≤ 16.7 ms，无 BigJank
- 交叉观察数据 (时间轴定位: 00:32.400 ~ 00:32.920)：
* 屏幕表现：FrameTime 瞬间达到约 521.4 ms
* 进程 I/O：同窗观察到 Disk Read 峰值约 24.8 MB/s，累计约 12.9 MB
* 计算/图形负载：APP CPU 在此期间约 18.2%，GPU Renderer 利用率约 4.1%（提示这两个利用率指标处于较低水平，但不能仅凭此排除 CPU/GPU 相关性）
- 当前证据层级：Level 2（同窗资源相关性）。CPU/GPU 均处于低位，磁盘读取与卡顿同窗，提示主线程同步 I/O 是候选方向之一，但尚未有调用栈证据确认。
- 建议下一步：用 Time Profiler 或对应模块的调用栈确认该 520ms 内主线程实际在执行什么调用，再决定是否提单给研发。
- 附件证据：Perfowl 导出的 Session 完整趋势报告（FrameTime 与 Disk Read 同窗曲线）6. 常见误区
- 把"同一时间窗口内多个指标异常"直接写成"确诊"或"根因"；
- 用"一锤定音"式的语言给出唯一解释，而不列出还需要哪些证据；
- 把 Device scope 指标的异常直接归因到目标 App；
- 把经验症候群组合当作判定树机械套用，忽略每个业务场景的具体差异；
- 把固定的温度、时长等数字当作系统官方判据，而不是需要按场景验证的候选参考。
7. 相关专论深入阅读
8. 版本历史
| 版本 | 日期 | 修订要点 |
|---|---|---|
| v2（本页） | 2026-09-18 | 从"五步交叉诊断法 + 七大临床诊断模型"重构为 Level 0～5 证据层级模型；删除"临床确诊"“一锤定音”“确凿排除”等确定性语言；候选症候群组合全部改为提示性描述并标注还需要什么证据才能升级确认；固定温度/时长阈值改为候选参考并说明不是官方判据。 |
| v1 | 2026-09-15 | 首次发布五步交叉诊断法与七大复合故障诊断模型。 |