在程序運行過程中，有時會發生內存泄漏的問題，導致程序卡頓或者卡死。
內存泄漏？
簡單的說，內存泄漏表示的是不再用到的對象因為被錯誤引用而無法進行回收。
內存管理是一件很復雜的事情，三言兩語也解釋不清楚，所以這里我就簡單的說兩句。
為什么內存泄漏會導致程序卡死出現呢？
這是因app運行的時候，手機要給app分配一定的內存來運行。而在這些內存中，app又要給它內部需要的或者創建的對象分配內存，但對象使用完之后，手機會自動的回收不用的對象說占用的內存，達到資源利用以便于再次分配內存。
但是如果不用的對象沒有得到回收，但無效對象越積越多，所占用的內存也越來越多，導致手機分配給app的內存不夠用，但是app又需要內存來提供給它必須運行的對象時，這時便會導致程序卡死或崩潰出現。
所以使用內存管理分析工具來分析android project的內存使用情況是非常有必要的，這可以達到合理分析系統內存，也可以提前避開導致系統崩潰的問題的發生。
內存管理分析工具
android studio里面內置了三個內存工具：
Memory Monitor；
Application tracker;
Heap Viewer;
Memory Monitor
Memory Monitor使用比較簡單，在程序運行的時候，它會直接顯示app的內存使用情況，一般是一條平線，但當內存分配或者進行GC回收的時候，便會出線波形，這時你就能知道大致是哪里出現了內存使用回收，然后找到執行的內進行分析。
舉個例子，現在我們有個按鈕點擊事件，點擊按鈕之后便會創建1000個矩形和輸出1000條語句，代碼如下
private void startAllocationLargeNumbersOfObjects() {
Toast.makeText(this, "請注意查看MemoryMonitor 以及AllocationTracker", Toast.LENGTH_SHORT).show();
for (int i = 0; i < 10000; i++) {
Rect rect = new Rect(0, 0, 100, 100);
System.out.println("-------: " + rect.width());
}
}
當我們點擊之后，Memory Monitor出現下面箭頭的現象，表示使用的內存急劇增加
當我們把代碼修改成下面的樣子，將輸出語句刪除之后：
private void startAllocationLargeNumbersOfObjects() {
Toast.makeText(this, "請注意查看MemoryMonitor 以及AllocationTracker", Toast.LENGTH_SHORT).show();
Rect rect = new Rect(0, 0, 100, 100);
for (int i = 0; i < 10000; i++) {
if (rect == null) {
rect = new Rect(0, 0, 100, 100);
} else {
rect.bottom = 100;
rect.right = 100;
}
}
}
}
再次點擊事件時，Memory Monitor并沒有明顯的急劇增加
Application tracker
Application tracker是android studio的一個內存分配跟蹤器，使用之后能夠了解在一定時間內的內存分配情況，但是使用這個功能相對復雜。
我們再次以使用上面有問題的startAllocationLargeNumbersOfObjects()方法舉例
如下圖，在點擊紅色方框之后，再次點擊，停止跟蹤內存分配之后會彈出一個跟蹤情況報告
我們再次以使用上面有問題的startAllocationLargeNumbersOfObjects()方法舉例
內存跟蹤報告
選擇上面的Group by Allocator用內存分配器來分類我們的內存分配 ，這時我們能夠查看到按包名分配的內存，右邊的count表示分配了多少次內存，size表示分配的內存大小。當我們一直往下級點開始，便會發現每個對象分配的內存大小。
Heap Viewer
最后我們來看Heap Viewer，這是用來實時查看App分配的內存大小和空閑內存大小，但這個功能只限于Android5.0以上。
分析圖如下
那么如何檢測呢？Heap Viewer中的數值會自動在每次發生GC時會自動更新，那么我們是等著他自己GC么？小弟不才，剛開始我就是這么一直等啊等，由于GC的時機是系統把握的，所以很不好把握，既然我們是來看內存泄漏，那么我們在需要檢測內存泄漏的用例執行過后，手動GC下，然后觀察data object
一欄的total size
(也可以觀察Heap Size/Allocated內存的情況)，看看內存是不是會回到一個穩定值，多次操作后，只要內存是穩定在某個值，那么說明沒有內存溢出的，如果發現內存在每次GC后，都在增長，不管是慢增長還是快速增長，都說明有內存泄漏的可能性。
另外還有一個內存檢測神器LeakCanary
這是一個是一個開源的在debug版本中檢測內存泄漏的java庫。
github地址：https://github.com/square/leakcanary
使用之后能夠直接在手機或者虛擬機發生明顯的內存泄漏之后彈出通知欄，告知在哪個類中出現問題。
下圖的例子是因為一個static靜態的TextView在所在的Activity被銷毀時沒有被回收而引起的，只要把TextView前的static去掉就可以了。
檢查內存泄漏是一件非常復雜的事情，通常情況下只能依靠人工排查，有一定經驗的開發者能夠比較快速的檢查出問題，而剛開始學習的開發者依靠工具和細心也是能夠找到問題所在的。
本文中所舉出的例子源代碼鏈接如下。
https://github.com/lzyzsd/MemoryBugs
例子中有幾處存在內存泄漏隱患的地方
1、在MainActivity中存在靜態的TextView，在結束MainActivity并跳轉到ActivityB時沒有被回收，造成內存泄漏。用LeakCanary能夠直接檢測出來，只需要把TextView變為非靜態就可以了。
2、在startAllocationLargeNumbersOfObjects()方法中，重復的大量的創建Rect()對象，占用了大量的內存。因此只需要在for循環之前創建Rect()對象，在for循環中重新設定Rect的大小和位置就可以。當然，其中的System.out打印出大量的字符串也造成一定的內存泄漏，可以考慮將其放在for循環之外。
3、在MyView類中，在onDraw方法中創建RectF也是不必要的，因為使用onDraw創建對象，相當于每次調用onDraw方法時就要重新創建一個RectF對象，也會造成內存泄漏。因此把創建RectF和Paint對象轉為本地變量即可。
以下是大神寫的關于內存管理工具的具體使用方法鏈接
Memory Monitor
