LeakCanary开源框架使用说明

一、分析内存泄漏，最常用的两种工具：一种是ddms+mat进行分析，另一种是leakcanary工具。

二、LeakCanary 是一个开源的在debug版本中检测内存泄漏的java库。 LeakCanary源码：https://github.com/square/leakcanary

三、使用说明
1、使用方式1
在 build.gradle 中加入引用，不同的编译使用不同的引用：
 dependencies {
   //debug编译模式依赖leakcanary-android；release编译模式依赖leakcanary-android-no-op
   //no-op只含有接口，不含有具体实现，因此release模式下编译的APK不具有检测内存泄露的功能
   debugCompile 'com.squareup.leakcanary:leakcanary-android:1.3'
   releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.3'
 }

在 Application 中：
public class ExampleApplication extends Application {
  @Override public void onCreate() {
    super.onCreate();
    if(!LeakCanary.isInAnalyzerProcess(context))
       LeakCanary.install(this);
  }
}
这样，就万事俱备了！ 在 debug build 中，如果检测到某个 activity 有内存泄露，LeakCanary 就是自动地显示一个通知。

note：也可以像LeakCanary中直接将源码copy过来依赖编译



2、使用方式2
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();
    if(!LeakCanary.isInAnalyzerProcess(context))
        refWatcher = LeakCanary.install(this);
  }
}

public abstract class BaseFragment extends Fragment {

  @Override public void onDestroy() {
    super.onDestroy();
    RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());
    refWatcher.watch(this);
  }
}

如上代码：LeakCanary.install() 会返回一个预定义的 RefWatcher，同时也会启用一个 ActivityRefWatcher，用于自动监控调用 onDestroy() 之后泄露的 Fragment。


工作机制：
    RefWatcher.watch() 创建一个 KeyedWeakReference 到要被监控的对象。
    然后在后台线程检查引用是否被清除，如果没有，调用GC。
    如果引用还是未被清除，把 heap 内存 dump 到 APP 对应的文件系统中的一个 .hprof 文件中。

    在另外一个进程中的 HeapAnalyzerService 有一个 HeapAnalyzer 使用HAHA 解析这个文件。
    得益于唯一的 reference key, HeapAnalyzer 找到 KeyedWeakReference，定位内存泄露。
    HeapAnalyzer 计算 到 GC roots 的最短强引用路径，并确定是否是泄露。如果是的话，建立导致泄露的引用链。
    引用链传递到 APP 进程中的 DisplayLeakService， 并以通知的形式展示出来。



3、使用方式3：自定义处理完成的默认行为，将 leak trace 和 heap dump 上传到你的服务器以便统计分析。
1）创建Lib工程：leakanalysis，依赖于leakcanary-android
步骤一：创建类MemoryLeakAnalysis
public class MemoryLeakAnalysis {

    public static boolean isInAnalyzerProcess(Context context) {
        return LeakCanary.isInAnalyzerProcess(context);
    }

    public static SogouRefwather startLeakAnalysis(Application application) {
        RefWatcher refWatcher = LeakCanary.refWatcher(application).listenerServiceClass(LeakUploadService.class).buildAndInstall();
        LeakCanaryInternals.setEnabled(application, DisplayLeakActivity.class, false);
        SogouRefwather sogouRefwather = new SogouRefwather();
        sogouRefwather.mRefWather = refWatcher;
        return sogouRefwather;
    }
}

步骤二：创建类CustomRefwather
public class CustomRefwather{
    public RefWatcher mRefWather = null;

    public void watch(Object watchedReference) {
        if (mRefWather != null) {
            mRefWather.watch(watchedReference);
        }
    }

    public void watch(Object watchedReference, String referenceName) {
        if (mRefWather != null) {
            mRefWather.watch(watchedReference, referenceName);
        }
    }
}

步骤三：自定义类LeakUploadService，继承AbstractAnalysisResultService或其子类DisplayLeakActivity，实现接口。用来实现具体的获取上传等功能。别忘了注册


2）创建Lib工程：leakanalysis-no-op
步骤一：创建类MemoryLeakAnalysis，不实现接口
public class MemoryLeakAnalysis {

    public static boolean isInAnalyzerProcess(Context context) {
        return false;
    }

    public static SogouRefwather startLeakAnalysis(Application application) {
        return null;
    }
}


步骤二：创建类CustomRefwather，不实现接口
public class CustomRefwather {
    public void watch(Object watchedReference) {
        return;
    }

    public void watch(Object watchedReference, String referenceName) {
        return;
    }
}




3)主工程。
public class ExampleApplication extends Application {
    public static CustomRefwather mRefWatcher = null;

    @Override
    public void onCreate() {
    super.onCreate();
    if (MemoryLeakAnalysis.isInAnalyzerProcess(mApplication)) {
            return;
    }
    mRefWatcher = MemoryLeakAnalysis.startLeakAnalysis(mApplication);
  }
}

（debug模式下）主工程——————>依赖于leakanalysis lib工程——————>依赖于leakcanary-android工程
（Release模式下）主工程——————>依赖于leakanalysis-no-op lib工程
上述方式可以减少内部代码的耦合性


四、其他
1、SDK 导致的内存泄露
随着时间的推移，很多SDK 和厂商 ROM 中的内存泄露问题已经被尽快修复了。但是，当这样的问题发生时，一般的开发者能做的事情很有限。
LeakCanary 有一个已知问题的忽略列表，AndroidExcludedRefs.java，如果你发现了一个新的问题，请提一个 issue 并附上 leak trace, reference key, 机器型号和 SDK 版本。如果可以附带上 dump 文件的 链接那就再好不过了。
对于最新发布的 Android，这点尤其重要。你有机会在帮助在早期发现新的内存泄露，这对整个 Android 社区都有极大的益处。

2、有时，leak trace 不够，你需要通过 MAT 或者 YourKit 深挖 dump 文件。
通过以下方法，你能找到问题所在：
    查找所有的 com.squareup.leakcanary.KeyedWeakReference 实例。
    检查 key 字段
    Find the KeyedWeakReference that has a key field equal to the reference key reported by LeakCanary.
    找到 key 和 和 logcat 输出的 key 值一样的 KeyedWeakReference。

    referent 字段对应的就是泄露的对象。

参考网址：
https://www.liaohuqiu.net/cn/posts/leak-canary-read-me/
https://www.liaohuqiu.net/cn/posts/leak-canary/