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

描述：

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()來獲得。更多的請看這篇文章

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

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

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

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

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

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

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

7.其他