Android App 內存泄露

Android App 內存泄露之Handler

Handler也是造成內存泄露的一個重要的源頭，主要Handler屬於TLS(Thread Local Storage)變量,生命週期和Activity是不一致的
，Handler引用Activity會存在內存泄露。

看一下如下代碼

/**
 *
 * 實現的主要功能。
 * @version 1.0.0
 * @author Abay Zhuang <br/>
 *         Create at 2014-7-28
 */
public class HandlerActivity extends Activity {

    private final Handler mHandler = new Handler() {
        @Override
        public void handleMessage(Message msg) {
            // ...
        }
    };

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mHandler.sendMessageDelayed(Message.obtain(), 60000);

        //just finish this activity
        finish();
    }

}

是否您以前也是這樣用的呢。

沒有問題？

Eclipse 工具有這樣的警告提示 警告: 

This Handler class should be static or leaks might occur (com.example.ta.HandlerActivity.1)

意思：class 使用靜態聲明否者可能出現內存泄露。

爲啥出現這樣的問題呢

Handler 的生命週期與Activity 不一致

• 當Android應用啓動的時候，會先創建一個UI主線程的Looper對象，Looper實現了一個簡單的消息隊列，一個一個的處理裏面的Message對象。主線程Looper對象在整個應用生命週期中存在。
• 當在主線程中初始化Handler時，該Handler和Looper的消息隊列關聯（沒有關聯會報錯的）。發送到消息隊列的Message會引用發送該消息的Handler對象，這樣系統可以調用 Handler#handleMessage(Message) 來分發處理該消息。

handler 引用 Activity 阻止了GC對Acivity的回收

• 在Java中，非靜態(匿名)內部類會默認隱性引用外部類對象。而靜態內部類不會引用外部類對象。

• 如果外部類是Activity，則會引起Activity泄露 。

  當Activity finish後，延時消息會繼續存在主線程消息隊列中1分鐘，然後處理消息。而該消息引用了Activity的Handler對象，然後這個Handler又引用了這個Activity。這些引用對象會保持到該消息被處理完，這樣就導致該Activity對象無法被回收，從而導致了上面說的 Activity泄露。

如何避免修？

• 使用顯形的引用，1.靜態內部類。 2. 外部類
• 使用弱引用 2. WeakReference

修改代碼如下：

/**
 *
 * 實現的主要功能。
 *
 * @version 1.0.0
 * @author Abay Zhuang <br/>
 *         Create at 2014-7-28
 */
public class HandlerActivity2 extends Activity {

    private static final int MESSAGE_1 = 1;
    private static final int MESSAGE_2 = 2;
    private static final int MESSAGE_3 = 3;
    private final Handler mHandler = new MyHandler(this);

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        mHandler.sendMessageDelayed(Message.obtain(), 60000);

        // just finish this activity
        finish();
    }

    public void todo() {
    };

    private static class MyHandler extends Handler {
        private final WeakReference<HandlerActivity2> mActivity;

        public MyHandler(HandlerActivity2 activity) {
            mActivity = new WeakReference<HandlerActivity2>(activity);
        }

        @Override
        public void handleMessage(Message msg) {
            System.out.println(msg);
            if (mActivity.get() == null) {
                return;
            }
            mActivity.get().todo();
        }
    }

上面這樣就可以了嗎？

  當Activity finish後 handler對象還是在Message中排隊。 還是會處理消息，這些處理有必要？
  正常Activitiy finish後，已經沒有必要對消息處理，那需要怎麼做呢？
  解決方案也很簡單，在Activity onStop或者onDestroy的時候，取消掉該Handler對象的Message和Runnable。
  通過查看Handler的API，它有幾個方法：removeCallbacks(Runnable r)和removeMessages(int what)等。

代碼如下：

 
/**
  * 一切都是爲了不要讓mHandler拖泥帶水
  */
 @Override
 public void onDestroy() {
     mHandler.removeMessages(MESSAGE_1);
     mHandler.removeMessages(MESSAGE_2);
     mHandler.removeMessages(MESSAGE_3);

     // ... ...

     mHandler.removeCallbacks(mRunnable);

     // ... ...
 }

如果上面覺的麻煩，也可以如下面：

@Override
public void onDestroy() {
    //  If null, all callbacks and messages will be removed.
    mHandler.removeCallbacksAndMessages(null);

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

Thread 內存泄露

線程也是造成內存泄露的一個重要的源頭。線程產生內存泄露的主要原因在於線程生命週期的不可控。

1.看一下下面是否存在問題

<span style="white-space:pre">    </span>/**
 *
 * @version 1.0.0
 * @author Abay Zhuang <br/>
 *         Create at 2014-7-17
 */
public class ThreadActivity extends Activity {
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        new MyThread().start();
    }

    private class MyThread extends Thread {
        @Override
        public void run() {
            super.run();
            dosomthing();
        }
    }
    private void dosomthing(){

    }
}

這段代碼很平常也很簡單，是我們經常使用的形式。

真的沒有問題嗎

我們思考一個問題：假設MyThread的run函數是一個很費時的操作，當我們開啓該線程後，將設備的橫屏變爲了豎屏，
一般情況下當屏幕轉換時會重新創建Activity，按照我們的想法，老的Activity應該會被銷燬纔對，然而事實上並非如此。
由於我們的線程是Activity的內部類，所以MyThread中保存了Activity的一個引用，當MyThread的run函數沒有結束時，
MyThread是不會被銷燬的，因此它所引用的老的Activity也不會被銷燬，因此就出現了內存泄露的問題。   

2.這種線程導致的內存泄露問題應該如何解決呢？

• 第一、將線程的內部類，改爲靜態內部類。

• 第二、在線程內部採用弱引用保存Context引用。 代碼如下：

  <span style="white-space:pre">        </span>/**
           *
           * @version 1.0.0
           * @author Abay Zhuang <br/>
           *         Create at 2014-7-17
           */
  
          public class ThreadAvoidActivity extends Activity {
              public void onCreate(Bundle savedInstanceState) {
                  super.onCreate(savedInstanceState);
                  setContentView(R.layout.activity_main);
                  new MyThread(this).start();
              }
  
              private void dosomthing() {
  
              }
  
              private static class MyThread extends Thread {
                  WeakReference<ThreadAvoidActivity> mThreadActivityRef;
  
                  public MyThread(ThreadAvoidActivity activity) {
                      mThreadActivityRef = new WeakReference<ThreadAvoidActivity>(
                              activity);
                  }
  
                  @Override
                  public void run() {
                      super.run();
                      if (mThreadActivityRef == null)
                          return;
                      if (mThreadActivityRef.get() != null)
                          mThreadActivityRef.get().dosomthing();
                      // dosomthing
                  }
              }
          }
  
  

上面的兩個步驟其實是切換兩個對象的雙向強引用鏈接

1. 靜態內部類：切斷Activity 對於 MyThread的強引用。
2. 弱引用： 切斷MyThread對於Activity 的強引用。

3.AsynTask 內部類會如何呢？

有些人喜歡用Android提供的AsyncTask，但事實上AsyncTask的問題更加嚴重，
Thread只有在run函數不結束時纔出現這種內存泄露問題，然而AsyncTask內部的實現機制是運用了ThreadPoolExcutor,
該類產生的Thread對象的生命週期是不確定的，是應用程序無法控制的，
因此如果AsyncTask作爲Activity的內部類，就更容易出現內存泄露的問題。

代碼如下：

/**
 *
 * 弱引用
 * @version 1.0.0
 * @author Abay Zhuang <br/>
 *         Create at 2014-7-17
 */
public abstract class WeakAsyncTask<Params, Progress, Result, WeakTarget>
    extends AsyncTask<Params, Progress, Result> {
protected WeakReference<WeakTarget> mTarget;

public WeakAsyncTask(WeakTarget target) {
    mTarget = new WeakReference<WeakTarget>(target);
}

@Override
protected final void onPreExecute() {
    final WeakTarget target = mTarget.get();
    if (target != null) {
        this.onPreExecute(target);
    }
}

@Override
protected final Result doInBackground(Params... params) {
    final WeakTarget target = mTarget.get();
    if (target != null) {
        return this.doInBackground(target, params);
    } else {
        return null;
    }
}

@Override
protected final void onPostExecute(Result result) {
    final WeakTarget target = mTarget.get();
    if (target != null) {
        this.onPostExecute(target, result);
    }
}

protected void onPreExecute(WeakTarget target) {
    // Nodefaultaction
}

protected abstract Result doInBackground(WeakTarget target,
        Params... params);

protected void onPostExecute(WeakTarget target, Result result) {
    // Nodefaultaction
}
}