內(nèi)存溢出，是Android開(kāi)發(fā)中常遇到的問(wèn)題，解決起來(lái)總是摸不著頭腦。今天爬爬就來(lái)講講如何定位內(nèi)存溢出。

 

OOM（內(nèi)存溢出）和Memory Leak（內(nèi)存泄露）有什么關(guān)系？

OOM可能是因?yàn)镸emory Leak，也可能是你的應(yīng)用本身就比較耗內(nèi)存（比如圖片瀏覽型的，或者應(yīng)用本身的設(shè)計(jì)有問(wèn)題）。所以，出現(xiàn)OOM不一定是Memory Leak。

同樣，Memory Leak也不一定就會(huì)導(dǎo)致OOM，如果泄露的速度很慢，可能還沒(méi)用完可用內(nèi)存應(yīng)用就被重啟了，那就不會(huì)OOM咯。當(dāng)然了，有bug解決了最好。

 

什么是shallow heap與retained heap？

shallow heap：你自身占了多少內(nèi)存，比如你有一個(gè)int屬性，就占4字節(jié)。不包括你引用的其他對(duì)象。
retained heap：如果你被銷(xiāo)毀，總共會(huì)釋放多少內(nèi)存。這些因你存在被占據(jù)的空間就是retained heap。
更詳細(xì)的解釋請(qǐng)看這篇博客

 

什么是GC roots？

GC的時(shí)候，是從這些節(jié)點(diǎn)開(kāi)始遍歷，不停的尋找其子節(jié)點(diǎn)直到結(jié)束。然后把不能遍歷到的節(jié)點(diǎn)釋放。這些遍歷的起點(diǎn)（注意，可不是一個(gè)哦）就叫做GC roots。

那，對(duì)于java來(lái)說(shuō)，誰(shuí)是GC roots？簡(jiǎn)單點(diǎn)說(shuō)（不是那么準(zhǔn)確）包括以下幾種：

棧上面的局部變量
棧上面的函數(shù)參數(shù)變量
所有由Bootstrap Loader加載的類(lèi)變量
另外，JNI相關(guān)的也會(huì)有
更多詳細(xì)解釋請(qǐng)看這篇博客
其實(shí)到最后，誰(shuí)是GC roots不是那么重要，因?yàn)橐话銇?lái)說(shuō)，到最后就剩下一些系統(tǒng)框架類(lèi)，以及jvm和class相關(guān)的東西。這里給大家說(shuō)GC roots主要是因?yàn)槭褂胢at需要了解它。

 

怎樣使用MAT定位內(nèi)存泄露？

 

看Histogram(類(lèi)統(tǒng)計(jì)圖)

histogram視圖顯示了每個(gè)類(lèi)有多少實(shí)例，并可以按照這些實(shí)例占據(jù)的Retained size和Shallow size排序。通過(guò)過(guò)濾包名，很容易發(fā)現(xiàn)有問(wèn)題的類(lèi)。

這里有幾個(gè)簡(jiǎn)單的原則，比如，activity的實(shí)例通常只應(yīng)該有一個(gè)。已經(jīng)關(guān)閉的activity不應(yīng)該出現(xiàn)。實(shí)體類(lèi)的Retained size應(yīng)該是比較小的，也就幾十KB。

對(duì)于Android程序來(lái)說(shuō)，內(nèi)存泄露通常都會(huì)牽扯到activity。因此，dump之前，可以多旋轉(zhuǎn)幾次屏幕并反復(fù)的進(jìn)出可能有問(wèn)題的activity，讓問(wèn)題盡可能的凸現(xiàn)。
通過(guò)Histogram我們可以看每個(gè)類(lèi)有多少個(gè)實(shí)例，shallow和retained heap分別有多大。如果只是看java的基礎(chǔ)類(lèi)型和framework的類(lèi)，沒(méi)有什么意義，一定要過(guò)濾出自己的類(lèi)型，如下圖

發(fā)現(xiàn)LeakInnerClassActivity產(chǎn)生了9個(gè)實(shí)例，一定是被hold住了。

 

看Dominator Tree

大家來(lái)看這個(gè)圖，左側(cè)是對(duì)象引用關(guān)系，右側(cè)是dominator tree

Note that A, B and C are dominated by a “virtual” root object.
Note that the dominator relationship is transitive;C dominates E which dominates G therefore C also dominates G.
這個(gè)視圖非常強(qiáng)大，它把所有實(shí)例按Retained heap和Shallow heap列出來(lái)；并且，只要展開(kāi)就可以看到這個(gè)實(shí)例所占有的實(shí)例（換句話說(shuō)，如果該對(duì)象被釋放，還會(huì)有哪些對(duì)象被釋放）

使用這個(gè)視圖，可以很方便的追蹤被泄露的內(nèi)存到底是誰(shuí)占用了，更多參考這篇博客

 

對(duì)比heap dumps，可以更快的定位內(nèi)存泄露的位置。操作步驟：

打開(kāi)一個(gè)HPROF文件，切換到histogram視圖
在Navigation View中右鍵點(diǎn)擊histogram，選擇Add to compare basket
打開(kāi)另一個(gè)HPROF文件，并重復(fù)上一個(gè)步驟
對(duì)比兩次heap dumps的內(nèi)容，看下圖，LeakInnerClassActivity的實(shí)例又增加了一個(gè)。而我僅僅是又啟動(dòng)了一次該Activity，所以問(wèn)題顯而易見(jiàn)。

參考：Memory Analysis for Android Applications

 

內(nèi)部類(lèi)怎樣使用才會(huì)產(chǎn)生內(nèi)存泄露，以及由此衍生的AsyncTask、Handler問(wèn)題如何解決？

如果非靜態(tài)內(nèi)部類(lèi)的方法中，有生命周期大于其所在類(lèi)的，那就有問(wèn)題了。比如：AsyncTask、Handler，這兩個(gè)類(lèi)都是方便開(kāi)發(fā)者執(zhí)行異步任務(wù)的，但是，這兩個(gè)都跳出了Activity/Fragment的生命周期?；蛟S，是時(shí)候?qū)W習(xí)Loader了
為什么？因?yàn)榉庆o態(tài)內(nèi)部類(lèi)會(huì)自動(dòng)持有一個(gè)所屬類(lèi)的實(shí)例，如果所屬類(lèi)的實(shí)例已經(jīng)結(jié)束生命周期，但內(nèi)部類(lèi)的方法仍在執(zhí)行，就會(huì)hold其主體。也就使主體不能被釋放，亦即內(nèi)存泄露。
靜態(tài)類(lèi)呢？靜態(tài)類(lèi)編譯后和非內(nèi)部類(lèi)是一樣的，有自己獨(dú)立的類(lèi)名。不會(huì)悄悄引用所屬類(lèi)的實(shí)例，所以就不容易泄露。

//首先，靜態(tài)類(lèi)
static class IncomingHandler extends Handler {
 //其次，弱引用
    private final WeakReference mService;
        IncomingHandler(UDPListenerService service) {
        mService = new WeakReference<UDPListenerService>(service);
    }
    @Override
    public void handleMessage(Message msg) {
        UDPListenerService service = mService.get();
        if (service != null) {
            service.handleMessage(msg);
        }
    }
}

 

圖片導(dǎo)致的OOM如何解決？

加載時(shí)使用option，用多大，載入多大。
res目錄下的圖片也是一樣，及時(shí)清理過(guò)大的圖片資源。
如果還有問(wèn)題，就想辦法把不可見(jiàn)的資源釋放掉，比如，TabActivity中不可見(jiàn)的Tab，ViewPager中的Fragment。
如果activity的圖片資源較多，需要考慮屏幕旋轉(zhuǎn)時(shí)，銷(xiāo)毀已有資源。請(qǐng)參考這篇文章

 

需要context的時(shí)候用activity還是application？

看使用的周期是否在activity周期內(nèi)，如果超出，必須用application；常見(jiàn)的情景包括：AsyncTask，Thread，第三方庫(kù)初始化等等。
還有些情景，只能用activity：比如，對(duì)話框，各種View，需要startActivity的等。
總之，盡可能使用Application。參考stackoverflow

 

什么時(shí)候需要手動(dòng)將變量設(shè)置為NULL？

類(lèi)變量，一旦用完，盡快釋放。因?yàn)轭?lèi)的存活時(shí)間最長(zhǎng)，所以，占用的資源越少越好；
比較耗時(shí)且耗內(nèi)存的方法內(nèi)的局部變量，比如，圖片處理的方法，每個(gè)bitmap對(duì)象用完就及時(shí)丟棄。盡可能讓gc介入。
參考：http://kohlerm.blogspot.com/