Android記憶體流失的各種原因詳解

標籤：

描述：

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

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

範例程式碼：

Cursor cursor = getContentResolver().query(uri...);  if (cursor.moveToNext()) {  ... ...  } 

 

修正範例程式碼：

1. 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; } 

 

修正範例程式碼：

1. 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()方法回收此對象的像素所佔用的記憶體，但這不是必須的，視情況而定。可以看一下代碼中的注釋：

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

Android記憶體流失的各種原因詳解