在日常开发中，iPhone 耗电异常 很少以一种"明确的 Bug"形式出现。
更多时候，它是从一句模糊反馈开始的，最近这个版本用着有点费电。
这句话对用户来说已经足够具体，但对工程师而言，却几乎没有直接可用的信息。
真正的问题不是电量掉了多少，而是在什么使用状态下，能耗开始变得不合理。
耗电异常和单次操作无关
第一次遇到类似问题时，我也尝试过最直观的方式，把 App 打开，操作几分钟，看电量变化。
结果通常是------什么也看不出来。
因为 iPhone 的耗电问题，很少是点一下就掉 10%，
更多是：
- 用着用着掉得比以前快
- 屏幕不亮，电量也在缓慢下降
- 没有明显卡顿，但手机发热
这些现象，本质上都和持续的系统活跃状态有关。
系统电池统计，有用但不够
iOS 系统本身提供了电池使用情况统计，可以看到：
- 每个 App 的电量占比
- 前台 / 后台使用时间
这些信息对于判断"是不是这个 App"很有帮助，
但它有一个明显限制： 你看不到过程，只能看到结果。
当你想知道"为什么这个 App 会更耗电"时，它给不了答案。
Instruments 的 Energy Log，很适合解释"某一次"
在开发阶段，我通常会用 Instruments 的 Energy Log 来分析耗电行为。
它能清楚展示：
- CPU 活跃情况
- 网络使用
- 定位、传感器调用
- 后台任务状态
在定位"某个操作为什么耗电"时，它非常有效。
但当问题是：
- 长时间使用后才明显
- 多次前后台切换才出现
- 弱网、后台场景下更明显
Energy Log 的短时间采样，就很容易错过关键阶段。
把耗电问题放回真实使用路径
真正让我对耗电异常有更清晰认识的，是一次比较"笨"的测试方式：
在真机上连续使用 App 很长时间，尽量模拟真实用户行为。
这时，我开始使用 克魔（KeyMob）。
我并不是为了找一个"耗电结论"，而是想观察：
- 使用过程中 CPU、GPU 是否长期活跃
- 网络请求是否在后台持续发生
- 能耗变化是否和某些操作时间点对应
当这些数据被放在一条时间线上时，耗电问题开始变得具体。
耗电异常，往往不是单点问题
在一次测试中，我们发现电量下降明显，但并没有任何"重操作"。
进一步观察后才发现：
- App 在后台仍然频繁唤醒
- 有定时任务没有按预期结束
- 网络在弱网环境下不断重试
单独看每一项，都算不上严重；
但叠加在一起，就会表现为持续耗电。
KeyMob 在这里的作用，是把这些行为同时呈现出来，而不是只看某一个指标。
WebView 场景下，能耗问题更隐蔽
如果 App 中存在 WebView，耗电异常的排查会更复杂。
通过 Safari Inspector，可以看到：
- JS 定时任务是否仍在执行
- 页面退到后台后是否仍有活动
而通过 KeyMob 的能耗与 CPU 变化，可以确认这些行为是否真正影响了系统资源。
在一次排查中，我们就是通过这种对照，发现某个 H5 页面在后台仍然保持活跃状态。
网络行为，常常是耗电的放大器
在另一个案例中，耗电问题最终和网络有关。
使用 Charles 抓包后发现：
- 弱网条件下请求被频繁重试
- 同一接口短时间内多次调用
- 解析与日志输出持续发生
这些行为单独看并不夸张，但在后台状态下，会明显拉高能耗。
经历几次类似问题后，我对 iPhone 耗电异常检测的理解变得更现实了一些。
它是在发现几个更基础的问题：
- App 是否在不该活跃的时候保持活跃
- 后台行为是否符合预期
- 使用模式是否改变了系统负担
KeyMob 在这个过程中，更像是一个观察运行状态的窗口，而不是一个简单的能耗评分工具。
实际工程中常用的一种组合方式
现在在处理耗电相关问题时，我通常会这样配合工具：
- 系统电池统计：判断是否存在异常趋势
- Instruments（Energy Log）：分析具体操作
- KeyMob：观察真机长期能耗与资源活跃情况
- Safari Inspector：检查 WebView 行为
- Charles：分析网络对能耗的影响
这些工具关注的是同一个问题的不同侧面。