在做 iOS 开发的这些年里，“能耗”一直是个有点尴尬的话题。
它不像崩溃那样有明确的错误信息，也不像卡顿那样立刻可见。更多时候，问题是从用户的一句话开始的：最近这个版本有点费电。

这句话对工程师来说信息量其实非常低，但又很难忽略。
因为在 iOS 体系里， App 的使用记录与能耗，确实不是一个随手就能看清楚的东西。

能耗问题，很少只靠“感觉”就能确认

最初遇到这类反馈时，我也试过最直接的方式：
在自己的手机上用一会儿，看电量掉得快不快。

但很快就发现，这种方式几乎没有参考价值：

• 使用时间不一致
• 操作路径不同
• 网络、亮度、后台状态都在变化

真正有意义的，还是 可追溯的使用记录和能耗数据。

系统层面能看到的，其实比想象中少

iOS 系统本身并不是完全不提供信息。

在系统设置里，可以看到：

• 各个 App 的电池使用占比
• 前台 / 后台消耗时间

这些数据对用户来说很直观，但对开发者而言，问题在于：

• 粒度偏粗
• 无法对应到具体功能
• 看不到过程，只能看到结果

它更像是一个“结果提示”，而不是排查工具。

Xcode 和 Instruments：能耗分析的传统入口

在开发阶段，我通常还是会从 Instruments 入手。

Energy Log 可以看到：

• CPU 活跃情况
• 网络使用
• 定位、传感器调用
• 后台任务行为

它对理解“某一次操作为什么费电”非常有帮助。
但和内存、CPU 类似，它更适合 短时间、可控场景。

一旦问题出现在：

• 长时间使用后
• 多个功能交替
• 前后台频繁切换

单次 Energy Log 很容易遗漏关键阶段。

使用记录，往往比能耗本身更重要

后来在一次版本分析中，我们发现一个有意思的现象：
某些用户并不是单次使用很费电，而是 使用频率和使用方式发生了变化。

这时，单看“电量消耗百分比”已经不够了，更重要的是：

• App 一天被打开了多少次
• 每次使用大概持续多久
• 使用过程中调用了哪些硬件

这其实已经进入了 使用记录分析 的范畴。

把视角放回真实设备，是一个转折点

在这类问题上，我开始更多依赖真机环境，而不是模拟或单点测试。

这里我用到的是 克魔（KeyMob）。

一开始吸引我的，并不是“能耗”本身，而是它可以把下面这些信息放在一起看：

• App 的启动、结束时间
• 使用过程中 CPU、GPU、网络的活跃情况
• 电量变化趋势
• 硬件使用情况

当这些信息放在同一条时间线上时，很多原本模糊的问题会变得具体。

能耗并不总是来自“重操作”

在一次测试中，我们发现一个版本的能耗曲线明显比之前陡。
但仔细看使用记录，会发现：

• 用户的操作并不复杂
• 页面停留时间也不算长
• 真正的差异在于后台行为

通过 KeyMob 的使用记录，可以看到：

• App 在后台仍然频繁唤醒
• 网络请求次数明显偏多
• CPU 活跃时间拉长

这些信息，单靠系统电池统计是很难看出来的。

网络与 WebView，常常是能耗的放大器

在进一步分析中，我们结合了 Charles 和 Safari Inspector。

• Charles 显示弱网环境下存在重试
• Safari Inspector 发现 WebView 页面在后台仍有 JS 定时任务

这些行为单独看都不“重”，
但叠加在一起，就会反映为明显的电量消耗。

这类问题，往往只有在 使用记录 + 能耗 + 行为 同时对照时，才说得清楚。

使用记录的价值，在于解释为什么

慢慢地，我对“查看 App 的使用记录与能耗”这件事有了新的理解：

• 能耗只是结果
• 使用记录是过程
• 行为细节决定趋势

KeyMob 在这里的作用，并不是给出一个“你很费电”的结论，而是让你看到：

• 用户是怎么用的
• App 在什么状态下最活跃
• 能耗是在哪段时间被拉高的

当这些问题有了答案，优化才有方向。

工程实践中常用的一种组合方式

在现在的项目里，针对使用记录与能耗问题，我通常会组合使用：

• 系统电池统计：快速判断是否存在异常
• Instruments（Energy Log）：分析具体操作
• KeyMob：观察真实使用记录与长期能耗趋势
• Charles：确认网络行为
• Safari Inspector：检查 WebView 活跃情况

没有哪个工具是多余的，它们关注的是同一个问题的不同侧面。