今天刷微博，發(fā)現(xiàn)各位Android開源大神都在轉(zhuǎn)發(fā)一條關(guān)于Square開源的自動探測內(nèi)存泄露庫LeakCanary的信息姐仅。
自動探測內(nèi)存泄露花枫，這也太牛逼了吧！進入@扔物線110 分享的鏈接了解了下掏膏，對原文作簡單翻譯：(翻譯水平有限劳翰，湊合看吧-_-)
原文：https://corner.squareup.com/2015/05/leak-canary.html
LeakCanary開源庫地址：https://github.com/square/leakcanary
LeakCanary:探測所有內(nèi)存泄露！
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錯誤的出現(xiàn)
在Square Register應(yīng)用中馒疹，我們實現(xiàn)在一個位圖緩存bitmap cache中讓客戶簽名draw the customer's signature佳簸，這個bitmap占據(jù)設(shè)備屏幕的大小，當我們創(chuàng)建一個bitmap時，會出現(xiàn)一個很嚴重的OOM問題生均。
我們試過幾種方法袱讹，但是沒有一種可以解決這個問題：
- 使用 Bitmap.Config.ALPHA_8 (一種不需要顏色的簽名)
- 捕捉OOM錯誤讥蟆，觸發(fā)GC喻奥，并重試幾次(由GCUtils想起的)
- 我們并不打算脫離Java heap分配位圖內(nèi)存滋将。對于我們幸運的是，開源圖片處理庫Fresco至今不存在這個問題
其實佩脊，我們一直以一個錯誤的方式思考這個問題了
這個bitmap的尺寸不是問題所在蛙粘。當內(nèi)存幾乎滿時，OOM隨時會發(fā)生威彰。OOM常會發(fā)生在你創(chuàng)建大對象如bitmap的地方出牧。OOM出現(xiàn)是一個更深層次問題內(nèi)存泄露的征兆。
什么是內(nèi)存泄露(memory leak)歇盼？
一些對象有有限的使用期舔痕，當它們的工作完成后，它們預期會被當作內(nèi)存垃圾回收豹缀。如果一個持有對象的引用鏈結(jié)束了它的預期壽命伯复，這將會產(chǎn)生一個內(nèi)存泄露。隨著泄露的積累耿眉，應(yīng)用程序?qū)谋M內(nèi)存边翼。
例如鱼响，Activity的onDestroy()被調(diào)用后鸣剪，這個Activity的視圖層次和相關(guān)的位圖都應(yīng)該進行垃圾回收。而如果一個線程在后臺運行這個Activity的引用丈积，那么相應(yīng)的內(nèi)存將不能被回收筐骇，這最終就導致了OutOfMemoryError的出現(xiàn)。
搜尋內(nèi)存泄露(memory leaks)
搜尋內(nèi)存泄露是一個手動過程江滨，在Raizlabs上的Wrangling Dalvik系列文章中得到很好的描述铛纬。
這里是關(guān)鍵步驟：
- 通過Bugsnag, Crashlytics或Google的Developer Console了解OOM問題;
- 嘗試重現(xiàn)問題。你需要想盡辦法找到出現(xiàn)內(nèi)存泄露的設(shè)備(You might need to buy, borrow, or steal the specific device that suffered the crash.) 不是所有設(shè)備都有內(nèi)存泄露問題唬滑「嫠簦或者你也需要自己制作內(nèi)存泄露。
- 當OOM出現(xiàn)時進行堆轉(zhuǎn)儲(dump the heap);
- 使用MAT或YourKit內(nèi)存檢測工具檢測內(nèi)存的變化晶密，并找出哪個對象應(yīng)該被垃圾回收;
- 從那個對象到GC roots推斷最短的強引用路徑;
- 在路徑中找出不存在的引用擒悬，并修復memory leak;
- 要是有一個庫能夠在程序出現(xiàn)OOM前做這些檢測，讓你專注于解決內(nèi)存泄露稻艰，那該多好呀懂牧？
(注：好，LeakCanary正能做到尊勿！)
LeakCanary的介紹
LeakCanary是一個在調(diào)試時就可以檢測內(nèi)存泄露的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;
創(chuàng)建一個Refwatcher的實例并傳入一個Cat對象：
// We expect schrodingerCat to be gone soon (or not), let's watch it.
refWatcher.watch(schrodingerCat);
當泄露被檢測到時畜侦，可以自動地獲取到泄露的地方：
* GC ROOT static Docker.container
* references Box.hiddenCat
* leaks Cat instance
我們知道你正忙著寫功能，所以我們使LeakCanary更容易地設(shè)置躯保。只用一行代碼旋膳，LeakCanary就可以自動檢測活躍的泄露。
public class ExampleApplication extends Application {
@Override public void onCreate() {
super.onCreate();
LeakCanary.install(this);
}
}
當內(nèi)存不足時途事，會有一個通知和良好的展示界面：
總結(jié)：
使用LeakCanary后溺忧，我們在我們的app中發(fā)現(xiàn)并修復了很多內(nèi)存泄露問題，我們甚至發(fā)現(xiàn)了一些Android SDK自身的內(nèi)存泄露盯孙。
有了LeakCanary的結(jié)果是驚人的鲁森，我們現(xiàn)在減少了94%的OOM錯誤。
如果你想消除OOM引起的崩潰振惰，[現(xiàn)在就安裝LeakCanary吧](If you want to eliminate OOM crashes, install LeakCanary now!)歌溉！
注：搜索資料時，發(fā)現(xiàn)Hacker News和reddit上開發(fā)者對LeakCanary滿滿的贊言骑晶，Square(電子現(xiàn)金支付公司)確實是非常棒的一家公司痛垛，Github上有很多優(yōu)秀的開源項目，如okhttp, dagger, picasso, otto, retrofit等桶蛔。技術(shù)型驅(qū)動的公司就是贊匙头！
第一次翻譯才知道自己的英語有多渣o(╯□╰)o, 做技術(shù)的，英語水平低確實是一個瓶頸仔雷，好好加油吧蹂析！
