LeakCanary: 讓內(nèi)存泄露無所遁形

09 May 2015

---

本文為LeakCanary: Detect all memory leaks!的翻譯。原文在:?https://corner.squareup.com/2015/05/leak-canary.html

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

誰也不會喜歡?OutOfMemoryError

在?Square Register?中, 在簽名頁面，我們把客戶的簽名畫在 bitmap cache 上。 這個 bitmap 的尺寸幾乎和屏幕的尺寸一樣大，在創(chuàng)建這個 bitmap 對象時，經(jīng)常會引發(fā)?OutOfMemoryError，簡稱OOM。

當(dāng)時，我們嘗試過一些解決方案，但都沒解決問題

• 使用 Bitmap.Config.ALPHA_8 因為，簽名僅有黑色。

• 捕捉?OutOfMemoryError, 嘗試 GC 并重試（受?GCUtils?啟發(fā)）。

• 我們沒想過在 Java heap 內(nèi)存之外創(chuàng)建 bitmap 。苦逼的我們，那會?Fresco?還不存在。

路子走錯了

其實 bitmap 的尺寸不是真正的問題，當(dāng)內(nèi)存吃緊的時候，到處都有可能引發(fā) OO。在創(chuàng)建大對象，比如 bitmap 的時候，更有可能發(fā)生。OOM 只是一個表象，更深層次的問題可能是:?內(nèi)存泄露。

什么是內(nèi)存泄露

一些對象有著有限的生命周期。當(dāng)這些對象所要做的事情完成了，我們希望他們會被回收掉。但是如果有一系列對這個對象的引用，那么在我們期待這個對象生命周期結(jié)束的時候被收回的時候，它是不會被回收的。它還會占用內(nèi)存，這就造成了內(nèi)存泄露。持續(xù)累加，內(nèi)存很快被耗盡。

比如，當(dāng)?Activity.onDestroy?被調(diào)用之后，activity 以及它涉及到的 view 和相關(guān)的 bitmap 都應(yīng)該被回收。但是，如果有一個后臺線程持有這個 activity 的引用，那么 activity 對應(yīng)的內(nèi)存就不能被回收。這最終將會導(dǎo)致內(nèi)存耗盡，然后因為 OOM 而 crash。

對戰(zhàn)內(nèi)存泄露

排查內(nèi)存泄露是一個全手工的過程，這在 Raizlabs 的?Wrangling Dalvik?系列文章中有詳細(xì)描述。

以下幾個關(guān)鍵步驟：

通過?Bugsnag,?Crashlytics?或者?Developer Console?等統(tǒng)計平臺，了解?OutOfMemoryError情況。

重現(xiàn)問題。為了重現(xiàn)問題，機型非常重要，因為一些問題只在特定的設(shè)備上會出現(xiàn)。為了找到特定的機型，你需要想盡一切辦法，你可能需要去買，去借，甚至去偷。 當(dāng)然，為了確定復(fù)現(xiàn)步驟，你需要一遍一遍地去嘗試。一切都是非常原始和粗暴的。

在發(fā)生內(nèi)存泄露的時候，把內(nèi)存 Dump 出來。具體看這里。

然后，你需要在?MAT?或者?YourKit?之類的內(nèi)存分析工具中反復(fù)查看，找到那些原本該被回收掉的對象。

計算這個對象到 GC roots 的最短強引用路徑。

確定引用路徑中的哪個引用是不該有的，然后修復(fù)問題。

很復(fù)雜對吧？

如果有一個類庫能在發(fā)生 OOM 之前把這些事情全部都搞定，然后你只要修復(fù)這些問題就好了，豈不妙哉！

LeakCanary

LeakCanary?是一個檢測內(nèi)存泄露的開源類庫。你可以在 debug 包種輕松檢測內(nèi)存泄露。

先看一個例子:

class Cat { }class Box {Cat hiddenCat; } class Docker {// 靜態(tài)變量，將不會被回收，除非加載 Docker 類的 ClassLoader 被回收。static Box container; }// ...Box box = new Box();// 薛定諤之貓 Cat schrodingerCat = new Cat(); box.hiddenCat = schrodingerCat; Docker.container = box;

創(chuàng)建一個RefWatcher，監(jiān)控對象引用情況。

// 我們期待薛定諤之貓很快就會消失（或者不消失），我們監(jiān)控一下 refWatcher.watch(schrodingerCat);

當(dāng)發(fā)現(xiàn)有內(nèi)存泄露的時候，你會看到一個很漂亮的 leak trace 報告:

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

我們知道，你很忙，每天都有一大堆需求。所以我們把這個事情弄得很簡單，你只需要添加一行代碼就行了。然后 LeakCanary 就會自動偵測 activity 的內(nèi)存泄露了。

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

然后你會在通知欄看到這樣很漂亮的一個界面:

結(jié)論

使用 LeakCanary 之后，我們修復(fù)了我們 APP 中相當(dāng)多的內(nèi)存泄露。我們甚至發(fā)現(xiàn)了?Android SDK 中的一些內(nèi)存泄露問題。

結(jié)果是驚艷的，我們減少了 94% 的由 OOM 導(dǎo)致的 crash。

如果你也想消滅 OOM crash，那還猶豫什么，趕快使用?LeakCanary

相關(guān)鏈接:

• LeakCanary 中文使用說明

• 一個非常簡單的 LeakCanary demo:?https://github.com/liaohuqiu/leakcanary-demo

• ? ? 本文轉(zhuǎn)自 一點點征服 ? 博客園博客，原文鏈接：http://www.cnblogs.com/ldq2016/p/6635816.html

• ，如需轉(zhuǎn)載請自行聯(lián)系原作者
  

總結(jié)

以上是生活随笔為你收集整理的LeakCanary: 让内存泄露无所遁形的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。