一、摘要
该部分属于进阶内容,要先掌握了java内存回收机制，说白了就是引用计数法和可达性分析法。但是代码写的再认真，也难免出现一两个差错。这一两个差错就会导致内存泄漏，轻则内存增大，重则内存溢出。
二、背景
自从引入了WebView，内存变得难以测试，因为WebView内存不可控，一加载就导致内存暴涨，所以最近比较少跑内存测试了。直至在jara系统上反馈了项目出现内存crash，没办法，必须得处理了。
现象，内存达到了300m。
三、推广建议
理解原理再深，也无法彻底避免问题的处理。就算了经过多次代码审查，也难以发现细节上的错误，还是要通过测试验证，反复排查，才能完成避免问题的出现。
大部分人都喜欢声明成员变量，内部类。因为他们的作用域比较广，代码写起来比较爽。但是违反了“最小作用域原则”。往往就会导致内存泄漏。
最终，项目经过优化，内存减少到72M
四、正文
问题复现：跑monkey测试，在过程中执行：adb shell dumpsys meminfo 包名。就算可以输出应用的内存信息。多次执行就可以输出内存曲线图，查看内存情况。
排除干扰：在一次竞品分析中，发现小米用户中心，把WebView都放在一个独立的进程，这样就可以排除干扰了，也可以使apk轻量化。
重要步骤：
1、 手动排除问题，进入一个页面前，执行adb shell dumpsys meminfo 包名。查看内存，进入后再退出页面，再次执行：adb shell dumpsys meminfo 包名。对比两次的内存情况是否一致。如果出现内存异常，重复操作多次，确认那个页面异常了。
说明：主要关注一下参数：
Native Head：Native内存
DalvikHead:虚拟机内存
EGL/GL：图像渲染相关。（activity泄漏时，该项会很大）
Views/AppContexts/Activvities:实例，需要重点关注这三个参数
2、进一步排查
基本上，经过上一步的操作，百分之九十的内存问题都会发现并且解决。还有比较难复现的情况，需要在monkey情况下复现。
排查方法：mat
方法：打一个debug版本的apk，跑monkey。跑完后退出页面，执行：
adb shell am dumpheap 包名 /data/local/tmp/test.hprof
adb pull /data/local/tmp/test.hprof
hprof-conv test.hprof temp1.hprof
使用mat打开temp1.hprof
查看那些对象占有大，排查代码
重要，点击QQL,执行查询方法。
常用：
select* from instanceof android.graphics.Bitmap
select* from instanceof android.app.Activity
select* from instanceof android.support.v4.app.Fragment
查询出那些比较可能泄漏的实例。
因为dump前页面已经退出了，所以存在的实例基本都是泄漏。都要处理。
泄漏点排查。右键对象，with all reference。查询有那些对象长期引用它，导致它无法释放。
常见案例：
1、 xxxListener:如果你的对象实现了xxxListener方法，或者存在xxxListener的内部类，一定要注意反注销。（onClickListener会自己销毁的）
2、 所有Context，fragment被作为成员变量，参数的地方，都要考虑是否会长时间引用。（mvp中会）
3、 广播的注册与注销
4、 Bitmap要及时回收，Bitmap属于大对象，会直接存在于老年代，最好是不用就回收，减少内存
5、EventBus反注销
