内存泄露自动探测神器——LeakCanary

今天刷微博，发现各位Android开源大神都在转发一条关于Square开源的自动探测内存泄露库LeakCanary的信息。

自动探测内存泄露，这也太牛逼了吧！进入@扔物线110 分享的链接了解了下，对原文作简单翻译：(翻译水平有限，凑合看吧-_-)

原文：https://corner.squareup.com/2015/05/leak-canary.html
LeakCanary开源库地址：https://github.com/square/leakcanary

LeakCanary:探测所有内存泄露！

java.lang.OutOfMemoryError
        at android.graphics.Bitmap.nativeCreate(Bitmap.java:-2)
        at android.graphics.Bitmap.createBitmap(Bitmap.java:689)
        at com.squareup.ui.SignView.createSignatureBitmap(SignView.java:121)

没有人喜欢OOM错误的出现

在Square Register应用中，我们实现在一个位图缓存bitmap cache中让客户签名draw the customer’s signature，这个bitmap占据设备屏幕的大小，当我们创建一个bitmap时，会出现一个很严重的OOM问题。

我们试过几种方法，但是没有一种可以解决这个问题：

使用 Bitmap.Config.ALPHA_8 (一种不需要颜色的签名)
捕捉OOM错误，触发GC，并重试几次(由GCUtils想起的)
我们并不打算脱离Java heap分配位图内存。对于我们幸运的是，开源图片处理库Fresco至今不存在这个问题

其实，我们一直以一个错误的方式思考这个问题了
这个bitmap的尺寸不是问题所在。当内存几乎满时，OOM随时会发生。OOM常会发生在你创建大对象如bitmap的地方。OOM出现是一个更深层次问题内存泄露的征兆。

###什么是内存泄露(memory leak)？
一些对象有有限的使用期，当它们的工作完成后，它们预期会被当作内存垃圾回收。如果一个持有对象的引用链结束了它的预期寿命，这将会产生一个内存泄露。随着泄露的积累，应用程序将会耗尽内存。
例如，Activity的onDestroy()被调用后，这个Activity的视图层次和相关的位图都应该进行垃圾回收。而如果一个线程在后台运行这个Activity的引用，那么相应的内存将不能被回收，这最终就导致了OutOfMemoryError的出现。

###搜寻内存泄露(memory leaks)
搜寻内存泄露是一个手动过程，在Raizlabs上的Wrangling Dalvik系列文章中得到很好的描述。

这里是关键步骤：

通过Bugsnag, Crashlytics或Google的Developer Console了解OOM问题;
尝试重现问题。你需要想尽办法找到出现内存泄露的设备(You might need to buy, borrow, or steal the specific device that suffered the crash.) 不是所有设备都有内存泄露问题。或者你也需要自己制作内存泄露。
当OOM出现时进行堆转储(dump the heap);
使用MAT或YourKit内存检测工具检测内存的变化，并找出哪个对象应该被垃圾回收;
从那个对象到GC roots推断最短的强引用路径;
在路径中找出不存在的引用，并修复memory leak;
要是有一个库能够在程序出现OOM前做这些检测，让你专注于解决内存泄露，那该多好呀？
(注：好，LeakCanary正能做到！)

###LeakCanary的介绍
LeakCanary是一个在调试时就可以检测内存泄露的Java开源库。

看个cat类的例子：

class Cat {
}
class Box {
  Cat hiddenCat;
}
class Docker {
  static Box container;
}

// ...

Box box = new Box();
Cat schrodingerCat = new Cat();
box.hiddenCat = schrodingerCat;
Docker.container = box;

创建一个Refwatcher的实例并传入一个Cat对象：

1 2	// We expect schrodingerCat to be gone soon (or not), let's watch it. refWatcher.watch(schrodingerCat);

当泄露被检测到时，可以自动地获取到泄露的地方：

1
2
3

* GC ROOT static Docker.container
* references Box.hiddenCat
* leaks Cat instance

我们知道你正忙着写功能，所以我们使LeakCanary更容易地设置。只用一行代码，LeakCanary就可以自动检测活跃的泄露。

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

当内存不足时，会有一个通知和良好的展示界面：

###总结：
使用LeakCanary后，我们在我们的app中发现并修复了很多内存泄露问题，我们甚至发现了一些Android SDK自身的内存泄露。
有了LeakCanary的结果是惊人的，我们现在减少了94%的OOM错误。

如果你想消除OOM引起的崩溃，[现在就安装LeakCanary吧](If you want to eliminate OOM crashes, install LeakCanary now!)！

注：搜索资料时，发现Hacker News和reddit上开发者对LeakCanary满满的赞言，Square(电子现金支付公司)确实是非常棒的一家公司，Github上有很多优秀的开源项目，如okhttp, dagger, picasso, otto, retrofit等。技术型驱动的公司就是赞！

第一次翻译才知道自己的英语有多渣o(╯□╰)o, 做技术的，英语水平低确实是一个瓶颈，好好加油吧！

From:cfanr, 转载需声明出处：http://navyifanr.github.io/2015/05/09/Automatically-detect-memory-leaks%E2%80%94LeakCanary/