外观
能耗、电池与热状态总览：三层证据模型与边界
先看结论
- Process Energy Cost 是 Apple 私有加权算法给出的软件成本分，不是物理单位瓦特（W）或焦耳（J），不能换算成毫安时（mAh）耗电量。
- Battery Current/Voltage/Power 只在设备真正处于纯电池放电状态时才有物理意义；插着 USB 时这三项正确地保持空值，这是 fail-closed 保护，不是采集故障。
- Thermal Status 是系统给出的状态枚举，不是 Perfowl 根据电池温度反推出来的派生值；当前团队没有找到可跨 iOS 版本验证的稳定当前值来源，不用固定温度数字（如 35/38/41℃）映射 nominal/fair/serious/critical。
- 电池温度 ≠ SoC 温度 ≠ 机身表面温度，三者是不同测量点，长稳测试中性能下降与温升同窗出现只能提示 thermal 影响的可能性，不能单独作为确诊依据。
图：四层信号不能互相换算；尤其不能用固定电池温度阈值反推出系统 Thermal Status。
0. 当前实现摘要
本领域覆盖三个独立的证据层：Process Energy Cost（七项 source-native 成本分，经 com.apple.xcode.debug-gauge-data-providers.Energy DTX debug gauge 采集）、Battery Electrical（Current/Voltage/Power 三项设备级电学量，经 com.apple.mobile.diagnostics_relay 诊断接口采集，需 battery-only 门禁成立）、Battery Temperature 与 Thermal Status（同样经诊断接口采集，20 秒固定节拍）。四页由旧版 energy-battery-thermal.md 拆分而来，拆分与冻结依据详见 Energy/Battery/Thermal 技术演进与实验。
1. 这个领域到底观察什么
本领域回答三个不同层级的问题：目标 App 的 source-native Energy cost 如何变化；设备在 battery-only 门禁成立且字段语义得到验证时，电池电流/电压/功率候选值如何；设备当前的电池温度与系统热状态如何。三层不能互相替代，也不能强行折算成同一个“能耗健康分”。
2. iOS 系统原理：三层证据为什么彼此独立
text
[第 1 层：进程软件能耗成本分]
ios.process.energy.* —— Apple Debug Gauge 闭源加权算法给出的相对评分（0 起，无固定上限说明）
│ 与第 2 层的关系：相关但不等价——高 Energy 分不直接等于高放电电流
▼
[第 2 层：设备物理电池电学量]
ios.device.battery.current / voltage / power —— 系统电源管理维护的真实物理量，仅 battery-only 时有意义
│ 与第 3 层的关系：相关但不等价——高放电电流不直接等于高温
▼
[第 3 层：电池温度 / 系统热状态枚举]
ios.device.battery.temperature_* / ios.device.thermal.status —— 热敏传感器读数 与 系统状态枚举，两者也不是同一件事Energy 的加权算法是 Apple 闭源实现，Perfowl 无法也不应重新推导；Battery 电学量的物理意义依赖"是否处于纯电池放电状态"这一前提条件；Thermal Status 概念上类似公开 API ProcessInfo.thermalState 的 nominal/fair/serious/critical 四态，但当前 source 是诊断接口字段，尚未证实与公开 API 语义完全一致。
3. 本领域指标地图
| 指标 | metricID | scope | 回答什么问题 |
|---|---|---|---|
| Process Energy Cost | ios.process.energy.total_cost 等 7 项 | process | 目标 App 的 source-native Energy cost 相对趋势 |
| Battery Electrical | ios.device.battery.current / .voltage / .power | device | battery-only 条件下的放电电学量候选；当前产品状态 Unsupported |
| Battery Temperature | ios.device.battery.temperature_raw / .temperature_celsius | device | 电池自身温度 |
| Thermal Status | ios.device.thermal.status | device | 系统热压力状态；不等价于“已经发生具体降频” |
4. Perfowl 当前怎样取得这些事实
Energy 经 pymobiledevice3 原生 EnergyMonitor(provider, [pid]) 按目标 PID 订阅 Debug Gauge 通道；Battery Electrical / Temperature / Thermal Status 均经 Lockdown 通道下的 com.apple.mobile.diagnostics_relay 诊断服务读取 IOPMPowerSource 电源信息，按"首次立即 + monotonic 固定 deadline 20 秒"节拍采样，超时跳过已错过窗口、不做追赶式补发（详见演进文章第 6 节）。
5. Scope / Identity / Runtime Condition
- Process Energy Cost 是 process scope，经目标 PID 与身份核验过滤；
- Battery Electrical / Temperature / Thermal Status 均是 device scope，反映整机状态，不针对目标 App 单独归因；
- Battery Electrical 额外依赖 battery-only 门禁（
ExternalConnected=false且IsCharging=false且InstantAmperage<=0），门禁不成立时三项一律missing，不产出 0 或符号不明的数值； - Battery Temperature 的采集独立于该电学门禁，USB 连接时仍可正常产出。
6. 指标应该怎样组合阅读
排查“发热/掉电”类问题的推荐顺序：先看 Process Energy Cost 的 source-native 分项趋势 → 若要观察电池物理放电，再看 Battery Electrical（前提：battery-only 门禁成立且字段语义已验证；当前产品状态仍是 Unsupported）→ 关注长稳场景是否伴随温升与帧表现变化，同时看 Battery Temperature 与 FrameTime → Thermal Status（当前来源仍不稳定）只能提供系统热压力状态线索，不能单独证明 CPU/GPU 已经发生具体降频。
7. 常见异常形态：观察 → 候选原因 → 交叉验证 → 不能确认
| 观察到的现象 | 候选原因（需交叉验证） | 下一步验证 | 不能确认的结论 |
|---|---|---|---|
| 页面静止但某个 Energy 分项持续偏高 | 未停止的定位监听、未停止的后台任务等候选方向 | 检查对应能力声明（定位精度/后台模式）与代码是否及时停止 | 不能仅凭 Energy 分值判断具体是哪一行代码 |
| 长时间高负载后帧率明显下降 | 热压力影响、CPU/GPU 高负载或其他资源竞争都可能参与 | 结合 Thermal Status（若证据可信）、Battery Temperature 趋势、APP CPU/GPU 综合判断并做冷却复测 | Thermal Status 或温度变化都不能单独证明“CPU/GPU 已经发生具体降频” |
| Energy Total 出现负值 | 源端哨兵行为（source-sentinel），不是真实负成本 | 检查该窗口质量字段是否为 source-sentinel，不要当作真实负值展示 | 不能把负值当作"能耗为负"的物理事实 |
| USB 连接下 Battery Current/Voltage/Power 显示为空 | fail-closed 保护正常工作 | 确认设备是否连接外部电源；若需要电学数据需物理断开 USB 并保持 Wi-Fi | 不是采集故障，不应尝试"修复"这个空值 |
8. 连续性、质量、missing / 0 / warmup
- Energy 七项：Total 为负时整帧关闭为
source-sentinel；单项为负只使该项missing；身份未核验为identity-unverified；真实 0 予以保留； - Battery Electrical：battery-only 门禁不成立、字段缺失或电流为正（非放电方向）→ 三项均
missing（标记external-power-connected）； - Battery Temperature：字段存在且在合理范围 →
candidate；字段缺失 →missing；判定独立于 Battery Electrical 的门禁； - Thermal Status：字段存在且可解析 →
candidate；来源不稳定或缺失 →missing（source-missing）。
9. 当前证据与平台覆盖（如实披露，这是本领域证据强度差异最大的部分）
- Process Energy Cost：证据状态最好。
CORE-19（2026-09-05）iOS 17/18 真机已证明来源、身份核验、负值哨兵与交付闭环；跨领域自校准器复测显示 13 项中 9 项取得有效数值，Energy 相关分项全部在内。仍未完成：负载响应场景覆盖不全（静止短场景无有效数值变化）、与 PerfDog 等第三方工具的同窗数值对齐。 - Battery Electrical：产品状态
Unsupported。CORE-20（2026-09-05）已验证 fail-closed 门禁与 20 秒节拍本身工作正确（E4：iOS 17/18 各产生 2 个 Device Condition raw，间隔 19.983/19.987 秒），但两次真机验收时设备均处于外接电源状态，截至最新已整理的 devlog 时间线，从未取得过一次真实的 battery-only 放电数值。 - Battery Temperature：产品状态
Partial。已在 iOS 17/18 真机验证可独立于电学门禁正常产出（如 33.09–34.39℃ 范围的真实读数）。 - Thermal Status：产品状态
Partial。已审计 Battery IORegistry、完整 IOService 平面、MobileGestalt 与当前 DVT/Diagnostics 接口，未发现可跨 iOS 版本验证的稳定 0–3 当前值来源，两组真机条件快照均为missing。
详见 Energy/Battery/Thermal 技术演进与实验 的完整实验记录。
10. 常见误区
- 把 Energy Cost 分值当作物理瓦特/焦耳单位，或据此推算 mAh 耗电量；
- 把"USB 连接下 Battery 三项显示为空"当作采集故障，尝试绕过这个保护；
- 用固定温度数字（如"超过 40℃"）直接断定已触发系统 Thermal Throttling；
- 把电池温度当作 SoC 温度或机身表面温度使用；
- 用电池温度或 Energy thermal cost 反推 Thermal Status——这不是当前团队验证过的方法；
- 把
Unsupported（Battery Electrical）或Partial（Temperature/Thermal Status）当作已经生产可用。
11. 指标 Canonical 与技术演进入口
- Process Energy Cost、Battery Electrical、Battery Temperature、Thermal Status
- Energy/Battery/Thermal 技术演进与实验
- Energy/Battery/Thermal 拆分索引（兼容入口）
12. 继续阅读
- 跨指标诊断与证据升级：温升/掉电异常需要结合哪些其他领域证据。
- GPU 与图形硬件总览：长稳测试中 GPU 负载与发热经常同时出现，可交叉参考。
- 技术阅读地图