LeakCanary源码解析-很值得我们学习的一款框架

前言

一直在使用这个框架，但是一直没有注意这个框架的实现原理。使用过这款框架的人应该都知道，LeakCanary是一款能够帮助开发者检查内存泄漏的开源库，只需要简单配置，就可以当使用过程中产生内存泄漏时，弹出通知，并且可以我们可以查看详细的引用链，帮助我们进行内存泄漏的分析。

项目预览

项目结构

这里专门放了一张LeakCanary的项目的目录结构，可以看到，LeakCanary的项目目录还是很考究的，总体分为了5个模块，每个都专门负责一个功能。

1.analyzer 内存泄漏分析功能模块，内存泄漏的路径分析就是该模块，haha库就是在该模块中使用
2.watcher 内存泄漏监控模块，监控并且发现内存泄漏的就是该模块
3.android 将内存泄漏监控和Android的生命周期绑定，实现Android中的内存泄漏监听
4.android-no-op 空壳模块，实现真正发布realeas包后，不进行内存泄漏监控，损耗性能
5.sample demo模块

从上面的分析可以看出，LeakCanary这款内存泄漏框架的目录结构真的很考究，按照LeakCanary的功能体积，完全没必要拆分的这么散，但是这样做，充分将LeakCanary的功能发挥到最大化，为什么这么说哪？
熟悉LeakCanary原理的都知道，LeankCanary其实是利用Java的弱引用特性，加上JVM回收一定的机制，实现内存泄漏的监控的，也就是说，LeakCanary并不是一款和Android死绑定的一款开源框架，所以这时候LeakCanary这样的目录结构就体现出了它的优点，我们完全可以将watcher模块或者analyzer模块拆分出来，处理其他以Java语言作为开发语言的项目的内存泄漏分析。

源码分析

还是老方式，一个好的框架肯定有一个好的外观类来统领入口，LeakCanary当然不能少，一般我们的使用方式就是：

protected void setupLeakCanary() {
    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);
  }

当然最核心的就是这句代码LeakCanary.install(this);前面的LeakCanary.isInAnalyzerProcess(this)这里先暂不分析（当然后面会分析的，这里面有一个很棒的方法）

public static RefWatcher install(Application application) {
    //创建RefWatcher
    return refWatcher(application).listenerServiceClass(DisplayLeakService.class)
            //设置已知的内存泄漏问题，或者系统的内存泄漏问题
        .excludedRefs(AndroidExcludedRefs.createAppDefaults().build())
        .buildAndInstall();
  }

这里可以看到，总体上来看分为了四个步骤：

1. 创建了RefWatcher（也就是检测内存泄漏的类）
2. 设置了内存泄漏的通知Service（通知）
3. 设置了需要忽略的已知的系统级别的内存泄漏(可以自定义)
4. 开始监听

接下来就分别看看每一个步骤。

第一个步骤

/**
   * 创建一个builder对象
   */
  public static AndroidRefWatcherBuilder refWatcher(Context context) {
    return new AndroidRefWatcherBuilder(context);
  }

第一个步骤没什么好说的，创建了一个专门为Android使用的Watcher的Builder类。后面我们看的很多方法都基于这个类。

第二个步骤

public AndroidRefWatcherBuilder listenerServiceClass(
      Class listenerServiceClass) {
    return heapDumpListener(new ServiceHeapDumpListener(context, listenerServiceClass));
  }
  
  public ServiceHeapDumpListener(Context context,
      Class listenerServiceClass) {
    setEnabled(context, listenerServiceClass, true);
    setEnabled(context, HeapAnalyzerService.class, true);
    this.listenerServiceClass = checkNotNull(listenerServiceClass, "listenerServiceClass");
    this.context = checkNotNull(context, "context").getApplicationContext();
  }
  
  public final T heapDumpListener(HeapDump.Listener heapDumpListener) {
    this.heapDumpListener = heapDumpListener;
    return self();
  }
  
  @SuppressWarnings("unchecked")
  protected final T self() {
    return (T) this;
  }

接下来这个地方还是需要我们注意到，这里new了一个ServiceHeapDumpListener，在heapDumpListener方法里将new到listener赋值给了this.heapDumpListener。
这里有一个小细节挺值得我们注意的，这里由于是泛型,所以不能直接返回this，这里统一返回了self()方法，统一在self方法里做强制转换和unchecked操作。
通过这里的方法我们可以知道，我们将DisplayLeakService.class类，设置给了AndroidRefWatcherBuilder的一个自定义Listener变量。

第三个步骤:设置已知的内存泄漏问题，或者系统的内存泄漏问题

这里我们就看一下AndroidExcludedRefs.createAppDefaults().build()这个方法。

public static ExcludedRefs.Builder createAppDefaults() {
    return createBuilder(EnumSet.allOf(AndroidExcludedRefs.class));
  }
  public static ExcludedRefs.Builder createBuilder(EnumSet refs) {
    ExcludedRefs.Builder excluded = ExcludedRefs.builder();
    for (AndroidExcludedRefs ref : refs) {
      if (ref.applies) {
        ref.add(excluded);
        ((ExcludedRefs.BuilderWithParams) excluded).named(ref.name());
      }
    }
    return excluded;
  }

到这里其实我们没必要在往里面继续看了，通过这两个方法，大概可以看出这个是通过遍历AndroidExcludedRefs.class类中定义的已知的一些系统级别的bug，得到一个集合，在后面发现内存泄漏的时候会进行忽略操作。

第四个步骤:开始进行监听操作。

public RefWatcher buildAndInstall() {
    //只能创建一次
    if (LeakCanaryInternals.installedRefWatcher != null) {
      throw new UnsupportedOperationException("buildAndInstall() should only be called once.");
    }
    //创建RefWatcher
    RefWatcher refWatcher = build();
    if (refWatcher != DISABLED) {

      LeakCanary.enableDisplayLeakActivity(context);
      //默认为true
      if (watchActivities) {
        //注意，在这里通过监听Application,监听Activity的生命周期
        ActivityRefWatcher.install((Application) context, refWatcher);
      }
    }
    LeakCanaryInternals.installedRefWatcher = refWatcher;
    return refWatcher;
  }

可以看到，首先进行了判空，单例的思想还是很重要的。
下面这个build()方法还是很重要的。

public final RefWatcher build() {
    // 判断install是否在Analyzer进程里，重复执行
    if (isDisabled()) {
      return RefWatcher.DISABLED;
    }
    //用于排除某些系统bug导致的内存泄露
    ExcludedRefs excludedRefs = this.excludedRefs;
    if (excludedRefs == null) {
      excludedRefs = defaultExcludedRefs();
    }
    //用于分析生成的dump文件，找到内存泄露的原因
    HeapDump.Listener heapDumpListener = this.heapDumpListener;
    if (heapDumpListener == null) {
      heapDumpListener = defaultHeapDumpListener();
    }
    //用于查询是否正在调试中，调试中不会执行内存泄露检测
    DebuggerControl debuggerControl = this.debuggerControl;
    if (debuggerControl == null) {
      debuggerControl = defaultDebuggerControl();
    }
    //用于在产生内存泄露室执行dump 内存heap
    HeapDumper heapDumper = this.heapDumper;
    if (heapDumper == null) {
      heapDumper = defaultHeapDumper();
    }
    //执行内存泄露检测的executor
    WatchExecutor watchExecutor = this.watchExecutor;
    if (watchExecutor == null) {
      //创建默认的监听内存泄漏的线程池
      watchExecutor = defaultWatchExecutor();
    }
    //用于在判断内存泄露之前，再给一次GC的机会
    GcTrigger gcTrigger = this.gcTrigger;
    if (gcTrigger == null) {
      gcTrigger = defaultGcTrigger();
    }

    return new RefWatcher(watchExecutor, debuggerControl, gcTrigger, heapDumper, heapDumpListener,
        excludedRefs);
  }

这个build方法这里我们需要注意，我们在最开始的生成了AndroidRefWatcherBuilder,这个是继承于RefWatcherBuilder类的，但是这里的build()方法是父类的方法，也就是RefWatcherBuilder的方法，但是在build()内的许多调用都是AndroidRefWatcherBuilder重写的方法。
首先来看第一个方法isDisabled()

@Override protected boolean isDisabled() {
    //用于判断服务进程是否在前台，重要
    return LeakCanary.isInAnalyzerProcess(context);
  }

可以看到，这里又用到了我们前面提到的一个方法，是用于判断当前进程是否在前台，这里因为分析主流程，所以先不做分析。

@Override protected ExcludedRefs defaultExcludedRefs() {
    return AndroidExcludedRefs.createAppDefaults().build();
  }

接下来看到是设置了Android特有的一些系统的内存泄漏，和前面分析的一致。

//用于分析生成的dump文件，找到内存泄露的原因
    HeapDump.Listener heapDumpListener = this.heapDumpListener;
    if (heapDumpListener == null) {
      heapDumpListener = defaultHeapDumpListener();
    }
    @Override protected HeapDump.Listener defaultHeapDumpListener() {
    return new ServiceHeapDumpListener(context, DisplayLeakService.class);
  }

因为在install()方法中已经设置了用于发送内存泄漏通知的Service，这里变不为null，不然其实default的和初始化的也是相同的。

//用于查询是否正在调试中，调试中不会执行内存泄露检测
    DebuggerControl debuggerControl = this.debuggerControl;
    if (debuggerControl == null) {
      debuggerControl = defaultDebuggerControl();
    }
    
    @Override protected DebuggerControl defaultDebuggerControl() {
    return new AndroidDebuggerControl();
  }
  
  public final class AndroidDebuggerControl implements DebuggerControl {
  @Override public boolean isDebuggerAttached() {
    return Debug.isDebuggerConnected();
  }
}

这里其实也挺值得我们学习的，这里当是调试的时候，便不会进行内存泄漏检测，而如何确定是在进行调试，这里可以看到使用了Debug.isDebuggerConnected()方法。

//用于在产生内存泄露室执行dump 内存heap
    HeapDumper heapDumper = this.heapDumper;
    if (heapDumper == null) {
      heapDumper = defaultHeapDumper();
    }
    
    @Override protected HeapDumper defaultHeapDumper() {
    LeakDirectoryProvider leakDirectoryProvider = new DefaultLeakDirectoryProvider(context);
    return new AndroidHeapDumper(context, leakDirectoryProvider);
  }

这里就是生产内存泄漏的文件的。

//执行内存泄露检测的executor
    WatchExecutor watchExecutor = this.watchExecutor;
    if (watchExecutor == null) {
      //创建默认的监听内存泄漏的线程池
      watchExecutor = defaultWatchExecutor();
    }
    
    @Override protected WatchExecutor defaultWatchExecutor() {
    //默认线程池，5s
    return new AndroidWatchExecutor(DEFAULT_WATCH_DELAY_MILLIS);
  }
  
  public AndroidWatchExecutor(long initialDelayMillis) {
    //主线程Handler
    mainHandler = new Handler(Looper.getMainLooper());
    //这里new了一个HandlerThread，也就是一个异步线程，内部封装好了looper.prepare()等操作
    HandlerThread handlerThread = new HandlerThread(LEAK_CANARY_THREAD_NAME);
    handlerThread.start();
    //handlerThread内部的handler
    backgroundHandler = new Handler(handlerThread.getLooper());
    this.initialDelayMillis = initialDelayMillis;
    maxBackoffFactor = Long.MAX_VALUE / initialDelayMillis;
  }

可以看到这里虽然叫做看似像是线程池，其实也是利用了Android官方的基础组件，这里可以看到快速的创建了一个主现场的handler和一个HanlderThread,和HandlerThread内部的Handler。具体HanlderThread是什么，这里放上这个类。

/**
 * Handy class for starting a new thread that has a looper. The looper can then be 
 * used to create handler classes. Note that start() must still be called.
 */
public class HandlerThread extends Thread {
@Override
    public void run() {
        mTid = Process.myTid();
        Looper.prepare();
        synchronized (this) {
            mLooper = Looper.myLooper();
            notifyAll();
        }
        Process.setThreadPriority(mPriority);
        onLooperPrepared();
        Looper.loop();
        mTid = -1;
    }
}

可以看到就是一个Thread只不过内部封装好了Android使用多线程Hanlder的一系列操作。

//用于在判断内存泄露之前，再给一次GC的机会
    GcTrigger gcTrigger = this.gcTrigger;
    if (gcTrigger == null) {
      gcTrigger = defaultGcTrigger();
    }
    
    public interface GcTrigger {
  GcTrigger DEFAULT = new GcTrigger() {
    @Override public void runGc() {
      // Code taken from AOSP FinalizationTest:
      // https://android.googlesource.com/platform/libcore/+/master/support/src/test/java/libcore/
      // java/lang/ref/FinalizationTester.java
      // System.gc() does not garbage collect every time. Runtime.gc() is
      // more likely to perfom a gc.
      //这里用的是Runtime.getRuntime().gc()
      //注意这里和System.gc()的区别
      Runtime.getRuntime().gc();
      //等待100毫秒
      enqueueReferences();
      System.runFinalization();
    }

    private void enqueueReferences() {
      // Hack. We don't have a programmatic way to wait for the reference queue daemon to move
      // references to the appropriate queues.
      try {
        Thread.sleep(100);
      } catch (InterruptedException e) {
        throw new AssertionError();
      }
    }
  };

  void runGc();
}

接下来算是LeakCanary的一个比较特殊的地方，接下来看到，设置了一个和GC相关的一个类，最终我们会发现是使用的上面放的DEFAULT,这里可以看到一个很特殊的一点，这里使用了一个方法Runtime.getRuntime().gc()，而且也看到了官方对于此处的注释这里引用了AOSP的一段代码，System.gc()并不会每次都真正调用回收，所以使用Runtime.getRuntime().gc();这里就是我们平常不会注意到的知识点，这里需要我们区分一下两个的区别，我自己看了一下两个的源码，并没有发现两个内部的不同（不知道是不是我看的方式的问题），我通过查询，网上对于这两个方法的区别总体是这样解释的。

/**
 * Indicates to the VM that it would be a good time to run the
 * garbage collector. Note that this is a hint only. There is no guarantee
 * that the garbage collector will actually be run.
 */
public static void gc() {
    boolean shouldRunGC;
    synchronized(lock) {
        shouldRunGC = justRanFinalization;
        if (shouldRunGC) {
            justRanFinalization = false;
        } else {
            runGC = true;
        }
    }
    if (shouldRunGC) {
        Runtime.getRuntime().gc();
    }
}

以上是引用一篇不错的LeakCanary的源码分析中关于gc()源码（不知道为什么我自己看不到这样的源码，如果有人知道，评论告诉我一下，谢谢～～），从这里就可以看出，System.gc()的实质其实是调用Runtime.getRuntime().gc()，只不过做了一些多线程同步的判断，所以，我们调用System.gc()并不会一定出发JVM的GC操作。
到此build()方法到这里就分析完了，通过上面的分析我们会发现，到目前为止基本上都是做的准备工作，接下来就是LeakCanary的核心操作，检测内存泄漏。

//开启LeakCanary的Activity,使图标显示
LeakCanary.enableDisplayLeakActivity(context);

  public static void enableDisplayLeakActivity(Context context) {
    setEnabled(context, DisplayLeakActivity.class, true);
  }
  
  public static void setEnabled(Context context, final Class componentClass,
      final boolean enabled) {
    final Context appContext = context.getApplicationContext();
    executeOnFileIoThread(new Runnable() {
      @Override public void run() {
        setEnabledBlocking(appContext, componentClass, enabled);
      }
    });
  }
  
   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);
  }

下面这行代码其实作用是开启LeakCanary的应用图标，使其显示。我们可以看到，这里传入了DisplayLeakActivity.class类，最后通过packageManager.setComponentEnabledSetting这个方法，将Activity设置为COMPONENT_ENABLED_STATE_ENABLED状态。这样设置有什么作用哪，我们来看一下AndroidManifest.xml文件。

可以看到，这里在清单文件中，将DisplayLeakActivity的enabled。这里还有一个需要我们注意到点，这里使用了线程池。

private static final Executor fileIoExecutor = newSingleThreadExecutor("File-IO");

public static void executeOnFileIoThread(Runnable runnable) {
    fileIoExecutor.execute(runnable);
  }
  
  public static Executor newSingleThreadExecutor(String threadName) {
    return Executors.newSingleThreadExecutor(new LeakCanarySingleThreadFactory(threadName));
  }

可以看到这里创建了Java中的newSingleThreadExecutor线程池，具体特点这里就不详细介绍了，简单的说就是一个唯一的线程，顺序的执行任务。

监听生命周期

//默认为true
      if (watchActivities) {
        //注意，在这里通过监听Application,监听Activity的生命周期
        ActivityRefWatcher.install((Application) context, refWatcher);
      }

前面的一系列分析，这里终于可以开始监听生命周期，也就是检测内存泄漏的地方了。

public static void install(Application application, RefWatcher refWatcher) {
    new ActivityRefWatcher(application, refWatcher).watchActivities();
  }
  
  public void watchActivities() {
    // Make sure you don't get installed twice.
    stopWatchingActivities();
    //注册监听回调
    application.registerActivityLifecycleCallbacks(lifecycleCallbacks);
  }

  public void stopWatchingActivities() {
    application.unregisterActivityLifecycleCallbacks(lifecycleCallbacks);
  }

可以看到这里避免重复监听，因为内部是使用一个ArrayList进行保存lifecycleCallbacks,所以为了和之前的单例保持一致，这里就做移除操作。这里其实我们就要关注，这里是如果实现监听的。

private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
      new Application.ActivityLifecycleCallbacks() {
        @Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
        }

        @Override public void onActivityStarted(Activity activity) {
        }

        @Override public void onActivityResumed(Activity activity) {
        }

        @Override public void onActivityPaused(Activity activity) {
        }

        @Override public void onActivityStopped(Activity activity) {
        }

        @Override public void onActivitySaveInstanceState(Activity activity, Bundle outState) {
        }

        @Override public void onActivityDestroyed(Activity activity) {
            //onDestroy的时候回调
          ActivityRefWatcher.this.onActivityDestroyed(activity);
        }
      };

可以看到这里利用了Android中的Application的特性，注册了Application.ActivityLifecycleCallbacks监听器，在Activity的onDestroy方法中，调用了ActivityRefWatcher.this.onActivityDestroyed(activity);方法。

void onActivityDestroyed(Activity activity) {
      //Activity在onDestroy的时候回调
    refWatcher.watch(activity);
  }

这里就调用了我们之前构建的refWatcher对象的watch方法。

public void watch(Object watchedReference, String referenceName) {
    if (this == DISABLED) {
      return;
    }
    checkNotNull(watchedReference, "watchedReference");
    checkNotNull(referenceName, "referenceName");
    //获得当前时间
    final long watchStartNanoTime = System.nanoTime();
    //生成一个唯一的key
    String key = UUID.randomUUID().toString();
    //保存这个key
    retainedKeys.add(key);
    //将检查内存泄漏的对象保存为一个弱引用，注意queue
    final KeyedWeakReference reference =
        new KeyedWeakReference(watchedReference, key, referenceName, queue);
    //异步开始分析这个弱引用
    ensureGoneAsync(watchStartNanoTime, reference);
  }

这里可以看到，这里使用了当前时间作为唯一标示，这里获取时间的方法也很讲究，System.nanoTime()这个和System.currentTimeMillis()的区别也很简答，这里引用别人的分析简单的说明一下：

平时产生随机数时我们经常拿时间做种子，比如用System.currentTimeMillis的结果，但是在执行一些循环中使用了System.currentTimeMillis，那么每次的结果将会差别很小，甚至一样，因为现代的计算机运行速度很快。后来看到java中产生随机数函数以及线程池中的一些函数使用的都是System.nanoTime，下面说一下这2个方法的具体区别。
System.nanoTime提供相对精确的计时，但是不能用他来计算当前日期
System.nanoTime与System.currentTimeMillis的区别

接下来利用UUID.randomUUID().toString()生成了一个唯一的key保存在retainedKeys集合中，而这个retainedKeys是一个Set数据类型。

// 用于判断弱引用所持有的对象是否已被GC,如果被回收，会存在队列中，反之，没有存在队列中则泄漏了
  private final ReferenceQueue