LeakCanary源码解析之检测篇
源码分析基于：1.6.3
对于Android开发者而言，内存泄漏是一种很常见的问题。LeakCanary就是捕获内存泄漏的一把利器。我们在这里就分析一下它的工作原理。
一、使用方法
使用方法就是我们在Application中添加代码：
if (LeakCanary.isInAnalyzerProcess(this)) {
// This process is dedicated to LeakCanary for heap analysis.
// You should not onStart your app in this process.
return;
}
LeakCanary.install(this);
看到这些估计你也会和我一样，这样我们就能捕获到内存泄露了么？不禁会产生这样的疑问。我们就带着疑问阅读一下源码寻找答案吧。
二、内存泄漏的检测过程：
LeakCanary这个类是一个工具类，我们先看一下LeakCanary.install(this)这个方法的源码：
/**
* 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(application)方法获取AndroidRefWatcherBuilder实例对象；“.listenerServiceClass(DisplayLeakService.class)”方法是对内存泄漏分析结果的监听；“.buildAndInstall()”方法用于生成RefWatcher对象，关于该方法的详细代码如下：
/**
* Creates a {@link RefWatcher} instance and makes it available through {@link
* LeakCanary#installedRefWatcher()}.
*
* Also starts watching activity references if {@link #watchActivities(boolean)} was set to true.
*
* @throws UnsupportedOperationException if called more than once per Android process.
*/
public @NonNull RefWatcher buildAndInstall() {
//保证RefWatcher的唯一性
if (LeakCanaryInternals.installedRefWatcher != null) {
throw new UnsupportedOperationException("buildAndInstall() should only be called once.");
}
//如果没有创建过RefWatcher,则创建一个；
RefWatcher refWatcher = build();
//非空置对象（内存分析相关工具对象都是空壳对象）
if (refWatcher != DISABLED) {
//是否允许使用内置展示页面展示内存泄露信息
if (enableDisplayLeakActivity) {
LeakCanaryInternals.setEnabledAsync(context, DisplayLeakActivity.class, true);
}
//是否允许监测activity
if (watchActivities) {
ActivityRefWatcher.install(context, refWatcher);
}
//是否允许检测fragment
if (watchFragments) {
FragmentRefWatcher.Helper.install(context, refWatcher);
}
}
//RefWatcher对象赋值
LeakCanaryInternals.installedRefWatcher = refWatcher;
return refWatcher;
}
在这里RefWatcher就是内存泄漏的监控器。该方法就是生成RefWatcher对象,该框架默认允许检测Activity和Fragment的内存泄漏，那么它又是怎么监控的呢？原理由是啥？以什么为判断内存泄漏的标准呢？
我们看一下ActivityRefWatcher中install()方法的逻辑：
public static void install(@NonNull Context context, @NonNull RefWatcher refWatcher) {
Application application = (Application) context.getApplicationContext();
ActivityRefWatcher activityRefWatcher = new ActivityRefWatcher(application, refWatcher);
//Application注册生命周期回调
application.registerActivityLifecycleCallbacks(activityRefWatcher.lifecycleCallbacks);
}
private final Application.ActivityLifecycleCallbacks lifecycleCallbacks =
new ActivityLifecycleCallbacksAdapter() {
@Override public void onActivityDestroyed(Activity activity) {
refWatcher.watch(activity);
}
};
lifecycleCallbacks是该类中的成员变量，通过注册生命周期回调RefWatcher就可以通过页面销毁的方法回调触发RefWatcher的watch()方法。我们先不管watch()方法中的具体逻辑，下面在分析一下fragment中的监测机制，下面我们分析一下FragmentRefWatcher.Helper这个内部类的源码：
final class Helper {
private static final String SUPPORT_FRAGMENT_REF_WATCHER_CLASS_NAME =
"com.squareup.leakcanary.internal.SupportFragmentRefWatcher";
public static void install(Context context, RefWatcher refWatcher) {
List fragmentRefWatchers = new ArrayList<>();
//大于26的Android版本使用AndroidOFragmentRefWatcher
if (SDK_INT >= O) {
fragmentRefWatchers.add(new AndroidOFragmentRefWatcher(refWatcher));
}
//否则使用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);
Application application = (Application) context.getApplicationContext();
//注册生命周期回调
application.registerActivityLifecycleCallbacks(helper.activityLifecycleCallbacks);
}
private final Application.ActivityLifecycleCallbacks activityLifecycleCallbacks =
new ActivityLifecycleCallbacksAdapter() {
@Override public void onActivityCreated(Activity activity, Bundle savedInstanceState) {
for (FragmentRefWatcher watcher : fragmentRefWatchers) {
//对应的FragmentManager注册回调
watcher.watchFragments(activity);
}
}
};
private final List fragmentRefWatchers;
private Helper(List fragmentRefWatchers) {
this.fragmentRefWatchers = fragmentRefWatchers;
}
}
该类中主要就是通过Activity的生命周期回调的onActivityCreated()方法，来获取activity实例对象，具体需要分析watcher.watchFragments(activity)中的逻辑，由于存在两种fragment对应的watcher,我们在这里只分析SupportFragmentRefWatcher中对应的代码逻辑。
@Override public void watchFragments(Activity activity) {
if (activity instanceof FragmentActivity) {
FragmentManager supportFragmentManager =
((FragmentActivity) activity).getSupportFragmentManager();
supportFragmentManager.registerFragmentLifecycleCallbacks(fragmentLifecycleCallbacks, true);
}
}
方法中获取FragmentManager实例对象，并注册生命周期方法。对于Android版本大于26的，请阅读AndroidOFragmentRefWatcher中的相关源码，原理是一致的。通过上面的源码我们分析得知，对于Activity而言，是在activity的onDestory()方法内进行监测的；对于fragment而言，在生命周期回调方法内的onFragmentViewDestroyed（）和onFragmentDestroyed（）方法内进行监测，在这里onFragmentViewDestroyed（）方法对应于Fragment的onDestroyView()方法，onFragmentDestroyed（）方法对应于Fragment#onDestroy()方法。
我们知道了LeakCanary的监测位置了，我们下面就通过源码分析一下它是怎么做到监测内存泄漏的。下面是RefWatcher类中的watch()方法的源码：
/**
* Watches the provided references and checks if it can be GCed. This method is non blocking,
* the check is done on the {@link WatchExecutor} this {@link RefWatcher} has been constructed
* with.
*
* @param referenceName An logical identifier for the watched object.
*/
public void watch(Object watchedReference, String referenceName) {
if (this == DISABLED) {
return;
}
checkNotNull(watchedReference, "watchedReference");
checkNotNull(referenceName, "referenceName");
final long watchStartNanoTime = System.nanoTime();
//生成随机的UUID作为该引用对象的key值
String key = UUID.randomUUID().toString();
//添加的集合中
retainedKeys.add(key);
//保存引用信息
final KeyedWeakReference reference =
new KeyedWeakReference(watchedReference, key, referenceName, queue);
//判断引用是否存在
ensureGoneAsync(watchStartNanoTime, reference);
}
在该方法中，将之前生命周期中的方法中拿到的activity对象实例或者fragment对象实例进行保存并进行相关的处理，在保存时会生成一个唯一的key值，后面会通过key值进行相应的业务逻辑。下面我们看一下ensureGoneAsync()方法相关的逻辑，源码如下：
private void ensureGoneAsync(final long watchStartNanoTime, final KeyedWeakReference reference) {
watchExecutor.execute(new Retryable() {
@Override public Retryable.Result run() {
return ensureGone(reference, watchStartNanoTime);
}
});
}
该方法中watchExecutor是AndroidWatchExecutor的一个具体实例对象，最终是通过该实现类的execute（）方法去执行引用相关的逻辑，这部分后面会分析。同时需要注意在excute()方法的内部类中run()方法会通过ensureGone()方法返回Retryable.Result的值。这个值会在后面的分析中用到。我们在这里先看一下AndroidWatchExecutor的具体实现。AndroidWatchExecutor是WatchExecutor接口的具体实现类，该接口主要用来执行Rertyable对象，并根据需要进行重试操作。我们看一下AndroidWatchExecutor的源码：
/**
* {@link WatchExecutor} suitable for watching Android reference leaks. This executor waits for the
* main thread to be idle then posts to a serial background thread with the delay specified by
* {@link AndroidRefWatcherBuilder#watchDelay(long, TimeUnit)}.
*/
public final class AndroidWatchExecutor implements WatchExecutor {
static final String LEAK_CANARY_THREAD_NAME = "LeakCanary-Heap-Dump";
private final Handler mainHandler;
private final Handler backgroundHandler;
private final long initialDelayMillis;
private final long maxBackoffFactor;
public AndroidWatchExecutor(long initialDelayMillis) {
mainHandler = new Handler(Looper.getMainLooper());
HandlerThread handlerThread = new HandlerThread(LEAK_CANARY_THREAD_NAME);
handlerThread.start();
backgroundHandler = new Handler(handlerThread.getLooper());
this.initialDelayMillis = initialDelayMillis;
maxBackoffFactor = Long.MAX_VALUE / initialDelayMillis;
}
@Override public void execute(@NonNull Retryable retryable) {
//当前线程是否为主线程
if (Looper.getMainLooper().getThread() == Thread.currentThread()) {
waitForIdle(retryable, 0);
} else {
postWaitForIdle(retryable, 0);
}
}
private void postWaitForIdle(final Retryable retryable, final int failedAttempts) {
mainHandler.post(new Runnable() {
@Override public void run() {
waitForIdle(retryable, failedAttempts);
}
});
}
private void waitForIdle(final Retryable retryable, final int failedAttempts) {
// This needs to be called from the main thread.
//主线程中进行调用，当主线程的消息队列空闲时调用
Looper.myQueue().addIdleHandler(new MessageQueue.IdleHandler() {
@Override public boolean queueIdle() {
//转移到后台线程进行
postToBackgroundWithDelay(retryable, failedAttempts);
return false;
}
});
}
private void postToBackgroundWithDelay(final Retryable retryable, final int failedAttempts) {
long exponentialBackoffFactor = (long) Math.min(Math.pow(2, failedAttempts), maxBackoffFactor);
long delayMillis = initialDelayMillis * exponentialBackoffFactor;
//延迟一定时间，再执行；
backgroundHandler.postDelayed(new Runnable() {
@Override public void run() {
Retryable.Result result = retryable.run();
if (result == RETRY) {
postWaitForIdle(retryable, failedAttempts + 1);
}
}
}, delayMillis);
}
}
AndroidWatchExecutor 是Android平台中内存泄漏的监测工具类。该类的主要方法就是execute()方法，其主要逻辑是判断当前正在执行的线程是否为主线程，如果是主线程，则通过IdleHandler监测主线程是否空闲，当空闲的时候，执行postToBackgroundWithDelay方法，在此方法中，先通过计算exponentialBackoffFactor（补偿因子），并通过该因子计算出需要延迟的时间（delayMillis ），说实话为什么这么算没想明白。最后通过backgroundHandler延迟执行一条线程去获取Retryable.Result的结果，通过是否需要重试也就是“result == RETRY”来判断是否需要继续postWaitForIdle方法，同时在重试的时候failedAttempts参数会加1。那么我们不禁会思考，retryable.run()的结果，也就是Retryable.Result是在什么时候改变的呢？这个我们在RefWatcher中的ensureGoneAsync()方法的分析中提到，result的值是在ensureGone()方法返回的。好了就是那么清晰。当正在执行的线程非主线程的的时候postWaitForIdle()方法被执行，这里就不再说明了。
下面我们看一下RefWatcher中ensureGone()方法的源码：
@SuppressWarnings("ReferenceEquality") // Explicitly checking for named null.
Retryable.Result ensureGone(final KeyedWeakReference reference, final long watchStartNanoTime) {
//GC开始检测时间
long gcStartNanoTime = System.nanoTime();
//从开始watch到GC开始检测的时间差
long watchDurationMs = NANOSECONDS.toMillis(gcStartNanoTime - watchStartNanoTime);
//移除已经被GC的引用信息
removeWeaklyReachableReferences();
//如果调试模式，则后续重试
if (debuggerControl.isDebuggerAttached()) {
// The debugger can create false leaks.
return RETRY;
}
//如果不包含应用信息，则表示监测已经完成，没有发生泄漏；
if (gone(reference)) {
return DONE;
}
//触发GC
gcTrigger.runGc();
//再次确认移除已经被GC的引用信息
removeWeaklyReachableReferences();
//如果队列中还存在引用信息，
if (!gone(reference)) {
long startDumpHeap = System.nanoTime();
long gcDurationMs = NANOSECONDS.toMillis(startDumpHeap - gcStartNanoTime);
//使用Dumper类dump当前堆内存中的对象信息
File heapDumpFile = heapDumper.dumpHeap();
if (heapDumpFile == RETRY_LATER) {
// Could not dump the heap.
return RETRY;
}
long heapDumpDurationMs = NANOSECONDS.toMillis(System.nanoTime() - startDumpHeap);
//将hprof文件和reference引用信息构造HeapDump对象
HeapDump heapDump = heapDumpBuilder.heapDumpFile(heapDumpFile).referenceKey(reference.key)
.referenceName(reference.name)
.watchDurationMs(watchDurationMs)
.gcDurationMs(gcDurationMs)
.heapDumpDurationMs(heapDumpDurationMs)
.build();
//分析dump信息
heapdumpListener.analyze(heapDump);
}
return DONE;
}
要理解LeackCanary是怎么定义内存泄漏的呢？此方法就是关键。同时不了解Java中的弱引用，强引用的概念的可以查阅一下这方面的资料，这里就不在进行过多的解释了。首先该方法先调用了removeWeaklyReachableReferences()方法，该方法就是移除已经被GC的引用信息，在该方法里就是看queue队列中是否还存在引用的信息KeyedWeakReference，如果存在就从retainedKeys中进行移除。在RefWatcher类中的watch()方法中已经将观察对象watchReference对应的key保存在retainedKeys中，同时关联到了ReferenceQueue的实例对象queue。当弱引用持有的对象被GC之后，与之关联的引用信息KeyedWeakReference的对象reference就会被添加到关联的队列中queue.所以可以通过queue中是否存在对应的引用信息来判断是否发生内存泄漏。下面说一下为什么在开启Debug模式下需要返回RETRY，那是因为在该模式下对象引用的时间会变长。我们继续向下分析，gone(refreence)方法就是看retainedKeys是否包含相应的引用的信息，如果不存在则说明就完成了GC,本次检测也告一段落。否则， 通过gcTrigger.runGc()手动触发一次GC,并在此通过removeWeaklyReachableReferences()方法进行引用信息的移除。如果还存在该引用信息那么说明app当前发生了内存泄漏。后续就是通过heapDumper.dumpHeap()将当前堆内存中的信息保存下来，并通过heapdumpListener.analyze(heapDump)分析获取的dump信息。到此，相信大家就清楚了我们Android开发中内存泄漏检测神器LeakCanary的检测原理了吧。
后续将在下一篇文章中分析该框架是怎么分析内存泄漏的，敬请期待~