出處：http://blog.csdn.net/zhuanglonghai
Android App 內存泄露之資源
資源內存泄露主要是資源申請未釋放，還有資源沒有重複使用。
- 第一種解決這部分問題的關鍵在於申請資源後能保證能釋放資源。
- 第二種利用複用機制優化，如池的概念 。
1.引用資源沒有釋放
代碼如下：
- private final class SettingsObserver implements Observer {
- public void update(Observable o, Object arg) {
- // todo ...
- }
- }
- ContentQueryMap.getInstance().addObserver(new SettingsObserver());
你對這段代碼正常嗎
答案是否定
存在的問題是沒有辦法註銷觀察者（SettingsObserver），這樣帶來的問題是沒有辦法釋放該觀察者。
那麼這個對象將伴隨整個單例生命週期，無形中就泄露一個SettingsObserver的內存。
1.1註冊未取消造成的內存泄露
這種Android的內存泄露比純Java的內存泄露還要嚴重，
因爲其他一些Android程序可能引用我們的Anroid程序的對象（比如註冊機制）。
即使我們的Android程序已經結束了，但是別的引用程序仍然還有對我們的Android程序的某個對象的引用，泄露的內存依然不能被垃圾回收。
還是我們的對象週期不一致引起的。
例如：BroadcastReceiver對象註冊
... has leaked IntentReceiver ... Are you missing a call to unregisterReceiver()?
Observer對象
被觀察對象生命週期和觀察者的生命週期不一致
不觀察的時候需要需要註銷
1.2集合中對象沒清理造成的內存泄露
我們通常把一些對象的引用加入到了集合中，當我們不需要該對象時，並沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。
如果這個集合是static的話，那情況就更嚴重了
在add 情況也要記得 remove
2.資源對象沒關閉造成的內存泄露
資源性對象比如（Cursor，File文件等）往往都用了一些緩衝，我們在不使用的時候，應該及時關閉它們，
以便它們的緩衝及時回收內存。它們的緩衝不僅存在於java虛擬機內，還存在於java虛擬機外。
如果我們僅僅是把它的引用設置爲null,而不關閉它們，往往會造成內存泄露。因爲有些資源性對象，
比如SQLiteCursor（在析構函數finalize（）,如果我們沒有關閉它，它自己會調close()關閉），
如果我們沒有關閉它，系統在回收它時也會關閉它，但是這樣的效率太低了。
因此對於資源性對象在不使用的時候，應該調用它的close()函數，將其關閉掉，然後才置爲null.
在我們的程序退出時一定要確保我們的資源性對象已經關閉。
程序中經常會進行查詢數據庫的操作，但是經常會有使用完畢Cursor後沒有關閉的情況。如果我們的查詢結果集比較小，
對內存的消耗不容易被發現，只有在常時間大量操作的情況下才會復現內存問題，這樣就會給以後的測試和問題排查帶來困難和風險
代碼如下：
- try {
- Cursor c = queryCursor();
- int a = c.getInt(1);
- ......
- // 如果出錯,後面的cursor.close()將不會執行
- ......
- c.close();
- } catch (Exception e) {
- }
合理的寫法：
- Cursor c;
- try {
- c = queryCursor();
- int a = c.getInt(1);
- ......
- // 如果出錯,後面的cursor.close()將不會執行
- //c.close();
- } catch (Exception e) {
- } finally{
- if (c != null) {
- c.close();
- }
- }
3.一些不良代碼造成的內存壓力
有些代碼並不造成內存泄露，但是它們， 或是對沒使用的內存沒進行有效及時的釋放，
或是沒有有效的利用已有的對象而是頻繁的申請新內存，
對內存的回收和分配造成很大影響的，容易迫使虛擬機不得不給該應用進程分配更多的內存，造成不必要的內存開支。
如果優化呢
頻繁的申請內存對象和和釋放對象，可以考慮Pool 池。
多線程可以考慮線程池
頻繁的申請對象釋放對象。可以考慮對象池。 例如：AbsListView 中RecycleBin 類是view對象池
頻繁的鏈接資源和釋放資源。可以考慮鏈接資源池。
3.1，Bitmap沒調用recycle()
Bitmap對象在不使用時,我們應該先調用recycle()釋放內存，然後才它設置爲null.
雖然recycle()從源碼上看，調用它應該能立即釋放Bitmap的主要內存，
但是測試結果顯示它並沒能立即釋放內存。但是我它應該還是能大大的加速Bitmap的主要內存的釋放。
3.2，構造Adapter時，沒有使用緩存的 convertView
以構造ListView的BaseAdapter爲例，在BaseAdapter中提共了方法：
public View getView(int position, View convertView, 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 --> obtainView 方法。
在使用過程中java代碼如下：
- @Override
- public View getView(int position, View convertView, ViewGroup parent) {
- Log.d(TAG, "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.setImageDrawable(mDefaultDrawable);
- holder.text.setText(mData[position]);
- return convertView;
- }
- static class ViewHolder {
- ImageView icon;
- TextView text;
- }
優化點
- 1.複用convertView ， convertView在ListView有RecycleBin的對象池維護。
- 2.ViewHolder出現減少findViewById 的調用
代碼位置：https://github.com/loyabe/Docs/tree/master/%E5%86%85%E5%AD%98%E6%B3%84%E9%9C%B2
Android App 內存泄露之資源
資源內存泄露主要是資源申請未釋放，還有資源沒有重複使用。
- 第一種解決這部分問題的關鍵在於申請資源後能保證能釋放資源。
- 第二種利用複用機制優化，如池的概念 。
1.引用資源沒有釋放
代碼如下：
- private final class SettingsObserver implements Observer {
- public void update(Observable o, Object arg) {
- // todo ...
- }
- }
- ContentQueryMap.getInstance().addObserver(new SettingsObserver());
你對這段代碼正常嗎
答案是否定
存在的問題是沒有辦法註銷觀察者（SettingsObserver），這樣帶來的問題是沒有辦法釋放該觀察者。
那麼這個對象將伴隨整個單例生命週期，無形中就泄露一個SettingsObserver的內存。
1.1註冊未取消造成的內存泄露
這種Android的內存泄露比純Java的內存泄露還要嚴重，
因爲其他一些Android程序可能引用我們的Anroid程序的對象（比如註冊機制）。
即使我們的Android程序已經結束了，但是別的引用程序仍然還有對我們的Android程序的某個對象的引用，泄露的內存依然不能被垃圾回收。
還是我們的對象週期不一致引起的。
例如：BroadcastReceiver對象註冊
... has leaked IntentReceiver ... Are you missing a call to unregisterReceiver()?
Observer對象
被觀察對象生命週期和觀察者的生命週期不一致
不觀察的時候需要需要註銷
1.2集合中對象沒清理造成的內存泄露
我們通常把一些對象的引用加入到了集合中，當我們不需要該對象時，並沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。
如果這個集合是static的話，那情況就更嚴重了
在add 情況也要記得 remove
2.資源對象沒關閉造成的內存泄露
資源性對象比如（Cursor，File文件等）往往都用了一些緩衝，我們在不使用的時候，應該及時關閉它們，
以便它們的緩衝及時回收內存。它們的緩衝不僅存在於java虛擬機內，還存在於java虛擬機外。
如果我們僅僅是把它的引用設置爲null,而不關閉它們，往往會造成內存泄露。因爲有些資源性對象，
比如SQLiteCursor（在析構函數finalize（）,如果我們沒有關閉它，它自己會調close()關閉），
如果我們沒有關閉它，系統在回收它時也會關閉它，但是這樣的效率太低了。
因此對於資源性對象在不使用的時候，應該調用它的close()函數，將其關閉掉，然後才置爲null.
在我們的程序退出時一定要確保我們的資源性對象已經關閉。
程序中經常會進行查詢數據庫的操作，但是經常會有使用完畢Cursor後沒有關閉的情況。如果我們的查詢結果集比較小，
對內存的消耗不容易被發現，只有在常時間大量操作的情況下才會復現內存問題，這樣就會給以後的測試和問題排查帶來困難和風險
代碼如下：
- try {
- Cursor c = queryCursor();
- int a = c.getInt(1);
- ......
- // 如果出錯,後面的cursor.close()將不會執行
- ......
- c.close();
- } catch (Exception e) {
- }
合理的寫法：
- Cursor c;
- try {
- c = queryCursor();
- int a = c.getInt(1);
- ......
- // 如果出錯,後面的cursor.close()將不會執行
- //c.close();
- } catch (Exception e) {
- } finally{
- if (c != null) {
- c.close();
- }
- }
3.一些不良代碼造成的內存壓力
有些代碼並不造成內存泄露，但是它們， 或是對沒使用的內存沒進行有效及時的釋放，
或是沒有有效的利用已有的對象而是頻繁的申請新內存，
對內存的回收和分配造成很大影響的，容易迫使虛擬機不得不給該應用進程分配更多的內存，造成不必要的內存開支。
如果優化呢
頻繁的申請內存對象和和釋放對象，可以考慮Pool 池。
多線程可以考慮線程池
頻繁的申請對象釋放對象。可以考慮對象池。 例如：AbsListView 中RecycleBin 類是view對象池
頻繁的鏈接資源和釋放資源。可以考慮鏈接資源池。
3.1，Bitmap沒調用recycle()
Bitmap對象在不使用時,我們應該先調用recycle()釋放內存，然後才它設置爲null.
雖然recycle()從源碼上看，調用它應該能立即釋放Bitmap的主要內存，
但是測試結果顯示它並沒能立即釋放內存。但是我它應該還是能大大的加速Bitmap的主要內存的釋放。
3.2，構造Adapter時，沒有使用緩存的 convertView
以構造ListView的BaseAdapter爲例，在BaseAdapter中提共了方法：
public View getView(int position, View convertView, 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 --> obtainView 方法。
在使用過程中java代碼如下：
- @Override
- public View getView(int position, View convertView, ViewGroup parent) {
- Log.d(TAG, "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.setImageDrawable(mDefaultDrawable);
- holder.text.setText(mData[position]);
- return convertView;
- }
- static class ViewHolder {
- ImageView icon;
- TextView text;
- }
優化點
- 1.複用convertView ， convertView在ListView有RecycleBin的對象池維護。
- 2.ViewHolder出現減少findViewById 的調用
代碼位置：https://github.com/loyabe/Docs/tree/master/%E5%86%85%E5%AD%98%E6%B3%84%E9%9C%B2
