Perfowl

外观

Energy/Battery/Thermal 技术演进与实验 ​

2026-10-26 · Energy三项专项与剩余暂停范围 ​

10月25日Total、CPU、GPU软件能耗成本各自新完整5/5正式通过；本页9月“只有静止短场景”的状态已过时，保留作历史。当前网络/定位/显示/Overhead、三项电学量、两项温度和系统热状态暂停，不因本节复盘恢复。

实验与机制：Total600固定槽/1,444条Energy源、CPU600槽/1,504源、GPU600槽/1,475源；GPU受控负载完成20,281次真实Metal工作。每项绑定新Raw、目标生命和host新鲜度，来源最多消费一次，旧值不因每秒发布而续命；设备实际Energy测量窗口仍未验证，非独立物理功耗校准。Total · CPU · GPU。

判断与避免：score不是mW；Total不按分项求和；负哨兵、缺失/非有限或身份不符保留原文并拒绝，真实0与异常归零分开。网络字段曾另立版本化局部质量合同，当前修复/准入仍未完成，不可沿用成其它Energy通用规则。前台和thermal状态必须独立读取，组合文案不能唯一归因锁屏/热；nominal冷却不等于任意物理温度合格。网络未完成方案。

USB供电时电池门禁生效不等于battery-only 数据已验；独立参考必须明确测量对象，外部USB功率不能验证电池侧功率，外壳温度也不能当电池传感器。软件cost、实际电学量、温度/枚举始终三层分开。

本节E1复盘，正式范围仍55/66；实验方法索引给出复现与证据边界。

1. 当前结论先放前面 ​

  • Process Energy Cost（七项）已完成产品化，是本领域证据状态最好的一组：iOS 17/18 真机证明了来源、身份核验、负值哨兵与交付闭环（CORE-19），自校准器 13 项中有 9 项取得有效数值，Energy 相关分项全部在内。
  • Battery Current/Voltage/Power 的 fail-closed 门禁逻辑本身已验证正确（CORE-20：USB 供电下正确输出 null），但截至最新已整理的 devlog 时间线，从未取得过一次真实的 battery-only 放电数值——产品状态是 Unsupported，不是 candidate。
  • ThermalStatus 审计过 Battery IORegistry 、完整 IOService 平面、MobileGestalt 与当前 DVT/Diagnostics 接口，未发现可靠的跨 iOS 版本稳定当前值来源（p2-p5-foundation-self-calibration-result.md），保持 Partial，不用电池温度或 Energy thermal cost 代替推断。
  • Battery Temperature 独立于电学门禁，可以在 USB 连接时正常产出，这是它与 Current/Voltage/Power 的关键差异。

2. 最初工程问题是什么 ​

Energy、Battery、Thermal 三者在早期讨论中容易被当作同一件事的三个视图（“App 越耗电，电池越烫，系统越降频”），但它们来自不同系统服务、不同 scope，也有完全不同的证据状态：Energy 是 Debug Gauge 的 source-native cost；Battery Electrical 的目标语义是 battery-only 条件下的设备级电学量，但当前仍未取得一次通过该门禁的真机数值；Thermal Status 是系统热状态候选，而且稳定来源尚未关闭。第一代工程问题是：要不要、能不能把这三层强行折算成同一个“能耗健康分”，以及在证据不足时是否可以用近似值或固定阈值顶上。

3. 第一代方案与为什么当时合理 ​

CORE-10（2026-09-05，公式冻结批次）确立的第一代方案是"原样透传 + 不猜测"：Energy cost 字段原样承接、不转换成瓦特；Battery Current/Voltage 原始值取绝对值输出 candidate；Battery Temperature 原始值原样保存为 source-native（不预设是摄氏度还是百分摄氏度）；ThermalStatus 原始枚举值原样保存，映射关系保持 candidate。这在当时是合理的：七个 Energy 字段、Battery 三项电学量、Temperature、ThermalStatus 都还没有经过真机验证，贸然定义换算公式风险更高。

4. 暴露出的真实问题 ​

第一代方案投入真机验证后暴露出三类真实问题：

  1. Energy 负值：energy.*.cost 字段在部分窗口会返回负数（源哨兵行为，语义不是"负成本"），如果直接展示会出现类似 "-10" 的误导性曲线。
  2. Battery 电学量在 USB 连接下没有物理意义：早期方案没有区分"电池正在充电/外接供电"与"电池纯放电"，如果不加门禁，USB 连接下的电流读数会被误当作放电功耗。
  3. Temperature 与 ThermalStatus 的量纲/语义都不确定：Temperature 原始值范围约 0–8000，需要验证是否是百分之一摄氏度；ThermalStatus 的 0–3 候选映射（Normal/Fair/Serious/Critical）也需要验证来源是否稳定。

5. 候选方案 A：Energy 负值哨兵化（CORE-19） ​

  • 假设：energy.*.cost 的负值是源端的一种特殊标记（sentinel），不是真实的负成本。
  • 配置：Total 为负时，七项全部标记 source-sentinel 并整帧关闭；单项为负时只使该项 missing，不影响其余六项；身份未核验时标记 identity-unverified；字段存在且通过门禁的真实 0 予以保留，不当缺失处理。
  • 实验（E4，iOS 17 设备 A / iOS 18 设备 B）：iOS 17 最终打包 Collector 产生 4 个 Energy raw event，四组质量均为 source-sentinel，value=null（负 Total 被正确整帧关闭，不再显示类似 "-10" 的曲线）；iOS 18 产生 3 个 Energy raw event，三组质量均为 candidate，真实源值 0 被保留。
  • 判定：负值哨兵化方案在两套系统上表现一致，且没有产生假 0 或假负数，判定为最终方案的一部分，继续使用。

6. 候选方案 B：Battery Only 门禁（CORE-20） ​

  • 假设：只有 ExternalConnected=false 且 IsCharging=false 且 InstantAmperage<=0（放电方向）同时成立时，电流/电压/功率才有物理意义。
  • 配置：Device Condition 改为"首次立即 + monotonic 固定 deadline 20 秒"节拍，超时跳过已错过窗口，不做追赶式补发（避免高频轮询干扰被测机电源管理，符合仓库"轻量化与执行效率门禁"）；门禁不成立时三项一律 value=null 并标记 external-power-connected，不发布 0 或符号不明的电流。
  • 实验（E4）：iOS 17/18 最终打包 Collector 各产生 2 个 Device Condition raw，两次采样间隔实测 19.983423547s / 19.987156217s（与 20 秒设计目标一致）；两套系统均报告 ExternalConnected=true、IsCharging=false，因此 Current/Voltage/Power 三项均正确输出 null / external-power-connected。
  • 判定：fail-closed 逻辑与 20 秒节拍本身验证通过（E4），继续使用；但这次实验没有一次是在真正 battery-only 状态下完成的——两台设备当时都连着外部电源。这是候选方案 B 目前唯一被证实的部分；"断开 USB 后数值长什么样"仍是完全开放的问题。

7. 候选方案 C：ThermalStatus 稳定来源探索 ​

  • 假设：诊断接口的 ThermalStatus 字段能提供跨 iOS 版本稳定的 0–3 当前值。
  • 实验：CORE-20 来源审计 + 自校准器复测（p2-p5-foundation-self-calibration-result.md）审计了 Battery IORegistry、完整 IOService 平面、MobileGestalt 与当前 DVT/Diagnostics 接口，iOS 17/18 两组条件快照均未观察到稳定的 0–3 字段（均为 missing / source-missing）。
  • 判定：候选方案 C 目前未成功，没有找到可跨 iOS 版本验证的稳定当前值源，因此保持 Partial，不发布 candidate 级的枚举映射结论；也明确排除了"用电池温度或 Energy thermal cost 反推 ThermalStatus"这条捷径，因为那不是当前团队验证过的方法，混用会掩盖来源本身未确认的事实。

8. 被证伪路线与停止条件 ​

  • 用固定温度数字映射 Thermal State（如"35/38/41℃ 对应 nominal/fair/serious/critical"）：当前 devlog 没有证据支持这类映射来自 Apple 官方或本项目实测校准，属于未经证据支持的经验数字，本轮知识库重排已从各 Canonical 页删除。
  • 用电池温度或 Energy thermal cost 代替 ThermalStatus：p2-p5-foundation-self-calibration-result.md 明确记录"不用温度或 Energy thermal cost 推断"，这是审计后明确排除的捷径，不是候选方向。
  • 在 USB 连接下展示电池"放电"数值：第一代方案的隐患，CORE-20 的 battery-only 门禁正式停止了这条路线。

9. 最终方案为什么胜出 ​

当前方案（CORE-19 + CORE-20 冻结的组合）胜出的原因是：它在三个独立维度上都坚持"没有证据就不发布数值"——Energy 负值不显示为负成本、Battery 电学量在非 battery-only 条件下不显示为 0 或伪造放电值、ThermalStatus 在来源不稳定前不发布候选枚举映射。这与仓库 AGENTS.md 的诚实红线（"未 E4 不描述为可用；缺值不得写成 0；候选值必须带 candidate 标注"）直接对应，代价是 Battery 与 ThermalStatus 目前对使用者可见度较低，但避免了产出误导性数字。

10. 从 POC 到产品化又踩了什么坑 ​

  • Energy 的静止短场景（页面静置、无操作）没有产生可用于数值校准的非零变化，导致"负载响应"这一验收项在 CORE-19 结束时仍标记未关门——真机验证需要覆盖前台静止、CPU、GPU、网络、定位、显示等多种负载场景，不能只用一种场景外推所有场景下的行为。
  • 20 秒的 Device Condition 采样节拍是在"数据新鲜度"与"轻量化门禁（避免高频轮询干扰被测机电源管理）"之间权衡的结果，不是任意选择；后续如果要提高频率，需要重新评估对被测设备电源子系统的影响。
  • Battery-only 门禁虽然逻辑验证通过，但两次真机验收都恰好发生在外接电源状态下，说明"验证门禁逻辑正确"和"取得目标数据"是两件独立的事，不能因为前者达成就默认后者也已完成。

11. 当前仍未关闭的门禁 ​

  • Battery Current/Voltage/Power：需要物理断开 USB 与充电器、保持 Wi-Fi 配对，运行至少 40 秒 Session，取得第一组真正 battery-only 的真机数值。
  • ThermalStatus：需要找到可跨 iOS 版本验证的稳定 0–3 当前值来源；在此之前不升级为 candidate 生产可用。
  • Energy：负载响应场景覆盖不全（静止短场景无有效数值变化），且与 PerfDog 等第三方工具的同窗数值对齐尚未开始。
  • 三层证据（软件成本分 / 电学量 / 温度与状态）之间目前没有交叉校准，不能用其中一层验证另一层。

12. 可复用工程经验 ​

  • source-native 优先于猜测单位：面对私有算法或未公开量纲的字段（Energy cost、Temperature raw、ThermalStatus enum），先原样保存、标 candidate，再逐步积累证据升级，不要在第一版就定义换算公式。
  • 门禁逻辑验证与数据验证要分开记录：CORE-20 的经验是，"fail-closed 正确工作"和"取得目标场景下的真实数据"是两个独立的验收项，必须分别标注证据等级，不能因为前者通过就把后者也算作完成。
  • 负值/异常值优先当哨兵处理，而不是过滤或归零：energy.*.cost 的负值哨兵化方案证明，把异常值标记为特定质量状态（而不是静默丢弃或写 0）能同时保留可观测性和避免误导。

13. 原始 devlog 索引 ​

14. 继续阅读 ​

版本历史补记 ​

日期修订来源
2026-10-26补本月实验结论、失败路线与适用限制；早期阶段数字保留月度梳理

Perfowl · Performance Observer

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