任意门性能测试报告分享

#性能测试报告总结为了让大家了解我们做的任意门的长处和不足,可以通过这份报告得以反馈.针对不足的地方也可以为...



性能测试报告总结

为了让大家了解我们做的任意门的长处和不足,可以通过这份报告得以反馈.针对不足的地方也可以为我们日后的优化指出方向.下面我会分别通过对检测项的报表做出使用和分析做出介绍.

检测报表包含:

1.启动时间

2.CPU曲线图

3.内存使用曲线图

4.流量测试曲线图

5.内存泄露

6.SDK包大小统计

7.动画帧率对比

8.拍照功能性能测试

9.过渡绘制

原理

1、通过调用"adb shell"命令获取shell脚本的输出，拿到我们想要的数据

2、appium 脚本编写各种场景

凯华当时的脚本配置的坐标依赖于当前指定的手机和应用，更换不同的手机需要重新配置一遍坐标信息。引入appium后就可以避过这个缺点,可以达到一次编写,在所有的手机上运行.这个可以完成1-4项的数据获取。

启动时间,CPU,内存和流量

这几点对我们来说是比较重要的.我放在一起说,是因为我们统计的过程中基本上是一起完成的.不过缺点还是网络的影响(不过这一次在跑的过程中还好).

数据的获取思路:

我是通过模拟不同的场景去拿到对应的数据,目前首次安装启动这个场景自动模拟不出来,需要借助其他办法.对于数据的采集:

启动时间:应用反复的启动拿到启动时间

cpu和内存:在不同的场景下通过异步线程补捉,每一秒钟补捉一次数据

流量:主要是在每次点击关闭插件后拿到

目前每个动作的操作时间是耗时5秒钟，cpu和内存是每一秒补捉一次，流量是操作完一个动作完成后补捉一次。

内存泄露

关于内存泄漏的的检测,最后都是通过需要通过MAT工具进行数据分析.

MAT需要下载安装.

我介绍的这一种,算是比较好实现的.

整体思路是通过DDMS导出.hprof文件,再用MAT工具进行解析.

第一步:通过DDMS导出.hprof文件

1. 启动AS后，切换到DDMS透视图，并确认Devices视图、Heap视图都是打开的；

2. 将手机通过USB链接至电脑，链接时需要确认手机是处于“USB调试”模式，而不是作为“Mass Storage”；

3. 链接成功后，在DDMS的Devices视图中将会显示手机设备的序列号，以及设备中正在运行的部分进程信息；

4. 点击选中想要监测的进程，比如system_process进程；

5. 点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标,进行相应的操作.此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况。；

6. 点击Heap视图中的“Dump HPROF file”按钮,把.hprof保存起来；

第二步:通过MAT工具对.hprof进行解析

1.DDMS导出的内存映像文件并不能被MAT直接使用。需要转换一下。在命令行输入：

hprof-conv com.paic.example.simpleapp.hprof simpleapp.hprof

2.在MAT里面打开该文件就可以了

第三步:图表解析

Overview分析Process showmap中的/dev/ashmem/dalvik-heap(deleted)一项所占用的Memory.

Histogram可以看到所有实例的分配情况，

Dominator Tree列出了堆的最大对象。

Leak Suspects主要是列出怀疑的内存泄露处。

Shallow Heap Size是对象自身占用的Size。

Retained Heap Size是对象自身的Shallow Size +对象直接引用或者间接引用的对象的Shallow Size。

Leak Suspects列出了工具怀疑的内存泄露点.

点击“Histogram”,在Class Name后面的输入框输入应用的名字：com.XXX.XXX。

如果没有泄露的情况下只应该有一个实例，说明存在内存泄露。在MainActivity上点击右键->"Merge Shortest Paths To GC Roots"->"exclude all phantom/weak/soft etc.refrences"。在打开的页面中，点击可以看到详细的引用信息。

SDK的包大小统计

这个基本上没什么技术含量,主要是在测试那边的服务器上通过裁切打包的脚本去实现.只要注意裁切时候不要裁切错,然后赖心对各个文件的大小统计

动画的帧率对比

之前这个的统计都是使用GT这个工具来拿数据完成的.这个办法也可以.我在这里另外介绍一种相对简单一点的.参考网站:

http://jingyan.baidu.com/article/ac6a9a5e7e5f352b653eacfa.html

操作步骤如下:

1.在设置里打开GPU呈现模式分析。点击Android设备的“设置”->"开发者选项-->监控-->GPU呈现模式分析"，然后勾选“在adb shell dumpsys gfxinfo中的显示时间”。

2.重启我们的应用。启动应用以后，在应用的页面上做滑动。

3.打开命令行，在命令行输入：adb shell dumpsys gfxinfo com.paic.example.simpleapp > fps.txt(文件名可以自己设置)

4.打开生成的fps.txt，找到Profile data in ms这部分数据。

正常情况下帧率应该在16ms左右。

这个可以考虑也运用代码自动实现(后期可以试试)拿数据

拍照功能性能测试

这个统计上级上基本使用手动实现的,原理很简单.通过在我们代码里添加相应的log进行统计.拍照对cpu的消耗是根据GT手动操作获取。

过渡绘制

绘制不同的颜色来

显示这个像素被过度绘制的次数。一共有四种颜色：蓝色、绿色、淡红、深红。根据过度绘制的次数，依次递增。1x过度绘制是蓝色、2x是绿色、3x是淡红、4x是深红

过度绘制产生的原因

太多重叠的背景

重叠着的背景有时候是有必要的，有时候是没必要的。这要视你的项目具体情况而定.

太多叠加的View

或者本来这个UI布局就很复杂或者你是为了追求一个炫丽的视觉效果，这都有可能使得很多view叠加在一起。这个情况非常普遍，下面的建议中会谈谈怎么减少这种情况带来的影响。

复杂的Layout层级

复杂的层级关系，这个在布局中也很常见，下面也会说这种情况怎么做可以尽可能的减少过度绘制。

建议

太多重叠的背景

这个问题其实最容易解决，建议就是检查你在布局和代码中设置的背景，有些背景是被隐藏在底下的，它永远不可能显示出来，这种没必要的背景一定要移除，因为它很可能会严重影响到app的性能。如果采用的是selector的背景，将normal状态的color设置为”@android:color/transparent”,也同样可以解决问题。

太多重叠的view

第一个建议是：使用ViewStub来加载一些不常用的布局，它是一个轻量级且默认不可见的视图，可以动态的加载一个布局，只有你用到这个重叠着的view的时候才加载，推迟加载的时间。第二个建议是：如果使用了类似viewpager+Fragment这样的组合或者有多个Fragment在一个界面上，需要控制Fragment的显示和隐藏，尽量使用动态地Inflation view，它的性能要比SetVisiblity好。

复杂的Layout层级

这里的建议比较多一些，首先推荐用Android提供的布局工具Hierarchy Viewer来检查和优化布局。第一个建议是：如果嵌套的线性布局加深了布局层次，可以使用相对布局来取代。第二个建议是：用标签来合并布局，这可以减少布局层次。第三个建议是：用标签来重用布局，抽取通用的布局可以让布局的逻辑更清晰明了。记住，这些建议的最终目的都是使得你的Layout在Hierarchy Viewer里变得宽而浅，而不是窄而深。

这个是用一个空的应用集成任意门,在手机的开发者选项里面-->硬件加速渲染-->调试GPU过渡绘制-->宣示过渡绘制区域.然后根据颜色判断.

优缺点总结

我认为自动化测试的目的就是，用工具替代人的部分工作，并且随着工具不断改进和脚本的不断完善，使我们的工作越来越高效。相比测试统计的办法,他们大部分是通过GT工具手动操作去拿数据,这个过程是非常耗时耗力的。我们要是想自己拿到一份数据就很困难.运用自动化后,将大量烦琐的任务就变得简单.另外还具有一致性和可重复性。

优点:

1.可以很快的自动获取数据,制作成图标.

2.场景可以随意修改,增加或减少

3.基本上可以在所有的手机上检测

4.更省时省力

缺点:

1.对网络的依赖

2.appium环境的配置有点小麻烦

3.流量这一块在很多手机上拿不到数据(目前只有杨震的红米2是OK的)

4.不能取代手工测试,场景还需要日后逐渐完善

    关注 insightLabs