android 快速定位記憶體洩露位置技巧

衆所周知，android有垃圾回收機制，在android開發過程中我們不需要去關注記憶體問題，但是在某些情況下還是會出現記憶體洩露，在我的工作過程中出現記憶體洩露的主要原因是因為static變量引起的，然後static變量和其他變量進行互相引用，最終引用到了activity，是以會導緻activity退出了但是不能被銷毀,進而activity中的view和圖檔也不能被銷毀，極大的消耗了系統記憶體．經過查找資料和自我分析，個人得出一下分析技巧(以樂視TV版為例，感覺很實用):

利用到的工具和指令如下:

1.adb shell dumpsys meminfo  com.letv.tv

2.Mat工具(Memory analysis tool)

分析過程:

首先打開TV版應用，随機打開幾個頁面，然後回到首頁，在利用ddms進行手動gc一下，然後利用adb shell dumpsys..這個指令得到如下資訊

Applications Memory Usage (kB):

Uptime: 2667972 Realtime: 2667972

** MEMINFO in pid 31769 [com.letv.tv] **

                         Shared  Private     Heap     Heap     Heap

                   Pss    Dirty    Dirty     Size    Alloc     Free

                ------   ------   ------   ------   ------   ------

       Native        0        0        0    10520     9999      124

       Dalvik    70818     4564    70692    67984    65377     2607

        Stack       32        4       32                           

       Cursor        0        0        0                           

       Ashmem        0        0        0                           

    Other dev        4       36        0                           

     .so mmap     3793     2936     2548                           

    .jar mmap        0        0        0                           

    .apk mmap      271        0        0                           

    .ttf mmap       52        0        0                           

    .dex mmap     4076        4       24                           

   Other mmap     1457        8        8                           

      Unknown     7172      396     7164                           

        TOTAL    87675     7948    80468    78504    75376     2731

 Objects

               Views:     2091         ViewRootImpl:        1

         AppContexts:        5           Activities:        1

              Assets:        2        AssetManagers:        2

       Local Binders:       17        Proxy Binders:       28

    Death Recipients:        4

     OpenSSL Sockets:        1

 SQL

         MEMORY_USED:      108

  PAGECACHE_OVERFLOW:       24          MALLOC_SIZE:       62

 DATABASES

      pgsz     dbsz   Lookaside(b)          cache  Dbname

         4       20             97         4/19/5  /data/data/com.letv.tv/databases/letv.sqlite

我們主要看activities這個數值，如果activity的數量大于1，就存在activity記憶體洩露，我們可以看到目前隻有一個activity存在，是以就不存在activity的洩露．如果存在，我們就利用ddms擷取hprof檔案，然後經過android　sdk中的工具進行轉換，得到可以用mat打開的hprof檔案，然後過濾出activity對象，然後得到引用路徑，一步步查找即可得到記憶體洩露的真正原因．