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

原文：http://cfanr.cn/2015/05/09/Automatically-detect-memory-leaks%E2%80%94LeakCanary/

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

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

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

LeakCanary:探测所有内存泄露！

1 2 3 4

java.lang.OutOfMemoryError at android.graphics.Bitmap.nativeCreate(Bitmap.jav a:- 2) at android.graphics.Bitmap.createBitmap(Bitmap.jav a:689) at com.squareup.ui.SignView.createSignatureBitmap(SignView.jav a: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类的例子：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

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就可以自动检测活跃的泄露。

1 2 3 4 5 6

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

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

总结：

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

如果你想消除OOM引起的崩溃，现在就安装LeakCanary吧！

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

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