内存泄漏产生的原因
一个长生命周期的对象持有一个短生命周期对象的引用,通俗讲就是该回收的对象,因为引用问题没有被回收,最终会产生OOM。
内存分析工具
top/procrankmeinfoProcstatsDDMSMATFinder-ActivityLeakCanaryLeakInspector
工具很多,掌握原理方法,工具随便找两个能用就行
1、Android Profiler的使用
点击Run菜单下的profile...,如下图:
![38595d9665b107cb280d644ee4e04ab0.png](https://i-blog.csdnimg.cn/blog_migrate/c8d58f557a59c8fe64f9c3b38b43b176.jpeg)
profile
在图型用户界面上选择要分析的一段内存,右键export出来 :
![ab02aefd019d3ac5e553f581be81c80d.png](https://i-blog.csdnimg.cn/blog_migrate/8907f898c5cded07d875be37950007ec.jpeg)
export
Allocations: 动态分配对象个数
Deallocation:解除分配的对象个数
Total count :对象的总数
Shallow Size:对象本身占用的内存大小
Retained Size:GC回收能收走的内存大小
![4768bf80c5dd64d55d08a8c2db1e7848.png](https://i-blog.csdnimg.cn/blog_migrate/086edc741a1c79e9e9a1412139041868.jpeg)
app heap
分配对象过多,说明该对象被其他地方引用而没被释放,造成内存泄漏,此对象是需要关注并排查内存泄漏的对象。Deallocation、Total count没调出来,可能版本问题。
点击某个对象,右边会弹出引用情况:
![aefebb7a383191da2b7010a92d0bab75.png](https://i-blog.csdnimg.cn/blog_migrate/6808e23e9ee35eab178ac7377254524f.jpeg)
对象引用情况
2、Mat工具的使用
将上述到处的文件转换profile文件格式:找到sdk/platform-tools/hprof-conv.exe,使用命令转换命令 hprof-conv -z src dst,如src:1.hprof,dst:1-mat.hprof
下载Mat工具: https://www.eclipse.org/mat/downloads.php
打开软件 File菜单下Open Heap Dump... 打开转换好的文件
点击QQL按钮查找activity:select * from instanceof android.app.Activity
![078e2318e92dbb9a326cc565a3b8f53d.png](https://i-blog.csdnimg.cn/blog_migrate/68cd4d6ad2d3b28020206be3b9f83caa.jpeg)
查找对象引用链
查看activity的引用链,找到内存泄漏的根源。而profile的作用是找准泄漏的对象。
典型的处理方案
Android源码引发的问题处理(同样可以用在第三方库):可以使用反射将引用变量置空,如InputMethodManager。
第三方SDK引发的问题处理:有注册、没有解注册。
常见的错误代码引起的问题处理:下次会整理总结出来