20. Doze模式与电池历史数据（Battery Historian）：如何分析Doze影响
做Android电源管理这些年，我遇到过最头疼的问题之一就是：明明Doze模式已经开启了，为什么手机待机耗电还是居高不下？
这时候，Battery Historian就是我们的“照妖镜”。它能告诉你Doze到底有没有生效，哪些App在偷偷搞小动作。今天我就带你彻底搞懂这套分析工具。
20.1 为什么需要Battery Historian？
你想想看，Doze模式就像一个保安，它会在手机空闲时把App都关进“小黑屋”。但问题是——你怎么知道保安有没有偷懒？
Battery Historian能回答三个核心问题：
- Doze是否真的进入了？ 系统有没有从Active状态切换到Idle状态
- 谁在阻止Doze？ 哪个App持有了Partial WakeLock，或者频繁使用Alarm
- Doze的效果如何？ 待机电流曲线是否平坦，有没有异常尖峰
核心观点： 没有Battery Historian，你就是在黑暗中摸索。有了它，Doze的每一个动作都清晰可见。
20.2 数据采集：从手机到PC
先说说怎么拿到原始数据。我个人习惯用以下命令：
# 重置电池统计信息（建议先充满电）
adb shell dumpsys batterystats --reset
# 等待一段时间（至少6小时，最好过夜）
# 然后导出数据
adb bugreport bugreport.zip小技巧： 我一般会在晚上10点开始采集，第二天早上8点看结果。这样能覆盖完整的Doze周期。
拿到bugreport.zip后，把它上传到Battery Historian工具。你可以用Google官方的在线版，也可以像我一样在本地搭一个Docker环境：
docker run -p 9999:9999 gcr.io/android-battery-historian/stable:3.0然后浏览器打开 http://localhost:9999，上传zip文件即可。
20.3 关键指标解读：Doze的“心电图”
进入Battery Historian界面后，你会看到一张时间轴图表。我重点看这几个指标：
| 指标 | 含义 | 正常表现 | 异常表现 |
|---|---|---|---|
| Device active | 设备是否处于活跃状态 | 长时间为灰色（非活跃） | 频繁变绿（活跃） |
| Doze | 是否进入Doze模式 | 长时间为蓝色（Doze中） | 蓝色断断续续 |
| WakeLock | App持有的唤醒锁 | 几乎没有红色条 | 红色条密集出现 |
| Alarm | App设置的定时器 | 每小时几次 | 每分钟都在触发 |
| Battery level | 电量变化曲线 | 平缓下降 | 阶梯式下降 |
嗯，这里要注意：Doze模式不是一上来就生效的。系统需要满足几个条件才会进入：
- 屏幕关闭超过30分钟
- 设备静止不动（没有加速度变化）
- 没有正在进行的运动活动
所以如果你看到Doze一直没进入，先检查是不是手机放在桌上不够久，或者有App在频繁唤醒屏幕。
20.4 实战案例：揪出“耗电元凶”
我记得有一次，某款社交App在Doze模式下每小时耗电3%。用户反馈说“晚上充满电，早上起来掉了20%”。
用Battery Historian一看，问题一目了然：
// 在Battery Historian的Alarm标签下，我看到这个App
// 每5分钟触发一次Alarm，而且用的是setExact()方法
// 这意味着它绕过了Doze的Alarm合并机制
// 正常App应该用setAndAllowWhileIdle()或者setAlarmClock()
// 但这款App用了setExact()，导致Doze被频繁打断避坑指南： 我曾经遇到过更隐蔽的情况——App在Doze期间没有直接唤醒，但它注册了ContentObserver监听系统设置变化。每次设置变化都会触发回调，导致App被临时唤醒。这种问题在Battery Historian上表现为“WakeLock”很短但很频繁。
解决方案其实不复杂：
- 让App改用
setAndAllowWhileIdle()替代setExact() - 对于非紧急任务，使用
JobScheduler替代Alarm - 在Doze期间，减少网络请求和传感器监听
20.5 用SVG图看懂Doze分析流程
下面这张图是我自己总结的Doze分析流程，每次排查问题我都会对照着走一遍：
20.6 常见问题与排查技巧
在实际项目中，我总结了几种典型场景：
场景一：Doze从未进入
- 检查是否有App持有
PARTIAL_WAKE_LOCK且未释放 - 检查是否有
SYSTEM_ALERT_WINDOW权限的App在显示悬浮窗 - 检查设备是否在充电（Doze在充电时不会进入）
场景二：Doze频繁退出
- 查看Alarm标签，找出发送频率最高的App
- 查看Network标签，检查是否有App在后台频繁联网
- 查看Sensor标签，检查是否有App在监听加速度传感器
我的经验： 有一次排查了三天，最后发现是系统自带的“天气”App每15分钟刷新一次位置。这种系统级App普通用户根本关不掉，只能通过ADB命令禁用。所以遇到顽固问题，别忘了看看系统App。
20.7 量化Doze效果
最后，我习惯用一组数据来量化Doze的效果：
// 从Battery Historian的Battery Level曲线中提取数据
// 假设待机8小时（480分钟）
// 没有Doze优化时：
// 每小时耗电 2.5%，8小时共 20%
// 电流曲线：频繁波动，平均电流 15mA
// 有Doze优化后：
// 每小时耗电 0.8%，8小时共 6.4%
// 电流曲线：平坦，平均电流 5mA
// 优化效果：待机功耗降低 68%这个数据怎么来的？说白了就是看Battery Historian里“Battery Level”那条线的斜率。斜率越陡，耗电越快。Doze生效时，斜率会明显变缓。
嗯，到这里你应该已经掌握了用Battery Historian分析Doze影响的核心方法。下次遇到待机耗电问题，别急着怀疑硬件，先跑一遍这个流程。你会发现，大部分问题都出在App身上。
公众号:蓝海资料掘金营，微信deep3321