尊重原創作者，轉載請註明出處：

首先了解一下dalvik的Garbage Collection：

如上圖所示，GC會選擇一些它瞭解還存活的物件作為記憶體遍歷的根節點（GC Roots），比方說thread stack中的變數，JNI中的全域性變數，zygote中的物件（class loader載入）等，然後開始對heap進行遍歷。到最後，部分沒有直接或者間接引用到GC Roots的就是需要回收的垃圾，會被GC回收掉。如下圖藍色部分。

Java記憶體洩漏指的是程序中某些物件（垃圾物件）已經沒有使用價值了，但是它們卻可以直接或間接地引用到gc roots導致無法被GC回收。無用的物件佔據著記憶體空間，使得實際可使用記憶體變小，形象地說法就是記憶體洩漏了。下面分析一些可能導致記憶體洩漏的情景。

常見的記憶體洩漏

 1、非靜態內部類的靜態例項容易造成記憶體洩漏

public class MainActivityextends Activity
{
         static Demo sInstance = null;
        
    @Override
    public void onCreate(BundlesavedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        if (sInstance == null)
        {
           sInstance= new Demo();
        }
    }
    class Demo
    {
    voiddoSomething()
    {
               System.out.print("dosth.");
    }
    }
}
 

上面的程式碼中的sInstance例項型別為靜態例項，在第一個MainActivity act1例項建立時，sInstance會獲得並一直持有act1的引用。當MainAcitivity銷燬後重建，因為sInstance持有act1的引用，所以act1是無法被GC回收的，程序中會存在2個MainActivity例項（act1和重建後的MainActivity例項），這個act1物件就是一個無用的但一直佔用記憶體的物件，即無法回收的垃圾物件。所以，對於lauchMode不是singleInstance的Activity， 應該避免在activity裡面例項化其非靜態內部類的靜態例項。

2、activity使用靜態成員

private static Drawable sBackground;  
@Override  
protected void onCreate(Bundle state) {  
    super.onCreate(state);  
  
    TextView label = new TextView(this);  
    label.setText("Leaks are bad");  
  
    if (sBackground == null) {  
        sBackground = getDrawable(R.drawable.large_bitmap);  
    }  
    label.setBackgroundDrawable(sBackground);  
  
    setContentView(label);  
} 

由於用靜態成員sBackground 快取了drawable物件，所以activity載入速度會加快，但是這樣做是錯誤的。因為在android 2.3系統上，它會導致activity銷燬後無法被系統回收。

label .setBackgroundDrawable函式呼叫會將label賦值給sBackground的成員變數mCallback。

上面程式碼意味著：sBackground（GC Root）會持有TextView物件，而TextView持有Activity物件。所以導致Activity物件無法被系統回收。

下面看看android4.0為了避免上述問題所做的改進。

先看看android 2.3的Drawable.Java對setCallback的實現：

    public final void setCallback(Callback cb){

        mCallback = cb;

}

再看看android 4.0的Drawable.Java對setCallback的實現：

    public final void setCallback(Callback cb){

        mCallback = newWeakReference<Callback> (cb);

}

在android 2.3中要避免記憶體洩漏也是可以做到的, 在activity的onDestroy時呼叫

sBackgroundDrawable.setCallback(null)。

以上2個例子的記憶體洩漏都是因為Activity的引用的生命週期超越了activity物件的生命週期。也就是常說的Context洩漏，因為activity就是context。

想要避免context相關的記憶體洩漏，需要注意以下幾點：

·不要對activity的context長期引用(一個activity的引用的生存週期應該和activity的生命週期相同)

·如果可以的話，儘量使用關於application的context來替代和activity相關的context

·如果一個acitivity的非靜態內部類的生命週期不受控制，那麼避免使用它；正確的方法是使用一個靜態的內部類，並且對它的外部類有一WeakReference，就像在ViewRootImpl中內部類W所做的那樣。

3、使用handler時的記憶體問題

我們知道，Handler通過傳送Message與其他執行緒互動，Message發出之後是儲存在目標執行緒的MessageQueue中的，而有時候Message也不是馬上就被處理的，可能會駐留比較久的時間。在Message類中存在一個成員變數 target，它強引用了handler例項，如果Message在Queue中一直存在，就會導致handler例項無法被回收，如果handler對應的類是非靜態內部類 ，則會導致外部類例項（Activity或者Service）不會被回收，這就造成了外部類例項的洩露。 所以正確處理Handler等之類的內部類，應該將自己的Handler定義為靜態內部類，並且在類中增加一個成員變數，用來弱引用外部類例項，如下：

public class OutterClass
{
        ......
        ......
        static class InnerClass
        {
        	private final WeakReference<OutterClass> mOutterClassInstance;
        	......
        	......
        }
}

HandlerThread的使用也需要注意：

  當我們在activity裡面建立了一個HandlerThread，程式碼如下：

public classMainActivity extends Activity
{
    @Override
    public void onCreate(BundlesavedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        Thread mThread = newHandlerThread("demo", Process.THREAD_PRIORITY_BACKGROUND); 
        mThread.start();
MyHandler mHandler = new MyHandler( mThread.getLooper( ) );
…….
…….
…….
}
    @Override
    public void onDestroy()
    {
    super.onDestroy();
    }
}

這個程式碼存在洩漏問題，因為HandlerThread實現的run方法是一個無限迴圈，它不會自己結束，執行緒的生命週期超過了activity生命週期，當橫豎屏切換，HandlerThread執行緒的數量會隨著activity重建次數的增加而增加。

應該在onDestroy時將執行緒停止掉：mThread.getLooper().quit();

另外，對於不是HandlerThread的執行緒，也應該確保activity消耗後，執行緒已經終止，可以這樣做：在onDestroy時呼叫mThread.join();

4、註冊某個物件後未反註冊

註冊廣播接收器、註冊觀察者等等，比如：

假設我們希望在鎖屏介面(LockScreen)中，監聽系統中的電話服務以獲取一些資訊(如訊號強度等)，則可以在LockScreen中定義一個PhoneStateListener的物件，同時將它註冊到TelephonyManager服務中。對於LockScreen物件，當需要顯示鎖屏介面的時候就會建立一個LockScreen物件，而當鎖屏介面消失的時候LockScreen物件就會被釋放掉。

　　但是如果在釋放LockScreen物件的時候忘記取消我們之前註冊的PhoneStateListener物件，則會導致LockScreen無法被GC回收。如果不斷的使鎖屏介面顯示和消失，則最終會由於大量的LockScreen物件沒有辦法被回收而引起OutOfMemory,使得system_process程序掛掉。

雖然有些系統程式，它本身好像是可以自動取消註冊的(當然不及時)，但是我們還是應該在我們的程式中明確的取消註冊，程式結束時應該把所有的註冊都取消掉。

5、集合中物件沒清理造成的記憶體洩露

　　我們通常把一些物件的引用加入到了集合中，當我們不需要該物件時，如果沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。如果這個集合是static的話，那情況就更嚴重了。

比如某公司的ROM的鎖屏曾經就存在記憶體洩漏問題：

這個洩漏是因為LockScreen每次顯示時會註冊幾個callback，它們儲存在KeyguardUpdateMonitor的ArrayList<InfoCallback>、ArrayList<SimStateCallback>等ArrayList例項中。但是在LockScreen解鎖後，這些callback沒有被remove掉，導致ArrayList不斷增大， callback物件不斷增多。這些callback物件的size並不大，heap增長比較緩慢，需要長時間地使用手機才能出現OOM，由於鎖屏是駐留在system_server程序裡，所以導致結果是手機重啟。

6、資源物件沒關閉造成的記憶體洩露

　　資源性物件比如(Cursor，File檔案等)往往都用了一些緩衝，我們在不使用的時候，應該及時關閉它們，以便它們的緩衝及時回收記憶體。它們的緩衝不僅存在於Java虛擬機器內，還存在於Java虛擬機器外。如果我們僅僅是把它的引用設定為null,而不關閉它們，往往會造成記憶體洩露。因為有些資源性物件，比如SQLiteCursor(在解構函式finalize(),如果我們沒有關閉它，它自己會調close()關閉)，如果我們沒有關閉它，系統在回收它時也會關閉它，但是這樣的效率太低了。因此對於資源性物件在不使用的時候，應該立即呼叫它的close()函式，將其關閉掉，然後再置為null.在我們的程式退出時一定要確保我們的資源性物件已經關閉。

　　程式中經常會進行查詢資料庫的操作，但是經常會有使用完畢Cursor後沒有關閉的情況。如果我們的查詢結果集比較小，對記憶體的消耗不容易被發現，只有在長時間大量操作的情況下才會復現記憶體問題，這樣就會給以後的測試和問題排查帶來困難和風險。

7、一些不良程式碼成記憶體壓力

有些程式碼並不造成記憶體洩露，但是它們或是對沒使用的記憶體沒進行有效及時的釋放，或是沒有有效的利用已有的物件而是頻繁的申請新記憶體，對記憶體的回收和分配造成很大影響的，容易迫使虛擬機器不得不給該應用程序分配更多的記憶體，增加vm的負擔，造成不必要的記憶體開支。

7.1，Bitmap使用不當

    第一、及時的銷燬。

    雖然，系統能夠確認Bitmap分配的記憶體最終會被銷燬，但是由於它佔用的記憶體過多，所以很可能會超過Java堆的限制。因此，在用完Bitmap時，要及時的recycle掉。recycle並不能確定立即就會將Bitmap釋放掉，但是會給虛擬機器一個暗示：“該圖片可以釋放了”。

    第二、設定一定的取樣率。

    有時候，我們要顯示的區域很小，沒有必要將整個圖片都加載出來，而只需要記載一個縮小過的圖片，這時候可以設定一定的取樣率，那麼就可以大大減小佔用的記憶體。如下面的程式碼：

private ImageView preview;  
BitmapFactory.Options options = newBitmapFactory.Options();  
options.inSampleSize = 2;//圖片寬高都為原來的二分之一，即圖片為原來的四分之一  
Bitmap bitmap =BitmapFactory.decodeStream(cr.openInputStream(uri), null, options); preview.setImageBitmap(bitmap); 

第三、巧妙的運用軟引用（SoftRefrence）

有些時候，我們使用Bitmap後沒有保留對它的引用，因此就無法呼叫Recycle函式。這時候巧妙的運用軟引用，可以使Bitmap在記憶體快不足時得到有效的釋放。如下：

SoftReference<Bitmap>  bitmap_ref  = new SoftReference<Bitmap>(BitmapFactory.decodeStream(inputstream)); 
……
……
if (bitmap_ref .get() != null)
          bitmap_ref.get().recycle();

7.2，構造Adapter時，沒有使用快取的 convertView

　　以構造ListView的BaseAdapter為例，在BaseAdapter中提共了方法：

　　public View getView(intposition, View convertView, ViewGroup parent)

　　來向ListView提供每一個item所需要的view物件。初始時ListView會從BaseAdapter中根據當前的屏幕布局例項化一定數量的view物件，同時ListView會將這些view物件快取起來。當向上滾動ListView時，原先位於最上面的list item的view物件會被回收，然後被用來構造新出現的最下面的list item。這個構造過程就是由getView()方法完成的，getView()的第二個形參 View convertView就是被快取起來的list item的view物件(初始化時快取中沒有view物件則convertView是null)。

　　由此可以看出，如果我們不去使用convertView，而是每次都在getView()中重新例項化一個View物件的話，即浪費時間，也造成記憶體垃圾，給垃圾回收增加壓力，如果垃圾回收來不及的話，虛擬機器將不得不給該應用程序分配更多的記憶體，造成不必要的記憶體開支。ListView回收list item的view物件的過程可以檢視:

　　android.widget.AbsListView.Java--> void addScrapView(View scrap) 方法。

　　Java程式碼：

public View getView(int position, View convertView, ViewGroupparent) {
　　View view = newXxx(...);
　　return view;
　　}

　　修正示例程式碼：

　　Java程式碼：

　　public View getView(intposition, View convertView, ViewGroup parent) {
　　View view = null;
　　if (convertView != null){
　　view = convertView;
　　populate(view, getItem(position));
　　} else {
　　view = new Xxx(...);
　　}
　　return view;
　　}

7.3、不要在經常呼叫的方法中建立物件，尤其是忌諱在迴圈中建立物件。可以適當的使用 hashtable ， vector 建立一組物件容器，然後從容器中去取那些物件，而不用每次 new 之後又丟棄。

關於記憶體洩漏的除錯

(1).記憶體監測工具 DDMS --> Heap
 無論怎麼小心，想完全避免bad code是不可能的，此時就需要一些工具來幫助我們檢查程式碼中是否存在會造成記憶體洩漏的地方。Android tools中的DDMS就帶有一個很不錯的記憶體監測工具Heap(這裡我使用eclipse的ADT外掛，並以真機為例，在模擬器中的情況類似)。用 Heap監測應用程序使用記憶體情況的步驟如下：
1. 啟動eclipse後，切換到DDMS透檢視，並確認Devices檢視、Heap檢視都是開啟的；
2. 將手機通過USB連結至電腦，連結時需要確認手機是處於“USB除錯”模式，而不是作為“MassStorage”；
3. 連結成功後，在DDMS的Devices檢視中將會顯示手機裝置的序列號，以及裝置中正在執行的部分程序資訊；
4. 點選選中想要監測的程序，比如system_process程序；
5. 點選選中Devices檢視介面中最上方一排圖示中的“Update Heap”圖示；
6. 點選Heap檢視中的“Cause GC”按鈕；
7. 此時在Heap檢視中就會看到當前選中的程序的記憶體使用量的詳細情況。
 說明：
a) 點選“Cause GC”按鈕相當於向虛擬機器請求了一次gc操作；
b) 當記憶體使用資訊第一次顯示以後，無須再不斷的點選“CauseGC”，Heap檢視介面會定時重新整理，在對應用的不斷的操作過程中就可以看到記憶體使用的變化；
c) 記憶體使用資訊的各項引數根據名稱即可知道其意思，在此不再贅述。
  如何才能知道我們的程式是否有記憶體洩漏的可能性呢。這裡需要注意一個值：Heap檢視中部有一個Type叫做dataobject，即資料物件，也就是我們的程式中大量存在的類型別的物件。在data object一行中有一列是“Total Size”，其值就是當前程序中所有Java資料物件的記憶體總量，一般情況下，這個值的大小決定了是否會有記憶體洩漏。可以這樣判斷：
a) 不斷的操作當前應用，同時注意觀察data object的Total Size值；
b) 正常情況下Total Size值都會穩定在一個有限的範圍內，也就是說由於程式中的的程式碼良好，沒有造成物件不被垃圾回收的情況，所以說雖然我們不斷的操作會不斷的生成很多物件，而在虛擬機器不斷的進行GC的過程中，這些物件都被回收了，記憶體佔用量會會落到一個穩定的水平；
c) 反之如果程式碼中存在沒有釋放物件引用的情況，則dataobject的Total Size值在每次GC後不會有明顯的回落，隨著操作次數的增多Total Size的值會越來越大，
  直到到達一個上限後導致程序OOM被kill掉。

(2).記憶體分析工具 MAT(Memory Analyzer Tool) 

並不是所有的記憶體洩漏都可以用觀察heap size的方法檢測出來，因為有的程式只是洩漏了幾個物件，而且洩漏的物件個數不會隨著程式的執行而增加，這種記憶體洩漏不會直接導致OOM，但是無用物件無法回收，無疑是對記憶體的浪費，會影響到程式的效能，我們需要使用MAT工具才能發現這種比較隱蔽的記憶體洩漏。
使用MAT之前有2個概念是要掌握的：Shallowheap和Retained heap。Shallow heap表示物件本身所佔記憶體大小，一個記憶體大小100bytes的物件Shallow heap就是100bytes。Retained heap表示通過回收這一個物件總共能回收的記憶體，比方說一個100bytes的物件還直接或者間接地持有了另外3個100bytes的物件引用，回收這個物件的時候如果另外3個物件沒有其他引用也能被回收掉的時候，Retained heap就是400bytes。

MAT使用Dominator Tree這樣一種來自圖形理論的概念。

所謂Dominator，就是Flow Graph中從源節點出發到某個節點的的必經節點。那麼根據這個概念我們可以從上圖左側的Flow Graph構造出右側的Dominator Tree。這樣一來很容易就看出每個節點的Retained heap了。Shallow heap和Retained heap在MAT中是非常有用的概念，用於記憶體洩漏的分析。

我們做一個Demo。在工程的MainActivity當中加入如下程式碼:

publicclassMainActivityextends Activity{
    static Leaky leak=null;
    classLeaky{
        voiddoSomething(){
            System.out.println("Wheee!!!");
        }
    }
    @Override
    publicvoidonCreate(Bundle savedInstanceState){
        super.onCreate(savedInstanceState);
        if(leak==null){
            leak =new Leaky();
        }
        ...

上面這段程式碼，對Java熟悉的同學都應該瞭解非靜態內部類物件預設持有外部類物件引用，而leak作為靜態變數在非空判斷下只產生了一個物件，因此當旋轉螢幕時生成新的Activity的時候舊的Activity的引用依然被持有，如下圖： 

通過觀察旋轉螢幕前後Log中GC的資訊也能看出heap的data object分配往上漲了一點，並且在GC執行完heap的分配穩定之後並沒有降下來，這就是記憶體洩漏的跡象。

我們通過MAT來進行分析。先下載MAT，可以作為Eclipse外掛下載，也可以作為RCP應用下載，本質上沒有區別。DDMS中選中應用對應的程序名，點選Dump HPROF file的按鈕，等一小段時間生成HPROF檔案，如果是Eclipse外掛的話，Eclipse會為這個HPROF自動轉化成標準的HPROF並自動開啟MAT分析介面。如果是作為RCP應用的話，需要用sdk目錄tools中的hprof-conv工具來進行轉化，也就是上文提及的命令hprof-convorig.hprof converted.hprof，這種方式儲存HPROF檔案的位置選擇更為自主，你也可以修改Eclipse的設定讓Eclipse提示儲存而不是自動開啟，在Preferences -> Android -> DDMS中的HPROFAction由Open in Eclipse改為Save todisk。開啟MAT，選擇轉化好的HPROF檔案，可以看到Overview的介面如下圖：

中間的餅狀圖就是根據我們上文所說的Retained heap的概念得到的記憶體中一些Retained Size最大的物件。點選餅狀圖能看到這些物件型別，但對記憶體洩漏的分析還遠遠不夠。再看下方Action中有Dominator Tree和Histogram的選項，這一般來說是最有用的工具。還記得我們上文說過的DominatorTree的概念嗎，這就是我們用來跟蹤記憶體洩漏的方式。點開Dominator Tree，會看到以Retained heap排序的一系列物件，如下圖：

Resources型別物件由於一般是系統用於載入資源的，所以Retained heap較大是個比較正常的情況。但我們注意到下面的Bitmap型別物件的Retained heap也很大，很有可能是由於記憶體洩漏造成的。所以我們右鍵點選這行，選擇Path To GC Roots ->exclude weak references，可以看到下圖的情形：

Bitmap最終被leak引用到，這應該是一種不正常的現象，記憶體洩漏很可能就在這裡了。MAT不會告訴哪裡是記憶體洩漏，需要你自行分析，由於這是Demo，是我們特意造成的記憶體洩漏，因此比較容易就能看出來，真實的應用場景可能需要你仔細的進行分析。

根據我們上文介紹的Dominator的概念，leak物件是該Bitmap物件的Dominator，應該出現在Dominator Tree視圖裡面，但實際上卻沒有。這是由於MAT並沒有對weak references做區別對待，這也是我們選擇exclude weakreferences的原因。如果我們Path To GC Roots ->with all references，我們可以看到下圖的情形：

可以看到還有另外一個物件在引用著這個Bitmap物件，瞭解weak references的同學應該知道GC是如何處理weak references，因此在記憶體洩漏分析的時候我們可以把weak references排除掉。

有些同學可能希望根據某種型別的物件個數來分析記憶體洩漏。我們在Overview檢視中選擇Actions -> Histogram，可以看到類似下圖的情形：

上圖展示了記憶體中各種型別的物件個數和Shallow heap，我們看到byte[]佔用Shallow heap最多，那是因為Honeycomb之後Bitmap Pixel Data的記憶體分配在Dalvik heap中。右鍵選中byte[]陣列，選擇List Objects -> with incomingreferences，可以看到byte[]具體的物件列表：

我們發現第二個byte[]的Retained heap較大，記憶體洩漏的可能性較大，因此右鍵選中這行，Path To GC Roots -> exclude weak references，同樣可以看到上文所提到的情況，我們的Bitmap物件被leak所引用到，這裡存在著記憶體洩漏。

在Histogram檢視中第一行<Regex>中輸入com.example.android.hcgallery，過濾出我們自己應用中的型別，如下圖：

我們發現本應該只有一個MainActivity現在卻有兩個，顯然不正常。右鍵選擇List Objects-> with incoming references，可以看到這兩個具體的MainActivity物件。右鍵選中Retained heap較大的MainActivity，Path To GC Roots -> exclude weak references，再一次可疑物件又指向了leak物件。

以上是MAT一些基本的用法，如果你感興趣，可以自行深入的去了解MAT的其他功能。