Android中使用Handler形成內存泄露的分析和解決，Handler機制原理(SDK源碼設計)

本文引用：http://www.linuxidc.com/Linux/2013-12/94065.htm

一、什麼是內存泄露？

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

Android中使用Handler形成內存泄露的緣由

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

上面是一段簡單的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被持有引用而沒法被回收。

 

處理方式一：

在Activity中的部分代碼：

/** 實現驗證碼按鈕倒計時 */
private void messageCountDown(){
　　handler = new Handler();
　　seconds = 60;
　　handler.post(run);
}

Runnable run = new Runnable() {
　　@Override
　　public void run() {
　　　　if(seconds >= 0){
　　　　　　textMessageCode.setEnabled(false);
　　　　　　textMessageCode.setText(seconds+"");
　　　　　　seconds --;
　　　　　　handler.postDelayed(this,1000);
　　　　}else{
　　　　　　textMessageCode.setEnabled(true);
　　　　　　textMessageCode.setText(R.string.get_message_code_again);
　　　　}
　　}
};

@Override
protected void onDestroy() {
　　//activity銷燬時移除handler防止內存泄漏
　　if(handler != null){
　　　　handler.removeCallbacks(run);
　　}
　　super.onDestroy();
}

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

靜態類不持有外部類的對象，因此你的Activity能夠隨意被回收。代碼以下：

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

但其實沒這麼簡單。使用了以上代碼以後，你會發現，因爲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);
        }
    }
}

 

延伸：什麼是WeakReference？

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

 

我的體會：

經過對sdk源碼的學習，我所理解的handler實現原理：
Android是消息驅動的，實現消息驅動有幾個要素：
一、消息的表示：Message
二、消息隊列：MessageQueue
三、消息循環，用於循環取出消息進行處理：Looper
四、消息處理，消息循環從消息隊列中取出消息後要對消息進行處理：Handler

 

一、在實例化handler的時候當前會獲取Looper的實例，同時獲取消息隊列：

二、在handler.post()後，會把你所要執行的線程Runable封裝到Mssage中    

三、再通過MessageQueue.enqueueMessage(Message msg, long when)將Message放入消息隊列中；

四、當子線程完成操做後調用Looper.loop(),並調用dispatchMessage()，並在改方法中回調callback.handleMessage(msg);

【ps：loop方法怎麼啓用的爲找出關聯源碼，我的分析應該是在子線程完以後觸發改方法，loop是startc聲明的靜態方法】

public static void loop() {
　　final Looper me = myLooper();
　　if (me == null) {
　　　　throw new RuntimeException("No Looper; Looper.prepare() wasn't called on this thread.");
　　}
　　final MessageQueue queue = me.mQueue;

　　// Make sure the identity of this thread is that of the local process,
　　// and keep track of what that identity token actually is.
　　Binder.clearCallingIdentity();
　　final long ident = Binder.clearCallingIdentity();

　　for (;;) {
　　　　Message msg = queue.next(); // might block
　　　　if (msg == null) {
　　　　　　// No message indicates that the message queue is quitting.
　　　　　　return;
　　　　}

　　// This must be in a local variable, in case a UI event sets the logger
　　Printer logging = me.mLogging;
　　if (logging != null) {
　　　　logging.println(">>>>> Dispatching to " + msg.target + " " +
　　　　msg.callback + ": " + msg.what);
　　}

　　msg.target.dispatchMessage(msg);

　　if (logging != null) {
　　　　logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
　　}

　　// Make sure that during the course of dispatching the
　　// identity of the thread wasn't corrupted.
　　final long newIdent = Binder.clearCallingIdentity();
　　if (ident != newIdent) {
　　　　Log.wtf(TAG, "Thread identity changed from 0x"
　　　　+ Long.toHexString(ident) + " to 0x"
　　　　+ Long.toHexString(newIdent) + " while dispatching to "
　　　　+ msg.target.getClass().getName() + " "
　　　　+ msg.callback + " what=" + msg.what);
　　}

　　msg.recycleUnchecked();
　　}
}

五、回調callback