今天刷微博,发现各位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.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类的例子:

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 Newsreddit上开发者对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/