Android內(nèi)存泄漏的幾個原因

1.資源對象沒關(guān)閉釀成的內(nèi)存泄漏
資源性對象比如(Cursor，F(xiàn)ile文件等)常常都用了1些緩沖，我們在不使用的時候，應(yīng)當(dāng)及時關(guān)閉它們，以便它們的緩沖及時回收內(nèi)存。它們的緩沖不但存在于 java虛擬機(jī)內(nèi)，還存在于java虛擬機(jī)外。如果我們僅僅是把它的援用設(shè)置為null,而不關(guān)閉它們，常常會造成內(nèi)存泄漏。由于有些資源性對象，比如 SQLiteCursor(在析構(gòu)函數(shù)finalize(),如果我們沒有關(guān)閉它，它自己會調(diào)close()關(guān)閉)，如果我們沒有關(guān)閉它，系統(tǒng)在回收它時也會關(guān)閉它，但是這樣的效力太低了。因此對資源性對象在不使用的時候，應(yīng)當(dāng)調(diào)用它的close()函數(shù)，將其關(guān)閉掉，然后才置為null.在我們的程序退出時1定要確保我們的資源性對象已關(guān)閉。
程序中常常會進(jìn)行查詢數(shù)據(jù)庫的操作，但是常常會有使用終了Cursor后沒有關(guān)閉的情況。如果我們的查詢結(jié)果集比較小，對內(nèi)存的消耗不容易被發(fā)現(xiàn)，只有在常時間大量操作的情況下才會復(fù)現(xiàn)內(nèi)存問題，這樣就會賜與后的測試和問題排查帶來困難和風(fēng)險。
示例代碼：
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.構(gòu)造Adapter時，沒有使用緩存的convertView
以構(gòu)造ListView的BaseAdapter為例，在BaseAdapter中提供了方法：
public View getView(int position, ViewconvertView, ViewGroup parent)

來向ListView提供每個item所需要的view對象。初始時ListView會從BaseAdapter中根據(jù)當(dāng)前的屏幕布局實例化1定數(shù)量的 view對象，同時ListView會將這些view對象緩存起來。當(dāng)向上轉(zhuǎn)動ListView時，本來位于最上面的list item的view對象會被回收，然后被用來構(gòu)造新出現(xiàn)的最下面的list item。這個構(gòu)造進(jìn)程就是由getView()方法完成的，getView()的第2個形參View convertView就是被緩存起來的list item的view對象(初始化時緩存中沒有view對象則convertView是null)。由此可以看出，如果我們不去使用 convertView，而是每次都在getView()中重新實例化1個View對象的話，即浪費資源也浪費時間，也會使得內(nèi)存占用愈來愈大。 ListView回收list item的view對象的進(jìn)程可以查看:
android.widget.AbsListView.java