首先，我们需要将Battery Historian工具在本地跑起来，要跑起来可以选择使用docker，也可以选择编译源码。
(1)如果是使用Mac或Linux平台的话，推荐直接通过docker运行Battery Historian来完成
docker run -d -p 9999:9999 bhaavan/battery-historian
之后在浏览器中输入 9999 就可以看到效果，然后上传bugreport文件进行分析了。
上面的步骤都完成之后就可以启动Battery Historian了，默认端口是9999
$ go run cmd/battery-historian/battery-historian.go
待控制台输出listening on port:9999的时候，可以打开浏览器输入 就可以看到
其次，这个版本的输入是bugreport文件，根据系统版本不同它的获取方式略有差别：
如果是Android 7.0及以上版本的话可以通过adb bugreport bugreport.zip 来获取bugreport 如果是Android 6.0及以下版本的话可以通过 adb bugreport > bugreport.txt 来获取bugreport 获取到bugreport文件之后，我们就可以将其上传到Battery Historian上进行分析，下面是它的输出结果
在页面的下方我们可以查看这段时间内系统的状态system stats，也可以选择某个应用查看应用的状态app stats
其中我们可以看到Device estimated power use中显示了估算的应用耗电量值为 0.18%
Battery Historian还有个比较功能，在首页选择 Switch to Bugreport Comparisor，然后就可以上传两个不同的bugreport文件，submit之后就可以看到它们的对比结果了，这个功能用来分析同一个应用的两个不同版本前后的耗电量非常有用。
需要注意的是，一般开始统计数据之前需要使用下面的命令将以前的累积数据清空
adb shell dumpsys batterystats --reset
By default, Android does not record timestamps for application-specific userspace wakelock transitions even though aggregate statistics are maintained on a running basis. If you want Historian to display detailed information about each individual wakelock on the timeline, you should enable full wakelock reporting using the following command before starting your experiment:
adb shell dumpsys batterystats --enable full-wake-history
关于bugreport相关的知识推荐阅读这篇文章，作者简单地从源码角度分析了adb bugreport命令的运行原理，结论是bugreport其实是启动了dumpstate服务来输出数据，其中数据来源包括：
下面是其他的几篇关于battery-historian使用的文章可供参考
(1) (2) (3)3.关于电量方面的Android性能优化
电量方面的性能优化可以参考主要有以下两点：
(1)为了减少电量的消耗，在蜂窝移动网络下，最好做到批量执行网络请求，尽量避免频繁的间隔网络请求 (2)使用Job Scheduler，应用需要做的事情就是判断哪些任务是不紧急的，可以交给Job Scheduler来处理，Job Scheduler集中处理收到的任务，选择合适的时间，合适的网络，再一起执行Hujiawei is a mobile developer Guangdong, China 本博客所有文章均为原创，请勿随意转载，如需转载请联系我 ()我在小专栏有个移动开发技术专栏，不定期分享移动开发的核心技术，总结移动开发的实战经验
参考
https://hub.docker.com/r/bhaavan/battery-historian/