13、dumpsys batterystats：用命令揪出耗电元凶
各位同学，今天我们来聊聊 Android 系统里一个非常实用的调试工具——dumpsys batterystats。说白了，它就是系统内置的「电量侦探」，能帮你查清楚电量到底被谁偷走了。
我个人习惯在开发测试机上一周跑一次这个命令。为什么呢？因为很多耗电问题不是马上能复现的，需要长时间观察。你想想看，用户抱怨手机耗电快，你总不能说「重启试试」吧？
13.1 命令怎么用？
先说说最基本的用法。打开终端，连上设备，输入：
adb shell dumpsys batterystats嗯，这里要注意，这个命令会输出非常多的信息。我第一次跑的时候，屏幕刷了整整两页，差点看花眼。所以我建议你加上一些参数来过滤：
# 只看某个应用的耗电情况
adb shell dumpsys batterystats --charged <包名>
# 重置统计信息（建议测试前先重置）
adb shell dumpsys batterystats --reset
# 输出更详细的唤醒锁信息
adb shell dumpsys batterystats --wakeup我在项目中遇到过一个问题：测试同学说某个版本耗电异常，但 log 里看不出什么。后来我用了 --reset 重置统计，然后让手机正常使用半天，再 dump 出来一看，真相大白。
13.2 输出解读：看懂这些数字
命令执行后，输出内容大致分为几个区块。我挑几个重点给你讲：
| 区块名称 | 含义 | 重点关注 |
|---|---|---|
| Global Battery Info | 全局电池信息 | 电池容量、剩余电量、温度 |
| Per-PID Battery Stats | 每个进程的耗电统计 | CPU 时间、唤醒次数 |
| Uid Battery Stats | 每个应用（UID）的耗电 | 前台/后台时间、网络流量 |
| Wakeup Reason Stats | 唤醒原因统计 | 谁把手机唤醒了 |
举个例子，输出中你会看到类似这样的内容：
Uid 10123:
Wakeup alarms: 342 times
CPU time: 12m 34s
Foreground time: 8m 12s
Background time: 4m 22s
Network: 234 MB received, 56 MB sent看到这个数字了吗？Wakeup alarms: 342 times，这个应用在后台唤醒了手机 342 次。你想想看，每次唤醒都要点亮屏幕、启动 CPU，电量就这么一点点被吃掉了。
关键指标速查：
- Wakeup alarms：唤醒次数，越高越耗电
- Background time：后台运行时间，过长说明有常驻后台行为
- Network：网络流量，频繁联网会唤醒射频模块
13.3 定位耗电应用：三步走
好了，现在你知道怎么看输出了。那怎么找到「耗电元凶」呢？我一般按这三步来：
- 先看全局：检查电池温度是否过高（超过 40°C 就要警惕），剩余电量下降曲线是否异常。
- 再看 UID 排行：按 CPU 时间或唤醒次数排序，找出 TOP 3 的应用。
- 最后看细节：针对可疑应用，查看它的唤醒锁（Wake Lock）和闹钟（Alarm）记录。
我曾经遇到一个案例：某社交应用在后台每 5 分钟就发起一次定位请求。用户晚上睡觉时手机放在床头，一晚上被唤醒了 200 多次。你说这电量能撑到天亮吗？
小技巧：如果你发现某个应用的唤醒次数异常高，可以用 dumpsys alarm 命令进一步查看是谁注册了这些闹钟。有时候是第三方 SDK 搞的鬼。
13.4 避坑指南
我曾经踩过的坑：
- 不要只看「前台时间」——有些应用前台时间很短，但后台唤醒次数很多，这才是真正的耗电大户。
- 注意「累计统计」——
batterystats默认是从上次充电开始统计的。如果你刚充过电，数据可能不准确。建议先--reset再测试。 - 区分「系统应用」和「第三方应用」——系统服务（如 Google Play 服务）的耗电有时是正常的，不要误杀。
13.5 知识体系图
下面这张图帮你理清整个分析流程：
说白了，这个工具就是你的「电量审计师」。它不会直接告诉你「这个应用有问题」，但会给你足够的数据去判断。我建议你养成习惯：每次发布新版本前，跑一遍 batterystats，看看有没有异常耗电的应用。嗯，这比用户骂上门来再修要省心多了。
公众号:蓝海资料掘金营，微信deep3321