目前,随着APP行业的竞争越来越激烈,功能也越发丰富,人们评价一款产品的优秀程度,已经不能单纯通过 ”是否具备某些功能“ 来评价某个产品了,纯技术壁垒的产品已经是凤毛麟角,从用户角度,客户端不仅仅需要具备用户的基本诉求功能,流畅程度、发热程度、启动速度等等,分分钟可能让用户放弃你的APP,从而拥向你竞品APP的怀抱。
随着H5技术的快速发展,微信小程序的出现,使用前端相关语言开发,无论是“网页版”APP还是混合开发模式,市场占有率也不断增高,试想如果前端语言开发的产品和Native开发的产品,体验差不多,也就没有原生APP什么事情了, 毕竟开发成本摆在那。谁都不是sha zi,能用一份价格,搞定多个环境(Android手机、iOS手机、PC),相信老板们是很精明的。
那么作为一名Android APP的研发人员,我们应该从哪些角度来优化我们的APP以提高竞争力呢?又应该以什么“标准”来评价自己所做的优化工作是否合理呢?基于这些背景,我总结了一些关于产品优化的几个维度,如图:
网友们也称作使用率,通俗的可以理解为APP在运行过程中,对于CPU资源的使用情况,若CPU使用率过高,会使整个手机无法响应用户,整体性能降低,影响用户体验,也容易引起ANR等问题,故我们的目标是APP正常运行的情况下,CPU使用率越低为好。
常用的测试方法:使用adb命令;使用Android studio profiler;使用各种云测平台;
方法1、基于adb shell dumpsys cpuinfo的方式,此方式可以测试手机中任意packageName的app
adb shell "dumpsys cpuinfo | grep package" //其中package为具体应用的包名信息
例如: adb shell "dumpsys cpuinfo | grep com.android.browser" //当前系统浏览器的情况
第一个参数:0.1%即为当前情况下,该应用的CPU使用情况,具体一目了然。
方法2、读取方 /proc/pid/stat的方式
adb shell cat /proc/stat
Linux层有公共目录。很多公共信息资源由两个虚拟的文件系统提供:
/proc:包括内存,CPU,网络等
/sys:设备驱动,网络环境(/sys/class/net/)等
通过/proc这个伪文件系统,我们可以和内核内部数据结构进行交互,获取有关进程的有用信息。
具体的解释,可以看参考文档,里面有具体的说明,图中详细记载8核CPU的使用情况。
方法3、基于Linux的top命令
adb shell top
常用参数一般有如下:
-m:表示需要展示的进程数目
-n:结束前需要刷新多少次
-d:刷新间隔(单位秒)
-s:按照什么列排序(CPU,VSS,RSS,THR)
输出的信息里面主要包括:
PID(进程ID),CPU%(CPU使用率),VSS(虚拟内存使用量),RSS(实际物理内存使用量)等等。
我们一般关心的数据列就是我们CPU%。
例如:adb shell top -m 1 -d 0 -n 1
最直观的,应该是使用Android studio的Profiler工具了,具体代码中,出现的方法占用均有明确的信息(当然前提是APP是自己的,如果是别人的APP,用adb测试):
工具中,详细展示了各个进程的使用情况,通过record一段时间记录,来分析当前环境下,具体代码占用CPU的信息。
参考:https://www.jianshu.com/p/31b1a4aef550
在Android系统中,每个APP进程除了同其他进程共享(shared dirty)外,还独用私有内存(private dirty),通常我们使用PSS(=私有内存+比例分配共享内存)来衡量一个APP的内存开销。移动设备的内存资源是非常有限,为每个APP进程分配的私有内存也是有限制。一方面我们要合理的申请内存使用,以免导致频繁的GC(垃圾回收机制)影响性能和大对象申请发生内存溢出;另一方面,我们要及时释放内存,以免发生内存泄漏。
关于内存涉及几个概念:
Terms
VSS- Virtual Set Size 虚拟耗用内存(包含共享库占用的内存)
RSS- Resident Set Size 实际使用物理内存(包含共享库占用的内存)
PSS- Proportional Set Size 实际使用的物理内存(比例分配共享库占用的内存)
USS- Unique Set Size 进程独自占用的物理内存(不包含共享库占用的内存)
一般来说内存占用大小有如下规律:VSS >= RSS >= PSS >= USS
参考:https://blog.csdn.net/adaptiver/article/details/7084364
常用的测试方法:使用adb命令;使用Android studio profiler;
方法1、基于adb shell dumpsys meminfo的方式,打印详细的当前环境PSS使用信息
adb shell "dumpsys meminfo | grep package" //其中package为具体应用的包名信息
例如: adb shell "dumpsys meminfo | 具体应用包名" //当前系统某个APP的总体情况
例如: adb shell dumpsys meminfo 具体应用包名 //当前系统某个APP的详细信息
方法2、基于adb方 shell top,将内存使用信息以文件方式储存后,再查阅
步骤如下:
(1)、adb shell top -d 1 > d://meminfo //将得到的数据输出到pc中d盘的,meminfo文件中
(2)、操作被测试的应用
(3)、中断,分析记录的数据,具体命令如下
如果是window的环境,可以使用cgywin,具体工具的安装过程,这里不做详解,来使用cat 命令过滤出想要的APP的内存使用情况信息,linux或者mac的小伙伴就没有这个烦恼了。
cat d://meninfo | grep 具体某个包名
另外,更高级的做法,是通过脚本,将meminfo信息,转换为Excel的分析报告,然后做每个时间段的对比分析图,这里不做方式的延伸,具体感兴趣的小伙伴可以自行查阅相关的资料。
最直观的,应该是使用Android studio的Profiler工具了,具体代码中,出现的方法占用均有明确的信息(当然前提是APP是自己的,如果是别人的APP,用adb测试):
发现没,和上面查看CPU情况的工具相同,没错,Android Studio 3.+以后,已经做了统一,且去留意sdk tools工具也少了很多bat,例如.9工具,MAT等等
工具中,详细展示了各个进程的使用情况,通过record一段时间记录,来分析当前环境下,具体代码占用内存的信息。
对于运行时内存的优化目标:占用越小越好,扫掉一切内存泄漏的场景
通俗理解为,用户打开APP,看到正常的画面,启动分为冷启动和热启动两种。
冷启动:应用程序首次启动,进程首次创建并加载资源的过程;
热启动:应用程序启动后点“back”键、“Home”键,应用程序退到后台,并未被完全“Kill”的状态,再次启动;
冷启动测试:
启动APP命令: adb shell am start -W -n package/activity
停止APP命令: adb shell am force-stop package
package为应用的包名,activity为具体页面,启动测试可以是launcher配置的页面
例如,测试浏览器的启动时间:
adb shell am start -W -n com.android.browser/.BrowserActivity
adb shell am force-stop com.android.browser
结果分析: ThisTime:596 这条信息中的时间就作为这次应用启动(冷启动)的耗时,单位是ms。
热启动测试:
启动APP命令: adb shell am start -W -n package/activity
停止APP命令: adb shell input keyevent 3 (发送一个keyevent事件,3代表点击手机上的“back”键)
例如,依旧是测试浏览器的启动时间:
adb shell input keyevent 3 //关掉上面程序已经冷启动的页面
adb shell am start -W -n com.android.browser/.BrowserActivity //重新打开APP
结果分析:ThisTime:196 这条信息中的时间就作为这次应用启动(热启动)的耗时,单位是ms。
更加专业的手段,可以通过监控脚本实现,具体这里不做详细介绍,有兴趣的小伙伴可以另行查阅,资料还是蛮多的。
对于启动时间的优化目标:启动时间越小越好!没有最小,只有更小
应用的流畅度是最直接影响用户体验的,与之直接挂钩的概念为 FPS(每秒的帧数),Android系统里定义每秒大于60帧是流畅的(一帧的完成时间是16ms),通过帧率和流畅度曲线,可以帮助开发者分析是否存在UI问题。
平滑的完成一帧意味着任何特殊的帧需要执行所有的渲染代码(包括 framework 发送给 GPU 和 CPU 绘制到缓冲区的命令)都要在 16ms 内完成,才能保持流畅的体验。如果没有在期间完成渲染秒就会发生掉帧。掉帧是用户体验中一个非常核心的问题,丢弃了当前帧,并且之后不能够延续之前的帧率,这种不连续的间隔会容易会引起用户的注意,也就是我们常说的卡顿、不流畅。
测试方法:https://developer.android.com/training/testing/performance?hl=zh-cn
方法1、开发者模式下:“GPU呈现模式分析”, 只要下方的曲线不超过绿线,都可以视之为流畅
方法2、Android设备的“设置”->"开发者选项",然后勾选“GPU呈现模式分析”,勾选adb shell dumpsys gfxinfo,记录信息到文件中(不同品牌手机路径可能不同)
例如:adb shell dumpsys gfxinfo {具体某个应用的包名} > d://fps.txt 将某个应用的信息记录到d盘fps文件中
打开生成的fps.txt,找到Profile data in ms这部分数据,也可以将数据添加到Excel中查看
"Draw"" : 创建显示列表(display lists,记录所有view对象的绘制指令)的时间开销。
"Process" : 执行显示列表中绘制指令的时间。UI视窗中的View数量越多,需要执行的绘画命令就越多。
"Execute" : 将一帧图像交给合成器compostior的时间。这部分占用的时间通常比较少
通过图表方式,就很直观了,建议直接测试较复杂的页面,发现Execute这一列明显执行时间变长(大于16ms)后,就得留意看看具体APP对应的页面如何优化了,通过记录数据,与优化前的数据进行对比(例如做个折线图),也能清晰的分析自己的成果。
方法3、在程序中添加BlockCanary,监控程序的卡顿情况,这块资料比较多,不做详细介绍;
对于流畅度的优化目标:控制一帧的完成时间在16ms内
提到过度绘制,相信很多人都知道,产生的原因,一方面是设计的复杂性,但主要还是和研发人员所采用的具体方案决定。常说条条大路通罗马,其实想实现UI的功能,方法很多,走错路也很常见,对于过度绘制的测试主要通过人工进行测试,系统是不会报错的,一不小心就创建了一个多层套用的布局,想从根本上解决问题,还得从健康的习惯开始,首先我们先来几张熟图(被盗来盗去的)。
蓝色:1倍过度绘制
绿色:2倍过度绘制
浅红色:3倍过度绘制
深红色:4倍过度绘制及以上
测试方法有:
方法1、打开开发者选项中的显示GPU过度绘制来进行测试(PS:只有Android4.2及以上的版本才具备此功能),直接在手机上查看结果;
方法2、使用Android Studio的Tools——>Layout Inspector
首先启动APP后,打开Activity,然后再使用Inspector分析
这个是使用了分析后的结果,可以看到明显的存在过度绘制的问题,套用层级过多,如使用约束布局,或者自定义View来绘制Item,则可以减少很多层级关系。
凡事得有个标准,我们才能更好的来优化,所以比较流行的验收的标准(网友版)为:
(1)、不允许出现黑色像素;
(2)、不允许存在4x过度绘制;
(3)、不允许存在面积超过屏幕1/4区域的3x过度绘制(淡红色区域)
以上是我们自己的APP的分析,那么我们如何来分析别人的APP呢?
方法3、使用 “uiautomatorviewer” 测试;
从Android studio 3.1以后会发现没有了DDMS,用uiautomatorviewer可以替代它,路径在:Android SDK->tools->bin->uiautomatorviewer,启动后,可能会遇到“Unable to connect to adb. Check if adb is installed correctly”(我遇到了),此时,将uiautomatorviewer.bat,用NotePad++等工具打开,将文件最后一行的bindir路径修改为SDK的platform-tools所在路径(注意,用完后,还得还原回来,我测试用win10的操作系统,在platform-tools使用后,发现Android studio中Layout Inspector启动不了,下图配置还原后又恢复了)
上图,是我拿手机某个优秀APP来分析的案例,通过UI工具,可以很清晰的,分析别人做的产品使用了哪些布局技术,以及他们的层级关系。通过与优秀的APP做对标,我们来优化自己的APP,目标也就很清晰了。
对于过度绘制的优化目标:减少冗余的层次使用,活用相对布局、约束布局、自定义VIew,ViewGroup、活用Merge,ViewStub,include等等手段。
我们通常所说的APP卡、慢通常就是由于页面响应时间过长导致的。
可供参考的标准:
优秀:0~400ms;
标准:400ms~2000ms;
轻微隐患:2000ms~5000ms;
严重隐患:5000ms以上。
测试方法:
方法1、:使用 “logcat” 测试页面启动时间;
方法2、:使用第三方的云测工具,市面上很多,选择一款即可
例如:OneAPM, https://www.oneapm.com/
华为DevEco, https://deveco.huawei.com/
百度测试, http://bce.baidu.com/product/mat.html
Testin, https://www.testin.cn/
这里主要介绍下方式1,logcat这个控制台,相信大家都非常熟悉,通过过滤tag,display即可得到结果。772ms即为此次开启页面所消耗的时间
对于响应时间的优化目标:当然是越短内越好啦!
安卓稳定性标准,有两大指标:
(1)、闪退率,闪退率包括java的闪退率以及native闪退率;
(2)、ANR,就是应用没有响应。
主要分两个方面:
(1)、启动崩溃率,
公式 = 应用中一天发生闪退总数 / 应用一天中总的启动次数;
(2)、用户或设备崩溃率,
公式 = 应用一天中发生的闪推用户数(去重)/ 应用一天中总体的活跃用户数;
测试方式:1、上线前(Monkey测试、华为终端云测、Testin云测等等);2、上线后(友盟统计、腾讯Bugly等等);
而阿里推荐的优秀的产品,参考标准为:1、参考启动崩溃率:0~0.15%;2、参考设备崩溃率:0~0.2%。与上图的听云的数据大体相同,可以认为是行业的一个标准。
参考数据来源:
https://blog.csdn.net/x32sky/article/details/52778169
https://juejin.im/post/5ab47533f265da237d02f03c
作为开发人员,我们平时在打包Release包后,使用Monkey测试下,还是比较推荐的一种做法(基于测试员和工程师的友好相处法则),而Monkey测试具体标准是需要覆盖70%以上的页面,包括登陆,非登陆状态,并且经过八个小时不崩溃,平时如果是时间比较赶,短时间验证后及时修正明显的问题后,交付专业测试即可。
Monkey测试的方法:
1、在adb的目录,使用adb shell monkey测试;
2、如果Android studio已经配置了adb的路径,可以直接在Terminal控制台,输入指令;
具体指令为(指令比较多,这里只罗列了几个):
adb shell monkey -p {包名} -v {后面的测试的次数} –throttle {延迟时间} > {测试文件路径}
例如:
adb shell monkey -p xxx.xxx.xxx -v 100 –throttle 300 > D:\MTestLog.txt
针对包名为xxx.xxx.xxx的产品进行测试,每个事件执行时间为300ms,执行100个事件,并将测试报告输出到d盘的MTestLog.txt文件上
如果,monkey设置运行时间过长,期望中断,则可以按如下命令执行:
(1)、adb shell
(2)、ps | grep monkey 得到monkey进程号
(3)、kill pid [刚才查到的进程号]
monkey -help:可查看参数说明列表。参数选项有:
(1) -p 包名1 -p 包名2 … :指定一或多个待测试的包,若不指定则测试中可打开任意APP;
(2) -v:指定打印日志的详细程度,有‘-v’,'-v -v','-v -v -v'三个级别;
(3) -s seed值:在测试中,虽然用户操作序列(每次操作按一定的顺序所组成的一系列操作)是随机生成的,但只要对同一个包指定相同的Seed值,就能使测试事件相同,可用于排错。所以也说这个操作序列是伪随机的。若不添加此参数,结果中会自动生成seed值;
(4) –-throttle 毫秒数:指定操作(即事件)间的时延,单位是毫秒;
(5) –-ignore-crashes:使得操作序列可以全部执行完,而不会在发生崩溃时就终止程序进程;
(6) –ignore-timeouts:使得操作序列可以全部执行完,而不会在发生ANR(Android Not Responding)时就终止程序进程;
(7) –-ignore-security-exceptions:使得操作序列可以全部执行完,而不会在发生许可错误时(如证书许可,网络许可等)时就终止程序进程;
(8) –-kill-process-after-error:使得当应用程序发生错误时停止运行并保持在当前状态,即仅是静止在发生错误时的状态,而不是结束该应用程序的进程;
(9) –-monitor-native-crashes:指定监视并报告应用程序发生崩溃的本地代码;
(10)–-pct-事件1 事件百分比1 -pct-事件2 事件百分比2 … :用于指定某类事件数目占总事件数目的百分比;
其中所指定事件参数选项可为:
-flip(点击事件)
-touch(触摸事件是一个down-up事件)
-motion(动作事件由一个down事件、一系列的伪随机事件和一个up事件组成)
-trackball(轨迹事件,在屏幕上进行随机拖动)
-nav(基本导航事件,如上下左右键)
-majornav(主要导航事件,通常引发图形界面中的动作)
-syskeys(系统按键事件指如系统按键Home、Back、Start Call、End Call及volumeControl)
-appswitch(启动activity事件)
-anyevent(其它类型事件)
注意,各事件类型的百分比总数不能超过100
实际开发过程,可以通过脚本,例如Python等,指定点击设备的具体位置,流程化的进行测试验证,具体可以参考:
https://juejin.im/entry/59a7d23a6fb9a024a27c0e85 //含scriptfile、python
稳定性优化的目标:崩溃率控制在优秀的范围内,越小越好,且问题越早发现越好,上线前做下灰度测试也是不错的选择。
相对于PC来说,移动设备的电池电量是非常有限的,保持持久的续航能力尤为重要。Android的很多特性都比较耗电(如屏幕,GPS,sensor传感器,唤醒机制,CPU,连网等的使用),我们必须要慎重检查APP的电量使用,以免导致用户手机耗电发热,带来不良体验。
测试方法,测试手机安装目标APK前后待机功耗无明显差异, 常见使用场景中能够正常进入待机,待机电流在正常范围内。长时间连续使用应用无异常耗电现象;电量测试的方法分为软件测试和硬件测试两类。
测试手段包含软件测试和硬件测试两类,这里主要介绍下软件测试的手段:
方法1、通过BatteryManager发的广播来做分析,可参考:http://hukai.me/android-training-course-in-chinese/performance/monitor-device-state/battery-monitor.html
方法2.1、adb shell dumpsys battery来获取,本地分析
方法2.2、historian.py脚本 + Python环境
(1)、下载historian.py脚本,下载地址:https://github.com/google/battery-historian
(2)、依旧是方式1,系统方式,记录日志文件,初始化batterystats数据
adb shell dumpsys batterystats--reset
(3)、拔掉手机,操作APP,操作完成后,重新连接手机,执行下面的命令,收集系统整体的Battery数据
adb shell dumpsys batterystats > batterystats.txt
(4)、得到这些数据后,这个时候使用我们的battery-historian来生成我们可见HTML报告
python historian.py batterystats.txt > batterystats.html
(5)、浏览器打开,分析具体结果
如图,level值就是电量,取测试结束后和测试开始时的电量做差,就是我们要得到的测试过程中电量的消耗
方法3、使用腾讯的GT APP,操作选中APP后,将生成的.csv文件保存到本地,再进行分析,如图停止后,获取生成的文件,SD卡目录,找到GT文件夹,具体的分析过程,不在此详细描述
参考:http://gt.tencent.com/docs/a/GTAndroidUserGuide.pdf
方法4、采用市场上提供的第三方工具
耗电量的优化目标,根据不同APP的情况,视频类,游戏类等等,寻找发热原因,优化代码才是关键
包体大小能被列为性能指标,是从APP性能指标及运营两个维度考虑的,用户是更希望包体小的同时性能要好,有时它们会是一个互相取舍的关系。对Android Apk包的资源文件进行解析,分析冗余资源文件,可压缩资源文件,并计算可压缩的比例。
优化方法:
方法1、通过Android studio的分析工具,删除冗余的“历史资源”
方法2、通过Gradle的配置
release {
minifyEnabled true //proguard 删除所有未使用的方法和指令
proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), "proguard-rules.pro"
debuggable false
jniDebuggable false
renderscriptDebuggable false
pseudoLocalesEnabled false
zipAlignEnabled true
}
//应用不需要支持国际化,那么可以设置 resConfigs 为 "zh","en",对于官方的 support library,默认是支持国际化的,也就是包含了很多不同语言的资源文件
defaultConfig {
//...
resConfigs "zh","en"
}
方法3、通过将res中的png、jpeg等图片,可考虑转为webp格式使用
目前的网络类型包含2G、3G、4Gwifi,其中还有不同运营商的区分,我们在APP的使用中经常遇到大资源,重复请求,调用响应慢,调用失败等各种情况。在不同的网络类型之下,我们不仅要控制流量使用,还需要加快请求的响应。另外,对于需要联网的手游来说,部分游戏对不同联网方式的网络类型采用了不同的流量消耗策略,主要分为wifi环境和蜂窝网络环境。我们可以根据实际采用的方案来决定具体是否分开两种环境测试。
测试方法:
获取某个应用的PID,再获取该pid的消耗流量值
首先要获取进程的ID,命令:adb shell "ps | grep 具体包名"
然后获取报告:adb shell "cat/proc/pid/net/dev" 注意替换这个pid为上一行命令获取的pid
此应用一共三个进程,其中包含两个独立服务,我们获取pid=16746来进行测试
得到的结果中只需要关注两个值:Receive(app接收到的数据)、Transmit(app发出的请求数据);流量等于这两个值的和:Receive+Transmit,取有效值Receive和Transmit相加即可。
我们做性能测试的时候,不仅要发现问题,也要定位问题,深入挖掘性能问题的根源才是我们需要持续努力的方向,通过对比其他公司的优秀产品,分析出自身APP的不足,来优化我们的代码,通过竞品分析,可以避免闭门造车,不断完善我们的方案。
另外,除了上文中提到的云测试网站,一些可用的测试工具有:
iTest:http://itest.iflytek.com:8090/
能够记录特定应用的性能消耗情况,包括CPU、内存、流量、电量等信息,支持浮窗实时查看应用的具体信息,iTest不需要集成SDK到应用中,在iTest中选中需要测试的应用即可进行测试;
Emmagee: https://github.com/NetEase/Emmagee
网易开发的性能检测工具,Emmage和iTest一样,不需要在应用中集成SDK,能够对应用的常用性能指标进行检测,并以csv的格式保存方便查看应用的各项参数;
Tencent GT: https://gt.qq.com/
腾讯系的测试工具,直接安装到手机上即可。
参考:
《Android APP性能测试小结(7个性能指标》https://www.cnblogs.com/ailiailan/p/6397663.html
《Android FPS流畅度测试》https://www.jianshu.com/p/1fe9783d266b
《APP性能测试的6项关键指标及测试获取手段》https://blog.csdn.net/hualusiyu/article/details/78460809
《那些年我们用过的显示性能指标》https://blog.csdn.net/tencent_bugly/article/details/51354517
《Android应用性能评测调优》https://www.csdn.net/article/2015-06-12/2824949/1