Android 性能测试之内存性能及内存泄漏篇

性能测试-内存性能及内存泄漏篇

数据源

APP占用内存的测试，要比CPU的更为简单。App memory数据来源是dumpsysmeminfo。Android程序内存主要是两部分：native和dalvik，dalvik就是我们平常说的java堆，我们创建的对象是在这里面分配的，而bitmap是直接在native上分配的，对于内存的限制是native+dalvik不能超过最大限制，否则OOM。

图一dumpsysmeminfo信息

数据采集

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

图二 内存信息收集逻辑

数据使用

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

图三 内存泄漏示意图

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

图四DDMSdump内存

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

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

Android Studio的分析不够强大，也可以借助MAT来分析内存泄漏：更多内容。在链接内容中，可以关注下GIMP相关的内容，因为在APP中因为内存泄漏引起OOM一般会跟图片有关，其他对象往往没有bitmap对象大，所以解决图片相关的内存泄漏是优先级非常高的。

笔者目前水平止步于此，后续将继续深入学习内存泄漏测试的相关内容。

文章来源于：腾讯移动品质中心 TMQ