腾讯视频国际版（Android）电量测试方法研究与总结

本文由云+社区发表

做者：腾讯移动品质中心TMQ

一、研究背景：

在2017年Google I/O大会上，Google发布了Google Play管理中心的新功能：Android vitals。当app在大量设备上运行时，Android vitals会收集与应用性能相关的各类匿名数据，好比：与app稳定性相关的数据、app启动时间、电量使用状况、渲染时间以及权限遭拒等等，这些数据会被分析整理后展现在Google Play管理中心的Android vitals dashboard中。Android vitals 中须要开发者重点关注的核心指标有：crash率、ANR率、excessive wakeups（过渡唤醒）、stuck wake locks（唤醒锁定卡住）。其余指标，需根据应用类型选择性关注（Android vitals中的指标总览见图1-1）。若app某些指标表现不好，会影响用户体验，而且会致使应用在Google Play商店中的等级很低、排名靠后（APP指标异常示例图见图1-2）。开发者能够经过分析Android vitals中提供的一些参照指标，采起相应的措施来优化app。

图1-1 Android vitals平台检测指标总览

图1-2 某APP指标异常示例图

二、核心指标详细信息：

要对APP的指标进行监控，首先要明确该指标在Android vitals中是如何进行统计的，这一节主要介绍电量相关核心指标的基本概念和计算方式。

2.1 Stuck partial wake locks（部分唤醒锁定卡住）

A.WakeLock（唤醒锁）基本概念：

Android系统自己为了优化电量的使用，会在没有操做时进入休眠状态, 来节省电量。为了便于开发(不少应用不可避免的但愿在灭屏后还能运行一些事儿，或是要保持屏幕一直亮着--好比播放视频)，Android提供了一个PowerManager.WakeLock的东西。咱们能够用WakeLock来保持CPU运行，或是防止屏幕变暗/关闭，让手机能够在用户不操做时依然能够作一些事儿。然而，获取WakeLock很容易，释放很差就会成为难题，消耗电量。

例如咱们获取了一个WakeLock来保持CPU运转，作一个复杂运算并将数据上传到后台服务器, 而后释放该WakeLock。然而这个过程可能并不像咱们想象的那么快，可能由于好比服务器挂掉，计算出了异常等等WakeLock没有释放。问题就来了，CPU会一直得不到休眠，而大大增长耗电。

唤醒锁可划分为并识别四种用户唤醒锁：

自 API 等级 17 开始，FULL_WAKE_LOCK 将被弃用。应用应使用FLAG_KEEP_SCREEN_ON。

相关连接：https://developer.android.com...

B.Partial wake locks（部分唤醒锁）：

部分唤醒锁可确保CPU正常运行，但屏幕和键盘背光能够关闭。若是运行在后台的APP长时间持有某个部分唤醒锁，就致使部分唤醒锁卡住。这种状况十分消耗设备电量，由于它会阻止设备进入低电量状态。Android vitals重点关注了stuck partial wake locks这项指标，当你的APP存在唤醒锁定卡住的现象时，它会经过Play管理中心给出告警（APP出现部分唤醒锁定卡住示例图见图2-1），并从各个维度给出相关的详细统计图（如图2-2中给出每一个工做时段后台wake lock最长持续时间分布图）。当出现如下状况时，Android vitals会报告唤醒锁定卡住：

1. 至少70%以上的battery sessions发生过至少一次、长达一小时以上的部分唤醒锁定。
2. 当只在后台运行时，至少10%以上的battery sessions发生过至少一次、长达一小时以上的部分唤醒锁定。

（ps：battery session指两次电池充满电之间的时间间隔，Android vitals展现的battery sessions是全部app测试用户的battery session合计。）

相关连接：https://developer.android.goo...

图2-1 某APP出现部分唤醒锁定卡住（后台）示例图

图2-2 每一个工做时段后台wake lock最长持续时间的分布图

2.2 Excessive wakeups（过渡唤醒）

A.Wakeups 基本概念

Wakeups 是AlarmManager API中的一种机制，开发者能够设置一个alarm在特定的时间来唤醒设备。当某个唤醒alarm触发，设备会走出低电量模式，在执行alarm的onRecieve（）或onAlarm（）方法的时候，Alarm Manager会持有一个部分唤醒锁。若是wake alarms频繁触发，会耗尽设备电量。Android vitals中展现了app的过渡唤醒次数。

Alarm有如下四种类型：

1)RTC_WAKEUP

在指定的时刻（设置Alarm的时候），唤醒设备来触发Intent。

2)RTC

在一个显式的时间触发Intent，但不唤醒设备。

3)ELAPSED_REALTIME

从设备启动后，若是流逝的时间达到总时间，那么触发Intent，但不唤醒设备。流逝的时间包括设备睡眠的任什么时候间。注意一点的是，时间流逝的计算点是自从它最后一次启动算起。

4)ELAPSED_REALTIME_WAKEUP

从设备启动后，达到流逝的总时间后，若是须要将唤醒设备并触发Intent。

在Android vitals中只列出了RTC_WAKEUP和ELAPSED_REALTIME_WAKEUP两种类型的唤醒数据，Google会统计每小时发生10次以上wakeup的电池工做时段百分比（APP发生过渡唤醒示例见图2-3）。分别从应用版本、wakeup标记、设备、Android版本等几个维度统计每小时的Alarm Manager wakeup次数（每一个工做时段中每小时的wackup分布图见图2-4）。

图2-3 某APP发生过渡唤醒示例图

图2-4 每一个工做时段每小时wakeup次数分布图

三、测试方法研究

3.1 传统电量测试方法回顾

咱们以前也对腾讯视频主线版本进行过电量测试，以前关注的重点在于APP在各场景中耗电量是否正常，是从比较宏观的角度去进行测试的，采起的测试方法主要是物理仪器测试法和GT测试法。

A.物理仪器测试法（电流表等）

在保持电压恒定的状况下，获取各场景平均电流值来统计系统耗电状况，经过此方法能够从大致上看出APP电量消耗是否正常，若仪器精度大，此方法测出的电量值是最准确的。

缺陷：此方法只能测试整个手机的电流，不能区分APP，受影响的因素多，如屏幕亮度大小、音量大小等等，要保证每次测试的环境彻底一致是不可能的。

图3-1 物理仪器测电量

B.GT测试法

GT（随身调）是由MIG专项测试组自主研发的APP随身调测平台，它是直接运行在手机上的“集成调测环境”(IDTE, Integrated Debug Environment)。利用GT，仅凭一部手机，无需链接电脑，您便可对APP进行快速的性能测试(CPU、内存、流量、电量、帧率/流畅度等等)、开发日志的查看、Crash日志查看、网络数据包的抓取、APP内部参数的调试、真机代码耗时统计等。

经过GT，能够采集手机耗电量相关数据：电流、电压、电量、温度等，经过分析这些数据，能够对整个手机的电量使用状况进行分析。

缺点：和物理仪器测试方法同样，采用GT测试也只能获取到整个手机的电量数据，没法只关注单独APP，且受各类因素影响较大。

3.2 国际版电量测试方法预研

因为国际版APP在Google Play上发布，咱们作电量测试不只仅须要关注整个APP的电量使用状况是否正常，还须要关注APP持有 wack lock和使用alarm的状况。所以，传统的电量测试方法已经没法知足咱们的需求，咱们须要在此基础上增长额外的测试方法。

A.Batterystats/ bugreport

Android5.0后，电量数据可经过dumpsys batterystats获取。Android系通通计耗电量的基本公式是W=UIt。在手机中，U通常恒定不变，所以能够单独经过Q（电容量）=I*t来表示电量。核心类BatterStatsImpl提供App各部件运行时间、PowerProfile提供部件电流数值。Android部件电流信息存于：power_profile.xml文件中，每一个OEM厂商都有私有的power_profile.xml文件，PowerProfile经过读取该文件获取访问部件电流数值（图3-3是samsung某型号的power_profile.xml）。Android系统以uid为单位，依次统计每一个apk的使用cpu使用耗电量、wake lock耗电量、移动数据耗电量、wifi数据耗电量、wifi维持耗电量、wifi扫描耗电量、各传感器耗电量。其中wake lock消耗的电量只统计了持有Partial wake lock的耗电量，正好是咱们须要关注的唤醒类型，所以咱们能够经过分析batterystats得到的电量数据来测试app持有Partial wake lock状况。

Android为了方便开发人员分析整个系统平台和某个app在运行一段时间以内的全部信息，专门开发了bugreport工具。bugreport文件中记录了系统容许过程当中的各类log信息，其中也包括了耗电量信息。经过分析bugreport中的电量相关数据也能获取APP持有Partial wake lock的信息。

ps：Uid与App关系：2个App签名和sharedUserId相同，则在运行时，他们拥有相同Uid。就是说processAppUsage统计的多是多个App的耗电量数据，对于普通App，出现这种状况的概率较少，而对于Android系统应用则较为常见。

图3-2 wack lock耗电量计算源代码

图3-3 sumsung某型号power_profile.xml

数据准备：

• 先断开adb服务，而后开启adb服务。

(1)adb kill-server

(2)adb start-server

因为开发时作电量记录时会打开不少可能形成冲突的东西，为了保险起见，重启adb命令。

• 重置电池数据、收集数据

(3) adb shell dumpsys batterystats --enable full-wake-history

(4) adb shell dumpsys batterystats --reset

(5) adb shell logcat -c

经过以上命令来打开电池数据的获取以及重置，清除干扰的数据，清除历史日志。

• 获取电量报告

把数据线拔掉，防止数据线形成充放电数据干扰。而后作一些测试的case，通过一段时间后，从新链接手机确认adb连上了，运行如下命令来将bugreport的信息保存到txt文件中。

(6) adb bugreport >D:/bugreport.txt

或者用下面的命令也能够，官网上记述的内容，经实践，没法被读取…

(7) adb shell dumpsys batterystats > batterystats.txt

(8) adb shell dumpsys batterystats > com.example.app(包名) >batterystats.txt

ps：在此注意必定要等到该条命令执行完(稍微会有些慢)后，再打开bugreport.txt文件，以前遇到过没有导出完，就点开，信息缺失的状况，致使没法成功生成图表。

B.battery historian

生成的bugreport文件有的时候异常庞大，可以达到15M+，想想对于一个txt文本格式的文件内容长度达到了15M+是一个什么概念，若是使用文本工具打开查看将是一个噩梦。所以google针对android 5.0（api 21）以上的系统开发了一个叫作battery historian的分析工具，这个工具就是用来解析这个txt文本文件，而后使用web图形的形式展示出来，这样出来的效果更加人性化，更加可读。咱们可使用该工具对bugreport文件进行解析，更轻松的获取电量相关数据。

battery historian的安装能够参考如下连接：

https://github.com/google/bat...

https://developer.android.com...

也能够直接使用在线版本：

https://bathist.ef.lc/

数据分析：

（1）选择腾讯视频app

（2）Wacklocks表格中展现app持有的wacklock，持有时间及数量，经过这个表格咱们能够看到咱们APP是否有持有一小时以上的wack_lock。

（3）Wakeup alarm info表格中展现了APP运行过程当中触发的wakeup alarm名字和个数，经过该分析工具也能够统计app的闹钟唤醒次数。

C.QAPM

QAPM是SNG开发的致力于解放专项测试人员的工具平台，该平台带有电量监控功能，在电量个例菜单中会统计前台30分钟、后台5分钟两个场景下的wacklock持有信息。该平台上的数据能够做为咱们电量测试的参考对象，具体的统计方法还需后续深刻了解。

D.dumpsys命令

Android提供的dumpsys工具可以用于查看感兴趣的系统服务信息与状态，手机链接电脑后可以直接命令行运行adb shell dumpsys 查看电池、电量相关信息。

• adb shell dumpsys power

经过该条命令能够看到手机中全部的wack_lock持有信息

• adb shell dumpsys alarm

此命令会提供设备上的alarm系统服务相关信息。其中Alarm Stats列出了应用设置alarm的状况，其中有系统被该应用全部alarm消耗的时间以及被闹钟唤醒的次数。能够经过获取一小时内的电量数据来分析用户在每小时的唤醒次数。

相关连接：https://blog.csdn.net/memoryj...

该方法与经过burgreport文件统计电量信息相似，都是经过Android系统中提供的工具来输出电量的消耗状况，且该种方式输出的报告也比较复杂，可读性查，可在测试过程当中做为参考。

四、国际版电量测试方法总结与实践

4.1 测试方法总结

1. 根据上一节的测试方法研究，咱们打算首先用GT测试各个场景中APP电量消耗是否有异常。
2. 接下来采用battery historian分析工具对手机里获取的bugreport文件进行分析，统计app中持有超过一小时的wack_lock和一小时内发生的wackup数。
3. QAPM中采集到的数据做为咱们的辅助分析数据，咱们能够比较两份数据，看咱们经过battery historian统计的wack_lock数据是否准确。
4. 咱们也能够经过使用dumpsys命令，查看app电量相关信息做为测试辅助方法。

4.2 测试方法实践

腾讯视频国际版1.0.0已经发布，咱们已经使用该方法对其进行了一次电量测试，具体测试过程以下：

A.GT测试：

测试场景：启动-播放-前台静置

测试机器：nexus

测试结果分析：

1. 从如下电流趋势变化图中能够看出，播放过程和前台静置过程，电流曲线平稳，无较大波动，无明显异常。
2. 从播放到退出播放前台静置，使用电流明显变小，符合预期。

B.Battery Historian测试：

测试场景：

1. app前台静置2小时
2. app后台静置2小时
3. 全屏播放2小时

测试型号：

• Y7 Pro 2018 （LDN-LX2）
• OPPO F7 （CPH1819）

测试结果分析：

1. 三个场景中，仅播放场景下会持有WindowManager这个wakelock超过1小时以上。而Android Vitals中关注的是app运行在后台时，长时间持有部分唤醒锁的状况，播放这个场景能够排除在外，所以得出结论，国际版APP持有唤醒锁状况正常。

场景	机型	持有1小时以上的wack lock
app前台	华为Y7 Pro 2018 （LDN-LX2）	无
OPPO F7 （CPH1819）	无
app后台	华为Y7 Pro 2018 （LDN-LX2）	无
OPPO F7 （CPH1819）	无
全屏播放	华为Y7 Pro 2018 （LDN-LX2）	WindowManager
OPPO F7 （CPH1819）	WindowManager

2. 测试过程当中没有统计到alarm数据，说明国际版APP暂时没有使用到AlarmManager定时任务。

C.测试结论：

1. GT电流测试显示国际版APP各应用场景电量使用状况正常。

场景	启动APP	播放	退出播放，前台静置
结论	启动过程需加载图片等资源，电流较大，正常	播放过程电流平稳无异常	退出播放电流变小，静置过程平稳无异常

2. Battery Historian分析电量数据得出，前台静置、后台静置、播放三个场景中仅播放场景会持有wack lock1小时以上，不属于Android Vitals统计范畴，不会影响到国际版APP在Google Play商店的排名。

场景	机型	stuck wake locks	excessive wakeups	结论
前台静置	华为Y7 Pro	无唤醒锁定卡住	无过渡唤醒	正常
OPPO F7	无唤醒锁定卡住	无过渡唤醒	正常
后台静置	华为Y7 Pro	无唤醒锁定卡住	无过渡唤醒	正常
OPPO F7	无唤醒锁定卡住	无过渡唤醒	正常
播放	华为Y7 Pro	持有唤醒锁1小时以上	无过渡唤醒	正常
OPPO F7	持有唤醒锁1小时以上	无过渡唤醒	正常

五、总结与展望

因为腾讯视频国际版目前功能比较少，用到wack_lock和alarm的状况比较少，咱们只测试了前台静置、后台静置、播放三个场景，电量测试的结果也显示APP电量使用状况正常，无部分唤醒锁定卡住和过渡唤醒的状况出现，后续国际版功能会日渐丰富，可能须要补充push、下载等测试场景，持有wack_lock和alarm的状况也会更加复杂，所以咱们会根据实际状况不断改进和完善咱们的电量测试方法。

此文已由腾讯云+社区在各渠道发布

获取更多新鲜技术干货，能够关注咱们腾讯云技术社区-云加社区官方号及知乎机构号