51Testing软件测试论坛

标题: android客户端性能测试 [打印本页]

作者: 恭喜发财dife    时间: 2018-2-23 13:23
标题: android客户端性能测试
2.1 性能指标

a,响应时间/加载速度

b,动画帧率

        图片处理器每秒刷新的帧数(FPS),可用来指示页面是否平滑的渲染。高的帧率可以得到更流畅,
更逼真的动画,不过帧率达到60fps以上,人眼主观感受到的差别就不大了。所以以60fps作为衡量标
准,即要求每一帧刷新的时间小于16ms,这样才能保证滑动中平滑的流畅度。

c,内存使用

       在android系统中,每个APP进程除了同其他进程共享(shared dirty)外,还独用私有内存(private
dirty),通常我们使用PSS(=私有内存+比例分配共享内存)来衡量一个APP的内存开销。移动设备的
内存资源是非常有限,为每个APP进程分配的私有内存也是有限制。一方面我们要合理的申请内存
使用,以免导致频繁的GC影响性能和大对象申请发生内存溢出;另一方面,我们要及时释放内存,
以免发生内存泄漏。

d,电量

       相对于PC来说,移动设备的电池电量是非常有限的,保持持久的续航能力尤为重要。另外,
android的很多特性都比较耗电(如屏幕,GPS,sensor传感器,唤醒机制,CPU,连网等的使用),
我们必须要慎重检查APP的电量使用,以免导致用户手机耗电发热,带来不良体验。

e,流量

       目前的网络类型包含2G\3G\4G\wifi,其中还有不同运营商的区分,我们在APP的使用中经常遇
到大资源,重复请求,调用响应慢,调用失败等各种情况。在不同的网络类型之下,我们不仅要控
制流量使用,还需要加快请求的响应。

f,ANR

       在android应用程序中,如果主线程(即UI线程)在超时间内对用户输入时间没有处理完毕,就会
出现Application note responding弹出框,用户可以选择等待或者强制关闭来杀死进程。

g,app crash闪退

     由于空指针,内存泄漏,数组越界等等编码问题,导致应用程序在移动设备上运行异常,发生闪
退,进程被杀。


频繁发生的问题会导致用户体验差,最终使用户卸载APP。


2.2 适配机型

     对市面上的android机型活跃用户数量进行统计。将其划分为高,中,中低,低4类型机,分别选
择其中使用量最大的作为代表机型,进行细致深入的性能测试分析。

     也可以使用虚拟机进行模拟。


2.3 网络

       目前网络有2G,2G/3G,3G,3G/4G,4G,wifi。通过统计查看每个网路的使用量。 其中弱网络
也许关注。特别是弱网络+低端机型,性能的瓶颈尤其容易碰触到。

       (问题: 什么情况或者什么样的网络传输速度可以称为弱网络?)



3 场景设计

    具体哪些场景需要性能测试,可以初步依据下面角度进行判断:

    1,业务层面,用户最核心基础的模块。

    2,新增的基础逻辑,例如登入模块,大量的用户段时间内访问,如此必须保证性能

    3,活动需求,因为活动上的新逻辑,存在较的用户访问,需要尽力提升用户体验

    4,用户体验不好的模块

当场景A需要进行客户端性能测试,那么个性能指标唯独的表现都需要关心,排除改场景中是否存
在下面这些性能问题:

   a,页面加载是否缓慢

   b,滑动是否流畅

   c,是否存在在内存泄露

   d,流量开销大不大

   e,cpu占用高不高

    f,电量消耗是否合理

    g,是否有异常的crash和ANR

    h,低端机下ANR是否加剧



开发相关:

    a,主线程有没有不合理的io调用

    b,有没有重复的网络请求

    c,图片大小有没有控制好



测试相关:

     弱网络下的加载速度是否可接受

     网络切换或者断网时是否有异常

     机型适配中是否有特殊情况等


4 监控分析

4.1 加载响应速度

      在测试之前,我们需要了解一下activity的生命周期,比如从activity1跳转到activity2,在我们点
击触发之后,activity1是如何被暂停而activity2又是如何被创建执行的,过程中那些activity方法被调
用到(也可以结合adb logcat -v time -b events查看对应activity切换事件)。

      测试执行中,发现问题的方法有很多,肉眼也不失是一种办法,如果想要更准确,可以通过埋点
进行度量。另外adb logcat -v time -b events监控的am_activity_launch_time时间也可以参加,不过
它仅仅统计到Activity.onResume()的调用。

       一旦发现耗时问题,可以通过详细的埋点来分析定位耗时的方法逻辑,当然还有一个更值得推
荐的工具: traceview, 下面我们稍稍介绍一下它的使用。

      1) 安装可debug的apk包,启动DDMS,找到对应进程,按下头部工具栏按钮"Start method profiling",
如图4-1所示,一旦其变灰,开始监控。

      2) 操作app,完成被测业务后,再次点击头部工具按钮栏的对应按钮,使其变红。此时,监控结束,
会自动生成解析后的trace文件

    另外不通过DDMS,直接在app代码中植入Debug类的StartMonitor和StopMonitor方法,也可在
sdcard中得到trace文件,pull文件到电脑上,用sdk tools下的traceview命令打开trace文件即可。


4.2 滑动流畅度

4.2.1 View渲染原理

        Android UI视图窗口可以有N多个View组成,其中ViewGroup是一个特殊的View,继承自android.
view.view, 类似容器管理其子View和子ViewGroup。

4.2.2 流程度测试分析工具

4.2.2.1 gfxinfo

        Android4.1引入gfxinfo,用于监控分析GPU profiling信息,Draw+Process+Execute是一帧的绘
制渲染时间,如果持续超过16ms,用户会明显感知卡顿:

       a: "Draw" : 创建显示列表(display lists,记录所有view对象的绘制指令)的时间开销。

       b: "Process" : 执行显示列表中绘制指令的时间。UI视窗中的View数量越多,需要执行的绘画命
令就越多。

       c: "Execute" : 将一帧图像交给合成器compostior的时间。这部分占用的时间通常比较少

使用方法:

      1) 打开android手机 “设置->开发者选项->GPU呈现模式分析"

      2) 执行测试场景(比如滑动页面)后,执行adb shell dumpsys gfxinfo packageName

      3) 找到"Profile data in ms"的Draw Process Exceute这三列数据,Excel做出表格,sum出每列的
总GPU时间

      4) 针对时间大不幅度>16ms,可以使用systrace进行分析定位瓶颈。


4.2.2.2 systrace

      Systrace是Android4.1引入的一套用于做性能分析的工具,使用它来诊断绘图卡顿问题是非常有
效的。生成的trace.html文件中可以在同一时间轴上清晰的对比进程线程的运行内容和状态,展示
VSYNC间隔, SurfaceFlinger进程信息,调用方法的执行耗时等,让上下文运行状态的分析更简单方便。


4.2.2.3 Show GPU overdraw

      显示GPU过度渲染,从最美到最差依次是: 蓝,绿,淡红,红

       a,没有颜色意味着没有透支。像素只画了一次。

       b,蓝色 : 意味着透支1倍。像素绘制了2次。

       c,绿色:意味着透支2呗。像素绘制了3此

       d,淡红:意味着透支3倍。像素绘制了4次

       e,红:意味着透支4倍。像素绘制了5次或者更多


4.3 内存使用

      虽然Android L 版本正式使用ART代替Dalvik虚拟机运行机制,但是考虑到当前市场份额,我们再
次仍重要关注Dalvik虚拟机内存管理机制。需要注意:在Android2.×系统上,Bitmaps存储在Navtive
memory中,有recycle()进行释放,而android3.0之后,bitmaps则存储在dalvik heap中,由GC垃圾
惠州机制进行回收释放。

      android app的内存问题主要发生在dalvik heap和navtive heap上。而dalvik heap的内存问题最为
常见: 比如Activity内存泄漏,Bitmap内存泄漏,Bitmaps导致的内存溢出。

      我们先了解一下对象和引用的关系,然后通过GC log看一下GC垃圾回收的集中模型


4.4 CPU 监控

      在CPU持续使用较高或者不正常时,我们首先要确定APP相关进程的的占用,找到有问题的进程,
在进一步跟进到具体线程,所以排除方位。比借助traceview和systemtrace进行分析。


4.5 流量

       通常来说APP流量使用最大的两部分是: 服务端api交互,图片/css/js等cdn静态资源。减少这两个
部分的资源个数和资源大小,能有效的限制流量的使用。另外还需要严格控制后台静默时流量的使用。

4.5.1 流量统计工具

       DDMS Network Statistics

       3款代理工具: fiddler, charles, wmock

        抓包工具 : tcpdump

4.5.3 弱网络模拟&网络切换测试

         使用 charles throttle settings模拟,能够对上下行带宽,丢包率,延迟等网络参数进行设置


4.6 耗电量

4.6.1 耗电原理

          手机中的每个部件运行时对应的能耗值都放在power_profile.xml文件中,而系统的 设置->
电池->使用情况中,统计的能耗使用情况也是以power_profile.xml的value作为基础参数的。通过命
令监控app个部件的使用时长,然后结合设备耗电的基础参宿进行加权计算,即可得到app使用的
耗电量。

4.6.2 电量测试监控方法

          充电关注前台静默和后台静默。即APP没有被操作,但却偷偷的在耗电。

          a,系统自带电池使用监控工具

          b,adb shell dumpsys batteryinfo\batterystat 查看各部件耗时

4.6.3 查看CPU开销导致的耗电情况


作者: 梦想家    时间: 2018-2-28 16:10





欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2