Android内存监控与分析（四）：内存分析实例演示

Android内存监控与分析（四）：内存分析实例演示

APP测试中难免会有各种显式或者隐式的内存泄漏（Memory Leak）问题，如果不及时发现处理，可能会因为内存泄漏导致各种奇怪的问题（如，卡顿和闪退），甚至可能出现因内存不足（Out of Memory，简称OOM）而导致APP崩溃。
本文将通过实战分析内存泄漏和内存溢出问题，并在必要时说明原理或机制。结构分为四个模块，如图1：

图1 内存监控与分析

四、内存分析实例演示

（一）内存测试流程中的要点
1. 代码
通常用来进行内存测试的版本是纯净版本，不应该附加多余的Log和调试用组件。例如有些情况下，为了测试界面延迟/函数执行时间等性能，会加入一些桩点代码。在内存测试中这些代码是不必要的，它们可能会分配临时内存，引起更多的GC，导致应用出现运行缓慢、卡顿等现象。
2. 测试场景
测试场景通常有两类。一类是当前有新开发或改动的某项功能，需要对该功能进行性能测试。因此测试场景主要针对该功能组织，包括功能的开启前、运行、结束后等测试点。另一类是整体性能，考察应用的常见场景，在综合使用情况下的性能指标。测试场景应当包括启动后待机，切换到后台，执行主要功能，以及反复执行各功能后。
在各类场景中，经常作为测试重点的有：
·包含了图片显示的界面。
·网络传输大量数据。
·需要缓存数据的场景。
3. 场景转换成用例
选取了测试场景后，用例设计也要考虑内存测试的特点。一些常见的方法是：
·结合场景比较操作前后或不同版本的内存变化。
·显示多张图片的前台进程。
·多个场景来回切换。
·长时间运行进程的内存增长。
4. 执行
由于GC和广播机制的存在，应用内存通常都在不停地波动，幅度可能会达到几百KB，因此执行时需要考虑这种情况。在采集数据时，需要多次采集并计算平均值。
执行完成，我们就可以根据数据进行比较初步的分析以确定方向。一方面是我们熟悉的Dalvik Heap部分，即由Java代码直接分配的内存，可以通过IDE直接观察到使用情况，也可以使用MAT进行细致的分析。