深入浅出,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)(下)

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,547评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,399评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,428评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,599评论 1 274
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,612评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,577评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,941评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,603评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,852评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,605评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,693评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,375评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,955评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,936评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,172评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,970评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,414评论 2 342

推荐阅读更多精彩内容