007 LeakCanary 内存泄漏原理完全解析

一、 什么是LeakCanary

LeakCanary 是大名鼎鼎的 square 公司开源的内存泄漏检测工具。目前上大部分App在开发测试阶段都会接入此工具用于检测潜在的内存泄漏问题，做的好一点的可能会搭建一个服务器用于保存各个设备上的内存泄漏问题再集中处理。

本文首发于我的微信公众号：Android开发实验室，欢迎大家关注和我一起学Android，掉节操。

二、 为什么要使用LeakCanary

我们知道内存泄漏问题的排查有很多种方法， 比如说，Android Studio 自带的 Profile 工具、MAT(Memory Analyzer Tool)、以及LeakCanary。 选择 LeakCanary 作为首选的内存泄漏检测工具主要是因为它能实时检测泄漏并以非常直观的调用链方式展示内存泄漏的原因。

三、 LeakCanary 做不到的(待定)

虽然 LeakCanary 有诸多优点，但是它也有做不到的地方，比如说检测申请大容量内存导致的OOM问题、Bitmap内存未释放问题，Service 中的内存泄漏可能无法检测等。

四、 LeakCanary 源码解析

本章内容前后依赖关系强烈，建议顺序阅读。

4.1 ActivityLifecycleCallbacks 与 FragmentLifeCycleCallbacks

在开始 LeakCanary 原理解析之前，有必要简单说下 ActivityLifecycleCallbacks 与 FragmentLifeCycleCallbacks。

// ActivityLifecycleCallbacks 接口
public interface ActivityLifecycleCallbacks {
    void onActivityCreated(Activity var1, Bundle var2);

    void onActivityStarted(Activity var1);

    void onActivityResumed(Activity var1);

    void onActivityPaused(Activity var1);

    void onActivityStopped(Activity var1);

    void onActivitySaveInstanceState(Activity var1, Bundle var2);

    void onActivityDestroyed(Activity var1);
  }

Application 类提供了 registerActivityLifecycleCallbacks 和 unregisterActivityLifecycleCallbacks 方法用于注册和反注册 Activity 的生命周期监听类，这样我们就能在 Application 中对所有的 Activity 生命周期回调中做一些统一处理。

public abstract static class FragmentLifecycleCallbacks {

    public void onFragmentCreated(FragmentManager fm, Fragment f, Bundle savedInstanceState) {}

    public void onFragmentViewDestroyed(FragmentManager fm, Fragment f) {}

    public void onFragmentDestroyed(FragmentManager fm, Fragment f) {}

    // 省略其他的生命周期 ...
  }

FragmentManager 类提供了 registerFragmentLifecycleCallbacks 和 unregisterFragmentLifecycleCallbacks 方法用户注册和反注册 Fragment 的生命周期监听类，这样我们对每一个 Activity 进行注册，就能获取所有的 Fragment 生命周期回调。

4.2 LeakCanary 的使用

4.2.1 使用方法

我们直接在 Application 类中，添加一下代码即可。

public class ExampleApplication extends Application {
  @Override public void onCreate() {
    super.onCreate();
    setupLeakCanary();
  }

  protected void setupLeakCanary() {
    // 启用严格模式
    enabledStrictMode();
    // 判断是否是 HeapAnalyzerService 所属进程
    if (LeakCanary.isInAnalyzerProcess(this)) {
      // This process is dedicated to LeakCanary for heap analysis.
      // You should not init your app in this process.
      return;
    }
    // 注册 LeakCanary
    LeakCanary.install(this);
  }

  private static void enabledStrictMode() {
    StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder() //
        .detectAll() //
        .penaltyLog() //
        .penaltyDeath() //
        .build());
  }
}

由于 LeakCanary 的核心 hropf 文件解析服务 HeapAnalyzerService 所属进程是与主进程独立的一个进程，所以在 setupLeakCanary中，我们需要排除其他进程，只对 leakcanary 进程注册 LeakCanary 监听处理。

android:enabled="false" 这是什么？
这里简单说下，AndroidManifest文件中的 enabled 属性，可以看到 HeapAnalyzerService 这个组件默认是不可用的，所以如果在代码中动态启用这个组件，可以使用以下方法：

public static void setEnabledBlocking(Context appContext, Class componentClass,
      boolean enabled) {
  ComponentName component = new ComponentName(appContext, componentClass);
  PackageManager packageManager = appContext.getPackageManager();
  int newState = enabled ? COMPONENT_ENABLED_STATE_ENABLED : COMPONENT_ENABLED_STATE_DISABLED;
  // Blocks on IPC.
  packageManager.setComponentEnabledSetting(component, newState, DONT_KILL_APP);
}

4.3 LeakCanary.install(this) 干了什么

LeakCanary 的 install 方法实际上构造了一个 RefWatcher,

/**
   * Creates a {@link RefWatcher} that works out of the box, and starts watching activity
   * references (on ICS+).
   */
public static @NonNull RefWatcher install(@NonNull Application application) {
  return refWatcher(application).listenerServiceClass(DisplayLeakService.class)
      .excludedRefs(AndroidExcludedRefs.createAppDefaults().build())
      .buildAndInstall();
}

我们一个个来看这个注册方法。首先是 refWatcher 方法构造了一个 AndroidRefWatcherBuilder, 传入参数是当前Application 的 Context.

public static @NonNull AndroidRefWatcherBuilder refWatcher(@NonNull Context context) {
  return new AndroidRefWatcherBuilder(context);
}

listenerServiceClass 和 excludedRefs 方法是基于建造者模式传入分析Service 和 排除已知的泄漏问题 AndroidExcludedRefs，这里我就不贴代码了。

重点看下 buildAndInstall 方法，这个方法很形象的表示将要进行建造者模式的最后一步 build 和 注册一些监听器，下面我们来看具体代码：

public @NonNull RefWatcher buildAndInstall() {
  // 只允许 install 一次
  if (LeakCanaryInternals.installedRefWatcher != null) {
    throw new UnsupportedOperationException("buildAndInstall() should only be called once.");
  }
  // 建造者模式的最后一步，构造对象
  RefWatcher refWatcher = build();
  // 判断是否开启了 LeakCanary，没有开启默认会返回 DISABLED 对象
  if (refWatcher != DISABLED) {
    // 手动开启 DisplayLeakActivity 组件，会在桌面上显示一个查看内存泄漏结果的入口
    LeakCanaryInternals.setEnabledAsync(context, DisplayLeakActivity.class, true);
    // 是否检测 Activity 的 内存泄漏，默认开启
    if (watchActivities) {
      ActivityRefWatcher.install(context, refWatcher);
    }
    // 是否检测 Fragment 的 内存泄漏，默认开启
    if (watchFragments) {
      FragmentRefWatcher.Helper.install(context, refWatcher);
    }
  }
  // 复制给全局静态变量，防止二次调用
  LeakCanaryInternals.installedRefWatcher = refWatcher;
  return refWatcher;
}

以上代码作用大部分都在代码中注释了，剩下 ActivityRefWatcher.install 和 FragmentRefWatcher.Helper.install 方法没有注释。下面我们就来具体看看这两个方法究竟干了什么。

(1). ActivityRefWatcher.install

ActivityRefWatcher 的静态方法 install 获取到了当前 Application，然后添加了一个生命周期监听器 ActivityLifecycleCallbacks，这里的 lifecycleCallbacks 仅仅关注了 Activity 销毁的回调 onActivityDestroyed，在这里将传入的对象 activity 监听起来， refWatcher.watch(activity); 的具体代码我们稍后分析。

public static void install(@NonNull Context context, @NonNull RefWatcher refWatcher) {
 Application application = (Application) context.getApplicationContext();
 ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher);

 application.registerActivityLifecycleCallbacks(activityRefWatcher.lifecycleCallbacks);
}

private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
 new ActivityLifecycleCallbacksAdapter() {
   @Override public void onActivityDestroyed(Activity activity) {
     refWatcher.watch(activity);
   }
};

(2). FragmentRefWatcher.Helper.install
FragmentRefWatcher.Helper 的静态方法 install 里同样会注册一个 ActivityLifecycleCallbacks 用于监听 Activity 生命周期中的 onActivityCreated 的创建完成的回调，在 Activity 创建完成后，会对这个 Activity 注册 Fragment 的生命周期监听器。install 方法首先会判断系统是否大于等于 Android O， 如果是那么会使用 android.app.FragmentManager 进行注册，如果需要兼容 Android O 以下需要自行在依赖中添加对 leakcanary-support-fragment 组件的依赖，然后通过反射构造出SupportFragmentRefWatcher; 然后将fragmentRefWatchers所有监听器取出，在 Activity 创建完成后，添加 Fragment 的生命监听，主要关注 Fragment 的 onFragmentViewDestroyed 和 onFragmentDestroyed 方法。具体代码如下：

public static void install(Context context, RefWatcher refWatcher) {
      List fragmentRefWatchers = new ArrayList<>();
      // 系统是否大于等于 Android O，如果是，添加 AndroidOFragmentRefWatcher
      if (SDK_INT >= O) {
        fragmentRefWatchers.add(new AndroidOFragmentRefWatcher(refWatcher));
      }
      // 如果添加了leakcanary-support-fragment的依赖，通过反射可以构造SupportFragmentRefWatcher
      try {
        Class fragmentRefWatcherClass = Class.forName(SUPPORT_FRAGMENT_REF_WATCHER_CLASS_NAME);
        Constructor constructor =
            fragmentRefWatcherClass.getDeclaredConstructor(RefWatcher.class);
        FragmentRefWatcher supportFragmentRefWatcher =
            (FragmentRefWatcher) constructor.newInstance(refWatcher);
        fragmentRefWatchers.add(supportFragmentRefWatcher);
      } catch (Exception ignored) {
      }

      if (fragmentRefWatchers.size() == 0) {
        return;
      }

      Helper helper = new Helper(fragmentRefWatchers);
      // 先监听 Activity 的创建完成回调
      Application application = (Application) context.getApplicationContext();
      application.registerActivityLifecycleCallbacks(helper.activityLifecycleCallbacks);
    }

    private final Application.ActivityLifecycleCallbacks activityLifecycleCallbacks =
      new ActivityLifecycleCallbacksAdapter() {
        @Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
          // Activity 创建完成后，对Activity中的Fragment注册生命周期监听
          for (FragmentRefWatcher watcher : fragmentRefWatchers) {
            watcher.watchFragments(activity);
          }
        }
    };

// AndroidOFragmentRefWatcher.java

private final FragmentManager.FragmentLifecycleCallbacks fragmentLifecycleCallbacks =
  new FragmentManager.FragmentLifecycleCallbacks() {
    // Fragment 中的View 视图销毁时
    @Override public void onFragmentViewDestroyed(FragmentManager fm, Fragment fragment) {
      View view = fragment.getView();
      if (view != null) {
        refWatcher.watch(view);
      }
    }
    // Fragment 销毁时
    @Override
    public void onFragmentDestroyed(FragmentManager fm, Fragment fragment) {
      refWatcher.watch(fragment);
    }
  };

@Override public void watchFragments(Activity activity) {
  // 通过FragmentManager 注册 FragmentLifecycleCallbacks
  FragmentManager fragmentManager = activity.getFragmentManager();
  fragmentManager.registerFragmentLifecycleCallbacks(fragmentLifecycleCallbacks, true);
}

上述流程我们已经完全搞清楚了，用一个流程图可以表示为：

[图片上传失败...(image-f5fe25-1543852247130)]

4.4 LeakCanary 内存泄漏检测原理

从行文结构上，本小节应属于上一节后半部分内容，但是RefWatcher 的 watch 方法足够重要和复杂，所以有必要单独列一节仔细讲解内部原理。

4.4.1 基础知识——弱引用 WeakReference 和 引用队列 ReferenceQueue

关于引用类型和引用队列相关知识，读者可以参考白话 JVM——深入对象引用，这篇文章我认为讲解的比较清晰。

这里，我简单举个例子，弱引用在定义的时候可以指定引用对象和一个 ReferenceQueue，弱引用对象在垃圾回收器执行回收方法时，如果原对象只有这个弱引用对象引用着，那么会回收原对象，并将弱引用对象加入到 ReferenceQueue，通过 ReferenceQueue 的 poll 方法，可以取出这个弱引用对象，获取弱引用对象本身的一些信息。看下面这个例子。

mReferenceQueue = new ReferenceQueue<>();
// 定义一个对象
o = new Object();
// 定义一个弱引用对象引用 o,并指定引用队列为 mReferenceQueue
weakReference = new WeakReference