性能优化十四之电量分析工具Battery Historian使用

本文详细介绍如何使用battery-historian工具进行电池数据收集与分析。包括重置电池数据、收集bugreport信息、使用historian.py脚本生成html报告,并解读报告中的各项指标意义。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

上篇博客中并没有讲解BatterHistory该如何使用,这篇博客就开始给大家进行介绍。

数据准备

battery-historian工具需要使用bugreport中的BatteryHistory

1.     先断开adb服务,然后开启adb服务

adb kill-server  这一步很重要,因为当我们开发时做电量记录时会打开很多可能造成冲突的东西。

为了保险起见我们重启adb。

adb devices就会自动连接查找手机。当然也可以adb start-server

 

2.     重置电池数据收集数据,我们在开始的时候需要通过以下命令来打开电池数据的获取以及重置:

adb shell dumpsys batterystats --enable full-wake-history

adb shell dumpsysbatterystats –reset

执行的效果如下:

上面的操作相当于初始化操作,如果不这么做会有一大堆的干扰的数据,看起来会比较痛苦。

然后把数据线直接拔掉(防止数据线造成充放电数据干扰),现在做一些测试,手动或者跑一些自动化的case

都行。经过一段时间后,我们重新连接手机确认adb连上了,运行下面这条命令来将bugreport的信息保存到

txt文档中:

adb bugreport > bugreport.txt

或者用下面的命令也可以:

adb shell dumpsys batterystats > batterystats.txt

adb shell dumpsys batterystats > com.example.android.sunshine.app >batterystats.txt

加上包名可以限制输出的数据是我们要检测的。

后面这种方法生成的TXT文件是没法上传到battery-historian服务上面进行分析的,因为不兼容。

但是这个txt的数据可读性不强。接下来我们就要用到这个

battery-historian工具了。


到此我们有两种方式分析这个文件:(historian-V1之前的版本historian-V2最新的版本)

historian-V1之前的版本分析方式:

txt文档转化为html文件,命令如下:

     python historian.py -a bugreport.txt > battery.html

上面的historian.py脚本是Python写的,所以需要python环境,然后从github上下载这个脚本。

文件在github上面的scripts目录下面,需要下载到命令行所在的目录

注意:historian.py要与bugreport.txt在同一目录下

上面两条命令执行成功后,会在目录下发现两个文件

bugreport.txtbattery.html,这个时候我们用google浏览器打开html文件,可以看到如下信息:

各个参数的意义:


横坐标:

上面的1020代表的就是秒的意思,它是以一分钟为周期,到第60秒的时候变为0。横坐标就是一个时间范

围,咱们的例子中统计的数据是以重置为起点,获取bugreport内容时刻为终点。我们一共采集了多长时间的数据

,图表下也有信息说明。


纵坐标:

纵坐标的数据就很麻烦了,数据量太多,一条一条来吧。


battery_level

电量,可以看出电量的变化。比如上图中的数据显示刚开始电量是100%,然后在第11-12秒中间的

某个时刻降到了99%

 

plugged

充电状态,这一栏显示是否进行了充电,以及充电的时间范围。例如上图反映了我们在第22s插入了数

据线,然后一直持续了数据采集结束。


screen

屏幕是否点亮,这一点可以考虑到睡眠状态和点亮状态下电量的使用信息。


top

该栏显示当前时刻哪个app处于最上层,就是当前手机运行的app,用来判断某个app对手机电量的影响

,这样也能判断出该app的耗电量信息。该栏记录了应用在某一个时刻启动,以及运行的时间,这对我

们比对不同应用对性能的影响有很大的帮助。


wake_lock*

wake_lock该属性是记录wake_lock模块的工作时间。是否有停止的时候等


running

界面的状态,主要判断是否处于idle的状态。用来判断无操作状态下电量的消耗。


wake_lock_in

wake_lock有不同的组件,这个地方记录在某一个时刻,有哪些部件开始工作,以及工作的时间。


gps

gps是否开启


phone_in_call

是否进行通话


Sync

是否跟后台同步.

可以把鼠标停在某一项上面。可以看到何时sync同步启动的,持续时间Duration多久。

电池容量不会显示单一行为消耗的具体电量,这里只能显示使用电池的频率和时长,你可以看分时段

的剩余电量来了解具体消耗了多少电量。



Job

后台的工作,比如服务service的运行。从下面图中可以看到qihooAppStore和鲁大师都在运行后台

服务。

 

data_conn

数据连接方式的改变,上面的edge是说明采用的gprs的方式连接网络的。此数据可以看出手机是使用

2g3g4g还是wifi进行数据交换的。这一栏可以看出不同的连接方式对电量使用的影响。


status

电池状态信息,有充电,放电,未充电,已充满,未知等不同状态。

这一栏记录了电池状态的改变信息。


phone_signal_strength

手机信号状态的改变。

这一栏记录手机信号的强弱变化图,依次来判断手机信号对电量的影响。


health

电池健康状态的信息,这个信息一定程度上反映了这块电池使用了多长时间。

这一栏记录电池状态在何时发生改变,上面的图中电池状态一直处于good状态。


plug

充电方式,usb或者插座,以及显示连接的时间。

这一栏显示了不同的充电方式对电量使用的影响。


historian-V2最新的版本的方式:


将生成bugreport.txt文件在http://localhost:9999 中上传文件生成报告(前提在本地或者某服务器上搭好了

battery-historian项目环境)

其实在这里也可以看到两种版本分析模式:


至此使用方式就介绍完毕。


<think>我们正在分析Battery Historian报告中与游戏场景相关的参数。游戏场景通常对设备的电池消耗有显著影响,因此需要关注以下几个关键参数: 1. **CPU Usage**:游戏通常需要大量计算,导致CPU负载较高。在Battery Historian中,查看`top app`的CPU使用情况,特别是游戏进程的CPU时间片占用率。高CPU使用率会导致电池消耗加快[^1]。 2. **Wake Locks**:游戏可能会持有唤醒锁(`WakeLock`)以防止设备进入休眠状态。在报告中检查`partial wakelocks`部分,观察游戏进程持有的唤醒锁时长和次数。过长的唤醒锁时间会增加待机功耗[^2]。 3. **Screen Brightness**:屏幕亮度是游戏场景中的主要耗电源之一。报告中的`Screen Brightness`曲线可以显示亮度级别变化。高亮度设置会显著增加功耗[^3]。 4. **Network Usage**:在线游戏会持续使用网络(Wi-Fi或移动数据)。在报告中查看`Network`部分,关注游戏进程的数据传输量和连接时间。大量数据传输或频繁的网络切换会增加功耗[^4]。 5. **Sensor Usage**:游戏可能使用传感器(如加速度计、陀螺仪)。在报告中检查`sensor`部分,观察游戏进程的传感器激活时长。传感器使用也会增加功耗[^5]。 6. **GPU Usage**:游戏通常需要高性能的图形处理。在Battery Historian中,可以通过`SurfaceFlinger`或`GPU usage`相关指标来评估GPU负载。高GPU负载会导致功耗上升[^6]。 7. **Thermal Throttling**:长时间游戏可能导致设备温度升高,触发温控降频。在报告中查看`Temperature`和`CPU frequency`变化,如果出现频率下降,说明发生了降频,这会影响游戏性能并可能增加每帧计算的能耗[^7]。 8. **Battery Level Drop**:直接查看电池电量下降曲线,结合游戏运行时间段,计算单位时间内的电量消耗速率(例如,每分钟下降百分比)。这可以直观反映游戏的整体耗电情况[^8]。 9. **Alarms and Background Services**:游戏可能触发定时任务或后台服务。检查`alarms`和`background`部分,避免不必要的后台活动增加功耗[^9]。 通过以上参数的综合分析,可以定位游戏场景中的电池消耗瓶颈,并针对性地优化(如降低帧率、优化网络请求、调整亮度策略等)。 ```bash # 使用Battery Historian查看报告的示例命令(需先收集bugreport) $ python historian.py -a battery_history.txt > battery_report.html ``` §§相关问题§§ 1. 如何降低游戏场景中的CPU使用率? 2. 如何优化游戏中的网络请求以减少电池消耗? 3. 在Battery Historian中如何识别由传感器引起的电池消耗?</think>### Battery Historian报告中游戏场景参数分析分析游戏场景的电池消耗时,需要重点关注以下参数(按优先级排序): #### 核心参数 1. **CPU负载**: - `foreground_process`:游戏进程名称(如`com.xxx.game`) - `cpu_run`:游戏进程的CPU运行时间占比 - `top app`:游戏作为前台应用时的CPU频率分布(例如`<300MHz`时段占比过大表示性能不足)[^1] 2. **屏幕与GPU**: - `screen_brightness`:亮度级别(0-255),游戏通常维持高亮度 - `screen_on`:屏幕点亮时长 - `gpu_freq`:GPU频率变化曲线(高频持续时间反映图形负载) - `surfaceflinger`:帧率稳定性(`jank_count`卡顿次数)[^2] 3. **网络与定位**: - `mobile_radio`:蜂窝数据激活时长(`active`字段) - `wifi_running`:Wi-Fi持续连接时间 - `wifi_scan`:扫描次数(频繁扫描增加功耗) - `gps`:定位服务使用时长(尤其是AR游戏)[^3] #### 辅助诊断参数 4. **温度与电量曲线**: - `battery_level`:电量下降斜率(游戏时段斜率>$0.5\%$/分钟需警惕) - `temperature`:电池温度(>$38°C$可能触发降频) - `voltage`:电压波动(剧烈波动反映电流不稳)[^4] 5. **唤醒与后台**: - `partial_wakelock`:游戏持有的唤醒锁时长 - `alarm`:后台唤醒事件(如推送服务) - `background`:非游戏进程的CPU占用(广告SDK等)[^5] #### 分析示例 典型游戏场景异常模式: - **高帧率游戏**:`gpu_freq`持续最高档 + `cpu_run`>80% + 温度>$42°C$ - **网络游戏**:`mobile_radio`活跃占比>60% + `wifi_running`=100% - **卡顿问题**:`jank_count`突增 + `cpu_run`中低频占比过高 ```bash # 提取游戏进程数据的命令示例 $ python historian.py -m "foreground_process=com.xxx.game" report.txt > game_cpu.csv $ python historian.py -m "gpu_freq|screen_brightness" report.txt > game_gpu.csv ```
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值