內存溢出，是Android開發中常遇到的問題，解決起來總是摸不着頭腦。今天爬爬就來講講如何定位內存溢出。
1.OOM（內存溢出）和Memory Leak（內存泄露）有什麼關係？
OOM可能是因爲Memory Leak，也可能是你的應用本身就比較耗內存（比如圖片瀏覽型的，或者應用本身的設計有問題）。所以，出現OOM不一定是Memory Leak。
同樣，Memory Leak也不一定就會導致OOM，如果泄露的速度很慢，可能還沒用完可用內存應用就被重啓了，那就不會OOM咯。當然了，有bug解決了最好。
-
什麼是shallow heap與retained heap？
• shallow heap：你自身佔了多少內存，比如你有一個int屬性，就佔4字節。不包括你引用的其他對象。
• retained heap：如果你被銷燬，總共會釋放多少內存。這些因你存在被佔據的空間就是retained heap。
• 更詳細的解釋請看這篇博客 -
什麼是GC roots？
GC的時候，是從這些節點開始遍歷，不停的尋找其子節點直到結束。然後把不能遍歷到的節點釋放。這些遍歷的起點（注意，可不是一個哦）就叫做GC roots。
那，對於java來說，誰是GC roots？簡單點說（不是那麼準確）包括以下幾種：
• 棧上面的局部變量
• 棧上面的函數參數變量
• 所有由Bootstrap Loader加載的類變量
• 另外，JNI相關的也會有
• 更多詳細解釋請看這篇博客
其實到最後，誰是GC roots不是那麼重要，因爲一般來說，到最後就剩下一些系統框架類，以及jvm和class相關的東西。這裏給大家說GC roots主要是因爲使用mat需要了解它。
- 怎樣使用MAT定位內存泄露？
4.1 看Histogram(類統計圖)
histogram視圖顯示了每個類有多少實例，並可以按照這些實例佔據的Retained size和Shallow size排序。通過過濾包名，很容易發現有問題的類。
這裏有幾個簡單的原則，比如，activity的實例通常只應該有一個。已經關閉的activity不應該出現。實體類的Retained size應該是比較小的，也就幾十KB。
對於Android程序來說，內存泄露通常都會牽扯到activity。因此，dump之前，可以多旋轉幾次屏幕並反覆的進出可能有問題的activity，讓問題儘可能的凸現。
通過Histogram我們可以看每個類有多少個實例，shallow和retained heap分別有多大。如果只是看java的基礎類型和framework的類，沒有什麼意義，一定要過濾出自己的類型，如下圖
發現LeakInnerClassActivity產生了9個實例，一定是被hold住了。
4.2 看Dominator Tree
大家來看這個圖，左側是對象引用關係，右側是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.
這個視圖非常強大，它把所有實例按Retained heap和Shallow heap列出來；並且，只要展開就可以看到這個實例所佔有的實例（換句話說，如果該對象被釋放，還會有哪些對象被釋放）
使用這個視圖，可以很方便的追蹤被泄露的內存到底是誰佔用了，更多參考這篇博客
4.3 對比heap dumps，可以更快的定位內存泄露的位置。操作步驟：
• 打開一個HPROF文件，切換到histogram視圖
• 在Navigation View中右鍵點擊histogram，選擇Add to compare basket
• 打開另一個HPROF文件，並重復上一個步驟
• 對比兩次heap dumps的內容，看下圖，LeakInnerClassActivity的實例又增加了一個。而我僅僅是又啓動了一次該Activity，所以問題顯而易見。
參考：Memory Analysis for AndroidApplications
- 內部類怎樣使用纔會產生內存泄露，以及由此衍生的AsyncTask、Handler問題如何解決？
• 如果非靜態內部類的方法中，有生命週期大於其所在類的，那就有問題了。比如：AsyncTask、Handler，這兩個類都是方便開發者執行異步任務的，但是，這兩個都跳出了Activity/Fragment的生命週期。或許，是時候學習Loader了
• 爲什麼？因爲非靜態內部類會自動持有一個所屬類的實例，如果所屬類的實例已經結束生命週期，但內部類的方法仍在執行，就會hold其主體。也就使主體不能被釋放，亦即內存泄露。
• 靜態類呢？靜態類編譯後和非內部類是一樣的，有自己獨立的類名。不會悄悄引用所屬類的實例，所以就不容易泄露。
[mw_shl_code=java,true]//首先，靜態類
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);
}
}
}[/mw_shl_code]
6. 圖片導致的OOM如何解決？ • 加載時使用option，用多大，載入多大。
• res目錄下的圖片也是一樣，及時清理過大的圖片資源。
• 如果還有問題，就想辦法把不可見的資源釋放掉，比如，TabActivity中不可見的Tab，ViewPager中的Fragment。
• 如果activity的圖片資源較多，需要考慮屏幕旋轉時，銷燬已有資源。請參考這篇文章
-
需要context的時候用activity還是application？ • 看使用的週期是否在activity週期內，如果超出，必須用application；常見的情景包括：AsyncTask，Thread，第三方庫初始化等等。
• 還有些情景，只能用activity：比如，對話框，各種View，需要startActivity的等。
• 總之，儘可能使用Application。參考stackoverflow -
什麼時候需要手動將變量設置爲NULL？ • 類變量，一旦用完，儘快釋放。因爲類的存活時間最長，所以，佔用的資源越少越好；
• 比較耗時且耗內存的方法內的局部變量，比如，圖片處理的方法，每個bitmap對象用完就及時丟棄。儘可能讓gc介入。