深入淺出,Handler機制外科手術式的剖析(ThreadLocal,Looper,MessageQueen,Message)(上)

【版權申明】轉載請注明出處(請尊重原創,博主保留追究權)
http://blog.csdn.net/qq_24295537/article/details/77902372
出自【yangLiHai_的博客】

為什么會有handler機制?

在Android中,所有的UI控件都是運行在主線程中的, 如果我們從子線程訪問UI,系統會報異常。為什么不允許子線程訪問UI呢?因為Android的UI控件不是線程安全的,為了防止UI控件處于不可控的狀態,就禁止了。主線程是不允許做任何的網絡請求的,那么請求回來的數據如何同步到UI呢。所以為了方便線程間通訊,就產生了Handler機制,目的就是方便數據在線程間傳遞切換。而更新UI是我們用的最常見的。

先來看一段代碼:

private Handler mHandler = new Handler(){
        @Override
        public void handleMessage(Message msg) {
            // TODO: 9/7/17 do what you wanna  
        }
    };

這個是典型的handler用法,我們在使用的時候一般都在主線程初始化Handler,那么有沒有可能在子線程創建handler呢?答案是可以的,但是如果直接在子線程創建Handler,會報異常:

RuntimeException("Can't create handler inside thread that has not called Looper.prepare()");

說的很清楚,需要我們在子線程初始化Looper,通過Looper.prepare();那么這個Looper是個什么?它和handler是什么關系呢?別急,聽我細細道來。

在說Looper之前,先說一下MessageQueen,顧名思義他是一個消息隊列,遵循的是先進先出的原則,但是他的內部不是一個隊列的形式,而是以單鏈表的數據結構來實現的,單鏈表的優勢就不用說了吧,插入和刪除的速度相對快。分別對應的是enqueueMessage和next方法。但是他不處理消息,而Looper就是負責處理消息的。

Looper可以說是handler的核心類,他是鏈接MessageQueen和handler的媒介,它開啟后,會無限循環的去MessageQueen中獲取消息,然后交給Handler處理。在初始化Handler之前,必須先初始化Looper,否則就會報上邊的異常,Looper是和線程綁定的,每一個線程,只有一個Looper。這一點我們從Looper的靜態初始化方法中也可以看出來:

private static void prepare(boolean quitAllowed) {
        if (sThreadLocal.get() != null) {
            throw new RuntimeException("Only one Looper may be created per thread");
        }
        sThreadLocal.set(new Looper(quitAllowed));
    }

if語句的判斷就是判斷是否有當前thread的Looper,如果有就報異常。我們注意到,他的判斷依據是sThreadLocal,這是一個ThreadLocal實例。這是一個重要的線程工具類,下邊我們詳細講一下。

ThreadLocal

ThreadLocal是java里邊一個線程數據存儲類,他并不是一個Thread,其實作用非常簡單,就是每一個使用該變量的線程,都提供一個變量值的副本,每一個線程可以獨立的改變自己的副本,而不和其他線程的副本沖突。當某些數據是以線程為作用域并且不同線程有不同的數據副本的時候,可以考慮用ThreadLocal,很明顯Looper的作用域就是當前線程,所以非常適合了。通過下邊的下例子,簡單展示下ThreadLocal的特點和用法:

public static void main(String[] args){
        final ThreadLocal<String> mThreadLocal = new ThreadLocal<String>();
        mThreadLocal.set("main");
        new Thread("Thread-1") {
            public void run() {
                mThreadLocal.set(Thread.currentThread().getName());
                System.out.println("currentThread:"+Thread.currentThread().getName()+","+mThreadLocal.get());
            };
        }.start();
        System.out.println("currentThread:"+Thread.currentThread().getName()+","+mThreadLocal.get());
    }

首先我初始化了一個ThreadLocal的變量mThreadLocal,然后在主線程調用set方法,放入字符串”main“,然后開啟一個子線程,放入子線程的名字,然后分別在子線程和主線程打印get方法獲取的數據,打印結果如下:

currentThread:main,main
currentThread:Thread-1,Thread-1

從日志中我們可以看出來,盡管塞數據的時候調用的都是同一個ThreadLocal,但是在不同的線程獲取到的數據是不一樣的。是不是很厲害,但是到底他是如何實現不同的線程有不同的副本的呢,我們來看一下它的set方法的源碼:

public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }
    
ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }
    
void createMap(Thread t, T firstValue) {
        t.threadLocals = new ThreadLocalMap(this, firstValue);
    }    

從set方法中我們可以看到,通過getMap拿到一個ThreadLocalMap對象,然后通過ThreadLocalMap的set方法設置進去,如果這個ThreadLocalMap對象為null,則執行createMap方法。

從getMap的方法內容我們可以看出,他返回的Thread內部的一個成員變量:ThreadLocal.ThreadLocalMap。那么這個ThreadLocalMap就是數據存儲的關鍵,他是一個內部靜態類,我們看一下new ThreadLocalMap(this, firstValue)具體做了什么:

static class Entry extends WeakReference<ThreadLocal> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal k, Object v) {
                super(k);
                value = v;
            }
        }
        
ThreadLocalMap(ThreadLocal firstKey, Object firstValue) {
            table = new Entry[INITIAL_CAPACITY];
            int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1);
            table[i] = new Entry(firstKey, firstValue);
            size = 1;
            setThreshold(INITIAL_CAPACITY);
        }

table是一個數組,Entry是ThreadLocalMap的靜態內部類,繼承自WeakReference并以ThreadLocal作為key,ThreadLocal的泛型實例作為value。在new ThreadLocalMap的時候,把key和value存入Entry,然后通過一定的算法(算法的具體內容不在分析,有興趣的兄弟可以自己看看),把Entry放入數組。接著讓我們來看下ThreadLocalMap的set(ThreadLocal,Object)方法:

private void set(ThreadLocal key, Object value) {
            Entry[] tab = table;
            int len = tab.length;
            int i = key.threadLocalHashCode & (len-1);

            for (Entry e = tab[i];
                 e != null;
                 e = tab[i = nextIndex(i, len)]) {
                ThreadLocal k = e.get();

                if (k == key) {
                    e.value = value;
                    return;
                }

                if (k == null) {
                    replaceStaleEntry(key, value, i);
                    return;
                }
            }

            tab[i] = new Entry(key, value);
            int sz = ++size;
            if (!cleanSomeSlots(i, sz) && sz >= threshold)
                rehash();
        }

可以看出它內部是開啟一個for循環,來遍歷數組table,當Entry不為null的時候,拿到Entry里邊的value然后替換掉。到這里我們算搞明白了ThreadLocal和ThreadLocalMap的關系,以及他們的創建和set方法。

接下來我們看看ThreadLocal的get方法:

public T get() {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null) {
            ThreadLocalMap.Entry e = map.getEntry(this);
            if (e != null)
                return (T)e.value;
        }
        return setInitialValue();
}
    
 private T setInitialValue() {
    T value = initialValue();
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);
    if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
    return value;
}
    
protected T initialValue() {
    return null;
}

搞明白了剛才的內容再看這些應該很容易了,代碼邏輯也是比較清晰的,通過ThreadLocalMap拿到Entry,然后拿到Entry的value。值得注意的是,initialValue()直接返回null,所以沒有在相應的線程調用ThreadLocal.set的時候,那么我們通過get拿到的就是null。

通過分析源碼我們可以得出,ThreadLocal的get和set方法依賴于ThreadLocalMap對象,而ThreadLocalMap對象依賴于Thread被創建,所以不同的線程中訪問的數據是不一樣的。理解了這些,我們再去理解Looper就非常簡單了。

Looper

Looper是一個輪訓器,他會不斷地去MessageQueen中查看是否有新消息,如果有就立即處理。Looper有以下幾個原則:
1.Handler的創建依賴于對應線程的Looper;
2.一個線程只能有一個Looper,否則會出異常;

前邊我們講了,在子線程初始化Handler,會報RunTimeException,正確的創建方式如下:

new Thread(){
        @Override
        public void run() {
            Looper.prepare();
            Handler threadHandler = new Handler();
            Looper.loop();
        }
    }.start();

Looper.prepare()方法做了什么,下邊我們看一下源碼:

// sThreadLocal.get() will return null unless you've called prepare().
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
    
public static void prepare() {
        prepare(true);
}

private static void prepare(boolean quitAllowed) {
    if (sThreadLocal.get() != null) {
        throw new RuntimeException("Only one Looper may be created per thread");
    }
    sThreadLocal.set(new Looper(quitAllowed));
}
private Looper(boolean quitAllowed) {
        mQueue = new MessageQueue(quitAllowed);
        mThread = Thread.currentThread();
}

代碼中有一個成員變量sThreadLocal,他就是一個ThreadLocal實例,里邊的泛型是Looper,剛才我們分析完ThreadLocal,所以很容易我們就能知道,handler機制是通過這個sThreadLocal來保有當前線程的Looper的。從代碼上我們能看出來,Looper在prepare的時候,會通過sThreadLocal拿到當前線程的looper,如果不為null,就報異常,如果為null,就new一個Looper,塞到sThreadLocal中。

那么你可能會有一個疑問,為什么主線程不需要執行prepare方法呢?其實,主線程也執行了初始化方法,只不過不是prepare,而是prepareMainLooper方法,這個是專門為主線程提供的創建Looper的方法。

public static void prepareMainLooper() {
        prepare(false);
        synchronized (Looper.class) {
            if (sMainLooper != null) {
                throw new IllegalStateException("The main Looper has already been prepared.");
            }
            sMainLooper = myLooper();
        }
    }

從代碼上可以看出,他也執行了prepare,本質上也是一樣的。
prepare之后,Looper并不會去執行任何操作,只有調用了Looper.loop()方法之后,消息循環系統才算生效。loop()方法是Looper的主要方法,我們具體來看一下:

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
            final Printer logging = me.mLogging;
            if (logging != null) {
                logging.println(">>>>> Dispatching to " + msg.target + " " +
                        msg.callback + ": " + msg.what);
            }

            final long traceTag = me.mTraceTag;
            if (traceTag != 0) {
                Trace.traceBegin(traceTag, msg.target.getTraceName(msg));
            }
            try {
                msg.target.dispatchMessage(msg);
            } finally {
                if (traceTag != 0) {
                    Trace.traceEnd(traceTag);
                }
            }

            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();
        }
    }

代碼邏輯也是比較清晰的,首先會做一個校驗,檢查當前線程是否有初始化Looper,然后會開啟一個無條件的for循環,不斷地從MessageQueen中獲取消息,如果MessageQueen的next()返回null,則終止方法。message的next()方法是一個阻塞操作,當沒有消息的時候,next方法會阻塞,這也就導致loop方法阻塞。如果從MessageQueen中拿到了message,那么會通過message調用target的dispatchMessage(Message)。這個target其實就是Handler,一會講Handler的時候我們會講到。這樣就成功的把消息切換到了指定的線程中去執行,因為dispatchMessage是在創建Handler時候所使用的Looper執行的。

Looper還提供了退出的方法:quit()和quitSafely();他們倆執行的都是同一個方法,都是MessageQueen中的quit(boolean),但是傳入的參數不一樣。quit會直接退出looper,但是quitSafely只是設定了一個標記,然后把消息隊列的消息處理完畢后才安全退出。quit之后,handler發送消息會失敗,send方法會返回false。在子線程中,執行完所有的handler回調之后應該調用quit方法來終止Looper,否則這個線程會一直處于等待狀態,不能被gc回收。

第一部分就先剖析到這里,還有一半放在第二篇博客講。
深入淺出,Handler機制外科手術式的剖析(ThreadLocal,Looper,MessageQueen,Message)(下)

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容