宇宙APP简单的性能测试
2016-04-18 17:32
225 查看
前言
这两周用python自己折腾了一个安卓性能测试工具,当然,整套工具的功能还不够完善,但是,测试几个指标基本上是没什么问题的。本着结果驱动的原则,先用这套工具来试试我们的宇宙级炒股APP**微证券**(下称宇宙APP)的性能。工具概览
工具的开发流程在这里:《AndroidTestTool开发笔记》工具由两部分组成,一是客户端,二是web端,具体怎么划分的?其实我就是看心情。工具大概长这样
![](http://7xsgl3.com1.z0.glb.clouddn.com/6E2A853B-7FA1-46DB-970B-E153C53EB2AD.png)
![](http://7xsgl3.com1.z0.glb.clouddn.com/D40ABEF3-5AFF-4107-8DE9-1219E92A724E.png)
工具的作用
工具大概监控这么几个指标,内存、cpu、wlan流量,以及封装了Monkey做满负载执行。多次测试正常使用的指标
一次测试—模拟正常手工操作
首先模拟正常的操作监控内存、cpu和wlan流量(全程使用wifi,所以这个指标代表流量的消耗),测试时间5分钟左右(使用秒表记录,时间可能会有略微的偏差)。第一次内存监控数据:
![](http://7xsgl3.com1.z0.glb.clouddn.com/3F7C7D57-9435-4DFE-9CAC-08AB2F5D7619.png)
第一次cpu监控数据:
![](http://7xsgl3.com1.z0.glb.clouddn.com/20C18466-D2BE-4BF8-A848-57F6EC551E0F.png)
第一次流量监控:
![](http://7xsgl3.com1.z0.glb.clouddn.com/EAB14141-4D89-483C-8D34-9289401DA9CC.png)
第一次测试的总结
第一次测试我模拟了正常用户的使用,查看咨询内容、查看个股详情,查看排行榜数据、查看投资学院、修改了头像昵称等操作。第一次测试暴露了以下问题:
内存存在抖动现象
cpu走势不稳定
当然一次测试肯定是不够的,上述两个问题的出现很可能是由于其他因素导致的,比如第一次使用APP,会导致加载大量的数据,导致CPU使用量巨大,内存不稳定等问题,而且第一次使用需要加载大量的数据,流量也会慢慢的往上走,带着这些问题,继续进行第二次测试。
二次测试—模拟手工测试
二次测试如同第一次测试一样手工执行,获取的指标如下:第二次内存监控数据
![](http://7xsgl3.com1.z0.glb.clouddn.com/9DC2A24F-111F-49AA-A5F3-6A7D63BC37C2.png)
第二次cpu监控数据
![](http://7xsgl3.com1.z0.glb.clouddn.com/E21BA601-C20E-483F-B354-8CBF42C88944.png)
第二次流量监控数据
![](http://7xsgl3.com1.z0.glb.clouddn.com/D682E488-1EE0-4884-A571-A9A69177307B.png)
第二次测试结果的总结
从第二次测试结果来看,与第一次的结果并没有很大的出入,内存轻微抖动依然存在,CPU时高时低的情况也没有消除,流量数据也是老样子,不过综合第一第二次来分析,APP的流量消耗其实并不大,流量攀升都在APP打开的初始阶段,也就是在刷财讯数据的时候,都是加载新的资源,其他时候流量的消耗都是缓慢上升。属于可接受范围。那么问题来了,是因为APP内部的代码有问题,进行了过多的数据处理、图形的绘制,导致走势图抖动,还是正常处理数据的走势图就是这样呢?为了确认这个问题,我找了其他同类的APP进行竞品测试。
竞品测试
竞品我选择了腾讯的自选股,作为互联网龙头企业的产品比较有标杆作用,来看看自选股的表现怎么样。同样的时间,同样的我在操作,我们来看自选股的几个指标的表现。
自选股内存监控数据
![](http://7xsgl3.com1.z0.glb.clouddn.com/8040F4D5-94B4-4D51-9EDB-02699F248CFD.png)
自选股cpu监控数据
![](http://7xsgl3.com1.z0.glb.clouddn.com/0D67E6C8-4AC2-4FFF-9A71-2E602CCD2310.png)
自选股流量监控数据
![](http://7xsgl3.com1.z0.glb.clouddn.com/9FF14466-FB60-449B-AE26-DA1E4C7192F7.png)
综合自选股测试结果的总结
从自选股的三个指标来看,内存的轻微抖动属于正常现象,只要不超过最大值引发OOM,也不是全程频繁的抖动,我们都可以认为是合理的。CPU的上下波动属于正常现象,行情方面涉及到大量的数据处理,CPU标高,离开行情页面,CPU走低,这种波动也属于正常现象。从趋势图我们可以看出,自选股的内存抖动情况比我们的宇宙APP更加频繁,cpu的浮动相对较少,二者都可以理解为正常的范畴。从流量上看,自选股显然要比我们的宇宙APP少很多,但是由于APP安全处理等原因,导致没办法抓通讯数据进行分析,只能从表现层来分析数据,自选股的行情数据是通过手工刷新来更新数据的,而我们的宇宙APP是自动刷新的,也就是说在测试的5分钟内,自选股的行情只有我手工触发刷新时才会产生流量,而我们的宇宙APP属于5分钟内无时无刻都在刷新数据,因此产生的流量较高,当然影响流量的因素还有很多,由于种种原因没办法做很深入的分析,只能做一个粗浅的判断。
结果
有图有真相,有数据有真相,从这三个指标来看,我们的宇宙APP离行业的标杆产品还有一些距离,但是这个距离并不大。当然。APP的好坏不仅仅是这三个指标衡量的,还有功能,用户体验,流畅度等等许多因素影响,本文仅列出这三个指标是因为我的测试工具目前只能测试这三个指标。
现在,来一组满负载(使用Monkey执行)的指标图:
内存信息:
![](http://7xsgl3.com1.z0.glb.clouddn.com/520B8C6F-5177-485B-9B46-2768B7DA6A59.png)
cpu信息:
![](http://7xsgl3.com1.z0.glb.clouddn.com/CB9F808E-2DCF-4571-9D1A-4DC7C4BDB077.png)
流量信息:
![](http://7xsgl3.com1.z0.glb.clouddn.com/4974AEB2-EEC0-40CD-8133-401EE815D3FD.png)
由于我对Monkey命令没有做优化处理,因此单一的结果并不具有参考性(很明显,上面测试最后转到了一个死胡同里一直跑,数据全部都是平缓的走)。这里只是为了说明,我们宇宙APP的性能还可以,Monkey并没有跑挂,啊哈哈哈哈!
其他指标
除了我自己工具的几个指标以外,还有一些其他指标,比如gfxinfo、GPU过度绘制等,我也做了一下简单的测试。gfxinfo
这个指标其实就是FPS,打过游戏的对这个名词应该都不陌生,在APP中就表示动态绘制某个页面的时间,官方的说法是大于16MS就会产生卡顿的感觉。这个指标主要是用来衡量一些动态场景的流畅度,在炒股APP里面,一个股票列表的滑动,另一个是自选个股左右滑动的切换。gfxinfo有三个参考的指标。Draw、Process和Execute。
Draw表示显示列表的时间开销,记录了所有view对象的绘制时间,这个指标高,要么就是view太多,要么就是执行效率太低。
Process表示显示列表中绘制指令的时间,这个指标过高就表示View的数量过多。
Execute表示一副图像由合成器合成的时间,这个指标过高就表示合成的效率低下。
针对这个指标,我们的宇宙APP基本上是惨不忍睹。请看图:
![](http://7xsgl3.com1.z0.glb.clouddn.com/FC5C5E0C-8C50-4B1A-A794-2118007EB772.png)
在绿色横线以上都是不合格的。所以在使用的时候快速切换个股,可以很直观的感觉非常非常的卡。图中Process的指标突破天际了,所以可以初步断定View的数量过多
对比对比其他的我们看看结果。
![](http://7xsgl3.com1.z0.glb.clouddn.com/BFF65971-E761-4573-B35A-8B454F72FBAD.png)
![](http://7xsgl3.com1.z0.glb.clouddn.com/643641D4-D55E-49F9-A8BD-128E88956670.png)
![](http://7xsgl3.com1.z0.glb.clouddn.com/BE59FD0E-654C-4DDD-A7A7-D4E9B612E919.png)
![](http://7xsgl3.com1.z0.glb.clouddn.com/064D773D-3951-4663-A75C-817CC85BA2E0.png)
![](http://7xsgl3.com1.z0.glb.clouddn.com/857249ED-F71B-4634-AC18-2B5AB99D5610.png)
看了这么些APP的表现。。。只能说券商系的APP在这点上是一脉相承的烂到渣,而互联网公司的产品用户体验就会好上很多。
GPU过度绘制
GPU过度绘制指的是在屏幕一个像素上绘制多次(超过一次),比如一个TextView后有背景,那么显示文本的像素至少绘了两次,一次是背景,一次是文本。GPU过度绘制或多或少对性能有些影响。参考指标:
蓝色 1x过度绘制
绿色 2x过度绘制
淡红色 3x过度绘制
红色 超过4x过度绘制
怎么理解这个指标呢,打开GPU显示,如果是红色一片,就表示绘制过度,如果是蓝色绿色,就表示整个UI的体系设计的还是很好的。
我们来看看宇宙APP的表现。
可以看出,淡红色一整片附带了一些深红色,也就是说过度绘制是比较严重的。
上图是微信的表现,可以说是非常棒的,可以说,几乎看不到红色。当然,不同类型的产品可比性是比较低的。就像上文中我们说CPU上下跳动很大的情况一样,同类产品的比较才能看出问题。我找了自选股和同花顺的图来对比。
自选股:
同花顺:
可以看出,自选股和同花顺都是非常重度的进行了绘制,也从侧面反映了一个问题,行情页面的展示UI是比较复杂的,难免涉及到重复绘制的问题,而IM类的软件结构相对简单,因此重度绘制不明显。
不过话又说回来,这种绘制消耗最大的是CPU。而现在安卓手机的配置高的吓人,CPU没有个4核都不好意思拿出来卖,更何况旗舰级都已经到八核十六核了,再多绘几层用户也不会有感觉。
但是高CPU会大大增加电量的消耗,为什么玩游戏耗电特别快,就是因为游戏动画需要吃非常高的CPU,手机发热,耗电加快,因此这个指标虽然不影响用户体验,但是在不影响功能的情况下,进行优化,也是对APP一个很大的提升。
结语
文章列的一些指标都是无需root无需代码,从一些侧面就能够发现的性能问题,还有很多指标,比如uss需要root,数据处理和IO等指标更是需要从代码入手去埋点检查,衡量一个APP的好坏也不仅仅是看这些指标,还有很多其他因素,So,学习之路还很长。相关文章推荐
- android AsyncTask介绍
- Android 枚举(Enum)类最佳实践
- Android拓展系列(12)--使用Gradle发布aar项目到JCenter仓库
- Android studio 引用系jar包的问题
- Android M 新的运行时权限开发者需要知道的一切
- Unity3D_NGUI_性能优化实践_CPU卡顿
- Android Binder设计与实现 - 实现篇
- objc_setAssociatedObject关联
- Android获取程序路径 (/data/data/appname)
- android 通过uri获取bitmap图片并压缩
- iOS 应用程序生命周期中那些不可忽视的“存在”
- Android 练习项目 ——简单记账软件的实现
- Android 为PopupWindow设置动画效果
- Swift 闭包(Closures)传值
- Nagios利用NSClient++监控Windows主机
- Android - Jar mismatch! Fix your dependencies问题解决
- Android实现文本排版
- iOS--资料--类目Category收集
- android基础 --- 权重(weight)
- android中HandlerThread的原理和用法讲解