一.什么是內(nèi)存泄露
內(nèi)存不在GC掌控之內(nèi)了。
當(dāng)一個對象已經(jīng)不需要再使用了，本該被回收時，而有另外一個正在使用的對象持有它的引用從而就導(dǎo)致對象不能被回收。這種導(dǎo)致了本該被回收的對象不能被回收而停留在堆內(nèi)存中，就產(chǎn)生了內(nèi)存泄漏.
1.Android monitors
2.MAT
3.如何找到項目中存在的內(nèi)存泄露的這些地方呢？
1.確定是否存在內(nèi)存泄露
1)Android Monitors的內(nèi)存分析
最直觀的看內(nèi)存增長情況，知道該動作是否發(fā)生內(nèi)存泄露。
動作發(fā)生之前：GC完后內(nèi)存1.4M; 動作發(fā)生之后：GC完后內(nèi)存1.6M
2)使用MAT內(nèi)存分析工具
MAT分析heap的總內(nèi)存占用大小來初步判斷是否存在泄露
Heap視圖中有一個Type叫做data object，即數(shù)據(jù)對象，也就是我們的程序中大量存在的類類型的對象。
在data object一行中有一列是“Total Size”，其值就是當(dāng)前進程中所有Java數(shù)據(jù)對象的內(nèi)存總量，
一般情況下，這個值的大小決定了是否會有內(nèi)存泄漏。
我們反復(fù)執(zhí)行某一個操作并同時執(zhí)行GC排除可以回收掉的內(nèi)存，注意觀察data object的Total Size值，
正常情況下Total Size值都會穩(wěn)定在一個有限的范圍內(nèi)，也就是說由于程序中的的代碼良好，沒有造成對象不被垃圾回收的情況。
反之如果代碼中存在沒有釋放對象引用的情況，隨著操作次數(shù)的增多Total Size的值會越來越大。
那么這里就已經(jīng)初步判斷這個操作導(dǎo)致了內(nèi)存泄露的情況。
2.先找懷疑對象(哪些對象屬于泄露的)
MAT對比操作前后的hprof來定位內(nèi)存泄露是泄露了什么數(shù)據(jù)對象。（這樣做可以排除一些對象，不用后面去查看所有被引用的對象是否是嫌疑）
快速定位到操作前后所持有的對象哪些是增加了(GC后還是比之前多出來的對象就可能是泄露對象嫌疑犯)
技巧：Histogram中還可以對對象進行Group，比如選擇Group By Package更方便查看自己Package中的對象信息。
- MAT分析hprof來定位內(nèi)存泄露的原因所在。(哪個對象持有了上面懷疑出來的發(fā)生泄露的對象)
1）Dump出內(nèi)存泄露“當(dāng)時”的內(nèi)存鏡像hprof，分析懷疑泄露的類；
2）把上面2得出的這些嫌疑犯一個一個排查個遍。步驟：
(1)進入Histogram，過濾出某一個嫌疑對象類
(2)然后分析持有此類對象引用的外部對象（在該類上面點擊右鍵List Objects--->with incoming references）
(3)再過濾掉一些弱引用、軟引用、虛引用，因為它們遲早可以被GC干掉不屬于內(nèi)存泄露
(在類上面點擊右鍵Merge Shortest Paths to GC Roots--->exclude all phantom/weak/soft etc.references)
(4)逐個分析每個對象的GC路徑是否正常
此時就要進入代碼分析此時這個對象的引用持有是否合理，這就要考經(jīng)驗和體力了！
（比如上課的例子中：旋轉(zhuǎn)屏幕后MainActivity有兩個，肯定MainActivity發(fā)生泄露了，
那誰導(dǎo)致他泄露的呢？原來是我們的CommonUtils類持有了旋轉(zhuǎn)之前的那個MainActivity他，
那是否合理？結(jié)合邏輯判斷當(dāng)然不合理，由此找到內(nèi)存泄露根源是CommonUtils類持有了該MainActivity實例造成的。
怎么解決？罪魁禍?zhǔn)渍业搅耍趺唇鉀Q應(yīng)該不難了，不同情況解決辦法不一樣，要靠你的智慧了。）
4.判斷一個應(yīng)用里面內(nèi)存泄露避免得很好，怎么看？
當(dāng)app退出的時候，這個進程里面所有的對象應(yīng)該就都被回收了，尤其是很容易被泄露的（View，Activity）是否還內(nèi)存當(dāng)中。
可以讓app退出以后，查看系統(tǒng)該進程里面的所有的View、Activity對象是否為0.
工具：使用AndroidStudio--AndroidMonitor--System Information--Memory Usage查看Objects里面的views和Activity的數(shù)量是否為0.
