【腾讯TMQ】【Android场景化性能测试专栏】CPU耗电性能篇

一、思路简介

在腾讯内部或者业界，耗电性能测试已有非常多的成熟方案。既有高端深入、带着原理去测试的方案；也有直接读取系统文件、读取手机显示电量百分比的方案。如果你也玩《王者荣耀》，前者可以类比于王者高端局，后者则是青铜匹配局，各有各的乐趣。

读取系统文件或采用工具获取整体手机电流值的方法，受影响的因素多，数据波动大，可信度不高，同时从开发角度说，告诉他一个简单的电流值，对他们定位问题的帮助，也不够。

图一源码中计算APP耗电的逻辑

先简单看下Android源码，无需过于深入理解逻辑。在BatteryStatsHelper类中可以发现，某个App的耗电量值，来源于方法processAppUsage，其中包含CPU、wakeLock、移动网络、WiFi、蓝牙、传感器、摄像头、闪光灯等细分耗电量。通过以上分析：

“这个版本，我们APP耗电量高。”

就可以变成：

“这个版本，我们APP占用CPU时间片过高。”

“这个版本，我们APP单位时间收发网络流量过高。”

“……”

与此同时，CPU、wakeLock、移动网络耗电量等细分指标，则都可以成为测试人员关注的专项测试项。同时测试人员也可以根据自己业务团队重点关注的方向，设计对应的专项测试。

二、数据源 #

在linux中，使用cat /proc/pid/stat获取数据，其中第13、14位数据代表utime、stime。如下，这两个值代表pid进程从进程存活以来，在用户态运行的时间为：1587 jiffies，在内核态运行的时间10 jiffies。

utime=1587 该任务在用户态运行的时间，单位为jiffies。

stime=10 该任务在核心态运行的时间，单位为jiffies。

本方案，主要以这两个值为依托，输出APP耗电各场景下的耗电性能。

三、数据采集

首先设计一个基类，用于各类性能测试，包括本篇的CPU耗电，以及内存性能、UI流畅度等其他专项。主要用于统一化测试执行逻辑set_up()、tear_down()中的调用逻辑（都为start和stop）。

图二性能测试基类

Jiffs的收集方案，在set_up()调用JiffsCollector实例的start()方法时，创建定时器1s后开始执行self.__fun_get_jiffs。同样，在__fun_get_jiffs中同样适用定时器每隔5s收集一次/proc/pid/stat中的utime、stime数据，同时计算这5s过程中，进程耗用的CPU时间( =current_utime – last_utime )。同时每收集一次数据，使用__write_line向文本中将本次计算果写入csv文件。

图三JIFFS性能数据收集具体逻辑

四、数据使用

获得单一进程的JIFFS数据后，使用如下表的平均值即可评估出一个特定UI自动化用例场景下，对应的每5秒 utime、stime是否有优化或者达标。

图四平均值评估CPU耗电

但如上，假设获得333.10jiffs/5s这个值，从标准上可以判定其不符合预期，那如何驱动开发去修改问题呢？

开发在得知这个结果之后，需要复现测试的场景，相当于重走了测试同学的执行路径。所以如果测试多走一步，开发就可以少走两步。借助Android Device Monitor工具（Android Studio -> Tools -> Android -> Android Device Monitor），我们可以获取到详细的ThreadJiffs数据。（Tips:DDMS Threads界面可以 ctrl+a全选，ctrl+c复制到excel做排序）。

图五DDMS分析线程CPU占用

在黑盒性能自动化发现有进程有CPU耗电异常之后，使用DDMS分析debug包，一般可以找出几个耗电大头线程。同时使用refresh功能，又可以大致查看到该线程到底是运行在哪些方法上。

通过以上的分析，基本上可以为业务开发找到CPU耗电元凶。其实如果没有前述的黑盒UI自动化框架，测试在黑盒测试中如果感觉到应用总是会导致手机发烫，也可以去用DDMS关注下各个线程的CPU占用时间，找出Thread元凶给开发修改。

关注微信公众号：腾讯移动品质中心TMQ，获取更多测试干货！