一、数据源

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,获取更多测试干货!


↙↙↙阅读原文可查看相关链接,并与作者交流