10_Android的消息机制

从开发的角度来说，Handler是Android消息机制的上层接口，这使得在开发过程中只需要和Handler交互即可。Handler的使用过程很简单，通过它可以轻松地将一个任务切换到Handler所在的线程中去执行。很多人认为Handler的作用是更新UI，这的确没错，但是更新UI仅仅是Handler的一个特殊的使用场景。有时候需要在子线程中进行耗时的I/O操作，可能是读取文件或者访问网络等，当耗时操作完成以后可能要在UI上做一些改变，这个时候通过Handler就可以将更新UI的操作切换到主线程中执行。因此，本质上来说，Handler并不是专门用于更新UI的，只是常被开发者用来更新UI。

Android的消息机制主要是指Handler的运行机制，Handler的运行需要底层MessageQueue和Looper的支撑。MesageQueue的意思是消息队列，它的内部存储了一组消息，以队列的形式对外提供插入和删除的工作。虽然叫消息队列，但是它的内部存储结构并不是真正的队列，而是采用单链表的数据结构来存储消息列表。Looper是循环，在这里可以理解为消息循环。由于MessageQueue只是一个消息的存储单元，它不能去处理消息，而Looper就填补了这个功能，Looper会以无限循环的形式去查找是否有新消息，如果有的话就处理消息，否则就一直等待着。Looper中还有一个特殊的概念，那就是ThreadLocal，ThreadLocal并不是线程，它的作用是可以在每个线程中存储数据。我们知道，Handler创建的时候会采用当前线程的Looper来构造消息循环系统，那么Handler内部如何获取当前线程的Looper呢？这就要使用ThreadLocal了，ThreadLocal可以在不同的线程中互不干扰地存储并提供数据，通过ThreadLocal可以轻松获取每个线程的Looper。当然需要注意的是，线程是默认没有Looper的，如果需要使用Handler就必须为线程创建Looper。我们经常提到的主线程，也叫UI线程，就是ActivityThread，ActivityThread，ActivityThread被创建时就会初始化Looper，这也是主线程中默认可以使用Handler的原因。

10.1 Android的消息机制概述

Android的消息机制主要是指Handler的运行机制以及Handler所附带的MessageQueue和Looper的工作过程，这三者实际上是一个整体，只不过我们在开发过程中比较多地接触到Handler而已。Handler的主要作用是将一个任务切换到某个指定的线程中执行，那么Android为什么要提供这个功能呢？或者说Android纹身模需要提供在某个具体的线程中执行任务这种功能呢？这是因为Android规定访问UI只能在主线程中进行，如果在子线程中访问UI，那么程序就会抛出异常。ViewRootImpl对UI操作做了验证，这个验证工作是由ViewRootImpl的checkThread方法来完成的。

void checkThread(){
    if(mThread != Thread.currentThread()){
        xxxxx
    }
    
}

针对checkThread方法中抛出的异常信息，由于这一点限制，导致必须在主线程中访问UI，但是Android又建议不要在主线程中进行耗时操作，否则会导致程序无法响应ANR。这个时候必须在子线程中进行网络请求工作，完成后又不能在子线程中直接访问UI，如果没有Handler，那么我们的确没有办法将访问UI的工作切换到主线程中去执行。因此系统之所以提供Handler，主要原因就是为了解决在子线程中无法访问UI的矛盾。

系统为什么不允许在子线程中访问UI？这是因为Android的UI控件不是线程安全的，如果在多线程中并发访问可能导致UI控件处于不可预期的状态，那为什么系统不对UI控件的访问加上锁机制呢？缺点有两个：首先机制会让UI访问的逻辑变得复杂；其次锁机制降低了UI访问的效率，因为锁机制会阻塞某些线程的执行。

Handler的使用方法这里就不做介绍了，这里描述一下Handler的工作原理。Handler创建时会采用当前线程的Looper来构建内部的消息循环系统，如果当前线程没有Looper，那么就会报错。如果解决，只需要为当前线程创建Looper即可，或者在一个有Looper的线程创建Handler也行。

Handler创建完毕后，这个时候其内部的Looper以及messageQueue就可以和Handler一起协同工作了，然后通过Handler的post方法将一个Runnable投递到Handler内部的looper中去处理，也可以通过Handler的send方法发送一个消息，这个消息同样会在Looper中去处理。其实post方法最终也是通过send方法来完成的，接下来主要看一下send方法的工作过程。当Handler的sedn方法被调用时，它会调用MessageQueue的enqueueMesaage方法将这个消息放入消息队列中，然后Looper发现有新消息到来时，就会处理这个消息，最终消息中的Runnable或者Handler的handlerMessage方法就会被调用。注意Looper是运行在创建Handler所在的线程中。这样一来Handler中业务逻辑就被切换到创建Handler所在的线程中去执行了。

10.2 Android的消息机制分析 ThreadLocal的工作原理

ThreadLocal是一个线程内部的数据存储类，通过它可以在指定的线程中存储数据，数据存储以后，只有在指定线程中可以获取到存储的数据，对于其他的线程来说则无法获取到数据。在日常开发中用到ThreadLocal的地方较少，但是在某些特殊的场景下，通过ThreadLocal可以轻松地实现一些看起来很复杂的功能，这一点子android源码上也有所体现，比如Looper、ActivityThread以及AMS中都用到了ThreadLocal。具体到ThreadLocal的使用场景，这个不好统一来描述，一般来说，当某些数据是以线程为作用域并且不同线程具有不同的数据副本的时候，就可以考虑采用ThreadLocal。比如Handler来说，它需要获取当前线程的Looper，很显然Looper的作用域就是线程并且不同线程具有不同的Looper，这个时候通过ThreadLocal在线程中的存储。如果不采用ThreadLocal，那么系统就必须提供一个全局的哈希表供Handler查找指定线程的Looper，这样一来就必须提供一个类似于LooperManager的类了。

ThreadLocal另一个使用场景是复杂逻辑下的对象传递，比如监听器的传递，有些时候一个线程中的任务过于复杂，这可能表现为函数调用栈比较深以及代码入口的多样性，在这种情况下，我们有需要监听器能够贯穿整个线程的执行过程，这个时候可以怎么做呢？其实这时就可以采用ThreadLocal，采用ThreadLocal可以让监听器作为线程内部的全局对象而存在，在线程内部只要通过get方法就可以获取到监听器。如果不采用ThreadLocal，那么我们能想到的可能是如下两种方法：第一种方法是将监听器通过参数的形式在函数调用栈中进行传递，第二种方法就是将监听器作为静态变量供线程访问。上述两种方法都是有局限性的。第一种方法的问题是当函数调用栈很深的时候，通过函数参数来传递监听器对象这几乎是不可接受的，这会让程序的设计看起来很糟糕。第二种方法是可以接受的，但是这种状态不具有可扩充性的，比如同时有两个线程在执行，那么就需要提供两个静态监听器对象，如果有10个线程在并发执行呢？提供10个静态的监听器对象？这显然是不可思议的，而采用ThreadLocal，每个监听器对象都在自己的线程内部存储。

首先定义一个ThreadLocal对象，这里选择Boolean类型的，如下所示。

private ThreadLocal<Boolean> mBooleanThreadLcocal = new ThreadLocal<Boolean>();

然后分别在主线程、子线程1和子线2 中设置和访问它的值。

mBooleanThreadLocal.set(true);

new Thread("Thread#1"){
    @Override
    public void run(){
        mBooleanThreadLocal.set(false);
    }
}.start();

new Thread("Thread#2"){
    @Override
    public void run(){
        mBooleanThreadLocal.set(false);
    }
}

在上面的代码中，在主线程中设置mBooleanThreadLocal的值为true，子线程1中设置mBooleanThreadLocal的值为false，在子线程2中不设置mBooelanThreadLocal的值。然后分别在3个线程中通过get方法获取mBooleanThreadLocal的值，根据前面对ThreadLocal的描述，这个时候，主线程中应该是true，子线程1中应该是false，而子线程2中由于没有设置值，所以应该为null。

虽然在不同线程中访问的是同一个ThreadLocal对象，但是它们通过ThreadLocal获取的值却是不一样的，这就是ThreadLocal的奇妙之处。结合这个例子然后再看一遍前面对ThreadLocal的两个使用场景的理论分析，我们应该就能比较好地理解ThreadLocal的使用方法了。ThreadLocal之所以有这么奇妙的效果，是因为不同线程访问同一个ThreadLocal的get方法，ThreadLocal内部会从各个线程中取出一个数组，然后再从数组中根据当前ThreadLocal的索引去查找出对应的value值。很显然，不同线程中的数组是不同的，这就是为什么通过ThreadLocal可以在不同的线程中维护一套数据的副本并且彼此不干扰。

对ThreadLocal的使用方法和工作过程做了介绍后，下面分析ThreadLocal的内部实现，ThreadLocal是一个泛型类，它的定义为public class ThreadLocal<T>,只要清楚ThreadLocal的get和set方法就可以明白它的工作原理。

首先看ThreadLocal的set方法：

public void set(T value){
    Thread currentThread = Thread.currentThread();
    Values values = values(currentThread);
    if(values == null){
        values = initializeValues(currentThread);
    }
    values.put(this,value);
}

在上面的set方法中，首先会通过values方法来获取当前线程中的ThreadLocal数据，如果获取呢？其实获取的的方式也是很简单的，在Thread类的内部有一个成员专门用于存储线程的ThreadLocal数据: ThreadLocal.Values localValues, 因此获取当前线程其进程线程的ThreadLocal数据就变得异常简单了。如果localVaules的值为null，那么就需要进行初始化，初始化后再将ThreadLocal的值进行存储。下面看一下 ThreadLocal的值到底是如何在localValues中进行存储的。在localValues内部有一个数组： private Object[] table,ThreadLocal的值就存在在这个table数组中。下面看一下localValues是如何使用put方法将ThreadLocal的值存储到table数组中的。

void put(ThreadLocal<?> key,Object value){
    cleanUp();
    int firstTombstone = -1;
    for(int index = key.hash & mask;; index = next(index)){
        object k = table[index];
        if(k == key.reference){
            table[index +1] = value;
            return;
        }
        
        if(k == null){
            if(firstTombstone == -1){
                table[index +1] = value;
                size++;
                return;
            }
            
            table[firstTombstone] = key.reference;
            table[index + 1] = value;
            tombstones--
            size++;
            return;
        }
        if(firstTombstone == -1 && k == TOMBSTONE){
            firstTombstone = index;
        }
    }
}

上面的代码实现了数据的存储过程，这里不去分析它的具体算法，但是我们可以得出一个存储规则，那就是ThreadLocal的值在table数组中的存储位置总是为ThreadLocal的reference字段所标识的对象的下一个位置，比如ThreadLocal的reference对象在table数组中的索引为index，那么ThreadLocal的值在table数组中的索引就是index+1.最终ThreadLocal的值将会被存储在table数组中：table[index +1] = value。

上面分析了ThreadLocal的set方法，这里分析它的get方法：

public T get(){
    Thread currentThread = thread.currentThread();
    Values values = values(currentThread);
    if(values != null){
        Object[] = values.table;
        int index = has & values.mask;
        if(this.reference == table[index]){
            return (T) table[index +1];
        } else{
            values = initializeValues(currentThread);
        }
        return (T) values.getAfterMiss(this);
    }
}

可以发现，ThreadLocal的get方法的逻辑也比较清晰，它同样是取出当前线程的localVaules对象，如果这个对象为null那么就返回初始值，初始值由ThreadLocal的initiaLvauleue方法来描述，默认情况下为null；如果localValues对象不为null，那就取出它的table数组并找出ThreadLocal的reference对象在table数组中的位置，然后table数组中的下一个位置所存储的数据就是ThreadLocal的值。

从ThreadLocal的set和get方法可以看出，它们所操作的对象都是的当前线程的localValues对象的table数组，因此在不同线程中访问同一个ThreadLocal的set和get方法，它们对Thread所做的读/写操作仅限于各自线程的内部，这就是为什么ThreadLocal可以在多个线程中互不干扰地存储和修改数据。

10.2.2 消息对象的工作原理

消息队列在android中指MessageQueue，主要包含两个操作：插入和读取。读取操作本身会伴随这删除操作，插入和读取对应的方法分别为enqueueMessage和next，其中enqueueMessage的作用是往消息队列中插入一条消息，而next的作用是从消息队列中取出一条消息并将其从消息队列中移除。尽管MessageQueueu叫消息队列，但是它的内部实现并不是用的队列，实际上它是通过一个单链表的数据结构来维护消息列表，单链表在插入和删除上比较有优势：

boolean enqueueMessage(Message msg,long when){
    xxxx
    synchronized(this){
        xxxx
        msg.markInUse();
        msg.when = when;
        Message p = mMessages;
        boolean needWake;
        if(p == null || when < p.when){
            msg.next = p;
            mMessages= mBlocked;
        } else{
            needWake = mBlocked && p.target == null && msg.isAsynchronous();
            Message prev;
            for(;;){
                prev = p
                p = p.next;
                if(p == null || when < p.when){
                    break;
                }
                if(needWake && p.isAsynchronous()){
                    needWake = false;
                }
            }
            msg.next = ;
            prev.next = msg;
        }
        if(needWake){
            nativeWake(mPatr);
        }
    }
    return ture;
}

从enqueueMessage的实现来看，它的主要操作其实就是单链表插入操作，这里就不再过多解释了，下面看一下next方法的实现，next的主要逻辑如下所示。

Message next(){
    xxx
    int pendingIdleHandlerCount = -1;
    int nextPollTimeoutMillis = 0;
    for(;;){
        if(nextPolTimeoutMillis != 0){
            Binder.flushPendingCommands();
        }
        
        nativePollOnce(ptr,nextPollTimeoutMillis);
        synchronized(this){
            final long now = SystemClock.uptimeMills();
            Message prevMsg = null;
            Message msg = mMessages;
            if(msg != null && msg.target == null){
                do{
                    prevMsg = msg;
                    msg = msg.next;
                } while(msg != null && !msg.isAsynchronous());
            }
            if(msg != null){
                if(now < msg.when){
                    nextPollTimeoutMillis = (int)Math.min(msg.when - now,Integer.MAX_VALUE);
                } else{
                    mBlocked = false;
                    if(prevMsg != null){
                        prevMsg.next = msg.next;
                    }
                    msg.next = null;
                    return msg;
                }
            } else{
                nextPollTimeoutMillis = -1;
            }
            xxxx
        }
        xxxx
    }
}

可以发现next方法是一个无限循环的方法，如果消息队列没有消息，那么next方法会一直阻塞在这里。当有新消息来时，next方法会返回这条消息并将其从单链表中删除。

Lopper的工作原理

介绍了消息队列的主要实现，Looper在android的消息机制中扮演着消息循环的角色，具体来说就是说它会不停地从MessageQueue中查看是否有新消息，如果有新消息就会被立刻处理，否则就一直阻塞在那里。首先看一下它的构造方法，在构造方法中它会创建一个MessageQueue即消息队列，然后将当前线程的对象保存起来。

private Looper(boolean quiltAllowed){
    mQueue = new MessageQueue(quitAllowd);
    mThread = Thread.currentThread();
}

Handler的工作需要Looper，没有Loop而的线程就会报错，那么如何为一个线程创建Looper呢？其实很简单，通过Looper.prepare()即可为当前线程创建一个Looper，接着通过Looper.loop()来开启消息循环：

new Thread("Thread#2"){
    @Override
    public void run(){
        Looper.prepare();
        Handler handler = new Handler();
        Looper.loop();
    }
}

Looper除了prepare方法外，还提供了prepareMainLooper方法，这个方法主要是给主线程也就是ActivityThread创建Looper使用的，其本质也是通过prepare方法来实现的。由于主线程的Looper比较特殊，所以Looper提供了一个getgetMainLooper方法，通过它可以在任何地方获取到主线程的Looper。Looper也是可以退出的，Looper提供了quit和quit和Safely来退出一个Looper，二者的区别是：quit会直接退出Looper，而quitSafely只是设定一个退出标记，然后把消息队列中已有消息处理完毕后才安全地退出。Looper退出后，通过Handler发送的消息会失败，这个时候Handler的send方法会返回false。在子线程中，如果手动为其创建了Looper，那么在所有的事情完成以后应该调用quit方法来终止消息循环，否则这个子线程就会一直处于等待状态，而如果退出Looper以后，这个线程就会立刻终止，因此建议不需要的时候终止Looper。

Looper最重要的一个方法是loop方法，只有调用了loop后，消息循环系统才会真正地起作用。

Looper的loop方法的工作过程也比较好理解，loop方法是一个死循环，唯一跳出循环的方式是MessageQueue的next的next方法返回了null。当Looper的quit方法被调用时，Looper就会调用MessageQueue的quit或者quitSafely方法来通知消息队列退出，当消息队列被标记为退出状态时，它的next方法就会返回null。也就是说，Looper必须退出，否则loop方法就会无限循环下去。loop方法会调用MessageQueue的next方法来获取新消息，而next是一个阻塞操作，当没有消息时，next方法会一直阻塞在那里，这也导致loop方法一直阻塞那里。如果MessageQueue的next方法返回了新消息，Looper就会处理这条消息：

msg.target.dispatchMessage(msg);

这里的msg.target是发送这条消息的Handler对象，这样Handler发送的消息最终又交给它的dispatchMessage方法来处理了。但是这里不同的是，Handler的dispatchMesaage方法是在创建Handler时所使用的Looper中执行的，这样成功地将代码逻辑切换到指定的线程中去执行了。

10.2.4 Handler的工作原理

Handler的工作原理主要包含消息的发送和接收过程。消息的发送可以通过post的一系列方法以及send的一系列方法来实现，post的一系列方法最终是通过send的一系列方法来实现的。

public fianl boolean sendMessage(Message msg){
    return sendMessagedelayed(msg,0);
}

pulblic final boolean sendMessageDelayed(Message msg, long delayMillis){
    if(dlayMillis <0){
        delayMillis = 0
    }
    return sendMessageAtTime(msg,SystemColck.uptimeMillis() + delayMills)
}

public boolean sendMessageAtTime(Message msg, long uptimeMilis){
    MessageQueue queue = mQueue;
    if(queue == null){
        RuntimeException e = new RuntimeException(xxxxxxxx);
    }
    return enqueueMeassage(queue,msg,uptimeMillis);
}

private boolean enqueueMessage(MessageQueue queue,Message msg,long uptimeMillis){
    msg.target = this;
    if(mAsynchronous){
        msg.setAsynchronout(true);
    }
    return queue.enqueuMessage(msg,uptimeMillis);
}

可以发现，Handler发送消息的过程仅仅是向消息队列中插入了一条消息，MessageQueue的next方法就会返回这条消息给Looper，Looper收到消息后就开始处理了，最终消息由Looper交由Handler处理即Handler的dispatchMessage方法会被调用，这时Handler就进入了处理消息的阶段。

pulblic void dispatchMessage(Message msg){
    if(msg.callback != null){
        handleCallback(msg);
    } else{
        if(mCallback != null){
            if(mCallback.handleMessage(msg){
                return
            }
        }
        handleMessage(msg);
    }
}

首先，检查Message的callback是否为null，不为null就通过handleCallback来处理消息。Message的callback是一个Runnable对象，实际上就是Handler的post方法所传递的Runnable参数。handleCallback的逻辑也是简单：

private static void handleCallback(Message message){
    message.callback.run();
}

其次，检查mCallback是否为null，不为null就调用mCallback的handleMessage方法来处理消息。Callback是个接口：

public interface Callback{
    public boolean handleMessage(Message msg);
}

通过Callback可以采用如下方式来创建Handler对象：Handler handler = new Handler(callback)。那么Callback的意义是什么呢？源码里面的注释已经做了说明：可以用来创建一个Handler的实例但并需要派生Handler的子类。在日常开发中，创建Handler最常见的方式就是派生一个Handler的子类并充写Handler的子类并重写其handleMessage方法来处理具体的消息，而Callback给我们提供了另一种使用Handler的方式，当我们不想派生子类时，就可以通过Callback来实现。

最后，调用Handler的handleMessage方法来处理消息。Handler处理消息的过程可以归纳一个流程图：

Handler还有一个特殊的构造方法，那就是通过一个特定的Looper来构造Handler，它的实现如下所示。通过这个构造方法可以实现一些特殊的功能。

public Handler(Looper looper){
    this(looper,null,false);
}

下面看一下Handler的一个默认构造方法public Handler，这个构造方法会调用下面的构造方法。很明显，如果当前线程没有Looper的话，就会抛出异常，这也解释了在没有Looper的子线程中创建Handler会引发程序异常的原因。

10.3 主线程的消息循环

android的主线程就是ActivityThread，主线程的入口方法为main，在main方法中系统会通过Looper.prepareMainLooper()来创建主线程的Looper以及MessageQueue，并通过Looper.loop()来开启主线程的消息循环。

主线程的消息循环开始了以后，ActivityThread还需要一个Handler来和消息队列进行交互，这个Handler就是ActivityThread.H，它内部定义了一组消息类型，主要包含了四大组件的启动和停止等过程。

ActivityThread通过ApplicationThread和AMS进行进程间通信，AMS以进程间通信的方式完成ActivityThread的请求后会回调ApplicationThread中的Binder方法，然后ApplicationThread会向H发送消息，H收到消息后会将ApplicationThread中的逻辑切换到ActivityThread中去执行，即切换到主线程中去执行，这个过程就是主线程的消息循环模型。