2、功耗分析工具链：BatteryStats、dumpsys batterystats、batterymanager、功耗分析平台搭建
说到功耗分析，很多同学第一反应就是「拿个电流表测一下」。嗯，这确实是最直接的方法，但说实话，在Android系统层面，我们更需要的是软件层面的精细化分析工具。今天我就带大家把这套工具链捋一遍。
2.1 BatteryStats：系统自带的「黑匣子」
BatteryStats 是 Android 系统内置的一个服务，它就像飞机的黑匣子一样，默默记录着所有与功耗相关的事件。我个人习惯把它叫做「功耗日志器」——它不直接告诉你功耗是多少，但它记录了所有能推导出功耗的原始数据。
它的核心职责包括：
- 记录每个应用（UID）的CPU使用时间
- 记录网络活动（WiFi、移动数据、蓝牙）的时长和流量
- 记录传感器（GPS、加速度计等）的使用情况
- 记录唤醒锁（WakeLock）的持有时间和次数
- 记录屏幕亮度和亮屏时间
我在项目中遇到过一个问题：某个第三方应用在后台疯狂唤醒手机，导致一晚上掉电30%。当时就是靠 BatteryStats 抓到了它的唤醒锁记录，才定位到问题的。
核心要点：BatteryStats 的数据是「增量式」的，每次充电或重启后会重置。所以分析时要确保数据是在一个完整的放电周期内采集的。
2.2 dumpsys batterystats：把黑匣子数据读出来
光有 BatteryStats 记录数据还不够，我们得能把它读出来。这时候 dumpsys batterystats 就派上用场了。它其实就是 BatteryStats 的「读卡器」。
基本用法很简单：
adb shell dumpsys batterystats但这样输出的内容非常冗长，我一般会加上一些参数来过滤：
# 重置统计信息（建议在测试前执行）
adb shell dumpsys batterystats --reset
# 输出指定应用的数据
adb shell dumpsys batterystats --charged <package_name>
# 输出历史数据（时间线）
adb shell dumpsys batterystats --history这里有个小技巧：--charged 参数会输出从上次充满电到现在的完整统计。我每次做功耗测试前，都会先执行 --reset，然后跑测试用例，最后用 --charged 导出数据。这样数据干净，分析起来也省心。
我的经验：如果你觉得命令行输出太难看，可以用 dumpsys batterystats --history 导出历史数据，然后用 Python 脚本解析成 CSV 格式，导入 Excel 里做图表分析。我曾经用这个方法帮团队定位过一个「每5分钟唤醒一次」的定时器问题。
2.3 BatteryManager：系统广播里的功耗情报
BatteryManager 不是一个独立的工具，而是 Android 系统提供的一个系统服务接口。它通过广播（Intent）的方式，实时通知应用当前的电量状态。
常用的广播动作包括：
ACTION_BATTERY_CHANGED：电量变化时触发，包含电量百分比、电压、温度、充电状态等ACTION_POWER_CONNECTED/ACTION_POWER_DISCONNECTED：插拔充电器时触发ACTION_BATTERY_LOW：电量低于阈值时触发
在开发调试阶段，我们可以用 dumpsys battery 来模拟各种电池状态：
# 查看当前电池状态
adb shell dumpsys battery
# 模拟电池电量（比如设为50%）
adb shell dumpsys battery set level 50
# 模拟充电状态
adb shell dumpsys battery set status 2 # 2表示正在充电
# 重置为真实电池状态
adb shell dumpsys battery reset为什么要模拟？你想想看，有些功耗问题只在特定电量下才会出现。比如低电量时系统会触发省电模式，这时候某些后台服务的行为会发生变化。我曾经就遇到过一个问题：某个应用在电量低于20%时会频繁请求GPS定位，导致耗电异常。当时就是用 dumpsys battery set level 15 模拟出来的。
注意：模拟电池状态后，一定要记得执行 dumpsys battery reset 恢复真实状态。否则系统会一直使用你设置的虚拟值，影响正常使用。我有个同事就因为这个，手机一直显示「充电中」整整两天...
2.4 功耗分析平台搭建：从「临时工」到「正规军」
前面说的都是单次、手动的分析方法。但在实际项目中，尤其是做系统级功耗优化时，我们需要一个持续、自动化的功耗分析平台。说白了，就是把上面这些工具串起来，做成一个自动化的流水线。
我分享一下我个人搭建平台的思路：
2.4.1 数据采集层
这是最底层，负责从设备上拉取原始数据。我一般用 Python 脚本配合 adb 实现：
# 伪代码示例
def collect_battery_stats(device_id, duration_minutes):
# 1. 重置统计
adb(f"-s {device_id} shell dumpsys batterystats --reset")
# 2. 等待指定时间（或执行测试用例）
time.sleep(duration_minutes * 60)
# 3. 导出数据
adb(f"-s {device_id} shell dumpsys batterystats --charged > raw_data.txt")
# 4. 同时采集其他数据（如CPU频率、温度等）
adb(f"-s {device_id} shell cat /sys/class/power_supply/battery/uevent > battery_info.txt")2.4.2 数据解析层
原始数据是文本格式，需要解析成结构化数据。我习惯用 Python 的 re 模块做正则解析，然后存入 SQLite 数据库。这样方便后续做历史对比。
2.4.3 可视化层
数据解析出来之后，用图表展示会更直观。我推荐用 Grafana + InfluxDB 的组合，或者简单点用 Python 的 Matplotlib 生成静态报告。关键指标包括：
- 各应用CPU使用时间占比（饼图）
- 唤醒锁持有时间趋势（折线图）
- 网络活动与电量消耗的关联（散点图）
- 不同场景下的功耗对比（柱状图）
2.4.4 自动化触发层
最后，用 Jenkins 或 GitLab CI 定时触发整个流程。比如每天晚上10点自动跑一轮功耗测试，第二天早上就能看到报告。我之前的团队就是这样做的，效果非常好——把功耗问题从「事后救火」变成了「日常巡检」。
平台搭建的核心原则：
- 可重复性：每次测试的环境、条件要一致
- 可对比性：不同版本、不同设备的数据要能横向对比
- 可追溯性：每个数据点都能追溯到原始日志
2.5 避坑指南
最后，分享几个我踩过的坑：
- 不要相信第一次采集的数据：系统刚启动时，BatteryStats 的数据可能不准确。我习惯先跑一轮「预热」测试，再开始正式采集。
- 注意多用户场景：如果设备有多个用户（比如工作资料），BatteryStats 的数据是按用户隔离的。分析时要注意当前是哪个用户。
- dumpsys 输出可能被截断：当数据量很大时，adb 的输出可能会被截断。建议用
adb shell dumpsys batterystats > local_file.txt重定向到本地文件。 - 模拟电池状态后别忘了 reset：这个我前面提过，但还是要再强调一遍——真的很容易忘！
好了，这套工具链就讲到这里。下一章我们会深入 BatteryStats 的源码，看看它到底是怎么记录这些数据的。到时候你会发现，很多「黑盒」其实都是「灰盒」——只要肯往下挖，总能找到答案。