Android 性能测试之 CPU 耗电性能篇

思路简介

现有的耗电性能测试,除了高端深入带着原理去测试的方法,大多数都是读取系统文件或采用工具获取整体手机电流值,这样的方法受影响的因素多,数据波动大,可信度不高,同时从开发角度说,告诉他一个简单的电流值,对他们定位问题的帮助,也不够。

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

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

“这个版本,WiFi管家耗电量高。”

就可以变成:

“这个版本,WiFi管家占用CPU时间片过高。”

“这个版本,WiFi管家单位时间收发网络流量过高。”

“……”

与此同时,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),我们可以获取到详细的Thread Jiffs数据。(Tips:DDMSThreads界面可以ctrl+a全选,ctrl+c复制到excel做排序)

图五 DDMS分析线程CPU占用

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

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

文章来源于:腾讯移动品质中心 TMQ

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏杂烩

一种海量日志存储、分析解决方案V1.0 原

    flume,版本1.7.0,主要用来从业务系统收集数据以及从jms收集数据。

29520
来自专栏Java架构师历程

微服务架构是什么

架构师在软件行业一直有很高的位置,并且在开会中的架构师都带有主角光环。 架构师是可以说是软件的设计者,运用我们学会就会忘记的23种设计模式、企业架构模式、面向对...

64720
来自专栏Linyb极客之路

优化网站性能必备的6种架构方案,你知道吗?

一个成熟的大型网站(如淘宝、天猫、腾讯等)的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的,它是随着用户量的增加,业务功能...

11530
来自专栏织云平台团队的专栏

腾讯SNG全链路日志监控平台之构建挑战

全链路日志监控在现在盛行的微服务和分布式环境下,能有效地提高问题定位分析效率,成为开发和运维利器。当前已有开源解决方案和成熟的厂商提供。

1.3K00
来自专栏CDA数据分析师

敲黑板!你和GitHub高手就差这三条规则······

本文不会介绍如何创建 GitHub 简历或如何使用终端提交 Git。我将解释每天使用 Git 和 GitHub 的重要性,尤其对于正在学习写代码的人。我还将分享...

15820
来自专栏微服务

电商前端交易型系统设计原则

个人认为设计系统要因场景因时间而异,一个系统不是一下子就设计的非常完美,在有限的资源情况下一定是先解决当下最核心的问题,并预测/发现未来可能出现的问题,一步步解...

10810
来自专栏架构师之路

CA,给了数据库,给了机器,为啥也扩不了容?

随着业务越来越复杂,数据量越来越大,并发量越来越大,数据库的性能越来越低。好不容易找运维申请了两台机器,让DBA部署了几个实例,想把一些业务库拆分出来,却发现拆...

43970
来自专栏云计算D1net

微服务和云应用程序性能如何融合

在云应用开发时,微服务可能是开发人员最好的朋友,但他们也可能是有害的。行业专家汤姆·诺勒为此分析了人们所关注的重点。 ? 很少有技术工具是如此的优秀,以至于它们...

36440
来自专栏高性能服务器开发

1 游戏服务器开发的基本体系与服务器端开发的一些建议

近年来,我身边的朋友有很多都从web转向了游戏开发。他们以前都没有做过游戏服务器开发,更谈不上什么经验,而从网上找的例子或游戏方面的知识,又是那么的少,那么的零...

73630
来自专栏CSDN技术头条

中华万年历头条数据聚合优化之路

业务介绍 中华万年历的头条数据是根据推荐算法聚合而成的数据,包括ALS算法数据、用户画像数据、时效数据、非时效数据、定投数据、惊喜数据、频道数据、热榜数据、用户...

26380

扫码关注云+社区

领取腾讯云代金券