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