用 LeakCanary 检测内存泄漏

private static Button buyNowButton;

SELECT * FROM INSTANCEOF android.app.Activity a WHERE a.mDestroyed = true

public class MyActivity extends Activity {

  @Override protected void onDestroy() {
    super.onDestroy();
    // instance should be GCed soon.
  }
}

Resources resources = context.getResources();
LayoutInflater inflater = LayoutInflater.from(context);
File filesDir = context.getFilesDir();
InputMethodManager inputMethodManager =
  (InputMethodManager) context.getSystemService(Context.INPUT_METHOD_SERVICE);

public class ExampleApplication extends Application {

  public static RefWatcher getRefWatcher(Context context) {
    ExampleApplication application = (exampleApplication) context.getApplicationContest();
    return application.refWatcher;
  }

  private RefWatcher refWatcher;

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

public ActivityRefWatcher(Application application, final RefWatcher refWatcher) {
  this.application = checkNotNull(application, "application");
  checkNotNull(refWatcher, "androidLeakWatcher");
  lifecycleCallbacks = new ActivityLifecycleCallbacksAdapter() {
    @Override public void onActivityDestroyed(Activity activity) {
      refWatcher.watch(activity);
    }
  };
}

public void watchActivities() {
  // Make sure you don’t get installed twice.
  stopWatchingActivities();
  application.registerActivityLifecycleCallbacks(lifecycleCallbacks);
}

private static Button buyNowButton;

Context mContext;

WeakReference

/** Treated specially by GC. */
T referent;

public class Baguette Activity
  extends Activity {

  @Override protected void onCreate(Bundle state) {
    super.onCreate(state);
    setContentView(R.layout.activity_main);
  }
}

final class KeyedWeakReference extends WeakReference {
  public final String key; // (1) Unique identifier
  public final String name;

  KeyedWeakReference(Object referent, String key, String name, ReferenceQueue referenceQueue) {
    super(checkNotNull(referent, "referent"), checkNotNull(referenceQueue, "referenceQueue"));
    this.key = checkNotNull(key, "key");
    this.name = checkNotNull(name, "name");
  }
}

你可以看到，我们给弱引用添加了一个 Key，这个 Key 是一个唯一字符串。想法是这样的：当我们解析一个 heap dump 文件的时候，我们可以询问所有的 KeyedWeakReference 实例，然后找到对应的 Key。
首先，我们创建一个 weakReference，然后我们写入『一会儿，我需要检查弱引用』。（尽管一会儿可能就是几秒后）。当我们调用 watch 函数的时候，其实就是发生了这些事情。
public void watch(Object watchedReference, String referenceName) {
  checkNotNull(watchedReference, "watchedReference");
  checkNotNull(referenceName, "referenceName");
  if (debuggerControl.isDebuggerAttached()) {
    return;
  }
  final long watchStartNanoTime = System.nanoTime();
  String key = UUID.randomUUID().toString();
  retainedKeys.add(key);
  final KeyedWeakReference reference =
    new KeyedWeakReference(watchedReference, key, referenceName, queue);

  watchExecutor.execute(() → { ensureGone(reference, watchStartNanoTime); });
}

在这一切的背后，我们调用了 System.GC — 免责声明— 我们本不应该去做这件事情。然而，这是一种告诉垃圾回收器：『Hey，垃圾回收器，现在是一个不错的清理垃圾的时机。』，然后我们再检查一遍，如果发现有些对象依然存活着，那么可能就有问题了。我们就要触发 heap dump 操作了。
HAHA! (16:55)
亲手做 heap dump 是件超酷的事情。当我亲手做这些的时候，花了很多时间和功夫。我每次都是做相同的操作：下载 heap dump 文件，在内存分析工具里打开它，找到实例，然后计算最短路径。但是我很懒，我根本不想一次次的做这个。（我们都很懒对吧，因为我们是开发者啊！）
我本可以为内存分析器写一个 Eclipse 插件，但是 Eclipse 插件机制太糟糕了。 后来我灵机一动，我其实可以把某个 Eclipse 的插件，移除 UI，利用它的代码。
HAHA 是一个无UI Android 内存分析器。基本上就是把另一个人写的代码重新打包。开始的时候，我就是 fork 了一份别的代码然后移除了UI部分。两年前，有人重新fork了我的代码，然后添加了 Android 支持。又过了两年，我才发现这个人的仓储，然后我又重新打包上传到了 maven center。
我最近根据 Android Studio 修改了代码实现。代码还说的过去，还会继续维护。
LeakCanary 的实现 (19:19)
我们有自己的库去解析 heap dump 文件，而且实现的很容易。我们打开 heap dump，加载进来，然后解析。然后我们根据 key 找到我们的引用。然后我们根据已有的 Key 去查看拥有的引用。我们拿到实例，然后得到对象图，再反向推导发现泄漏的引用。
所有的工作实际上都发生在 Android 设备上。当 LeakCanary 探测到一个 Activity 已经被销毁掉，而没有被垃圾回收器回收掉的时候，它就会强制导出一份 heap dump 文件存在磁盘上。然后开启另外一个进程去分析这个文件得到内存泄漏的结果。如果在同一进程做这件事的话，可能会在尝试分析堆内存结构的时候而发生内存不足的问题。
最后，你会得到一个通知，点击一下就会展示出详细的内存泄漏链。而且还会展示出内存泄漏的大小，你也会很明确自己解决掉这个内存泄漏后到底能够解救多少内存出来。
LeakCanary 也是支持 API 的，这样你就可以挂载内存泄漏的回调，比方说可以把内存泄漏问题传到服务器上。在 Square 我们用了 Slack 的 API，在测试阶段出现内存泄漏的时候，它就会通知我们。
@Override protected void onLeakDetected(HeapDump heapDump, AnalysisResult result) {
  String name = classSimpleName(result.className);
  String title = name + " has leaked";
  slackUploader.uploadHeapDumpBlocking(heapDump.headDumpFile, title, result.leakTrace.toString(),
    MEMORY_LEAK_CHANNEL);
}

用上 API 以后，我们的程序崩溃率降低了 94%！简直棒呆！
Debug 一个真实的例子 (22:12)
这里有个例子，是来自 AOSB 的一个内存泄漏的代码。假设我们一个 App，包含了一个 undobar，你在点击某些按钮的时候 undobar 会消失掉。
public class MyActivity extends Activity {

  @Override protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstatnceState);
    setContentView(R.layout.activity_main);

    find ViewbyID(R.id.button).setOnClidkListener(new View.OnClickListener() {
      @Override public void onClick(View v) {
        removeUndoBar();
      }
    });
  }

  private void removeUndoBar() {...}

  private void checkUndoBarGCed(ViewGroup undoBar) {...}
}

我们把所有的 View 都存起来，然后设置了一个 Layout 的 Transition 动画（1）。我们还给 undobar 增加了一个 View 进去（2）。然后我们从 parent layout 移除了 undobar（3）。
public class MyActivity extends Activity {

  @Override protected void onCreate(Bundle savedInstanceState) {...}

  private void removeUndoBar() {
    ViewGroup rootLayout = (ViewGroup) findViewById(R.id.root);
    ViewGroup undoBar = (ViewGroup) findViewById(R.id.undo_bar);

    undoBar.setLayoutTransition(new LayoutTransition()); // (1)

    // (2)
    View someView = new View(this);
    undoBar.addView(someView);

    rootLayout.removeView(undoBar); // (3)

    checkUndoBarGCed(undoBar);
  }

  private void checkUndoBarGCed(ViewGroup undoBar) {...}
}

现在看来，没有任何对象指向 undobar 了，所以说它应该被回收掉。否则的话…我们可能就遇到麻烦了。
我们用 LeakCanary 的 API 告诉系统：『Hey，现在该回收掉 undobar 了，几秒后检查下 undobar 是否被回收掉了』：
public class MyActivity extends Activity {

  @Override protected void onCreate(Bundle savedInstanceState) {...}

  private void removeUndoBar() {...}

  private void checkUndoBarGCed(ViewGroup undoBar) {
    RefWatcher watcher = MyApplication.from(this).getWatcher();
    watcher.watch(undoBar); // (1)
  }
}

我们删除了 undobar，但是… LeakCanary 好像不高兴了，它发现了内存泄露，返回的报告如下：
static InputMethodManager.sInstance

references
InputMethodManager.mCurRootView

references
PhoneWindow$DecorView.mAttachInfo

references View$AttachInfo.mTreeObserver

references
ViewTreeObserver.mOnPreDrawListeners

references
ViewTreeObserver$CopyOnWriteArray.mData

references LayoutTransition$1.val$parent

leaks FrameLayout instance

不难发现，静态的InputMethodManager有一个引用指向了当前的 root view：mCurRootView。mCurRootView 是当前窗口所有 View 的父容器。Root view 有一个叫做 TreeObserver 的对象。TreeObserver 是用在布局改变时候的做回调，通知监听布局改变的 listener 的，一个 View 关系树上只有一个 TreeObserver，所以你会看到它有很多的 PreDrawListener。这就意味着你每添加一个 PreDrawLisener，当布局改变的时候就会发起一次回调。
到现在为止看起来没有什么异常。但是不难发现某个 PreDrawListener持有一个 LayoutTransition$1，这种写法是 Java 表示匿名类的一种写法，意味着这是第一个在 LayoutTransition 里定义的匿名类。然后你还会看到有一个叫做 val$parent 的变量指向了我们泄露的 undobar。val$parent 意思就是这是在匿名类外声明的 final 类型的临时变量，变量名为 parent。
我们继续来看：
android.animation.LayoutTransition#runChangeTransition

// This is the cleanup step. When we get this rendering event, we know that all of
// the appropriate animations have been set up and run. Now we can clear out the
// layout listeners.
observer.addOnPreDrawListener(new ViewTreeObserver.OnPreDrawListener() {
  public boolean onPreDraw () {
    parent.getViewTreeObserver().removeOnPreDrawListener(this);
    // ... More code
    return true;
  }
});

这是 Android 源码的一部分 — LayoutTransition 是一个 Android 的类。这里的 Observer 是 ViewTreeObserver。一切都看起来没啥问题，注册了一个 ViewTreeObserver，然后马上在第一个回调里解除掉注册。这个按理说不应该出问题，但是到底发生了什么？我们来看看 getViewTreeObserver。
public ViewTreeObserver getViewTreeObserver() {
  if (mAttachInfo != null) {
    return mAttachInfo.mTreeObserver; // (1)
  }
  if (mFloatingTreeObserver == null) {
    mFloatingTreeObserver = new ViewTreeObserver();
  }
  return mFloatingTreeObserver; // (2)
}

undoBar.setLayoutTransition(new LayoutTransition()); // (3)

View someView = new View(this);
undoBar.addView(someView); // (4)

rootLayout.removeView(undoBar); // (5)

getViewTreeObserver 函数首先判断 attached状态，如果是，则返回一个 view 树，即 ViewTreeObserver。否则，返回一个临时的 ViewTreObserver。
问题是如果我的 View 被 detach 掉了，我将会得到一个假的 ViewTreeObserver，而非一个真实的 ViewTreeObserver。你会发现，我们设置了 LayoutTransition（3），然后增加了一个 view （4）。这个触发了 addOnPreDrawListener 监听器。然后我们移除掉了 undo-bar，这就意味着 undobar 无法再访问 ViewTreeObserver了。
final ViewTreeObserver observer = parent.getViewTreeObserver(); // used for later cleanup
if (!observer.isAlive()) {
  // If the observer’s not in a good state, skip the transition
  return;

}

public void onAnimationEnd(Animator animator) {
...
// layout listeners.

observer.addOnPreDrawListener(new ViewTreeObserver.OnPreDrawListener() {
  public boolean onPreDraw() {
    observer.removeOnPreDrawListener(this);
    parent.getViewTreeObserver().removeOnPreDrawListener(this);

它得到了一个假的 ViewTreeObserver，并且无法移除自己，因为他并不在这个假的 ViewTreeObserver 里。
这个是 Android 4年前的一次代码修改留下的问题，当时是为了修复另一个 bug，然而带来了无法避免的内存泄漏。我们也不知道何时能被修复。
忽略 Android SDK Crashes (28:10)
通常来说，总是有些内存泄漏是你无法修复的。我们某些时候需要忽略掉这些无法修复的内存泄漏提醒。在 LeakCanary 里，有内置的方法去忽略无法修复的问题。
LAYOUT_TRANSITION(SDK_INT >= ICE_CREAM_SANDWICH && SDK_INT  LOLLIPOP_MR1) {
  @Override void add (ExcludedRefs.Builder excluded) {
    // LayoutTransition leaks parent ViewGroup through ViewTreeObserver.OnPreDrawListener
    // When triggered, this leak stays until the window is destroyed.
    // Tracked here: https://code.google.com/p/android/issues/detail?id=171830
    excluded.instanceField("android.animation.LayoutTransition$1", "val$parent");
  }
}

我想要重申一下，LeakCanary 只是一个开发工具。不要将它用到生产环境中。一旦有内存泄漏，就会展示一个通知给用户，这一定不是用户想看到的。
我们即便用上了 LeakCanary 依然有内存溢出的错误出现。我们的内存泄露依然有多个。有没有办法改变这些呢？
LeakCanary 的未来 (29:14)
public class OomExceptionHandler implements Thread.UncaughtExceptionHandler {
  private final Thread.UncaughtExceptionHandler defaultHandler;
  private final Context context;

  public OomExceptionHandler(Thread.UncaughtExceptionHandler defaultHandler, Context context) {...}

  @Override public void UncaughtException(Thread thread, Throwable ex) {
    if (containsOom(ex)) {
      File heapDumpFile = new File(context.getFilesDir(), "out-of-memory.hprof");
      try {
        Debug.dumpHprofData(heapDumpFile.getAbsolutePath());
      } catch (Throwable ignored) {
      }
    }
    defaultHandler.uncaughtException(thread, ex);
  }

  private boolean containsOom(Throwable ex) {...}
}

这是一个 Thread.UncaughtExceptionHandler，你可以将线程崩溃委托给它，它会导出 heap dump 文件，并且在另一个进程里分析内存泄漏情况。
有了这个以后，我们就能做一些好玩儿的事情了，比如：列出所有的应该被销毁却依然在内存里存活的 Activity，然后列出所有的 Detached View。我们可以依此来为泄漏的内存按重要性排序。
我实际上已经有一个很简单的 Demo 了，是我在飞机上写的。还没有发布，因为还有些问题，最严重的问题是没有足够的内存去解析 heap dump 文件。想要修复这个问题，得想想别的办法。比如采用 stream 的方法去加载文件等等。
Q&A (31:50)
Q: LeakCanary 能用于 Kotlin 开发的 App?
PY: 我不知道，但是应该是可以的，毕竟到最后他们都是字节码，而且 Kotlin 也有引用。
Q:你们是在 Debug 版本一直开启 LeakCanary 么？还是只在最后的某些版本开启做做测试
PY： 不同的人有不同的方法，我们通常是一直都开着的。



Sign up to be notified of new videos
— we won’t email you for any other reason, ever.