android內存泄露的原因
來源：程序員人生 發布時間：2015-06-24 08:09:03 閱讀次數：3825次
1、資源對象沒有關閉造成內存泄漏
資源性對象比如（Cursor，File文件等）常常都用了1些緩沖，我們在不使用的時候，應當及時關閉它們，以便它們的緩沖及時回收內存。它們的緩沖不但存在于java虛擬機內，還存在于java虛擬機外。如果我們僅僅是把它的援用設置為null,而不關閉它們，常常會造成內存泄漏。由于有些資源性對象，比如SQLiteCursor（在析構函數finalize(),如果我們沒有關閉它，它自己會調close()關閉），如果我們沒有關閉它，系統在回收它時也會關閉它，但是這樣的效力太低了。因此對資源性對象在不使用的時候，應當調用它的close()函數，將其關閉掉，然后才置為null.在我們的程序退出時1定要確保我們的資源性對象已關閉。
程序中常常會進行查詢數據庫的操作，但是常常會有使用終了Cursor后沒有關閉的情況。如果我們的查詢結果集比較小，對內存的消耗不容易被發現，只有在常時間大量操作的情況下才會復現內存問題，這樣就會賜與后的測試和問題排查帶來困難和風險
示例代碼：
[java]
Cursor cursor = getContentResolver().query(uri...);
if (cursor.moveToNext()) {
... ...
}
修正示例代碼：
[java]
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中根據當前的屏幕布局實例化1定數量的view對象，同時ListView會將這些view對象緩存起來。當向上轉動ListView時，本來位于最上面的list
item的view對象會被回收，然后被用來構造新出現的最下面的list item。這個構造進程就是由getView()方法完成的，getView()的第2個形參View convertView就是被緩存起來的list item的view對象(初始化時緩存中沒有view對象則convertView是null)。由此可以看出，如果我們不去使用convertView，而是每次都在getView()中重新實例化1個View對象的話，即浪費資源也浪費時間，也會使得內存占用愈來愈大。
能引發內存泄漏的代碼: BadAdapter.java
public class BadAdapter extends BaseAdapter {
......
@Override
public View getView(int position, View convertView, ViewGroup parent) {
Log.d("MyAdapter", "Position:" + position + "---"
+ String.valueOf(System.currentTimeMillis()));
final LayoutInflater inflater = (LayoutInflater) mContext
.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
View v = inflater.inflate(R.layout.list_item_icon_text, null);
((ImageView) v.findViewById(R.id.icon)).setImageResource(R.drawable.icon);
((TextView) v.findViewById(R.id.text)).setText(mData[position]);
return v;
}
}
修正優化示例代碼示例代碼：GoodAdapter.java
public class GoodAdapter extends BaseAdapter {
......
@Override
public View getView(int position, View convertView, ViewGroup parent) {
Log.d("MyAdapter", "Position:" + position + "---"
+ String.valueOf(System.currentTimeMillis()));
ViewHolder holder;
if (convertView == null) {
final LayoutInflater inflater = (LayoutInflater) mContext
.getSystemService(Context.LAYOUT_INFLATER_SERVICE);
convertView = inflater.inflate(R.layout.list_item_icon_text, null);
holder = new ViewHolder();
holder.icon = (ImageView) convertView.findViewById(R.id.icon);
holder.text = (TextView) convertView.findViewById(R.id.text);
convertView.setTag(holder);
} else {
holder = (ViewHolder) convertView.getTag();
}
holder.icon.setImageResource(R.drawable.icon);
holder.text.setText(mData[position]);
return convertView;
}
有時我們會手工的操作Bitmap對象，如果1個Bitmap對象比較占內存，當它不在被使用的時候，可以調用Bitmap.recycle()方法回收此對象的像素所占用的內存，但這不是必須的
4、試著使用關于application的context來替換和activity相干的context
這是1個很隱晦的內存泄漏的情況。有1種簡單的方法來避免context相干的內存泄漏。最顯著地1個是避免context逃出他自己的范圍以外。使用Application context。這個context的生存周期和你的利用的生存周期1樣長，而不是取決于activity的生存周期。如果你想保持1個長時間生存的對象，并且這個對象需要1個context,記得使用application對象。你可以通過調用Context.getApplicationContext()
or Activity.getApplication()來取得
5.注冊沒取消釀成的內存泄漏
1些Android程序可能援用我們的Anroid程序的對象（比如注冊機制）。即便我們的Android程序已結束了，但是別的援用程序依然還有對我們的Android程序的某個對象的援用，泄漏的內存仍然不能被垃圾回收。調用registerReceiver后未調用unregisterReceiver。
6、線程惹的禍
由于線程的履行時間是未知的，所以線程所持有的外部對象，1般要使用weak reference，除非你肯定它們的生命周期。另外，向其它線程post Runnable或send Message時也需要注意Runnalbe內部使用的變量和Message中的內容。
7、釋放對象的援用，誤將1個本來生命周期短的對象寄存到1個生命周期相對較長的對象中，也稱“對象游離“。隱蔽的內部類（Anonymous Inner
Class）
生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈
