Android app性能测试小结(7个性能指标)
1.性能测试的几个指标:
2.性能测试环境准备:
3.启动时间
3.1,监控值的获取方法
启动分为冷启动和热启动,冷启动:应用程序首次启动,进程首次创建并加载资源的过程;热启动:应用程序启动后点“back”键、“Home”键,应用程序退到后台,并未被完全“杀死”的状态,再次启动;
3.1.1,冷启动
启动App命令:adb shell am start -W -n package/activity 停止App命令:adb shell am force-stop package
获取package/activity的方法:1.先执行监控指令 adb logcat | grep START,再启动程序,生成的log信息中可以查看该程序的包名和activity名
ThisTime:647 这条信息中的时间就作为这次应用启动的耗时
3.1.2,热启动
启动App命令:adb shell am start -W -n package/activity 停止App命令:adb shell input keyevent 3 (发送一个keyevent事件,3代表点击手机上的“back”键)
ThisTime:427 这条信息中的时间就作为这次应用启动的耗时
3.2,“启动时间”监控的脚本实现
“启动时间”监控的脚本实现有两种方式:1.获取命令执行时间,作为启动时间参考值;2.在命令前后加上时间戳,以差值作为参考值(此种方式相对更精准)
脚本中需要创建两个类以及方法:
脚本实现如图1、2
得到的数据在csv文件中,数据分析时去掉第一次的数据,取均值,并绘制出一个数据曲线,得到的均值的参考价值的体现方式有两种形式:1.取竞品的数据作为对比(比如测试的是google浏览器,用其他浏览器做对比);2.取历史版本的数据做对比(版本间对比,看最新版本的开发过程中是否造成了启动时间的延长)
3.2.2,时间戳差值监控用到的类以及方法:
4,CPU监控值的获取方法、脚本实现和数据分析
4.1获取方法:
取图中第一个百分数作为cpu状态值
脚本实现如图3、4
注意:关于cpu的状态测试的时间要稍长一些,需要配合一个自动化脚本来实现对设备的操作,例如重复搜索100次,同时执行监控命令,来获取搜索100次之后的cpu状态值
5,流量监控值的获取方法、脚本实现和数据分析
5.1获取方法:
1.首先要获取进程的ID,命令:adb shell ps | grep packagename;
,如图中的“5715”就是我们想要的进程的ID。
2.获取进程的ID流量,命令:adb shell cat/proc/pid/net/dev(pid:第一步中获取到的进程的ID);
如图,得到的结果中只需要关注两个值:Receive(app接收到的数据)、Transmit(app发出的请求数据);流量等于这两个值的和:Receive+Transmit。只取eth0、eth1两个网卡的Receive和Transmit即可,也就是把图中框起来的4个数值相加。
脚本实现如图5、6
在实际的测试采集过程中,需要多次采集数据,取最后一次采集到的流量值和第一次采集到的流量值的差,作为我们本次测试过程中的流量消耗,这也是我们关注的重点!
6,电量监控值的获取方法、脚本实现和数据分析
*注意:一般,用硬件去测试电量的消耗更为准确,用脚本的方式去获取电量值会与用硬件获得的值有一点的偏差,但是用脚本的方式适合硬件资源相对有限的创业公司。
6.1获取方法:
1.命令:adb shell dumpsys battery;2.因为测试过程中需要手机和电脑通过USB线连接,这样会造成测试电量的过程中手机同时也在充电,所以需要通过命令切换成“非充电状态”,此命令为:adb shell dumpsys battery set status 1;
如图,level值就是电量,取测试结束后和测试开始时的电量做差,就是我们要得到的测试过程中电量的消耗。
脚本实现如图7、8
7,内存监控值的获取方法、脚本实现和数据分析
7.1.内存监控值的获取方法
命令:adb shell top;执行完命令后,在所得的数据中,需要关注两个字段:VSS(虚拟耗用内存)、RSS(实际使用物理内存),然后对测试过程中VSS、RSS的变化情况做曲线图,得出测试过程中内存的变化情况。
具体的步骤:1.,(-d:命令刷新的频率,1的单位是“秒”),将得到的数据输出到meminfo文件中
2.操作被测试的应用
3.对得到的数据过滤,过滤出所测试应用的内存值(如图)
7.2.脚本实现如图9、10
7.3.数据分析
打开得到的csv文件,windows系统可以用excel打开,然后对VSS、RSS做曲线图
得到的曲线图中,具体什么样的表现是有问题的、不可以接受的,需要长时间的测试之后才可能发现一些问题;
1.例如连续测试2个小时或以上,然后看内存变化的区间范围,如图中内存的变化区间(最大值-最小值)为6M,可以认为6M的变化对app的影响并不大!如果长时间测试之后得出的变化区间在几百M,一般认为此时的内存消耗是有问题的。
2.由于每次软件发版都会测试内存,我们要在多次测试的过程中根据内存的变化得出一个经验值(参考值),然后对比本次测试所得的值和经验值,来判断本次测试所得的值是不是在合理区间内。
8,FPS&过渡渲染的概念和监控方法--分析页面卡慢的方法
A.FPS:Android应用的帧率FPS(每秒的帧数)是衡量应用流畅度的一个非常重要的指标,可以根据FPS对应用做一些优化,Android系统里定义每秒大于60帧是流畅的(一帧的完成时间是16ms),如果每帧的完成时间大于16ms,我们认为就有卡顿的现象。
1.获取方法:进入到开发者选项,可以看到有“GPU呈现模式分析”的选项,开启后即可以条形图和线形图的方法显示系统的界面响应速度,可以用以观察系统流畅度。那么要如何根据曲线判断系统是否流畅呢?实际上这个曲线表达的是GPU绘制每一帧界面的时间,只要不超过顶部绿线,都可以视为足够流畅。
开启GPU呈现模式分析
只要下方的曲线不超过绿线,都可以视之为流畅
使用系统自带方法测试流畅度的好处很多,首先是数据准确,系统肯定最知道自己的帧率如何;其次是不占资源,对流畅度测试的影响比较小。那么这个方法是否万无一失呢?其实还是有一些缺点的。比如说利用CPU渲染UI的App界面,就无法得到测试结果(当然这些界面基本无一例外卡顿无比,不用测也知道不流畅);当系统停顿了一下,例如微博加载图片时,响应速度会大幅增加,曲线瞬间突破绿线——这情况不能说不流畅,因为这属于内容和界面先后响应的机制,如果光凭曲线是否突破绿线判断是否流畅,未免太过局限。所以,在测试应用程序的时候,需要一边操作应用,去直观的感受流畅度,一边观察曲线的走势,如果直观的感受流畅度差,并且曲线也大量的突破绿线,那么此时我们认为测试应用的流畅度低,需要优化。
1.在设置里打开GPU呈现模式分析。点击Android设备的“设置”->"开发者选项",然后勾选“GPU显示配置文件”。
2.
2.1.点击Android设备的“设置”->"开发者选项",然后勾选“GPU显示配置文件”。重启我们的应用。启动应用以后,在应用的页面上做滑动
2.2.lijiedeMacBook-Air:~ lijie$ adb shell dumpsys gfxinfo com.dianping.v1>fps.txt (com.dianping.v1即packagename)
2.数据分析:
打开生成的fps.txt,找到Profile data in ms这部分数据。
4.为了看得更直接,我们可以把数据放到Excel中,然后以图表的形式进行查看。
从图中可以看出来,我这个应用的流畅度是很低的,正常情况下每帧的完成时间在16ms左右,如果1秒60帧的话,而且Execute时间太长!所以是需要进行优化的。
a: "Draw" : 创建显示列表(display lists,记录所有view对象的绘制指令)的时间开销。
b: "Process" : 执行显示列表中绘制指令的时间。UI视窗中的View数量越多,需要执行的绘画命令就越多。
c: "Execute" : 将一帧图像交给合成器compostior的时间。这部分占用的时间通常比较少
测试方法二:FPS Meter测试安卓帧数
FPS Meter是一款非常实用的小软件,能够用数字实时显示安卓界面的每秒帧数,非常直观。此外,FPS Meter还可以显示最大帧数、最小帧数以及平均帧数,用来评价安卓流畅度极具价值。由于涉及到了系统功能,所以FPS Meter需要root。如果你打算尝试,请先root机后再使用。
FPS Meter的使用很简单,开启App后启动服务即可。在App内,你可以选择帧数显示的位置,以及是否开启平均帧数、最低/最高帧数显示。开启服务后,即可看到有帧数显示于界面上。这里要注意,使用FPS Meter测量帧数需要在开发者选项中停用HW叠加层才会比较准确。
FPS Meter可以显示最大最小帧数以及平均帧数
FPS Meter可以测试界面帧数,不过某些手机如果界面静止,帧数会为0。FPS Meter除了测量系统界面帧数外,还可以用来测量游戏的帧数,所以用FPS Meter来测试某部安卓机游戏性能多强也是个很好的选择。
当然,FPS Meter也并非十全十美。由于属于第三方App,所以可能会有一些兼容性问题。某些安卓机或者ROM使用FPS Meter可能会不兼容,即使成功开启了帧数显示也没法测量到准确数值,而某些设备使用FPS Meter甚至会死机。不过在大多数情况下,这款App还是相当值得信任的。
安卓在多个版本中都通过新技术提升了流畅度,比如说安卓2.3引入Dalvik、安卓4.0引入GPU界面绘制、安卓4.1引入黄油计划、安卓4.3引入Trim以及安卓4.4引入ART等等。
2.过渡渲染:
屏幕上的某个像素在同一帧的时间内被绘制了多次。简单言,app的一个页面所显示的效果是由像素一帧一帧绘制而成,过度绘制就是意味着这一帧被绘制多次。
如果是静态的布局,可能影响不是很大,如果是动态的,比如ListView,GridView,ViewPager等在性能上就会差一点,常见的比如listView上下滑动,过度绘制的情况下,就会出现卡顿,或者跳跃感很明显。 当然过度绘制肯定无法避免,我们只能减少不必要的绘制,那么如何看的出来,一个页面是否过度绘制呢?
下面我们来看一下,下面说的这个工具只有Android 4.2以上有此功能。
2.1.打开我们的手机设置--开发者选项--调试GPU过度绘制(可能有些手机不是这样的叫法,有的是显示GPU过度绘制,根据手机而来),选择显示过度绘制区域,此时手机页面会显示成这样,不要惊慌。。
这里给大家介绍下,绘制颜色的标识,从好到差:蓝色(1x次绘制)-》浅绿色(2x绘制)-》淡红色(3x绘制)-》红色(4x绘制)
2.2.怎么减少过度绘制
一般情况下,最好把绘制控制在2次以下,3次绘制有时候是不能避免的,尽量避免,4次的绘制基本上是不允许的。
怎么减少绘制是我们最关心的,我们来看一个图(自己项目里面的。。我们以图片下面的ListView为例子)从图上看的出来,被绘制3次甚至4次
我们来看下代码:listView和item
红色标记出来的,是问题的所在,背景颜色绘制了三次,最后一个是选择器,因为有点击效果,现在把前2个都给删掉,只留最后一个,现在我们看一下图片,看是不是达到预期的效果。
这里只是一个简单的例子,当然有很多原因组成,我们可以从以下几个方面着手:
第一:如果是相对比较复杂的布局,建议使用相对布局;
第二:如果需要多层嵌套,我们可以使用merge标签来减少嵌套;
第三:减少背景颜色的多次绘制;
第四:对于使用Selector当背景的Layout(比如ListView的Item,会使用Selector来标记点击,选择等不同的状态),可以将normal状态的color设置 为”@android:color/transparent”,来解决对应的问题;
第五:当一个页面有多种不同的显示效果,最常见的是listview 中的多种item布局,我们可以采用抽取的方式,等等。
下面再介绍以下Android studio自带的工具,
首先 打开 Android Device mointor,找到 Hierarychy view (这里我简称 视图树)
将你要查看的项目运行到模拟器或者真机上,在Android device mointor 上windows 找到当前的模拟器或者真机,找到当前的项目,
如图:点击当前项目某一个布局,在View里面会显示当前这个布局的各个节点图,然后点击3(profile node),在视图里面就会显示4上面的三个点
他们分别表示 测量 布局 绘制,再次点击的时候,我们就可以看到子节点上着三个圆点在变化,他有3个颜色,绿色,黄色,红色,红色代表着耗时最长,也就意味着我们需要优化,我们可以不断点击,查看 测量布局以及绘制所需要的时间,从而优化。