移动App性能测评与优化1.2.1 测试流程

1.2.1 测试流程

由于内存测试属于性能测试,Android系统又和Linux有很多相通之处,因此我们可以参考常见的Linux性能测试方法和指标,来制定客户端性能测试方案。常见的测试方法包括Monkey/UIAutomator类的常规压力测试、大数据/操作的峰值压力测试、长时间运行的稳定性测试等。这些方法都可以叠加在内存测试的方案中,观察这类场景下的应用内存情况,经常能够发现类似内存泄漏或OOM的问题。

参考了常见性能测试的方案,以及总结了以往对内存性能测试的经验后,我们总结出了一套进行内存测试的经验性流程,下面介绍这个流程中的要点。

1. 代码

通常用来进行内存测试的版本是纯净版本,不应该附加多余的Log和调试用组件。例如有些情况下,为了测试界面延迟/函数执行时间等性能,会加入一些桩点代码。在内存测试中这些代码是不必要的,它们可能会分配临时内存,引起更多的GC,导致应用出现运行缓慢、卡顿等现象。

2. 测试场景

测试场景通常有两类。一类是当前有新开发或改动的某项功能,需要对该功能进行性能测试。因此测试场景主要针对该功能组织,包括功能的开启前、运行、结束后等测试点。另一类是整体性能,考察应用的常见场景,在综合使用情况下的性能指标。测试场景应当包括启动后待机,切换到后台,执行主要功能,以及反复执行各功能后。

在各类场景中,经常作为测试重点的有:

包含了图片显示的界面。

网络传输大量数据。

需要缓存数据的场景。

3. 场景转换成用例

选取了测试场景后,用例设计也要考虑内存测试的特点。一些常见的方法是:

结合场景比较操作前后或不同版本的内存变化。

显示多张图片的前台进程。

多个场景来回切换。

长时间运行进程的内存增长。

4. 执行

由于GC和广播机制的存在,应用内存通常都在不停地波动,幅度可能会达到几百KB,因此执行时需要考虑这种情况。在采集数据时,需要多次采集并计算平均值。

执行完成,我们就可以根据数据进行比较初步的分析以确定方向。一方面是我们熟悉的Dalvik Heap部分,即由Java代码直接分配的内存,可以通过IDE直接观察到使用情况,也可以使用MAT进行细致的分析。

另一方面,假如我们发现Dalvik Heap没怎么增长,而其他部分增长了许多,这种情况下的分析就要复杂一些,我们留待后面的章节再说。

上一篇:移动App性能测评与优化1.3 新问题的进一步挖掘


下一篇:移动App性能测评与优化1.2.3 示例