原文: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:探测所有内存泄露!
|
|
没有人喜欢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类的例子:
|
|
创建一个Refwatcher的实例并传入一个Cat对象:
|
|
当泄露被检测到时,可以自动地获取到泄露的地方:
|
|
我们知道你正忙着写功能,所以我们使LeakCanary更容易地设置。只用一行代码,LeakCanary就可以自动检测活跃的泄露。
|
|
当内存不足时,会有一个通知和良好的展示界面:
总结:
使用LeakCanary后,我们在我们的app中发现并修复了很多内存泄露问题,我们甚至发现了一些Android SDK自身的内存泄露。
有了LeakCanary的结果是惊人的,我们现在减少了94%的OOM错误。
如果你想消除OOM引起的崩溃,现在就安装LeakCanary吧!
注:搜索资料时,发现Hacker News和reddit上开发者对LeakCanary满满的赞言,Square(电子现金支付公司)确实是非常棒的一家公司,Github上有很多优秀的开源项目,如okhttp, dagger, picasso, otto, retrofit等。技术型驱动的公司就是赞!
第一次翻译才知道自己的英语有多渣o(╯□╰)o, 做技术的,英语水平低确实是一个瓶颈,好好加油吧!