如何用数据回应耗电投诉

耗电投诉是移动端最难落实的一类反馈：没有时间点，没有复现步骤，也无法把您的 App 与同时运行的其他六个 App 区分开。而用户却很确定，因为设置页面上显示的是您的 App 图标。

下面介绍如何判断用户的反馈是否属实。

为什么设置页面不能作为证据

设置 → 电池 显示 24 小时或 10 天内各 App 的耗电百分比。投诉正是来自这个页面，因此需要查看它，但要清楚它能说明什么、不能说明什么。

它会把能耗归到「该工作发生时位于前台的 App」。一个被打开了两小时的 App，无论是否执行了高耗电操作，占比都会很高。这个页面的数据主要由屏幕耗电决定，而屏幕亮着是因为该 App 处于打开状态。与此同时，一个整夜每 15 分钟唤醒 4 秒的 App，几乎不会出现在这个页面上。

因此，这个页面回答的是「哪个 App 在屏幕上停留时间最长」。这与耗电相关，但并不是同一个问题。

两类不同的排查

「App 运行时耗电多少？」 实时排查：采集一段固定的使用过程，将能耗与 CPU、GPU、网络、定位数据对照分析。

「昨晚的电量被谁消耗了？」 历史排查：当时无人监测，没有采集数据可用。此时需要查看设备自身记录的数据：每个 App 的运行时段、使哪些硬件保持唤醒，以及归属于它的能耗。能回答「过了一夜电量大减」这类投诉的正是这些数据。

用第一种方法回答第二类问题，是最常见的错误，结果往往是花费数小时采集却得不出结论。

主要耗电行为（大致按耗电量排序）

行为	原因
持续精确定位	设备上耗电最高的操作之一。静止时仍使用「最佳导航精度」完全是浪费
保持屏幕常亮	屏幕通常是最大的单一耗电来源。禁用自动锁屏比任何计算都耗电
频繁的网络请求	射频模块最耗电的是唤醒。传输相同字节数，10 次批量请求远优于 100 次零散请求
后台刷新	单次开销很小，但每 15 分钟一次、长期持续就会很耗电
反复触发的定时器	使 CPU 无法进入低功耗状态
视频与动画	持续占用 GPU，并需要高亮度屏幕
蓝牙扫描	单次开销很小，但往往没有被正确停止

请注意，其中很多项与唤醒有关，而非与执行的工作量有关。设备的电源管理依赖长时间的空闲，高耗电的模式正是阻止设备进入空闲。

排查方法

1. 先查看历史记录。 在采集任何数据之前，先查看投诉时间段内运行了哪些程序，并按能耗排序。一半的排查到这一步就结束了，答案是其他 App。
2. 如果确实是您的 App，先确定耗电时机。 是前台使用、后台唤醒，还是两者都有？这决定了应检查哪部分代码。
3. 实时复现。 将设备充到已知电量后拔掉电源，开启采集，执行可疑操作 5 分钟。
4. 只修改一处。 去掉可疑的原因，再执行完全相同的操作。
5. 对比两次采集。 关注两次结果的差值，而不是孤立的数字。

常见原因

• 未被停止的定位管理器。 在某个页面中启动，退出页面时没有停止，此后随进程一直运行。
• 生命周期长于视图的定时器。 模式相同，单次开销更小，也更难发现。
• 没有退避机制的重试逻辑。 一个失败的请求整夜每秒重试一次。传输的字节数微不足道，但射频唤醒的开销不可忽视。
• 每个事件都立即上报的埋点。 应先缓存，再批量发送。
• 号称「轻量」的后台刷新，实际上同步了全部数据。

如何撰写结论

仅仅一句「我们检查过了，没有问题」不足以作为答复。请附上：

• 当时运行了哪些程序、各自耗电多少的历史记录
• 改动前后的两次采集结果
• 您修改了什么，以及修改的原因

这样，一次争论就变成了一份记录。这一点很重要，因为这类投诉往往会再次出现，届时您会希望上一次的排查记录依然清晰可读。

如果问题确实不在您的 App

有时原因是用户安装了一个自己都忘记的定位类 App，或者设备电池容量只剩 74%、循环次数已达 900 次。此时请用数据把情况说清楚。这比花一周时间去优化一个本不存在的问题要好得多。