記憶體洩露，這個應用開發中比較容易出現的問題，由於短時間內難以測出來一般都比較難以發現，只能靠開發者的警覺性來避免，長時間的Monkey測試就成為一個可行的手段。

Monkey測試能給出一個直觀的記憶體變化曲線和日誌，GC日誌在記憶體緊張時都會打印出測試程序的記憶體資訊。往往報錯資訊也會指明是 java.lang.OutOfMemoryError但是報這個異常的地方往往並不是記憶體洩露的位置，它只是比較倒黴正好申請記憶體發現不足了。

直接找重點GC日誌類似這樣：

 I art     : Starting a blocking GC Alloc
 I art     : Starting a blocking GC Alloc
 I art     : Waiting for a blocking GC Alloc
 I art     : Alloc sticky concurrent mark sweep GC freed 5223(480KB) AllocSpace objects, 5(100KB) LOS objects, 1% free, 189MB/192MB, paused 2.153ms total 35.644ms
 I art     : WaitForGcToComplete blocked for 21.733ms for cause Alloc
 I art     : Starting a blocking GC Alloc

相信網上解釋這幾句日誌的部落格已經很多了，就是現在已用記憶體189M上限是192M，應用下一次申請超過剩餘操作限制了就OOM了。

首先確認資訊是否符合系統設定

檢視系統設定單個程序的記憶體上限

adb shell
[email protected]:/ # getprop|grep heapgrowthlimit
[dalvik.vm.heapgrowthlimit]: [192m]

沒錯就是配置的192M，你的應用消耗的太多了，肯定是有記憶體洩露了的。

那麼怎麼查詢問題呢，通過這個日誌直接分析不到問題，只能根據日誌看出應用的大致操作流程，不過Monkey幾萬次估計所有邏輯都走到了，還是對整個應用內容的使用情況進行檢查。

Android上應用開發常見的記憶體洩露的型別可以看看大神寫的http://blog.csdn.net/u010687392/article/details/49909477

其實自從Bitmap的記憶體分配到java層之後這一類很容易搞定了，用弱引用的快取直接就安了，這個直接全程式碼搜尋一下挨個改就行了；

其他的同樣顯性的BraodcastReceiver，ContentObserver，File，Cursor，Stream這一類全程式碼搜尋改就行了；

剩下的比較難找的就是Activity的洩露同時也是應用主要的記憶體洩露問題，這個如果對程式碼很熟悉也可以對程式碼中所有的context、handler等搜尋處理，但是如果封裝層次比較深模組程式碼量比較大的情況下，會花費較長的時間。

首先可以用adb shell dumpsys meminfo package name看看當前程序的記憶體使用情況

Applications Memory Usage (kB):
Uptime: 774504 Realtime: 774504


** MEMINFO in pid 5592 [package namer] **
                   Pss  Private  Private  Swapped     Heap     Heap     Heap
                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
                ------   ------   ------   ------   ------   ------   ------
  Native Heap     9076     8980        0        0    12776    12483      292
  Dalvik Heap    12276    12200        0        0    14499    13738      761
 Dalvik Other      956      956        0        0
        Stack      328      328        0        0
      Gfx dev     3926     3056        0        0
    Other dev        5        0        4        0
     .so mmap     2320      464       60        0
    .apk mmap      136        0       16        0
    .ttf mmap      346        0      204        0
    .dex mmap     2524        0     2520        0
    .oat mmap     4493        0     1756        0
    .art mmap     2465     1196      628        0
   Other mmap       51        4       40        0
   EGL mtrack    28224    28224        0        0
      Unknown      233      232        0        0
        TOTAL    67359    55640     5228        0    27275    26221     1053


 Objects
               Views:      271         ViewRootImpl:        1
         AppContexts:        7           Activities:        1
              Assets:        3        AssetManagers:        3
       Local Binders:       22        Proxy Binders:       32
       Parcel memory:        8         Parcel count:       34
    Death Recipients:        0      OpenSSL Sockets:        0


 SQL
         MEMORY_USED:     1206
  PAGECACHE_OVERFLOW:      946          MALLOC_SIZE:       62


 DATABASES
      pgsz     dbsz   Lookaside(b)          cache  Dbname
         1     1673            281     834/125/25  /data/data/package name/databases/sqlit.db

如果此時這裡的Activities與目前應用的執行狀態不一致，比如目前退出了應該為零但是這裡還有數值，很顯然就是有Context洩露了（其實這裡還能看到很多其他記憶體資料），這時候就可以使用MAT工具進行分析。

先生成一個hprof檔案，然後用MAT工具開啟，直接在總覽介面選擇

Histogram: Lists number of instances per class

這時會將所有當前物件及其數量Heap大小一起列出來，非常的多，可以直接輸入Activity或者其他關鍵字進行搜尋。

如果其中的Objects數目與當前應用執行情況不一致就是有問題的地方。

在此條記錄上右鍵選擇Merge Shortest Paths to GC Roots --> with all references就可以列出當前物件到GC Root之間的最短引用鏈，找到並打斷這個引用關係就是我們工作

這個栗子由於專案關係就不能貼上具體程式碼和截圖了，最終是在一個單例中發現了一個HashMap引用了一系列的Context在裡面。

好了，分析完畢，為了最小的改動，直接將HashMap修改成WeakHashMap，這個東西是在檢測到某個key值沒有被引用的情況下會回收掉entry，最後檢查一下它的get方法如果為空會不會有問題，看一遍沒有問題。

問題解決，雖然看起來分析的很愉快，但是在專案的關鍵時期大半夜看這個還是很傷的，開發者還是需要在寫程式碼的時候就注意記憶體洩露的問題，尤其是Context的使用，沒事多用Application的Context，實在不行也要注意及時主動置空和弱引用。