【Android场景化性能测试】内存性能及内存泄漏篇

移动开发 TMQ

一、数据源

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稿源:TMQ (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 移动开发 » 【Android场景化性能测试】内存性能及内存泄漏篇

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录