一、什么是内存泄漏：
内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。
Android虚拟机的垃圾回收采用的是根搜索算法。GC会从根节点（GC Roots）开始对heap进行遍历。到最后，没有直接或者间接被引用到GC Roots的就是需要回收的垃圾，会被GC回收掉。而内存泄漏出现的原因就是存在了无效的引用，导致本来需要被GC的对象没有被回收掉。
二、如何发现内存泄漏：
方法①：AndroidStudio自带的 Android Monitor:
1.写一个空白的activity，只做跳转，跳转到检查目标activity或其他要检查的类，然后返回，再跳转过去，执行多次。
2.打开Android Profiler分析内存对象。
如果找不到，可以通过导航菜单栏打开该视图，具体操作如下：
在导航栏找到View-->Tool windows--->Android Profile即可。
点击MEMORY调到内存详细界面:
直行多次操作后，点击垃圾桶的图标，发生GC回收通知，让能回收的对象回收掉，然后点击红色小圆点去收集heep内存片段信息。
收集一段后再次点击结束收集。然后会自动打开内存中对象分析的框。
先根据包名来排序，然后找到自己项目包名下的对象，然后查看对象的在内存中有多少个实例。
从这里很明显看出来是目标activity--MainActivity泄漏，接下来开始找原因了。
3.查找内存泄漏的定位：
找到有多个实例对象的，就是没有回收掉的对象，我们点击一下Instance View窗口的实例，可以在Call Stack中看到是谁持有了引用。点击就会跳转过去到对应代码中。
4.内存泄漏原因分析：
再来看看跟踪到代码中的，
public class MainActivityextends AppCompatActivity {
16：private Handlerhandler =new Handler() {
@Override
public void dispatchMessage(Message msg) {
super.dispatchMessage(msg);
switch (msg.what) {
}
}
};
@Override
public void onCreate(@Nullable Bundle savedInstanceState, @Nullable PersistableBundle persistentState) {
super.onCreate(savedInstanceState, persistentState);
setContentView(R.layout.activity_main);
handler.sendEmptyMessage(0x12);
}
}
可以看到第16行是new了一个Handler，看到这里，知道怎么做了，这个Handler实例是内部类，当使用内部类（包括匿名类）来创建Handler的时候,隐式的持有外部类的引用，是会持有当前对象的，如果要销毁当前类的实例，就必须解除引用，因此要在销毁时，将他应用置为空，让该实例不在持有当前类实例应用，GC检测该实例应用不可达，就能顺利回收了。
解决办法有两种：
a.使用静态变量定义handler
static class MyHandler extends Handler {
WeakReference mActivityReference;
MyHandler(Activity activity) {
mActivityReference= new WeakReference(activity);
}
@Override
public void handleMessage(Message msg) {
final Activityactivity = mActivityReference.get();
if (activity != null) {
mImageView.setImageBitmap(mBitmap);
}
}
}
handler对象由于是静态类型无法持有外部activity的引用，但是这样Handler不再持有外部类的引用，导致程序不允许在Handler中操作activity中的对象了，这时候我们需要在Handler对象中增加一个队activity的弱引用。
b.在activity执行onDestory时，判断是否有handler已经执行完成，否则做相关逻辑操作；对于有延时处理的操作需要mHandler.removeCallbacksAndMessages(null);然后mHandler=null来消除引用。
android studio的第二种剑法：
与第一种区别点就是，第一种是直接分析片段的，第二种是将内存heep dump下来进行分析。
点击一次就可以了，然后会在一定时间自动收集完成，然后形成
收集完成后可以进入分析阶段了。点击Analyzer Task，Android Monitor就可以为我们自动分析泄漏的Activity啦，分析出来如下图所示
最终可以看到“this$0”,这个就是内部类引用，所以可以初略知道是内部类造成的。
android studio的第三种剑法：
使用sdk中自带的Monitor，但要通过android studo启动。
打开了，也是在app上重复操作一下，然后回到EmptyActivity，然后GC一下，开始dump内存。然后可以借助android studio分析，也可以使用MAT等工具来分析。对于android studio最近的几个版本不能在项目中直接打开了，需要点击open以文件的形式打开使用。然后就和方法一样可以分析了。对于MAT,我会在接下来的分享文章中来说明使用。
方法②：开源的第三方LeakCanary :
1.引入第三方：
在 build.gradle 中加入引用
dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3'
}
在 Application 中：
@Override public void onCreate() {
super.onCreate(); LeakCanary.install(this);
}
在 debug build 中，如果检测到某个 activity 有内存泄露，LeakCanary 就是自动地显示一个通知。
2.如何使用监听内存泄漏：
使用 RefWatcher 监控那些本该被回收的对象。
RefWatcher refWatcher = {...};
// 监控
refWatcher.watch(checkObj);
将要检查的对象放入watch方法中即可。
Activity是在Application的callback方法中完成的监听，因此就不用担心activity的。
该担心的是fragment了：
public class ExampleApplication extends Application {
public static RefWatcher getRefWatcher(Context context) {
ExampleApplication application = (ExampleApplication) context.getApplicationContext();
return application.refWatcher;
}
private RefWatcher refWatcher;
@Override public void onCreate() {
super.onCreate();
refWatcher = LeakCanary.install(this);
}
}
使用 RefWatcher 监控 Fragment：
public abstract class BaseFragment extends Fragment {
@Override public void onDestroy() {
super.onDestroy();
RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());
refWatcher.watch(this);
}
}
3.工作原理：
1.RefWatcher.watch() 创建一个 KeyedWeakReference 到要被监控的对象。（封装了一个有key-value弱引用）
2.然后在后台线程检查引用是否被清除，如果没有，调用GC。
3.如果引用还是未被清除，把 heap 内存 dump 到 APP 对应的文件系统中的一个 .hprof 文件中。
4.在另外一个进程中的 HeapAnalyzerService 有一个 HeapAnalyzer 使用HAHA 解析这个文件。
5.得益于唯一的 reference key, HeapAnalyzer 找到 KeyedWeakReference，定位内存泄露。
6.HeapAnalyzer 计算 到 GC roots 的最短强引用路径，并确定是否是泄露。如果是的话，建立导致泄露的引用链。
7.引用链传递到 APP 进程中的 DisplayLeakService， 并以通知的形式展示出来。
一切看起来是不是很简单。