battery historian 是用 go 语言开发的一个电池耗电分析工具
battery-historian 工具需要使用 bugreport 中的 Battery History
battery-historian 工具实则是一个支持在本地使用浏览器,对 bugreport 进行解析并可视化的这么一个工具。
搭建 battery-historian 有两种方式:
一个是源码安装(go+jdk+python+git+batteryhistorian),
另一种是搭建 docker 服务,安装 batteryhistorian。
搭建 battery-historian:
· cmd,进入 dos
· 执行 go get -d -u github.com/google/battery-historian/..
(注意最后有两点)
· pull 下来的源码在此目录结构下:
$GOPATH \workspace\src\github.com\google\battery-historian
· dos 进入到 $GOPATH \workspace\src\github.com\google\battery-historian
· 执行命令:go run setup.go
加载一些 js 资源
· 执行命令启动工具:
go run cmd/battery-historian/battery-historian.go
[--port default:9999]
· 查看是否启用成功:chrome 登录网址:http://localhost:9999
docker search battery
docker run --name=battery -d -p 9999:9999 bhaavan/battery-historian
拉取并运行 battery-historian 镜像,会自动下载并运行镜像,启动镜像运行工具即可· 如果可以科学上网,可以使用官方的镜像:
docker run -p port_number:9999 gcr.io/android-battery-historian/stable:3.0 --port 9999
(port_number 自己选择一个端口)
Battery Historian 容器就成功的运行了,端口映射本地端口 9999
同样的,chrome 登录网址:http://localhost:9999
耗电统计是系统组件,伴随系统运行的整个过程,也就是说系统运行他就一直在统计。这个统计是基于软件层面实现的,不同的硬件模块配置了不同的参数,然后使用算法进行估算,power_profile 文件的参数值 OEM 厂商必须测量并提供前实际值,所以不同的厂商是不一样的。另外获取统计报告的时候需要将统计重置,并断开 usb 连接(连接时充电),否则会大大影响统计有效性。
电脑搭建 adb 服务,手机连接并允许 usb 调试。
(a)执行命令:adb kill-server
这一步很重要,因为当我们开发时做电量记录时会打开很多可能造成冲突的东西。为了保险起见我们重启 adb。adb devices 就会自动连接查找手机
(b)执行命令:adb start-server
(c)执行命令:adb shell dumpsys batterystats --enable full-wake-history
(d)执行命令:adb shell dumpsys batterystats -–reset
获取电量报告
把数据线直接拔掉(防止数据线造成充放电造成数据干扰),然后做一些测试,手动操作或者跑一些自动化的 case。执行完成后,我们重新连接手机确认 adb 连上了,运行下面这条命令来将 bugreport 的信息保存到 txt 文档中
· 安卓 6.0 及以下:
adb bugreport > bugreport.txt
· 安卓 7.0 及更高版本
adb bugreport bugreport.zip
生成的文件上传后,就可以看到对应的报告
在报告中可筛选你需要测试的 app,查看对应的数据,耗电量、lock 数等等
工具可以使用多个 app 同时运动,从而比对数据,
battery-historian 也支持 2 个文件数据比对功能,从而可以使用多个安卓机跑数据,来比对数据
bugreport 通过 socket 与 dumpstate 服务建立通信,在 dumpstate.cpp 中的 dumpstate() 方法完成核心功能,该功能依次输出内容项,主要分为 5 大类:
1. current log: kernel,system, event, radio;
2. last log: kernel, system, radio;
3. vm traces: just now, last ANR, tombstones
4. dumpsys: all, checkin, app
5. system info:cpu, memory, io 等
从 bugreport 内容的输出顺序的角度,再详细列举其内容:
1. 系统 build 以及运行时长等相关信息;
2. 内存/CPU/进程等信息;
3. kernel log;
4. lsof、map 及 Wait-Channels;
5. system log;
6. event log;
7. radio log;
8. vm traces:
- just now 的栈信息;
- last ANR 的栈信息;(存在则输出)
- tombstones 信息;(存在这输出)
9. network 相关信息;
10. last kernel log;
11. last system log;
12. ip 相关信息;
13. 中断向量表
14. property 以及 fs 等信息
15. last radio log;
16. Binder 相关信息;
17. dumpsys all:
18. dumpsys checkin 相关:
* - dumpsys batterystats 电池统计;*
* - dumpsys meminfo 内存 *
- dumpsys netstats 网络统计;
- dumpsys procstats 进程统计;
- dumpsys usagestats 使用情况;
* - dumpsys package.*
19. dumpsys app 相关
- dumpsys activity;
* - dumpsys activity service all;*
* - dumpsys activity provider all.*
Tips: bugreport 几乎涵盖整个系统信息,内容非常长,每一个子项都以------ xxx ------开头。例如 APP ACTIVITIES 的开头便是------ APP ACTIVITIES (dumpsys activity all) ------,其中括号内的便是输出该信息指令,即 dumpsys activity all,还有可能是内容所在节点,各个子项目类似的规律。
更多来源:
https://blog.csdn.net/feitian_666/article/details/52880213
https://blog.csdn.net/feitian_666/article/details/54706430
搭建中遇到的问题以及解决方式:
是因为一些 js 文件需要获取国外源,所以解决方式可以科学上网或者将这些 js 源改为国内源或本地源
解决方式:使用线上版:https://bathist.ef.lc/ 需科学上网。
报告出来了,如何分析一个 app 最大耗电的进程或原因,这个我还没有解题思路,欢迎大家与我一起讨论!