一、数据源

APP 占用内存的测试，要比 CPU 的更为简单。App memory 数据来源是 dumpsys meminfo。当然，首先需要了解清楚 dumpsys 里面这些数值的含义是什么，这里不详述。

Android 程序内存主要是两部分：native 和 dalvik。dalvik 就是我们平常说的 java 堆，我们创建的对象是在这里面分配的，而 bitmap 是直接在 native 上分配的，对于内存的限制是 native+dalvik 不能超过最大限制，否则 OOM。

图一 dumpsys meminfo 信息

二、数据采集

与 CPU 耗电 jiffs 数据的采集一致，直接继承 Performace 基类，然后使用 threading.Timer 定时器来每隔 3 秒运行一次__fun_get_mem，调用 dumpsys meminfo 来获取相关内存信息。如下图中，只收集了 TOTAL 的数据，如果要具体分析 native 和 dalvik 的内存信息，也可以将其数据单独过滤出来保存。start() 在主路径的 set_up() 中调用，保证在执行 test() UI 自动化场景用例时，定时器一直在收集数据，直到 tear_down() 调用 stop() 将定时器取消。

图二内存信息收集逻辑

三、数据使用

评估一个使用场景是否存在内存泄漏，如从 APP 首页进入一个二级页面，我们只需要将这个操作封装成 UI 自动化，重复执行 N 遍，即可获得如下数据曲线。只要数据曲线不是如下图中的灰色平缓曲线，则可以证明该场景是有内存泄漏的。

图三内存泄漏示意图

同样，如果只提供上述的曲线给开发，定位问题也会比较麻烦，测试在内存泄漏的测试中，也可以多做一些。如果是 Dalvik 内存泄漏，也可以使用 Android Device Monitor dump 出一份 hprof 文件（别忘了先手工 Cause GC）。

图四 DDMSdump 内存

拿到 hprof 文件后，可以导入 Android Studio 中查看，一般查看 Retained Size 占用最大的类，分析是否有内存泄漏，一个对象的 ShallowHeap，指的是该对象自身占用内存的大小。一个对象的 Retained Heap, 指的是当该对象被 GC 回收时，所释放掉的内存大小。由于该对象先前可能直接或间接持有对其他多个对象的引用，那么当它自己被回收时，被它所引用的其他对象有些也可能会被回收，所以这种情况下，该对象的 Retained Heap 既包括他自身占用内存的大小，也包括所有被它直接或间接引用的某些对象占用内存的大小。

图五使用 Android Studio 查看内存泄漏

Android Studio 的分析不够强大，也可以借助 MAT 来分析内存泄漏：更多内容参考http://blog.csdn.net/cleverGump/article/details/52013873。

在链接内容中，可以关注下 GIMP 相关的内容，因为在 APP 中因为内存泄漏引起 OOM 一般会跟图片有关，其他对象往往没有 bitmap 对象大，所以解决图片相关的内存泄漏是优先级非常高的。

篇幅有限，还有很多深入的内容无法一一铺陈，后续将继续深入学习内存泄漏测试的相关内容。

关注微信公众号：腾讯移动品质中心 TMQ，获取更多测试干货！