BatteryHistorian页面顶部显示的是设备的基本信息型号、Android版本、内核版本、电池容量等。往下看是电池电量的变化曲线。如果曲线下降得特别陡说明这段时间功耗异常。3.1.1 关键指标解读指标含义正常范围Screen On屏幕亮起的时间段根据使用习惯Wake Lock应用持有唤醒锁的时间单次不超过30秒Top App前台运行的App与用户操作一致Job Scheduler系统调度的后台任务每小时不超过5次Sync数据同步操作每小时不超过3次你看这个表格每个指标都有对应的正常范围。如果某个指标超标了那就是嫌疑对象。3.1.2 实战案例定位异常唤醒拿到一个bugreport用户反映手机待机耗电快。导入BatteryHistorian后我一眼就看到了问题——Wake Lock那一栏有个叫com.example.push的App几乎每5分钟就持有一个唤醒锁每次持续10秒左右。这意味着什么这个App在频繁唤醒系统导致CPU无法进入深度睡眠。我点开那个Wake Lock的详情看到它调用了PowerManager.WakeLock的acquire()方法但没有及时release()。嗯这就是典型的「唤醒锁泄漏」。解决方案也很简单在App的推送逻辑里加上超时释放机制或者改用WorkManager来调度任务。经验总结BatteryHistorian最擅长的就是帮你发现「谁在频繁唤醒系统」。我处理过的功耗问题中有60%以上都和Wake Lock、Alarm、Job Scheduler有关。这三个指标建议你重点关注。3.2.1 进阶技巧对比分析单个报告能看出问题但有时候你需要对比——比如优化前和优化后的效果对比。我的做法是优化前导出一次BatteryStats数据做优化改动优化后再导出一次数据把两份报告并排打开对比关键指标的变化举个例子有一次我优化了一个App的定位逻辑。优化前GPS每小时唤醒20次优化后降到了3次。通过BatteryHistorian对比能清晰地看到Wake Lock的柱状图变矮了电量曲线也平缓了。小技巧对比时注意保持测试条件一致。比如同样的网络环境、同样的屏幕亮度、同样的后台App。否则对比结果会有偏差。3.3 异常唤醒源系统里的「半夜鸡叫」什么叫异常唤醒源你想想看手机屏幕关了CPU按理说该睡觉了。但总有些App或服务不老实频繁把系统叫醒。这种行为我们叫它Wakeup Source。在BatteryHistorian里你会看到一条条竖线那就是唤醒事件。如果某段时间内竖线密集得像梳子齿恭喜你抓到问题了。核心指标Wakeup count唤醒次数。单次不可怕可怕的是高频。Wakeup duration每次唤醒后系统保持清醒的时间。时间越长耗电越狠。Wakeup reason谁发起的唤醒。这是定位问题的关键线索。我个人的排查习惯是这样的先看总唤醒次数如果超过每小时50次基本可以判定异常。然后按Wakeup reason排序找到那个「头号嫌疑人」。实战技巧抓取Bugreport时记得加上--bugreport参数。我曾经见过有人只抓了普通log结果Wakeup reason字段全是空的白忙活半天。3.4 后台耗电应用那些「偷电」的App后台耗电是用户投诉的重灾区。BatteryHistorian里有个App Usage视图能清晰展示每个App的CPU占用、网络活动、WakeLock持有时间。我一般关注三个维度CPU running timeApp在后台占用了多少CPU时间。超过10秒就算可疑。Network traffic后台网络流量。有些App在后台疯狂上传数据流量和电量一起烧。WakeLock duration持锁时间。超过30秒的WakeLock基本可以判定为流氓行为。前排查过一个新闻App用户反馈「手机不用的时候比用的时候还烫」。拉出BatteryHistorian一看好家伙这个App在后台每2分钟发起一次HTTP请求每次请求后CPU高负载运行15秒。一天下来光这一个App就耗掉了30%的电量。避坑指南我曾经遇到过一种情况某个系统服务在后台频繁扫描Wi-Fi但BatteryHistorian里显示的是「System」进程耗电。这时候别急着骂系统点进去看看具体是哪个子模块。很多时候是第三方App通过系统API间接导致的。3.5 系统服务功耗看不见的「电耗子」系统服务功耗是最容易被忽视的。因为用户看不到「系统服务」这个App但它的耗电往往比任何第三方App都狠。BatteryHistorian里有个System Service分类里面列出了所有系统服务的耗电情况。我重点关注这几个服务名称常见问题优化方向AlarmManager第三方App注册了大量定时器合并闹钟、使用setExactAndAllowWhileIdleWifiService频繁扫描、连接断开调整扫描间隔、优化漫游策略LocationManagerGPS持续定位使用被动定位、降低更新频率PowerManagerServiceWakeLock泄漏检查持锁超时、强制释放我个人习惯在项目初期就把这些服务的功耗基线定下来。比如AlarmManager每小时触发次数不超过20次WifiService每小时扫描不超过6次。一旦超出基线自动告警。3.6 实战流程从Bugreport到优化落地好了理论说完了咱们走一遍完整流程。第一步抓取Bugreportadb bugreport bugreport.zip这个命令会生成一个zip包里面包含了所有你需要的数据。注意抓取时间至少覆盖一个完整的待机周期比如一晚上。第二步导入BatteryHistorian打开浏览器访问BatteryHistorian的Web界面或者用本地部署的版本。把bugreport.zip拖进去等几秒钟你就能看到完整的电量时间线了。第三步定位异常先看System Stats概览重点关注Wakeup Sources和App Usage。如果发现某个唤醒源频率异常点进去看详细时间线。第四步分析根因比如你看到qcom,smb1355-charger这个唤醒源每10秒触发一次。这说明充电IC在频繁上报状态。我遇到过类似问题最后发现是充电线接触不良导致的。换根线问题解决。第五步优化验证修改代码后重新抓取Bugreport对比优化前后的唤醒次数和耗电比例。我一般要求优化后唤醒次数降低80%以上才算通过。核心原则不要试图一次性解决所有问题。先抓大头把唤醒次数最多的前3个问题搞定电量通常能改善50%以上。3.7 知识体系总览下面这张图是我自己总结的BatteryHistorian实战知识体系。你可以把它当成一张地图遇到问题的时候按图索骥就行。