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的話，那情況就更嚴重了。