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

Save the date for Droidcon SF in March — a conference with best-in-class presentations from leaders in all parts of the Android ecosystem.

介绍 (0:00)

大家好，我是 Pierre-Yvews Ricau (叫我 PY 就行)，现在在 Square 工作。

Square 出了一款名为：Square Register 的 App，帮助你用移动设备完成支付。在用这个 App 的时候，用户先要登陆他的个人账号。

不幸的是，在签名页面有的时候会因为内存溢出而出现崩溃。老实说，这个崩溃来的太不是时候了 — 用户和商家都无法确认交易是否完成了，更何况是在和钱打交道的时候。我们也强烈的意识到，我们需要处理下内存溢出或者内存泄露这种事情了。

内存泄漏：非技术讲解 (1:40)

我想要聊的内存泄露解决方案是： LeakCanary。 LeakCanary 是一个可以帮助你发现和解决内存泄露的开源工具。但是到底什么是内存泄露呢？我们从一个非技术角度来开始，先来举个例子。

假设我的手代表着我们 App 能用的所有内存。我的手里能放很多东西。比如：钥匙，Android 玩偶等等。设想我的 Android 玩偶需要扬声器才能工作，而我的扬声器也需要依赖 Android 玩偶才能工作，因此他们持有彼此的引用。

我的手里可以持有如此多的东西。扬声器依附到 Android 玩偶上会增加总重量，就像引用会占用内存一样。一旦我放弃了我的玩偶，把他扔到地上，会有垃圾回收器来回收掉它。一旦所有的东西都进了垃圾桶，我的手又轻便了。

不幸的是，有的时候，一些不好的情况会发生。比如：我的钥匙没准和我的 Android 玩偶黏在了一起，阻止我把 Android 玩偶扔到地上。最终的结果就是 Android 玩偶无论如何都不会被回收掉。这就是内存泄露。

有外部的引用（钥匙，扬声器）指向了本不应该再指向的对象（Andorid 玩偶）。类似这样的小规模的内存泄露堆积以后就会造成大麻烦。

LeakCanary to the Rescue (3:47)

这就是我们为什么要开发 LeakCanary。

我现在可能已经清楚了可被回收的 Android 对象应该及时被销毁。

但是我还是没法清楚饿看到这些对象是否已经被回收掉。有了 LeakCanary 以后，我们给可被回收的 Android 对象上打了智能标记。智能标记能知道他们所指向的对象是否被成功释放掉。如果过一小段时间对象依然没有被释放，他就会给内存做个快照。

LeakCanary 随后会把结果发布出来，帮助我们看到内存到底怎么泄露了，清晰的展示无法被释放的对象的引用链。

举个具体的例子：在我们的 Square App 里的签名页面。用户准备签名的时候，App 因为内存溢出出错崩溃了。我们不能确认内存错误到底出在哪儿了。

签名页面持有了一个很大的有用户签名的 Bitmap 图片对象。图片的大小和用户手机屏幕大小一致 — 我们猜测这个有可能会造成内存泄露。首先，我们可以配置 Bitmap 为 alpha 8-bit 来节省内存。这是很常见的一种修复方案，而且效果也不错。但是并没有彻底解决问题，只是减少了泄露的内存总量。但是内存泄露依然在哪儿。

最主要的问题是我们 App 的堆满了，应该要留有足够的空间给我们的签名图片，但是由于很多处的内存泄露叠加在一起占用了很多内存。

技术讲解内存泄漏 (8:06)

假设，我有一个 App，这个 App 点一下就能买一个法棍面包（哈哈，可能只有法国人需要这样的App，没错，我就是法国人）。

private static Button buyNowButton;

由于某种原因，我把这个 button 设置成了 static 的。问题随之而来，这个按钮除非你设置成了null，不然就内存泄露了。

你也许会说：“只是一个按钮而已，没啥大不了”。问题是这个按钮还有一个成员变量：叫 “mContext”，这个东西指向了一个 Acitvity，Acitivty 又指向了一个 Window，Window 有拥有整个 View 继承树。算下来，那可是一大段的内存空间。

静态的变量是 GC root 类型的一种。垃圾回收器会尝试回收所有非 GC root 的对象，或者某些被 GC root 持有的对象。所以如果你创建一个对象，并且移除了这个对象的所有指向，他就会被回收掉。但是一旦你将一个对象设置成 GC root，那他就不会被回收掉。

当你看到类似“法棍按钮”的时候，很显然这个按钮持有了一个 Activity 的引用，所以我们必须清理掉它。当你沉浸在你的代码的时候，你肯定很难发现这个问题。你可能只看到了引出的引用。你可以知道 Activity 引用了一个 Window，但是谁引用了 Activity？

你可以用像 IntelliJ 这样的工具做些分析，但是它并不会告诉你所有的东西。通常，你可以把这些 Object 的引用关系组织成图，但是是个单向图。

分析堆 (10:16)

我们能做些什么呢？我们来做个快照。我们拿出所有的内存然后导出到文件里，这个文件会被用来分析和解析堆结构。其中一个工具叫做 Memory Analyzer，也叫 MAT。它会通过 dump 的内存，然后分析所有存活在内存中的对象和类。你可以用 SQL 对他做些查询，类似如下：

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

这条语句会返回所有的状态为 destroyed 的实例。一旦你发现了泄露的 Activity，你可以执行 merge_shortest_paths 的操作来计算出最短的 GC root 路径。从而找出阻止你 Acitivty 释放的那个对象。

之所以说要 “最短路径”，是因为通常从一个 GC root 到 Acitivty，有很多条路径可以到达。比如说：我的按钮的 parent view，同样也持有一个 mContext 对象。

当我们看到内存泄露的时候，我们通常不需要去查看所有的这些路径。我们只需要最短的一条。那样的话，我们就排除了噪音，很快的找到问题所在。

LeakCanary 救你于水火之中 (12:04)

有 MAT 这样一个帮我们发现内存泄露的工具是个很棒的事情。但是在一个正在运行的 App 的上下文中，我们很难像我们的用户发现泄露那样发现问题所在。我们不能要求他们在做一遍相同操作，然后留言描述，再把 70多 MB 的文件发回给我们。我们可以在后台做这个，但是并不 Cool。我们期望的是，我们能够尽早的发现泄露。比如在我们开发的时候就发现这些问题。这也是 LeakCanary 诞生的意义。

一个 Activity 有自己生命周期。你了解它是如何被创建的，如何被销毁的，你期望他会在 onDestroy() 函数调用后，回收掉你所有的空闲内存。如果你有一个能够检测一个对象是否被正常的回收掉了的工具，那么你就会很惊讶的喊出：“这个可能造成内存泄露！仍然没有被垃圾回收掉，它本该被回收掉的！”

Activity 无处不在。很多人都把 Activity 当做神级 Object 一般的存在，因为它可以操作 Services，文件系统等等。经常会发生对象泄漏的情况，如果泄漏对象还持有 context 对象，那 context 也就跟着泄漏了。

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);

LeakCanary API Walkthrough (13:32)

我们回过头来再看看智能标记（smart pin），我们希望知道的是当生命后期结束后，发生了什么。幸运的时，LearkCanary有一个很简单的 API。

第一步：创建 RefWatcher。给 RefWatcher 传入一个对象的实例，它会检测这个对象是否被成功释放掉。

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);
  }
}

第二步：监听 Activity 生命周期。然后，当 onDestroy 被调用的时候，我们传入 Activity。

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);
}

What are Weak References (14:17)

想要了解这个是怎么工作的，我得先跟大家聊聊弱引用（weak reference）。我刚才提到过静态域的变量会持有Activity 的引用。所以刚才说的“下单”按钮就会持有 mContext 对象，导致 Activity 无法被释放掉。这个被称作强引用（strong reference）。在垃圾回收过程中，你可以对一个对象有很多的强引用。当这些强引用的个数总和为零的时候，垃圾回收器就会释放掉它。

弱引用，就是一种不增加引用总数的持有引用方式。垃圾回收期是否决定要回收一个对象，只取决于它是否还存在强引用。所以说，如果我们将我们的 Activity 持有为弱引用，一旦我们发现弱引用持有的对象已经被销毁了，那么这个 Activity 就已经被垃圾回收器回收了。否则，那可以大概确定这个 Activity 已经被泄露了。

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);
  }
}

弱引用的主要目的是为了做 Cache，而且非常有用。主要就是告诉 GC，尽管我持有了这个对象，但是如果一旦没有对象在用这个对象的时候，GC 就可以在需要的时候销毁掉。

在下面的例子中，我们继承了 WeakReference：

final class KeyedWeakReference extends WeakReference