Android記憶體洩漏產生的6大原因

1.資源物件沒關閉造成的記憶體洩漏

描述：

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

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

示例程式碼：

Cursor cursor = getContentResolver().query(uri...); 

if (cursor.moveToNext()) { 

... ... 

}

修正示例程式碼：

Cursor cursor = null; 

try { 

cursor = getContentResolver().query(uri...); 

if (cursor != null &&cursor.moveToNext()) { 

... ... 

} 

} finally { 

if (cursor != null) { 

try { 

cursor.close(); 

} catch (Exception e) { 

//ignore this 

} 

} 

}

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

描述：

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

public View getView(int position, ViewconvertView, 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 –> voidaddScrapView(View scrap) 方法。

示例程式碼：

public View getView(int position, ViewconvertView, ViewGroup parent) { 

View view = new Xxx(...); 

... ... 

return view; 

}

修正示例程式碼：

public View getView(int position, ViewconvertView, ViewGroup parent) { 

View view = null; 

if (convertView != null) { 

view = convertView; 

populate(view, getItem(position)); 

... 

} else { 

view = new Xxx(...); 

... 

} 

return view; 

}

3.Bitmap物件不在使用時呼叫recycle()釋放記憶體

描述：

有時我們會手工的操作Bitmap物件，如果一個Bitmap物件比較佔記憶體，當它不在被使用的時候，可以呼叫Bitmap.recycle()方法回收此物件的畫素所佔用的記憶體，但這不是必須的，視情況而定。可以看一下程式碼中的註釋：

/** 

•Free up the memory associated with thisbitmap's pixels, and mark the 

•bitmap as "dead", meaning itwill throw an exception if getPixels() or 

•setPixels() is called, and will drawnothing. This operation cannot be 

•reversed, so it should only be called ifyou are sure there are no 

•further uses for the bitmap. This is anadvanced call, and normally need 

•not be called, since the normal GCprocess will free up this memory when 

•there are no more references to thisbitmap. 

*/

4.試著使用關於application的context來替代和activity相關的context

這是一個很隱晦的記憶體洩漏的情況。有一種簡單的方法來避免context相關的記憶體洩漏。最顯著地一個是避免context逃出他自己的範圍之外。使用Application context。這個context的生存週期和你的應用的生存週期一樣長，而不是取決於activity的生存週期。如果你想保持一個長期生存的物件，並且這個物件需要一個context,記得使用application物件。你可以通過呼叫 Context.getApplicationContext() or Activity.getApplication()來獲得。更多的請看這篇文章如何避免

Android記憶體洩漏。

5.註冊沒取消造成的記憶體洩漏

一些Android程式可能引用我們的Anroid程式的物件(比如序號產生器制)。即使我們的Android程式已經結束了，但是別的引用程式仍然還有對我們的Android程式的某個物件的引用，洩漏的記憶體依然不能被垃圾回收。呼叫registerReceiver後未呼叫unregisterReceiver。

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

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

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

6.集合中物件沒清理造成的記憶體洩漏

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