快捷導(dǎo)航

Android內(nèi)存泄漏終極解決篇（上）

更新時間：2016年01月12日 09:33:41 作者：Huang_Cai_Yuan

這篇文章主要為大家介紹了Android內(nèi)存泄漏的相關(guān)資料，重點(diǎn)介紹了內(nèi)存泄漏的檢查工具Heap和內(nèi)存泄漏的分析工具M(jìn)AT，感興趣的小伙伴們可以參考一下

一、概述
在Android的開發(fā)中，經(jīng)常聽到“內(nèi)存泄漏”這個詞?！皟?nèi)存泄漏”就是一個對象已經(jīng)不需要再使用了，但是因為其它的對象持有該對象的引用，導(dǎo)致它的內(nèi)存不能被回收?！皟?nèi)存泄漏”的慢慢積累，最終會導(dǎo)致OOM的發(fā)生，千里之堤，毀于蟻穴。所以在寫代碼的過程中，應(yīng)該要注意規(guī)避會導(dǎo)致“內(nèi)存泄漏”的代碼寫法，提高軟件的健壯性。
本文將從發(fā)現(xiàn)問題、解決問題、總結(jié)問題的三個角度出發(fā)，循序漸進(jìn)，徹底解決“內(nèi)存泄漏”的問題。

二、內(nèi)存泄漏的檢查工具Heap

工欲善其事必先利其器，要檢測“內(nèi)存泄漏”的發(fā)生，需要借助DDMS中的Heap工具及MAT工具，Heap工具用于大致分析是否存在“內(nèi)存泄漏”，而MAT工具則用于分析“內(nèi)存泄漏”發(fā)生在哪里。

Heap工具的使用介紹

這里寫圖片描述

具體操作

1.在Devices設(shè)備列表中，找到你所在的設(shè)備，點(diǎn)擊你想要監(jiān)控的進(jìn)程。
2.點(diǎn)擊“Update Heap”按鈕更新堆內(nèi)存的情況。
3.點(diǎn)擊“Heap”視圖，查看內(nèi)存的情況。
4.每次在Activity的退出和進(jìn)入的時候點(diǎn)擊“Cause GC”，手動調(diào)用GC釋放應(yīng)用的內(nèi)存。
5.觀察data oject那一行，每一次點(diǎn)擊“Casue GC”的時候，觀察Total Size的值，如果該值不斷增加，則說明該應(yīng)用程序存在“內(nèi)存泄漏”。

我們先模擬一下內(nèi)存泄漏，然后通過Heap工具來判斷一下是否存在內(nèi)存泄漏。
上一段存在內(nèi)存泄漏的代碼：

public class LeakAty extends Activity {

 @Override
 protected void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  setContentView(R.layout.aty_leak);
  testLeak();

 }

 /**
  * 測試內(nèi)存泄漏的代碼
  */
 private void testLeak() {
  new Thread(new Runnable() {

   @Override
   public void run() {
    while (true) {
     try {
      Thread.sleep(1000);
     } catch (InterruptedException e) {
      e.printStackTrace();
     }
    }
   }
  }).start();
 }

上述的代碼存在內(nèi)存泄漏，new Runnable(){}是一個非靜態(tài)的匿名內(nèi)部類，所以它會強(qiáng)引用創(chuàng)建它的外圍對象LeakAty，我們來測試一下內(nèi)存泄漏的過程，開啟手機(jī)的方向旋轉(zhuǎn)功能，不斷地旋轉(zhuǎn)手機(jī)，讓LeakAty不斷地創(chuàng)建新的實例。理論上如果不存在上述泄漏的代碼，之前的Activity會在onDestory之后被回收內(nèi)存。而一旦存在上述泄漏的代碼，新創(chuàng)建的Ruannale實例會一直處于運(yùn)行狀態(tài)，它不會被回收，而它強(qiáng)引用的LeakAty當(dāng)然也不會被回收，所以在屏幕不斷旋轉(zhuǎn)，之前創(chuàng)建的LeakAty就不會被釋放，會導(dǎo)致旋轉(zhuǎn)n次，內(nèi)存中就存在n+1個的LeakAty實例。
Heap工具第一次按下Cause GC按鈕的截圖:

這里寫圖片描述

上圖的data object的Total Size的大小為1.031M。經(jīng)過多次的旋轉(zhuǎn)屏幕之后，我們再看一下截圖

這里寫圖片描述

Total Size變成了2.059M，從1.031M到2.059M，每次調(diào)用GC的過程中data object的總大小沒有回落，所以可以證實上面的代碼確實是存在內(nèi)存泄漏的問題，那么泄漏發(fā)生在哪里？答案可以通過MAT工具來分析得到。

三、內(nèi)存泄漏的分析工具M(jìn)AT

要通過MAT分析，需要提供一個.hprof文件。我們可以通過”Dump HPROF file”按鈕轉(zhuǎn)存當(dāng)前的堆內(nèi)存信息。我們將其保存為1.hprof。

這里寫圖片描述

導(dǎo)出的1.hprof的格式需要通過..\sdk\tools\目錄下的hprof-conv.exe工具進(jìn)行轉(zhuǎn)換才能被MAT成功導(dǎo)入，我們將其轉(zhuǎn)換成out1.hprof
這里寫圖片描述

將out1.hprof導(dǎo)入到MAT工具中,File->Open Heap Dump…

這里寫圖片描述

點(diǎn)擊左邊的標(biāo)簽Overview,Actions->Histogram

這里寫圖片描述

在Histogram界面中，因為我們想要知道Activity是否泄漏了，所以輸入關(guān)鍵詞Activity,然后按下回車鍵。

這里寫圖片描述

之后便可以得到Activity的相關(guān)的搜索結(jié)果,下圖的搜索結(jié)果中Activity的實例有7個。點(diǎn)擊選中下圖標(biāo)紅色框框的地方，右鍵->Merge Shortest Paths to GC Roots->exclude all phantom/weak/soft etc. references。排除虛引用、弱引用、軟引用的實例，剩下的都是強(qiáng)引用實例。

這里寫圖片描述

從過濾出來的強(qiáng)引用的列表中，我們可以看到這七個實例都是被Thread所引用了。所以證實上面的代碼確實存在內(nèi)存泄漏。

這里寫圖片描述

四、本文總結(jié)

內(nèi)存泄漏檢測可以使用Heap工具，內(nèi)存分析可以使用MAT工具。本文的案例中提到了一種內(nèi)存泄漏的情況，就是非靜態(tài)內(nèi)部類的對象會強(qiáng)引用其外圍對象，一旦這個非靜態(tài)內(nèi)部類的實例沒有釋放，它的外圍對象也不會釋放，所以就會造成內(nèi)存泄漏。下篇將具體探討一下，在Android的開發(fā)過程中，哪些寫法容易造成內(nèi)存泄漏，該如何解決？請閱讀Android內(nèi)存泄漏終極解決篇（下）。

以上就是本文的全部內(nèi)容，希望大家喜歡。

您可能感興趣的文章: