1.2.1　测试流程

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

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

1. 代码

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

2. 测试场景

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

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

包含了图片显示的界面。

网络传输大量数据。

需要缓存数据的场景。

3. 场景转换成用例

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

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

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

多个场景来回切换。

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

4. 执行

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

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

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