把耗电投诉变成证据

耗电投诉是移动端最难落地的一类反馈。没有时间点、没有步骤、没法把你的 App 和同时醒着的另外六个分开 —— 而用户非常确定，因为设置页上那个图标是你的。

下面是怎么判断他说得对不对。

为什么设置页不是证据

设置 → 电池 给出 24 小时或 10 天内的分应用百分比。投诉就来自这个页面，所以要读它 —— 但要清楚它说了什么、没说什么。

它把能耗归给“这段工作发生时处在前台的那个 App”。一个被打开了两小时的 App，无论它有没有干什么昂贵的事，占比都会很高；这个页面被显示屏主导，而屏幕之所以亮着，是因为那个 App 开着。与此同时，一个整夜每十五分钟醒四秒的 App，几乎不会出现在上面。

所以这个页面回答的是“哪个 App 在屏幕上停留最久”，它和耗电相关，但不是同一个问题。

两类不同的排查

“它跑起来的时候耗多少？” 实时：采一段固定会话，把能耗和 CPU、GPU、网络、定位放在一起读。

“昨晚的电是谁耗的？” 历史：当时没人在看，所以没有采集可用。去读设备自己记下来的东西 —— 每个 App 的运行时段、各自让哪些硬件保持唤醒、归到它头上的能耗。真正能回答“过了一夜”这类投诉的是这个。

用第一种方法去回答第二个问题，是这里最常见的错误，代价是好几个小时得不出结论的采集。

什么最费电，大致排序

行为	为什么
持续精确定位	手机能做的最贵的事之一。静止时还用“最佳导航精度”是纯浪费
让屏幕常亮	显示屏通常是最大的单一消耗方。禁用自动锁屏比任何计算都贵
啰嗦的网络请求	射频最贵的是唤醒。同样字节数，十次批量远好过一百次零散
后台刷新	一次很便宜，每十五分钟一次、永远持续下去就很贵
反复触发的定时器	让 CPU 根本进不了低功耗状态
视频与动画	持续 GPU 加上高亮度屏幕
蓝牙扫描	单次很便宜，而且几乎从来没被真正停掉过

注意这里有多少是关于唤醒而不是关于干活的。手机的电源管理建立在长时间空闲之上，昂贵的模式是阻止它空闲。

一套能得出答案的方法

1. 先读历史。 在采任何东西之前，先看被投诉的那个时间窗里到底跑了什么，按能耗排序。一半的排查在这一步就结束，答案是另一个 App。
2. 如果确实是你的 App，先确定时机。 前台会话、后台唤醒，还是两者都有？这决定了该去读哪部分代码。
3. 实时复现。 充到一个已知电量，拔线，开着采集把可疑交互跑五分钟。
4. 只改一件事。 关掉可疑原因，把完全相同的交互再跑一遍。
5. 对比两次采集。 不是看孤立的数字，是看差值。

常见结论

• 没人停掉的定位管理器。 在某个页面里启动，页面退出时没停，之后跟着进程一直跑。
• 活得比视图久的定时器。 同样的模式，每次更便宜，更难被发现。
• 没有退避的重试逻辑。 一个失败的请求整夜每秒重试一次。字节数微不足道，射频唤醒不是。
• 每条事件都立即上报的埋点。 攒起来批量发。
• 一个“很轻量”的后台刷新，实际上同步了所有东西。

怎么写结论

一句“我们看过了，没问题”不算回答。请附上：

• 显示当时跑了什么、各耗多少的历史时间窗
• 改动前后的两次采集
• 你改了什么、为什么改

这把一场争论变成一份记录 —— 这很重要，因为这类投诉往往会再来一次，而下次你会希望上一次的排查还读得懂。

如果确实不是你

有时答案是用户装了一个自己都忘了的定位型 App，或者那台设备的电池只剩 74% 容量、循环 900 次。那就把数据摆出来说清楚。这比花一周去优化一个从来不是问题的东西，结果好得多。