LeakCanary

一言以蔽之：LeakCanary是一个傻瓜化并且可视化的内存泄露分析工具
为什么需要LeakCanary？

因为它简单，易于发现问题，人人可参与。

    简单：只需设置一段代码即可，打开应用运行一下就能够发现内存泄露。而MAT分析需要Heap Dump，获取文件，手动分析等多个步骤。
    易于发现问题：在手机端即可查看问题即引用关系，而MAT则需要你分析，找到Path To GC Roots等关系。
    人人可参与：开发人员，测试测试，产品经理基本上只要会用App就有可能发现问题。而传统的MAT方式，只有部分开发者才有精力和能力实施。

如何集成

尽量在app下的build.gradle中加入以下依赖

  dependencies {
   debugCompile ‘com.squareup.leakcanary:leakcanary-android:1.3.1‘ // or 1.4-beta1
   releaseCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3.1‘ // or 1.4-beta1
   testCompile ‘com.squareup.leakcanary:leakcanary-android-no-op:1.3.1‘ // or 1.4-beta1
 }



在Application中加入类似如下的代码

public class MyApplication extends Application {
    private static RefWatcher sRefWatcher;


    @Override
    public void onCreate() {
        super.onCreate();
        sRefWatcher = LeakCanary.install(this);
    }

    public static RefWatcher getRefWatcher() {
        return sRefWatcher;
    }
}

到这里你就可以检测到Activity的内容泄露了。其实现原理是设置Application的ActivityLifecycleCallbacks方法监控所有Activity的生命周期回调。内部实现代码为



想要检测更多?

首先我们需要获得一个RefWatcher，用来后续监控可能发生泄漏的对象

默认情况下，是对Activity进行了检测。另一个需要监控的重要对象就是Fragment实例。因为它和Activity实例一样可能持有大量的视图以及视图需要的资源（比如Bitmap）即在Fragment onDestroy方法中加入如下实现
public class MainFragment extends Fragment {
    @Override
    public void onDestroy() {
        super.onDestroy();
        MyApplication.getRefWatcher().watch(this);
    }
}

    

其他也可以监控的对象

    BroadcastReceiver
    Service
    其他有生命周期的对象
    直接间接持有大内存占用的对象（即Retained Heap值比较大的对象）

何时进行监控

首先，我们需要明确什么是内存泄露，简而言之，某个对象在该释放的时候由于被其他对象持有没有被释放，因而造成了内存泄露。

因此，我们监控也需要设置在对象（很快）被释放的时候，如Activity和Fragment的onDestroy方法。

一个错误示例，比如监控一个Activity，放在onCreate就会大错特错了，那么你每次都会收到Activity的泄露通知。
如何解决

常用的解决方法思路如下

    尽量使用Application的Context而不是Activity的
    使用弱引用或者软引用
    手动设置null，解除引用关系
    将内部类设置为static，不隐式持有外部的实例
    注册与反注册成对出现，在对象合适的生命周期进行反注册操作。
    如果没有修改的权限，比如系统或者第三方SDK，可以使用反射进行解决持有关系

    LeakCanary