一、如何发现内存泄露了
1.打开android studio，运行APP，android studio底部栏选择 “Android Monitor”的“Monitors”视图
2.在Monitors界面的上部分，左边下拉框选择运行APP的手机或模拟器，右边下拉框选择要调试的APP进程。
3.在Monitors界面的中间部分重点关注“Memory”这一块的内存值的变化。
当打开一个Activity后，已分配内存“Allocated”值会变大，再退出，按一下gc按钮
此时Activity正常情况下应该会被回收，已分配内存值“Allocated”应该会恢复成打开之前的值。
4.生成hprof文件进行验证与分析
点击“Dump java Heap”生成hprof文件
大概5秒后，hprof文件会被自动生成，并自动显示在代码浏览区域
此视图会显示对象的类型与实例个数，我们可以按包名进行分类，这样更方便查找自己定义的类
二、通过hprof文件分析内存泄露
用Package Tree View分类，能很快找到我们需要分析的Activity
(本APP的 launcher Activity点击进去，第二级的Activity名为MainActivity，当按返回按钮后，MainActivity正常情况下要被回收，我们正是分析MainActivity为什么发生内存泄露)
我在launcher Activity里点击进MainActivity 4次并返回，通过上图可以发现，回到launcher Activity后，MainActivty每次创建的Activity实例在返回后并没有被回收，如果这样重复操作很多次，程序肯定会因内存不足而崩溃。
点击上图的右上“Instance”区域里的某一个实例，在下方“Reference Tree”区域里会列出所有持有该实例的引用对象。
只靠人工分析hprof文件是否能找出内存泄露点？
本APP的MainActivity非常复杂，所有子界面都采用的是Fragment来进行切换，持有MainActivity引用的其它对象众多，所以只靠人工这样去看，很难发现问题所在。有人建议使用MAT工具打开hprof文件进行分析，本篇有更简单的方法，即使用LeakCanary工具。
三、使用LeakCanary工具查找内存泄漏
1.进入“https://github.com/square/leakcanary”查看LeakCanary的最新版本与使用方法
最新版本是1.5.1，使用方法很简单，只有两步。
2.集成LeakCanary到APP中
第一步：build.gradle里添加依赖
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5.1'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.1'
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5.1'
第二步：在自定义Application中初始化
public class ExampleApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
if (LeakCanary.isInAnalyzerProcess(this)) {
// This process is dedicated to LeakCanary for heap analysis.
// You should not init your app in this process.
return;
}
LeakCanary.install(this);
// Normal app init code...
}
}OK。
3.重新RUN APP，在模拟器中进行测试
我进入MainActivity4次，做一些操作，最后每次都返回到launcher Activity中，不一会儿，模拟器标题栏收到4个通知图标
下拉点击某一个
4.进入details界面
上图中MainActivity对象生成后，从下到上一直追述到 android.view.inputmethod.InputMethodManager$ControlledInputConnectionWrapper.mMainLooper,
同时我们可以查看logcat
显示android.view.inputmethod.InputMethodManager$ControlledInputConnectionWrapper.mMainLooper为GC ROOT，正是因为MainActivtiy被GC ROOT所持有，所以它不能被收回，发生内存泄露。
5.分析leaks details界面
里面引用MainActivity实例的都是系统对象，而且引用链条显示是直接的引用，换句话就是说，如果在MainActivity里有一个Fragment，Fragment里面的ImageView引用了MainActivity，那么此leaks details界面的引用链不会把Fragment实例显示出来，只会显示ImageView实例。
这样又增加了分析的难度，但是仔细分析，我们发现中间有一个
references android.support.v7.widget.AppCompatImageView.mContext
说明是某个ImageView持有MainActivity引用没有被释放，而又有一条
references android.animation.ValueAnimator$AnimationHandler.mAnimations
说明很可能是ImageView执行了属性动画，导致了内存泄露。
分析到此处，我们大概锁定了内存泄露的点，由于代码很多，去一个一个找有点麻烦，那么就在项目里用关键字“ValueAnimator”或“ObjectAnimator”进行全局搜索
终于在“CustomProgressDialog.java”查找到了动画的使用，ivIcon刚好是一个ImageView实例
private void startPropertyAnim() {
// 第二个参数"rotation"表明要执行旋转
// 0f -> 360f，从旋转360度，也可以是负值，负值即为逆时针旋转，正值是顺时针旋转。
ObjectAnimator anim = ObjectAnimator.ofFloat(ivIcon, "rotation", 0f, 360f);
anim.setRepeatCount(INFINITE);
// 动画的持续时间，执行多久？
anim.setDuration(5000);
anim.setInterpolator(new LinearInterpolator());
// 正式开始启动执行动画
anim.start();
}6.分析定位出的代码，修正
CustomProgressDialog是一个自定义对话框，对话框显示时，ImageView会执行旋转动画，但是对话框消失时，动画并没有被取消，导致了内存泄露。最后进行修正
private void startPropertyAnim() {
// 第二个参数"rotation"表明要执行旋转
// 0f -> 360f，从旋转360度，也可以是负值，负值即为逆时针旋转，正值是顺时针旋转。
if (anim != null){
anim.cancel();
}
anim = ObjectAnimator.ofFloat(ivIcon, "rotation", 0f, 360f);
anim.setRepeatCount(INFINITE);
// 动画的持续时间，执行多久？
anim.setDuration(5000);
anim.setInterpolator(new LinearInterpolator());
// 正式开始启动执行动画
anim.start();
}
@Override
public void dismiss() {
super.dismiss();
if (anim != null){
anim.cancel();
}
}最后重新运行修改的程序，测试，发现内存泄露成功解决。
总结：
当项目比较小，代码量不多时，可能人工检查一下，就能解决内存泄露的问题，但是当项目越来越庞大，代码量非常大时，就需要利用工具来帮助进行检查。就像上面这个问题，在没有利用工具的情况下，本人花了大量时间看代码都没有检查出来，而利用工具，很好的进行了定位，查找起来方向性非常明确，最后顺利解决隐藏很深的一个内存泄露点。
