12、Battery Historian：Battery Historian工具介绍、如何抓取bugreport、分析电量消耗
做Android系统开发这些年，我遇到过不少用户抱怨手机耗电快的案例。有的说待机一晚上掉电20%，有的说看个视频手机能煎鸡蛋。说实话，很多问题光靠猜是没用的。你得有数据，得有工具。
Battery Historian就是Google官方给咱们准备的一把利器。它能把系统里那些乱七八糟的电量日志，变成一张张直观的图表。你一眼就能看出，到底是哪个App在后台偷偷干活，还是哪个硬件模块没睡好觉。
12.1 Battery Historian是什么？
说白了，Battery Historian是一个基于Web的分析工具。它读取的是Android系统生成的bugreport文件，然后解析里面的电量统计信息，用时间轴的方式展示出来。
我个人习惯把它叫做「电量侦探」。为什么？因为它能帮你找到那些隐藏的耗电元凶。比如某个App每隔几分钟就唤醒一次系统，或者Wi-Fi模块一直没进入休眠状态。
Battery Historian支持两种模式：一个是本地模式（用Python启动Web服务），另一个是Docker模式。我建议新手直接用Docker，省去环境配置的麻烦。
12.2 如何抓取bugreport？
抓bugreport是分析电量消耗的第一步。嗯，这里要注意，抓取的时机和方法直接影响分析结果。
我一般分三步走：
- 重置电量统计 - 确保数据从零开始
- 复现问题场景 - 让耗电问题暴露出来
- 导出bugreport - 抓取完整日志
12.2.1 重置电量统计
在开始测试之前，先清空历史数据。这样后面抓到的数据才干净。
# 重置电池统计数据
adb shell dumpsys batterystats --reset
# 确认重置成功
adb shell dumpsys batterystats | grep "Statistics since"我曾经犯过一个错误：没重置就直接抓数据，结果分析了一堆历史记录，浪费了大半天时间。所以这个步骤千万别省。
12.2.2 复现问题场景
重置之后，让手机正常使用一段时间。比如你要分析待机耗电，就把手机放那不动，等个4-6小时。如果是看视频耗电，就播放半小时视频。
我个人建议至少收集2小时以上的数据。太短的数据看不出规律，太长又没必要。2-4小时是个比较合适的窗口。
12.2.3 导出bugreport
复现完成后，马上抓取bugreport：
# 抓取完整bugreport
adb bugreport bugreport_$(date +%Y%m%d_%H%M%S).zip这个命令会生成一个zip文件，里面包含了dumpsys、logcat、内核日志等所有信息。Battery Historian主要用的是里面的batterystats数据。
12.3 分析电量消耗
拿到bugreport之后，就可以用Battery Historian分析了。我习惯用Docker方式启动：
# 拉取镜像
docker pull gcr.io/android-battery-historian/stable:3.0
# 启动服务
docker run -p 9999:9999 gcr.io/android-battery-historian/stable:3.0然后在浏览器打开 http://localhost:9999，上传刚才抓到的bugreport文件。
12.3.1 时间轴概览
上传之后，你会看到一张密密麻麻的时间轴图。别慌，咱们先看几个关键指标：
| 指标 | 含义 | 重点关注 |
|---|---|---|
| Screen | 屏幕开关状态 | 灭屏后是否还有异常唤醒 |
| Top App | 前台运行的App | 是否频繁切换 |
| Wake Lock | 唤醒锁持有情况 | 是否有App长时间持有不释放 |
| Wifi | Wi-Fi连接状态 | 灭屏后是否持续扫描 |
| Mobile Radio | 移动网络状态 | 信号弱时是否频繁切换 |
你想想看，如果屏幕关了，但Wake Lock那一栏还有大片的蓝色块，说明有App在后台锁着系统不让睡。这就是典型的耗电问题。
12.3.2 系统状态分析
Battery Historian会把系统状态分成几个层级。我最常用的是「System Stats」面板，里面能看到：
- Total running time - 总运行时间
- Screen on time - 亮屏时间
- Kernel overheat time - 内核过热时间
- Total Wakelock time - 总唤醒锁时间
我记得有一次分析一个项目，发现Total Wakelock time占了总运行时间的60%。这明显不正常。后来顺着时间轴一查，发现是一个第三方SDK在后台轮询位置信息。
12.3.3 App级别耗电分析
往下翻，你会看到「App Stats」部分。这里列出了每个App的耗电详情：
App Name: com.example.someapp
Wakelock time: 12m 34s
CPU time: 8m 21s
Network usage: 45MB
Number of wakeups: 127重点关注三个数字：
- Wakelock time - 这个App让系统保持清醒的时间
- Number of wakeups - 唤醒系统的次数
- Network usage - 后台网络流量
如果某个App的唤醒次数超过100次/小时，基本可以判定它有问题。我曾经遇到过一个天气App，每小时唤醒系统300多次，就为了刷新天气数据。你说这合理吗？
12.3.4 找出异常耗电模式
分析的时候，我习惯用「排除法」：
- 先看系统级耗电（屏幕、Wi-Fi、信号）
- 再看App级耗电（唤醒锁、CPU、网络）
- 最后看具体的时间段（夜间待机、使用高峰期）
举个例子，如果夜间待机时，Mobile Radio一直处于高功率状态，那可能是信号不好导致手机频繁搜网。这种问题光靠优化App是没用的，得从射频层面解决。
12.4 实战案例：分析待机耗电
最后，我分享一个实际案例。有一次测试发现某款手机待机一晚掉电15%，正常应该在3%以内。
抓取bugreport后，Battery Historian显示：
- Screen全程关闭（正常）
- Wake Lock在凌晨2点到5点持续被持有（异常）
- 持有者是
com.google.android.gms（Google Play服务） - 具体原因是
*alarm*:com.google.android.gms.measurement
进一步分析发现，是Google Analytics的测量服务在后台频繁上报数据。解决方案是在待机时限制该服务的网络访问，或者调整上报间隔。
你看，如果没有Battery Historian，你可能得花好几天去猜问题。有了它，半小时就能定位到具体原因。
好了，Battery Historian的基本用法就这些。工具本身不复杂，关键是要养成「用数据说话」的习惯。下次遇到耗电问题，别急着骂App厂商，先抓个bugreport看看。