Android中使用Handler造成記憶體泄露的分析和解決

標籤：log   通知   reference   androi   保護   callbacks   XA   onstop   null   

Java使用有向圖機制，通過GC自動檢查記憶體中的對象（什麼時候檢查由虛擬機器決定），如果GC發現一個或一組對象為不可到達狀態，則將該對象從記憶體中回收。也就是說，一個對象不被任何引用所指向，則該對象會在被GC發現的時候被回收；另外，如果一組對象中只包含互相的引用，而沒有來自它們外部的引用（例如有兩個對象A和B互相持有引用，但沒有任何外部對象持有指向A或B的引用），這仍然屬於不可到達，同樣會被GC回收。

Android中使用Handler造成記憶體泄露的原因

Handler mHandler = new Handler() {    @Override    public void handleMessage(Message msg) {        mImageView.setImageBitmap(mBitmap);    }}

• 1
• 2
• 3
• 4
• 5
• 6

上面是一段簡單的Handler的使用。當使用內部類（包括匿名類）來建立Handler的時候，Handler對象會隱式地持有一個外部類對象（通常是一個Activity）的引用（不然你怎麼可能通過Handler來操作Activity中的View？）。而Handler通常會伴隨著一個耗時的後台線程（例如從網路拉取圖片）一起出現，這個後台線程在任務執行完畢（例片下載完畢）之後，通過訊息機制通知Handler，然後Handler把圖片更新到介面。然而，如果使用者在網路請求過程中關閉了Activity，正常情況下，Activity不再被使用，它就有可能在GC檢查時被回收掉，但由於這時線程尚未執行完，而該線程持有Handler的引用（不然它怎麼發訊息給Handler？），這個Handler又持有Activity的引用，就導致該Activity無法被回收（即記憶體泄露），直到網路請求結束（例片下載完畢）。另外，如果你執行了Handler的postDelayed()方法，該方法會將你的Handler裝入一個Message，並把這條Message推到MessageQueue中，那麼在你設定的delay到達之前，會有一條MessageQueue -> Message -> Handler -> Activity的鏈，導致你的Activity被持有引用而無法被回收。

記憶體泄露的危害

只有一個，那就是虛擬機器佔用記憶體過高，導致OOM（記憶體溢出），程式出錯。對於Android應用來說，就是你的使用者開啟一個Activity，使用完之後關閉它，記憶體泄露；又開啟，又關閉，又泄露；幾次之後，程式佔用記憶體超過系統限制，FC。

使用Handler導致記憶體泄露的解決方案

方法一：通過程式邏輯來進行保護。

1.在關閉Activity的時候停掉你的後台線程。線程停掉了，就相當於切斷了Handler和外部串連的線，Activity自然會在合適的時候被回收。

2.如果你的Handler是被delay的Message持有了引用，那麼使用相應的Handler的removeCallbacks()方法，把訊息對象從訊息佇列移除就行了。

方法二：將Handler聲明為靜態類。

靜態類不持有外部類的對象，所以你的Activity可以隨意被回收。代碼如下：

static class MyHandler extends Handler {    @Override    public void handleMessage(Message msg) {        mImageView.setImageBitmap(mBitmap);    }}

• 1
• 2
• 3
• 4
• 5
• 6

但其實沒這麼簡單。使用了以上代碼之後，你會發現，由於Handler不再持有外部類對象的引用，導致程式不允許你在Handler中操作Activity中的對象了。所以你需要在Handler中增加一個對Activity的弱引用（WeakReference）：

static class MyHandler extends Handler {    WeakReference<Activity > mActivityReference;    MyHandler(Activity activity) {        mActivityReference= new WeakReference<Activity>(activity);    }    @Override    public void handleMessage(Message msg) {        final Activity activity = mActivityReference.get();        if (activity != null) {            mImageView.setImageBitmap(mBitmap);        }    }}

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15

將代碼改為以上形式之後，就算完成了。

具體範例程式碼：

/** *  * 實現的主要功能。 *  * @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();        }    }

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13
• 14
• 15
• 16
• 17
• 18
• 19
• 20
• 21
• 22
• 23
• 24
• 25
• 26
• 27
• 28
• 29
• 30
• 31
• 32
• 33
• 34
• 35
• 36
• 37
• 38
• 39
• 40
• 41
• 42
• 43
• 44

上面這樣就可以了嗎？

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

代碼如下：

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

• 1
• 2
• 3
• 4
• 5

延伸：什麼是WeakReference？

WeakReference弱引用，與強引用（即我們常說的引用）相對，它的特點是，GC在回收時會忽略掉弱引用，即就算有弱引用指向某對象，但只要該對象沒有被強引用指向（實際上多數時候還要求沒有軟引用，但此處軟引用的概念可以忽略），該對象就會在被GC檢查到時回收掉。對於上面的代碼，使用者在關閉Activity之後，就算後台線程還沒結束，但由於僅有一條來自Handler的弱引用指向Activity，所以GC仍然會在檢查的時候把Activity回收掉。這樣，記憶體泄露的問題就不會出現了。

Android中使用Handler造成記憶體泄露的分析和解決