«

android app 内存分析

时间:2024-3-2 18:12     作者:韩俊     分类: Android


最近app的oom异常比较多,重点要求解决oom的bug,所以着重研究了一下eclipse中的mat分析内存的方法。

针对阅读页的分析比较繁琐,代码也比较多,不多说了,下面记录一下起始页ActLoading的内存分析及解决方案:

1.首先,在onDestroy中放一个System.gc();方法来提醒虚拟机进行内存回收,然后我们就可以在每次进出这个Activity的时候观察logcat中的情况,GC_EXPLICIT 这个表示调用System.gc时产生的内存回收:

GC_EXPLICIT freed 3502K, 41% free 54633K/91060K, paused 3ms+9ms, total 86ms,

上面的代码中就是调用关闭这个Activity的时候onDestroy中回收的日志,我重点看的是这个空闲的百分比(41%)和后面的总共分配的堆内存空间(91060K),反复进出后这个百分比越来越小或者总空间变大,证明有泄露的嫌疑。


2.反复进出几次,生成内存分析文件,过程不多说了,直接看图:



每个人都有自己的一套分析方法,我自己的方法是以直方图为主的:



因为要分析自己的写的类,所以先根据包名分一下类,方便查找自己的Activity。


很容易的找到这个Activity代码了,发现退出以后还存在8个Activity对象,下面要分析这个对象为啥没有被回收掉了:

一个对象在gc的时候没有被回收说明它在通往GC根节点的路径上有其他的引用。


右键这个类,找它到GC根节点之间所有的排除软引用,弱引用,虚引用的其他引用。


可以看到有两个原因使它不能被回收;一个线程,一个就是我们公司自己的开发的一个app统计sdk。


这里面的线程是不是一个主要原因,因为它只是延迟了我们的内存释放,并不会一直占用,当到一定的时间后,线程执行完毕,会自己回收掉的,但是我们并不能不管它,因为QA在测试的时候,不会给你足够的时间来回收这些耗时间的线程。

那么到底是哪里的线程呢,分析了一下代码整个Activity里面只有了一个网络请求:


那么内存泄露的点就有可能在这里,其实可以粗略的判断一下,这个是不是泄露点,那就是先把这个方法注释掉,重复以上的步骤,看看上面的线程泄露还在不在。如果注释以后,问题不在了,那么它就是我们重点解决的对象;


上面的测试看到,原来的线程泄露不在了,那么那个网络请求的方法到底有什么问题呢?

在于参数用到了LoginUtils.getSessionId(),而不是一个单纯的string,我修改一下这个方法:


上面的线程泄露问题就解决了。

至于第二个内存泄露的问题analysis.collect.DatabaseAdapater:是由于自家公司的统计sdk占用了第一次赋予的Activity实例,而不能被回收,我还无能为力,只能依靠sdk修改了。。。。


内存分析方法多多,我只是列举了自己摸索的一套分析方式而已




标签: android

热门推荐