使用MAT解决OOM的一次实战经历

最近在项目中,发现从TaskPageFragment界面反复进入某个模式会发生OOM.下面是使用MAT解决整个问题的过程

1.使用步骤

step1:在DDMS界面中选中要调式的项目

step2:点击右上角的update Heap图标

step3:点击右边的Heap选项

step4:点击Cause GC

step5:反复运行导致oom的界面,观察heap界面Total Size指标的变化->正常情况TotalSize会在一定范围内波动,如果TotalSize不断增加说明发生了内存泄露.

第一次运行

运行9次后,发现1-byte array 的Total Size从16.967M增加到112.566MB,说明确实存在内存泄露.

step6:在app差不多要oom时,点击右上角Dump HPROF file图标,等待Leak Suspects Report(前面属于DDMS,此后开始使用MAT)

Step7:稍等片刻后,弹出对话框,点击Finish

Step8:在弹出的界面中,点击右上角OverView

在OverView界面里面有两个非常重要的分析工具:Dominator Tree和Histogram

2.分析过程

工具Dominator Tree

Step1:打开Dominator Tree界面,右键怀疑对象Path To GC Roots(怀疑对象到GC的引用路径)->exclude weak reference(过滤到弱引用,弱引用不会阻止GC回收)

附:几个概念说明:

Shallow Heap:对象本身占用的内存大小

Retained Heap:对象本身以及它持有的所有对象的内存总和

System Class标签:由系统管理的对象,不会导致OOM,不用理会

Step2:打开GC到AppCompatImageView的引用路径界面

由下图可以看出

GC Roots->Thread->mMessage(MessageQueue)->SlideView的内部类(mHandler)->SlideView->TripodFragment的内部类(TakeOffSliderListener)->TripodFragment->AppCompatImageView

当前TripodFragment界面已退出,但是GC Roots持有Thread的引用,Tread持有MessageQueue的引用...TripodFragment内部类持有TripodFragment的引用,导致TripodFragment和它引用的内存都不能被回收,最终OOM.

内部类都隐式的持有着外部类的引用，且长生命周期对象（SlideView）持有短生命周期对象(TripodFragment),至此OOM原因已被查出.

附:几个说明

最上面一栏Regex:dominatorTree和Histogram界面最上面都有此栏,可以用来直接搜索你怀疑的泄露的对象,非常实用.

左边有小红点的对象:说明是GC直接持有的对象.

还可以使用Histogram查看内存中是否有多个被Thread持有,导致TripodFragment无法被回收的实例

工具Histogram:Histogram能够列出内存中所有的类,以及每个类的实例个数.

打开Histogram界面

在正则搜索框内输入"TripodFragment",发现有内存中有9个无法回收的TripodFragment实例,由此判断这里存在内存泄露.

3.解决办法

最终定位问题代码,TripodFragment里面使用了自定义的SlideView,在SlideView类里面使用了Handler,并且循环发送延时消息.

解决办法之一

在View类的onDetachedFromWindow()回调函数里面,使用handler对象将所有问题清空.

再次部署app,观察TotalSize,发现始终在一定范围内波动,不再出现oom,问题解决.