应用功耗测试各种方法有何利弊？
怎样的测试环境对应用功耗测试更有利？
百度降低功耗使用了哪种方法？
王正意
百度搜索公司的资深测试工程师
百度搜索公司移动端测试领域专家
现在负责百度地图的性能测试、AI 测试等工作
对于应用来说，即应用工作时所消耗的电量（耗电），对于测试应用功耗来说实际上测试的是应用工作时耗电的情况。
哪些因素会影响应用功耗呢？
外因： 这部分是应用无法改变的，具体有以下方面问题：
a． 硬件的生产制造工艺，硬件的功率，具体设计上的因素。
b． 系统版本，根据安卓不同的系统版本它们有不同的特性，在耗电这方面呢，也会有不同的影响的因素。
c． 手机本身无线信号的强度。
d． 手机工作状态。比如产生位移、海拔的高度变化等因素。
e． 周围环境温度变化，也会影响应用工作时的耗电。
对于我们做应用的功耗测试来说，外部影响因素我们需要尽量固定，以保证我们在前后两次测试或者是多次测试当中，能够让测试的数据具有可比性。
内因： 这部分是我们应用可以控制的，也是与应用相关的一些因素：
a．应用的计算强度。在某些情况下，应用会处理大量数据，这些数据可能会提高应用对 CPU 的使用的强度。表现就是应用 CPU 占用率较高。还有可能就是应用存在大量图象的绘制，比如游戏或跟图象相关的一些应用，它会有很大的图象计算强度，这也会提高 GPU 占用的数值，这也是内因的影响因素之一。
b．网络传输需求，传输数据的时间、传输数据的频率，都会影响应用的耗电。
c．手机中设备的使用。比如说传感器、GPS、麦克风摄像头都会影响应用的耗电情况。
d．应用系统休眠或唤醒。这些因素也会影响应用的功耗情况。
对于我们来说，测试应用的功耗其实就是去看应用的内因跟应用的功耗有什么相关关系，我们可以从测试结果中去分析，到底是哪一部分内因引起了怎样的功耗问题，从而想办法去解决。
其实含义非常简单，就是根据应用工作前后，我们系统电量的百分比的变化情况来衡量应用功耗的情况。
在测试之前看一下系统现在的电量百分比情况，进行一段时间的测试，可能是手动的，可能是自动的，或者是其他方式，然后再看一下系统的电量，差值就是这段时间消耗电量。
优点：
非常直观，也非常容易执行；
缺点：
它只能反映系统整体的耗电情况，不能精确到某个应用消耗多少电。
结果的数据也比较粗略，这体现在两个方面：一个是因为大部分系统都是从 1% 到 100%，1、2、3、4、5、6 到 100 这样整数数字；
另外一个就是大家可能都遇到这样的情况，明明手机还有 20% 的电，掏出来用了不到几分钟就突然黑屏、没电、关机了，这是因为系统的电量降幅，在很多手机上不是线性的。就像下图右侧的这个图，是一个锂电池的放电曲线图，可以看到最前面一部分是比较平缓的，从 100% 比如说到 20% 这一段区间内，系统电量的百分比跟存量电量的情况是呈比例关系的。但到最右边这块可以看到曲线是急转直下，也就是说到最后这一段系统电量的百分比变化会变快。所以说这个对于我们用它来做功耗测试来讲其实就是结果会比较粗略。
其实就是用专用的电流仪，去记录我们手机瞬时一个电流的变化情况。
如下图右侧：这是某段时间内用电流仪测得的电流的曲线图，这样看起来可能跟 CPU 占用图差不多，原理上其实也差不多，就是我们可以通过这样一个电流的变化情况，体现出耗电的趋势，然后通过一些计算的方式，计算出这一段时间内手机消耗了多少电，它的单位是毫安时。
优点：
这种办法比系统电量差法精确的多。
缺点：
也只能反映系统整体的耗电情况，不能精确到单独某个应用。
专用仪器的购买使用和维护的成本比较高的。之前百度也用过电流仪设备，包括百度的 MTC 在内，也是用这样一个电流仪设备，给大家提供耗电测试
使用受到环境的限制。比如对于百度地图来说我们在测试的过程中，很有可能需要到实际的、真实的环境中去做一些实际的道路测试，我们一般会开一辆车，拿手机做测试，因为电流仪太庞大，放在车里不方便，寻找电源也不方便。
每一台安卓手机里都会有下图右边这样的一个 XML 文件，这个文件是在 ROM 编译的时候就编译在 ROM 中的，它记录了手机中每个设备在某种状态下一个基准单位耗电量，比如每秒钟耗多少电。我们可以通过系统提供的接口去获取某个应用在某一个时间段内对系统设备占用的信息，比如时长和频次。
时长是一个关键的信息，用时长去乘以右边这个 XML 里面记录的单位耗电值，就能得出估计的耗电值。
优点：
计算某个应用耗电比较方便。
缺点：
无法控制测试环境的影响。比如说手机所处的地理位置、它的海拔、手机运动的状况还有周围环境的温度，都会影响设备的耗电速度。
如果只用 XML 记录的数值去进行计算，那么得到的结果肯定是非常不准确的。
这种方法和第三种方法类似，但是这种方法只记录和比较设计占用的频率、频次和时长，不进行计算，具体方法在下文会介绍。
优点：
可以衡量单个应用功耗。
由于这个数据没有经过固定值的计算，所以相对来说比较可信。
缺点：
数据项太多，不够直观。一方面，手机里面会耗电的设备比较多，每一项都需要对它进行频次和时长占用的比较，就会比较复杂，另一方面前，这个方法不会落实到某一个数上，数据可能会是一组数，复杂不够直观。
介绍完这四种方法大家也可以看出，我们现存所用的这种测试功耗的这四种方法，其实没有一种是完美的，这也是我们现在所面临的这样一个现实的问题，就是没办法只用一种方法去对应用的功耗进行测试。所以在实际的使用过程中，就是我们只能说按照我们的需求、按照测试的这种需要，去选取更适合我们当前测试的这样一个功耗测试的方法。
目前业界对功耗标准的认定不一，以下我们来剖析安卓绿色联盟功耗标准的内容
测试环境是影响应用功耗的一个很重要的因素，对于我们做应用功耗测试来讲，首先对外因要尽可能固定，这样前后的测试数据才具有足够的可比性。
我们就在标准中定义了一个标准环境：
使用 Nexus 系列的手机。这个考虑的是通常 Nexus 系列的手机里预装的一些应用不会受到我们所测试应用的互相关联启动或是唤醒的影响，环境相对比较纯净。而且一般来说，Nexus 系列的手机有比较好的延续性，在今后一段时间内我们都能找到 Nexus 系列的手机，而且它对系统版本的更新跟进也是比较及时的，我们通常可以拿到最新的系统版本进行测试；
不充电时，电池起始电量是 100%。这也与系统电量消耗的线性曲线有关，还记得刚才的那个耗电曲线图吗？最开始的部分比较平缓，所以我们通常选取最开始的一部分开始进行测试；
网络选择 Wi—Fi 或者是 4G，信号强度是最强。以保证我们测试的数据不太受网络波动的影响，让我们的测试比较顺利，得出的数据不会波动太大；
环境的温度在 25 度上下；
泛设备化。
考虑到功耗与硬件设备的特性非常相关，安卓的碎片化是常严重、更新快，所以在标准的制订中，我们采用了 “泛设备化” 的方法——在标准中不描述某一个应用在特定手机上的功耗衡量和判断标准。也就是说我们虽然用 Nexus 系列的手机去测试，但是我们的标准描述的不是在 Nexus 手机上这个功耗的衡量和判断标准，而是通过应用对手机上的设备的占用频次和时长来衡量某个应用的这样一个功耗，比如衡量这个应用 CPU 占了多少、屏幕占了几次、占用了多少次 GPS，有多少次用网络去传输数据、传输了多长时间……用这样一些频次和时长去衡量判断应用的功耗。
实际上与测试方法中设备占用记录法是比较吻合的，虽然说数据上比较复杂，但是相对来说数值是比较可靠的，而且适合作为一个标准来进行制定和应用的。从测试数据来说，最后的结果就是测试某一个应用在某个手机上的占用频次时长，数据对于功耗问题的优化和改进具有一定的指导意义的。所以这也是我们在功耗标准里采用这种方法的重要原因。
标准中对应用测试的使用场景进行了划分，按照应用对手机内设备的需求程度进行了划分，分成四类：分别是高需求、中需求、低需求和无需求。
在现行的标准中，我们只针对无需求场景进行了严格的要求，而对高需求、中需求、低需求统一把它归为了一个例外。用 GPS 举个例子，在无需求这样的场景下，我们要求所有的应用不应使用 GPS，比如播放视频的时候是没有理由使用 GPS 的，所以我们要求应用在 GPS 无需求的情况下不允许使用 GPS，也会有一些例外，比如说导航过程中对 GPS 是有强烈需求的，那么在我们的测试过程中，就把导航这样的场景作为 GPS 设备的一个例外列出来。
所以，大家可以看到我们会把常见的一些应用的使用场景作为例外列出来，对无需求的一些场景进行严格限制。
解释一下我们现在的标准，这个标准只针对应用在后台的功耗情况进行限制。我们做了一些用户的调研，发现用户其实更关注某一个应用在后台的时候它是不是耗电。所以在前台，我们现行的标准就没有做强制的规范，但是我们现行的"安卓绿色联盟"的功耗标准，对应用在后台进行了严格的规范，包括规范这个应用对手机用电设备的使用频率和使用时长，还规范了对 WakeLock、Alarm 的使用情况，并且我们还把应用在标准环境中后台的耗电情况也作为参考标准进行执行。
我们划分为了处理器、屏幕、无线网络、音频设备、摄像头、位置传感器和动作传感器这样七类，又分别对这些设备做了不同的衡量标准。
比如说屏幕，应用在后台的时候，我们严格禁止应用去阻止屏幕变暗或者关闭的；也会限制应用在后台对无线网络的扫描次数，包括音频设备、摄像头、位置传感器、动作传感器，我们会严格的限制应用在后台的时候使用这些设备。
除了刚才我们说的这些例外的场景之外，具体的例外场景大家可以参考功耗标准的文档。
Battery Historian 这个工具是包括百度等很多业界公司都在使用的，这个工具其实是刚才我们提到的四种测试方法里面的第四种。这个工具是安卓开发商做的解析诊断文件，用来分析电量消耗的开源工具。大家访问链接：
https://github.com/google/battery-historian，就可以看到工具源代码。
这个工具其实就是通过安卓手机的一些命令，让安卓系统生产 bugreport 文件，然后解析，生成各个应用、各个硬件设备占用的图表和数据。
大家可以看到下图右侧就是一个示例，列表纵坐标是设备，横坐标就是时间线，每个带颜色的点表示某一时刻设备的占用情况。大家可以看到，有的设备会是一个密集的点，有的设备是一条线，一条线就表示这个设备被持续占用，点就表示这个设备在被间歇性占用，由此可以看到系统里的各个设备的占用情况。
关于它的使用方法有以下几步：
开始测试之前，把手机连到电脑上，通过这样一个 adb shell 的命令，先把电池历史信息进行清空重置，这样我们获取到的数据就仅限于本次测试的数据了，会比较方便；
测试过程中就不需要连着电脑了，然后就进行测试，可以拿出去测试或者是在各种屋里面测试进行模拟测试，自动化测试等等；
在测试结束之后，我们再去把手机连到电脑上，然后通过 adb bugreport 这样一个命令把测试的信息导出。上面有两个命令，上面这个命令是安卓 7.0 以上支持的命令，下面是安卓 6.0 以及 6.0 以下导出的命令。两种命令的导出的信息其实是一样的。
导出了耗电的信息之后我们就需要把 Battery Historian 运行起来，有两种方法：
（1）如果我们自己运行的话，需要安装一个 docker，然后把 Battery Historian 运行起来，运行起来之后打开一个网页，在本地的网页上上传我们刚才导出的 Battery Historian 这样一个文件，上传之后就可以解析出我们刚才看到的情况了；
（2）如果不方便去运行 docker，或者是不方便安装 docker 去运行 Battery
Historian 的话，可以在网络上进行一些搜索，有一些网站会提供 Battery Historian 的功能，你只需要上传你的 Battery Historian 的文件，它的网站就会帮你把文件里面的内容解析出来，也是非常方便的。
大家可以在百度上搜索 Battery Historian，包括它的一些使用方法、它的解析的能力，都可以在网络上找到。
上传之后我们就可以看到一些数据——包括刚才介绍的时间线，左上角的图表，右边的系统统计。也就是在系统的层面上，手机的设备被占用了多少次、占用了多少时间、CPU 消耗了多少、Wi—Fi 传输了多少数据，在这个里面都会有。
在左边这一列，我们把应用筛选出来，就可以看到下面的界面，
这是针对某个 APP 进行的数据分析：包括 APP 占用了多少 CPU、多少传感器、每次占用的时长是多少、通过无线网络传输了多少数据、传输了多少次，这样的数据在图表里面都有一些统计。大家可以拿着自己的手机或者测试机进行一些测试，对它进行解析，这个数据是非常详细的。
以上的几种方法适用于不同场景，遇到具体问题还是需要具体分析。
文章转载自微信公众号：安卓绿色联盟
