前言
記憶體問題對于Android開發者是永遠的痛。如果一個android程式員說他沒有遇到過OutOfMemory，那隻能說他絕對不是做Android的。以往在ADT年代，都是使用eclipse的Mat(http://www.eclipse.org/mat/)插件來做記憶體分析。在使用了Android Studio開發後，發現AS不僅帶來了不少編碼上的便利，同時還帶來了很多有用的工具。其中的記憶體分析工具就是一個經典。
正文
打開AS，在底部的Android Monitor裡面就能發現這個Memory的Tab，在裡面可以實時的看到記憶體的走勢，能夠在自測中發現什麼地方會造成記憶體暴增，同時也很容易的看出GC point（記憶體突然下降一大截，肯定就是做了Full GC）。
看到右邊有4個按鈕，第一個是暫停，暫時不做任何講解了。下面詳細講解其他三個按鈕的功能。
Initial GC
這個指令會讓APP執行一次Full GC。這個功能使用場景不是很多，我一般是會在Dump Heap之前執行一次，這樣會減少很多無用的對象。點選之後，有時候能夠明顯看出記憶體變化
Dump Java Heap
這個功能是我用得最多，也是認為最好用的記憶體分析功能。因為基本能夠通過它觀察出哪些對象占用了巨量記憶體，并且能夠找出它們被什麼對象把持住，導緻無法釋放。點選Dump Java Heap後，APP會Freeze住。然後就是等待，這個時候最好别做其他事情，否則可能失敗。大概幾十秒後，就會進入讀取hprof檔案的界面了。
從途中可以基本看出來，有一個10Mac大小的Bitmap被gpuimage裡面的子產品把持住了(由于被混淆，是以類名是f)。通過這些資訊，基本就可以解決絕大部分OOM問題了。
Start Allocation Tracking
這個功能可以記錄一段區間内各個線程各個方法的記憶體配置設定情況。我用得并不多，主要用于調試在複雜系統裡面短時間記憶體暴增造成GC頻繁的Case。使用方法：先點選一次，然後會看到Memory Recorder開始轉動，然後自己開始在APP上面做相應的操作。在合适的時間再點一次，結束記錄。
然後APP會Freeze，過一會兒就會進入到alloc檔案的打開界面了。通過分析alloc資料，我們可以知道某一個thread裡面的所有的調用過的方法所配置設定的堆大小，通過這些資料可以讓我們針對方法級别堆程式進行優化。
題外話
除了即時Dump即時檢視，我們也可以用AS直接打開.hprof和.alloc檔案，十分友善打開一些其他人員（比如QA）Dump出來的Heap dump。
此外，這些工具雖然在以前的DDMS裡面也帶了，但是個人覺得在AS裡面進行了一些Improvement，界面十分簡潔，關鍵資料一目了然。基本能夠滿足日常生産需求了。但是如果要做更加深入的分析，還是需要借助外部工具，AS裡面帶的hprof檢視工具遠沒有MAT的資料詳細，隻是提供了一些關鍵資料。