OOM（內(nèi)存溢出）和Memory Leak（內(nèi)存泄露）有什么關(guān)系？
OOM可能是因為Memory Leak，也可能是你的應(yīng)用本身就比較耗內(nèi)存（比如圖片瀏覽型的敷矫，或者應(yīng)用本身的設(shè)計有問題）肉微。所以辽慕，出現(xiàn)OOM不一定是Memory Leak。
同樣续崖，Memory Leak也不一定就會導(dǎo)致OOM敲街，如果泄露的速度很慢，可能還沒用完可用內(nèi)存應(yīng)用就被重啟了严望，那就不會OOM咯。當(dāng)然了逻恐，有bug解決了最好像吻。
什么是shallow heap與retained heap？
shallow heap：你自身占了多少內(nèi)存复隆，比如你有一個int屬性拨匆，就占4字節(jié)。不包括你引用的其他對象挽拂。
retained heap：如果你被銷毀惭每，總共會釋放多少內(nèi)存。這些因你存在被占據(jù)的空間就是retained heap亏栈。
更詳細的解釋請看這篇博客
什么是GC roots台腥？
GC的時候，是從這些節(jié)點開始遍歷绒北，不停的尋找其子節(jié)點直到結(jié)束黎侈。然后把不能遍歷到的節(jié)點釋放。這些遍歷的起點（注意闷游，可不是一個哦）就叫做GC roots峻汉。
那，對于java來說脐往，誰是GC roots休吠？簡單點說（不是那么準(zhǔn)確）包括以下幾種：
棧上面的局部變量
棧上面的函數(shù)參數(shù)變量
所有由Bootstrap Loader加載的類變量
另外，JNI相關(guān)的也會有
更多詳細解釋請看這篇博客
其實到最后业簿，誰是GC roots不是那么重要瘤礁，因為一般來說，到最后就剩下一些系統(tǒng)框架類辖源，以及jvm和class相關(guān)的東西蔚携。這里給大家說GC roots主要是因為使用mat需要了解它。
怎樣使用MAT定位內(nèi)存泄露克饶？
看Histogram(類統(tǒng)計圖)
histogram視圖顯示了每個類有多少實例酝蜒，并可以按照這些實例占據(jù)的Retained size和Shallow size排序。通過過濾包名矾湃，很容易發(fā)現(xiàn)有問題的類亡脑。
這里有幾個簡單的原則，比如，activity的實例通常只應(yīng)該有一個霉咨。已經(jīng)關(guān)閉的activity不應(yīng)該出現(xiàn)蛙紫。實體類的Retained size應(yīng)該是比較小的，也就幾十KB途戒。
對于Android程序來說坑傅，內(nèi)存泄露通常都會牽扯到activity。因此喷斋，dump之前唁毒，可以多旋轉(zhuǎn)幾次屏幕并反復(fù)的進出可能有問題的activity，讓問題盡可能的凸現(xiàn)星爪。
通過Histogram我們可以看每個類有多少個實例浆西，shallow和retained heap分別有多大。如果只是看java的基礎(chǔ)類型和framework的類顽腾，沒有什么意義近零，一定要過濾出自己的類型，如下圖
發(fā)現(xiàn)LeakInnerClassActivity產(chǎn)生了9個實例抄肖，一定是被hold住了久信。
看Dominator Tree
大家來看這個圖，左側(cè)是對象引用關(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.
這個視圖非常強大入篮，它把所有實例按Retained heap和Shallow heap列出來；并且幌甘，只要展開就可以看到這個實例所占有的實例（換句話說潮售，如果該對象被釋放，還會有哪些對象被釋放）
使用這個視圖锅风，可以很方便的追蹤被泄露的內(nèi)存到底是誰占用了酥诽，更多參考這篇博客
對比heap dumps，可以更快的定位內(nèi)存泄露的位置皱埠。操作步驟：
打開一個HPROF文件肮帐，切換到histogram視圖
在Navigation View中右鍵點擊histogram，選擇Add to compare basket
打開另一個HPROF文件边器，并重復(fù)上一個步驟
對比兩次heap dumps的內(nèi)容训枢，看下圖，LeakInnerClassActivity的實例又增加了一個忘巧。而我僅僅是又啟動了一次該Activity恒界，所以問題顯而易見。
參考：Memory Analysis for Android Applications
內(nèi)部類怎樣使用才會產(chǎn)生內(nèi)存泄露砚嘴，以及由此衍生的AsyncTask十酣、Handler問題如何解決涩拙？
如果非靜態(tài)內(nèi)部類的方法中，有生命周期大于其所在類的耸采，那就有問題了兴泥。比如：AsyncTask、Handler虾宇，這兩個類都是方便開發(fā)者執(zhí)行異步任務(wù)的搓彻，但是，這兩個都跳出了Activity/Fragment的生命周期嘱朽『梦ǎ或許，是時候?qū)W習(xí)Loader了
為什么燥翅？因為非靜態(tài)內(nèi)部類會自動持有一個所屬類的實例，如果所屬類的實例已經(jīng)結(jié)束生命周期蜕提，但內(nèi)部類的方法仍在執(zhí)行森书，就會hold其主體。也就使主體不能被釋放谎势，亦即內(nèi)存泄露凛膏。
靜態(tài)類呢？靜態(tài)類編譯后和非內(nèi)部類是一樣的脏榆，有自己獨立的類名猖毫。不會悄悄引用所屬類的實例，所以就不容易泄露须喂。
//首先吁断，靜態(tài)類
staticclassIncomingHandlerextendsHandler?{
//其次，弱引用
privatefinalWeakReference?mService;
IncomingHandler(UDPListenerService?service)?{
mService?=newWeakReference(service);
}
@Override
publicvoidhandleMessage(Message?msg)?{
UDPListenerService?service?=?mService.get();
if(service?!=null)?{
service.handleMessage(msg);
}
}
}
圖片導(dǎo)致的OOM如何解決坞生？
加載時使用option仔役，用多大，載入多大是己。
res目錄下的圖片也是一樣又兵，及時清理過大的圖片資源。
如果還有問題卒废，就想辦法把不可見的資源釋放掉沛厨，比如，TabActivity中不可見的Tab摔认，ViewPager中的Fragment逆皮。
如果activity的圖片資源較多，需要考慮屏幕旋轉(zhuǎn)時级野，銷毀已有資源页屠。請參考這篇文章
需要context的時候用activity還是application粹胯？
看使用的周期是否在activity周期內(nèi)，如果超出辰企，必須用application风纠；常見的情景包括：AsyncTask，Thread牢贸，第三方庫初始化等等竹观。
還有些情景，只能用activity：比如潜索，對話框臭增，各種View，需要startActivity的等竹习。
總之誊抛，盡可能使用Application。參考stackoverflow
什么時候需要手動將變量設(shè)置為NULL整陌？
類變量拗窃，一旦用完，盡快釋放泌辫。因為類的存活時間最長随夸，所以，占用的資源越少越好震放；
比較耗時且耗內(nèi)存的方法內(nèi)的局部變量宾毒，比如，圖片處理的方法殿遂，每個bitmap對象用完就及時丟棄诈铛。盡可能讓gc介入。
