在实际项目里，这个版本有点费电往往是一个很模糊的反馈。
测试同事觉得发热，产品感觉续航下降，但真正落到工程层面，经常卡在一个点上： 耗电行为发生在什么场景、由谁触发、持续了多久。

电耗管理不是单一工具能解决的事，它更像是一个组合过程。下面我结合一次比较完整的 iOS App 电耗分析过程，说说我是如何把系统工具和第三方工具一起用起来的。

先确认：系统眼里的耗电到底是谁

在动任何测试工具之前，我通常会先看系统层面的判断。

系统电池使用记录的作用

iOS 自带的【设置 → 电池】其实非常有价值，它能回答两个基础问题：

• 这段时间主要耗电的是不是这个 App
• 耗电发生在前台，还是后台

这一步不能精确到函数级别，但它能帮你避免一个常见误判：
其实是后台任务或推送导致的耗电，却被误以为是某个页面性能问题。

如果系统记录显示耗电主要集中在前台使用阶段，才值得继续往下拆。

场景复现，比跑一次测试重要得多

电耗问题高度依赖使用路径。
同一个 App，刷列表和播放视频的耗电曲线完全不同。

我一般会做两件事：

• 固定测试场景（例如连续滚动列表 5 分钟）
• 固定测试环境（亮度、网络、设备型号）

这样后面的数据才有可比性。

用 Xcode Instruments 看，但别一上来就陷进去

Instruments 的 Energy Log 非常强，但也非常容易让人迷失在指标里。

我自己的习惯是：

• 不在第一次测试就打开 Instruments
• 先确认有没有 明显异常趋势

克魔在电耗管理里的实际作用

在进入 Instruments 之前，我会先用 克魔（KeyMob） 做一轮轻量监控，它主要承担三个功能点，而不是“全功能性能分析”。

察 CPU 是否长期异常活跃

电耗和 CPU 使用高度相关。
如果在用户“看起来什么都没做”的情况下，CPU 曲线持续抬高，本身就已经是一个问题。

怎么做：

1. 连接设备，打开克魔
2. 进入【性能图表】
3. 勾选 CPU 指标
4. 选择目标 App
5. 按既定使用路径操作

如果 CPU 在静止页面仍频繁波动，这时就值得警惕后台任务或定时逻辑。

配合实时日志，确认“谁在工作”

单看曲线只能知道“有问题”，但不知道“是谁”。

这时我会同时打开克魔的实时日志。

实际操作：

• 左侧进入【实时日志】
• 设置只看当前 App
• 保留关键模块的日志输出

有些电耗问题，本质是无意义的重复逻辑，比如：

• 定时刷新没有正确停止
• 页面退出后线程仍在跑

这些往往能直接在日志里看到。

长时间运行，比峰值更有价值

电耗管理不太看瞬时峰值，而更关注 持续性行为。

克魔的性能图表在这里有一个实用点：
它可以在不打断用户操作的情况下，持续观察资源变化。

我通常会：

• 让 App 在目标页面停留 10–20 分钟
• 观察 CPU 是否逐步抬升
• 对照实时日志，看是否有周期性输出

如果资源使用呈“锯齿状规律”，基本可以判断存在定时或轮询逻辑。

回到 Instruments，验证和定位

当以上步骤已经明确“问题存在”，再回到 Instruments 的 Energy Log，效率会高很多。

这时你已经知道：

• 哪个页面
• 大概发生在什么时间段
• 是否与 CPU 或后台任务相关

再去看 Wakeups、Network、CPU Activity，基本不会迷路。

最后一个经验是 电耗优化往往是回归问题，而不是一次性问题。

每次功能改动后，最好用同样的场景再跑一遍对比：

• 系统电池记录
• 克魔的 CPU 曲线
• 关键日志是否变化

这样你才能确定是“真的优化了”，而不是“感觉好了一点”。

参考链接：https://keymob.com/tutorial/zh/1/1.html