Android消息机制-Handler

基本概述

在Android开发中提到消息机制应该所有人都不陌生，但是估计也很少有人能把消息机制详细地说出个所以然来，我们在开发过程中，有很多技术痛点，就是明明很多时候我们在用的东西，我们却不知道是为什么，它具体是个什么东西，很多时候我们只在乎它如何被拿来用，而不去关心更深层次的东西，也许这就是初中级向上进阶的阻碍吧。还好，我意识到了这一点，尽力去了解更多事实的真相…一不小心说了这么多废话，言归正传吧。

在Android中，我们提到的消息机制常常指的就是Handler机制，Handler是Android中的上层接口，在开发的过程中，我们可以利用Handler将一件事情切换到Handler所在的线程中去执行（好好理解这句话）。为什么会有这样的机制出现？我们来考虑一下，在实际的操作中，我们发现，Handler机制的运用主要是在UI更新上，当我们需要做一个耗时操作时，我们不可能在mainThread中做这个事情，因为ANR的存在，这时我们需要开启一个新的线程去做这个事情，当事件完成后再通过Handler去告诉mainThread现在可以更新UI了。这就是对消息机制的一个很宽泛的描述。这时候，我们应该考虑一个问题？为什么我们不干脆在开启的新线程中更新UI呢，应该很多人会说是因为Android不允许这样做？那么， 为什么不允许呢？

如果不限制UI的更新规则（即可在任何线程中操作UI）会带来什么样的坏处？如果所有线程都可以改变UI，那我们如何保证UI朝着我们预期的方向发展？这就像是共享内存一样，同时的操作会让UI的状态变得不可预期。那么，如果加上锁机制呢？这样必定会大大降低UI的访问效率，因为锁机制会阻塞线程，就会让我们的应用在很多情况下看起来像失了智一样，卡顿严重，所以Handler机制油然而生了。

---

工作原理

Android的Handler机制它的工作原理是怎样的呢？我们在线程中创建一个Handler对象，当使用它的时候会发现系统会报这样的错：

can not create handler inside thread that has not called Looper.prepare();

它描述了在一个线程中我们不能在没有Looper的前提下去使用Handler，也就是说Handler机制的实现需要Looper这个东西，那么Looper是啥呢？我们可以通过Looper.prepare()在当前线程中创建一个Looper对象，当我们查阅源码的时候可以发现，Looper.prepare()做了什么，实际上它创建了一个MessageQueue（消息队列）。Looper相关源码如下：

public static void prepare(){    prepare(true);}public static void prepare(boolean quitAllowed){    if( sThreadLocal.get()!=null ){        ...    }    sThreadLocal.set(new Looper(quitAllowed));}public Looper(){    mQueue = new MessageQueue(quitAllowed);    mThread = Thread.currentThread();}

在创建了Looper之后，我们不仅仅得到了looper对象，还得到了一个消息队列messageQueue，这时候才构建了一个完整的Handler机制。它们是如何分工的。

线程内部负责处理业务逻辑，looper的作用负责消息的存取查阅，其中messageQueue是消息的存储结构，它是单链表形式，looper负责消息的轮询，handler负责发送和处理消息。looper、线程、messageQueue是一一对应的，在不同的线程中它们各自有着对应的模块。我们还能看到创建的looper对象被放入了ThreadLocal中去，这样的作用是，各个线程中的Looper对象是相对独立，谁也影响不到谁，如何达到这个效果的呢？我们就来看一下ThreadLocal这个类。

在实际使用的过程中我们发现，运行在主线程的Handler我们不需要事先为它创建一个Looper来进行消息管理，这是为什么？这是因为系统早已经默认给主线程创建了Looper对象。

---

ThreadLocal类

从它的名字来看，它似乎是个什么线程，其实不然ThreadLocal不是线程但和线程有关，具体的来讲，它是一个和线程相关的存储方式。它是线程内部的存储方式，只有在当前线程内可以获得这个值。它的内部是如何实现的？我们通过查看源码不难发现，它是一个类似于数组且以key-value方式存储的一种数据格式。

ThreadLocal内部存储是数组结构，它以当前线程作为Key来区别各个线程之间的数据，查看源码可以发现，在偶数位它用来存放当前线程，在此的后一位来存放具体的数据。所以通过不同的线程可以定位到不同位置的key，然后向后延一位就能得到存储的数据，这就是ThreadLocal能做到各个线程间互不干涉的所在。它最典型的应用就是Handler机制中Looper的构建。

我们下面来举个很简单的例子，我们来看伪代码：

private ThreadLocal<Boolean> mThreadLocal = new ThreadLocal<Boolean>;// 主线程mThreadLocal.set(true);Log.i("threadLocal", mThreadLocal.get());// 线程1new Thread("Thread1"){    @ovrride    public void run(){        mThreadLocal.set(false);        Log.i("threadLocal", mThreadLocal.get());    }}// 线程2new Thread("Thread2"){    @ovrride    public void run(){        Log("threadLocal", mThreadLocal.get());    }}

上面的例子中，我们分别在主线程，线程1，线程2中对mThreadLocal变量进行了操作，并且在这三个地方分别打印该变量的值，如果是普通的变量，那么我想这些打印的值恐怕只能靠猜了…，而现在，我们了解了ThreadLocal的存储原理，不难分析出各个位置打印的值。

因为它们不会相互影响， 所以在主线程中设置了true，那么我以主线程去保存数据，我在打印的时候还以主线程为key去获取对应的值，这个值一定是当时存储的值true。同样的判断，在线程1中打印的值是false。而在线程2中，我们从来没有在对应的存储空间上为线程2来开辟存储空间，所以它的值应该是null。

---

消息队列

我们在上面的介绍中可以知道，Looper对象是在其内部创建了一个消息队列用来存储消息的，所以在了解Looper之前，我们有必要知道消息队列的一些事情。

消息队列在Android中指的就是MessageQueue，从它的名字上来看是个队列，实际上它的内部实现不是队列，而是单链表结构的，它提供了消息机制中消息的插入和读取。

说点其他的，我们应该知道链表的概念，链表的概念是从C语言中引用而来的，它表示每个消息是相连的，每一个消息在链表中称作一个节点，节点不仅仅保存数据，它还保存了一个指针用来指向下一个节点的地址，所以它的优点在可以高效率地插入、删除。因为消息队列常用的操作就是插入消息和取出消息，而取出消息实质上就是将该节点从数据结构中剔除，所以消息队列会选取链表结构来存储消息。

---

Looper

我们从上面的分析中可以知道，Handler的工作需要Looper，也知道可以通过Looper.prepare()为Handler创建一个Looper。我们通过Looper.loop()开启Looper轮询，此时Looper会不停的轮询消息队列中的数据，一有消息通过Handler发出时，Looper就能捕获这个消息，并通过这个函数来处理：

msg.target.dispatchMessage(msg)

其实，msg.target实际上就是发出消息的那个Handler，调用Handler的dispatchMessage(msg)函数来最终处理这个消息。

每个线程都有自己的Looper，非主线程我们是不可预期的，但是主线程永远只有一个，所以我们可以通过静态方法Looper.getMainLooper()随时获取主线程的Looper。

我们说过，如果消息队列中不存在消息时，Looper将会处于阻塞状态，这无疑增加了系统的开销，所以当我们确定不再有消息传递进来时，可以通过Looper.quit()或Looper.quitSately()方法来退出Looper。前者是一调用立马退出Looper，后者是需要将现有的消息处理完之后再退出Looper，相对来讲后者更有责任心一些，但这也不一定就是必要的。

---

Handler

说了这么多是时候来认识最后的东西了。从以上种种我们的介绍，我们可以很清晰地知道，在Handler消息机制中，Handler做扮演的角色的作用就是发送和接收消息。

我们经常性的操作来用语言描述一次。我们在主线程中定了一个Handler，由于系统已经默认帮我们把Looper创建好了，所以我们不需要再去创建Looper。这时候我们需要向服务器进行一个耗时的请求，那么我们开启了线程a去请求数据，当数据请求完成后，我们希望数据可以在UI上（即主线程）上展示，所以我们利用Handler将线程a取到的数据发送出去。Looper循环机制接收并处理了该消息，最终该消息交由Handler所在的线程（主线程）处理。我们通过Handler机制将UI操作从线程a中搬到了主线程中去。

那么Handler是如何处理消息的？我们看到 msg.target.dispatchMessage(msg) 这个函数，略过长篇大论的判断和callback，在日常开发中，创建Handler最常用的就是派生一个Handler的子类，并重写handlerMessage()方法来处理具体的消息。

---

进一步认清Handler

当我们了解以上Android的消息机制后，我们不禁沾沾自喜，偶尔看到了这样的代码：

new Handler().postDelayed(new Runnable(){    @Override    public void run(){        Toast.makeText(mContext, "hellow", Toast.LENGHT_LONG).show();    }}, 1000);

乍一看，咦？在非主线程中更新UI？竟然不报错…，好吧我们来分析一下吧。首先我们来看Handler的构造函数。

1. Handler的构造函数

public Handler(){    this(null, false);}public Handler(Callback callback, boolean async) {    mLooper = Looper.myLooper();    if (mLooper == null) {        throw new RuntimeException(            "Can't create handler inside thread that has not called Looper.prepare()");    }    mQueue = mLooper.mQueue;    mCallback = callback;    mAsynchronous = async;}

此时Handler做了一些准备工作，比如准备Looper等，此时一个变量mCallback==null。此时我们将Looper中的队列和Handler中的队列关联起来。

2. 我们再来看postDelayed()函数

public final boolean postDelayed(Runnable r, long delayMillis){    return sendMessageDelayed(getPostMessage(r), delayMillis);}private static Message getPostMessage(Runnable r) {    Message m = Message.obtain();    m.callback = r;    return m;}

很显然我们将Runnable这个线程设置为了Message的callback属性。我们经过跟踪，依次调用了这些方法。

public boolean sendMessageAtTime(Message msg, long uptimeMillis) {    MessageQueue queue = mQueue;    if (queue == null) {        RuntimeException e = new RuntimeException(                this + " sendMessageAtTime() called with no mQueue");        Log.w("Looper", e.getMessage(), e);        return false;    }    return enqueueMessage(queue, msg, uptimeMillis);}private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {    msg.target = this;    if (mAsynchronous) {        msg.setAsynchronous(true);    }    return queue.enqueueMessage(msg, uptimeMillis);}

从 msg.target = this; 这句话看出msg.target就是Handler，也就是说此时MessageQueue和Handler发生了联系，这个enqueueMessage方法很显然就是我们在MessageQueue中讲的入列方法，即将消息加入到了对应线程的Looper消息队列中去了，此时Looper获取到了这个消息，并且我们上面讲Looper时提到了Looper调用这个函数来处理消息msg.target.dispatchMessage(msg)，msg.target是什么？就是Handler啊，所以这个消息由Handler的dispatchMessage(msg)函数来处理消息。

3. dispatchMessage()方法

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

通过步骤2可以知道，msg.callback!=null，而是runnable。所以执行handlerCallback(msg);

4. handlerCallback(msg)方法

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

这样，就会执行我们在Activity 的Runnable 中的run 方法了，也就是显示Toast。所以为什么这个Toast是没问题的呢？

这是因为，我们将Runnable设置给了Message的属性callback，这个callback连同Message被传递到Handler所在的线程（即UI线程）中去了，所以它实际上试运行在UI线程上的。

---

至此，我们应该对Handler机制有了比较深刻的理解了。

如果有你认为不恰当的描述，不妨留言告诉我…