最近在项目中,发现从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,问题解决.
