Android消息机制（四）：Handler

Handler是我们在开发中接触到最多的类了。
他可谓是Android消息机制中的总调度员。他几乎无所不能：创建消息可以是他，发消息是他，处理消息是他，移除消息还是他。所以，很多开发者对Handler很熟悉，对其背后底层默默工作的MessageQueue和Looper反而比较陌生。

我们先看一下Handler的类结构：

Handler类结构.jpg

从图中我们可以看出，其包含了文章开头所讲的所有功能函数。
Handler的主要功能有：

1. 构造函数
2. 获取消息
3. 发送消息（消息入队）
4. 处理消息（消息的真正处理逻辑）
5. 移除消息（消息出列）

构造函数

Handler的构造函数最终目的就是设置Handler中的几个重要的成员变量：mLooper,mQueue,mCallback,mAsynchronous。

filed	含义	说明
mLooper	消息循环器Looper	该Handler所对应的Looper
mQueue	消息队列MessageQueue	该Handler所处理消息所在的消息队列
mCallback	Handler级别回调	Handler处理所有send Message系列消息时的统一回调。(下文会细述)
mAsynchronous	是不是异步处理方式	其实只有一个作用，就是在设置Barrier时仍可以不受Barrier的影响被正常处理，如果没有设置 Barrier，异步消息就与同步消息没有区别

代码如下：

    public Handler(Callback callback, boolean async) {
        //这个会判断一个警告，意思是说Handler class应该是一个静态类，否则可能导致内存泄漏，
        // 至于为什么可以参考链接http://stackoverflow.com/questions/11407943/this-handler-class-should-be-static-or-leaks-might-occur-incominghandler
        if (FIND_POTENTIAL_LEAKS) {
            final Class<? extends Handler> klass = getClass();
            if ((klass.isAnonymousClass() || klass.isMemberClass() || klass.isLocalClass()) &&
                    (klass.getModifiers() & Modifier.STATIC) == 0) {
                Log.w(TAG, "The following Handler class should be static or leaks might occur: " +
                    klass.getCanonicalName());
            }
        }
        //必须先执行Looper.prepare()，才能获取Looper对象，否则为null.
        mLooper = Looper.myLooper();
        if (mLooper == null) {
            throw new RuntimeException(
                "Can't create handler inside thread that has not called Looper.prepare()");
        }
        mQueue = mLooper.mQueue;//消息队列，来自Looper对象
        mCallback = callback;//回调方法
        mAsynchronous = async; //设置消息是否为异步处理方式
    }

代码比较简单，过程为：

1. 首先判断下是不是有可能内存泄漏（该问题我会有单独的文章阐述），
2. 然后得到当前线程的Looper赋值给mLooper，如果mLooper为空，说明当前线程并不是一个可接受消息的线程，需要在线程开启时用Looper.prepare()和Looper.loop()来初始化才可以继续。
3. 为mQueue和mCallback、mAsynchronous等成员函数赋值。

Handler也是在这里和Looper、MessageQueue联系起来的。

获取消息

Handler中通过一系列的obtainMessage()方法，封装了Message从消息池中取到符合要求的消息的方法。

public final Message obtainMessage()
public final Message obtainMessage(int what)
public final Message obtainMessage(int what, Object obj)
public final Message obtainMessage(int what, int arg1, int arg2)
public final Message obtainMessage(int what, int arg1, int arg2, Object obj)

这些方法都会将该Handler设置为该消息的target。

发送消息

Handler发送消息主要有两种方法：post系列方法和send系列方法。

1. post runnable 系列

final boolean post(Runnable r)
final boolean postAtTime(Runnable r, long uptimeMillis)
final boolean postAtTime(Runnable r, Object token, long uptimeMillis)
final boolean postDelayed(Runnable r, long delayMillis)
final boolean postAtFrontOfQueue(Runnable r)

2. send Message 系列

final boolean sendEmptyMessage(int what)
final boolean sendEmptyMessageDelayed(int what, long delayMillis)
final boolean sendEmptyMessageAtTime(int what, long uptimeMillis)
final boolean sendMessageDelayed(Message msg, long delayMillis)
boolean sendMessageAtTime(Message msg, long uptimeMillis)
final boolean sendMessageAtFrontOfQueue(Message msg) 

他们之间的调用关系如图：

Handler发送消息调用过程

他们最终都是将某个消息压入到MessageQueue中，等待处理。区别在于：

1. 发送机制不同。
   post runnable系列处理的参数是封装了需执行动作的runnable，首先将runnable封装成一个Message，然后再调用对应的send系列函数把最终它压入到MessageQueue中。
   send message系列处理的参数直接是Message，经过一些赋值后，直接压入到MessageQueue中。
2. 最终处理机制不同。
   post runnable系列方法在被封装成Message时，设置了其Callback为该runnable，最终在Handler的dispatchMessage里面会交由handlerCallback方法处理，执行其runnable的run()方法。
   send message系列方法最终会受到Handler的Callback影响，或交由Handler的handleMessage()方法处理。
3. 两者本质没有区别，区别在于是否post runnable系列方法可以在不继承Handler并重写handleMessage()方法的前提下对一些不可预知的消息类型做相应处理。比较常见的例子如SDK中的这些方法：

Activity.runOnUiThread(Runnable)
View.post(Runnable)
View.postDelayed(Runnable, long)

这也是post系列方法存在的意义。

处理消息

从上一篇文章中我们可以知道，Looper循环过程中，取出一条消息后，是通过调用该消息对应的Handler的dispatchMessage(Message msg)对消息进行处理。

code in Looper.loop():

msg.target.dispatchMessage(msg); //msg.target就是与此线程关联的Handler对象，调用它的dispatchMessage处理消息

Handler处理消息的源码如下：

    /**
     * 在这里处理系统消息
     * Handle system messages here.
     */
    public void dispatchMessage(Message msg) {
        if (msg.callback != null) {//post系列方法走这里
            handleCallback(msg);
        } else {//sendMessage系列方法走这里
            if (mCallback != null) {//Handler构造函数中定义了Callback的这里处理
                if (mCallback.handleMessage(msg)) {
                    return;
                }
            }
            handleMessage(msg);
        }
    }

其处理逻辑流程如图：

Handler处理消息.jpg

其实逻辑很简单。

1. 首先看是否这条消息是否有已被预设了callback，如果有，直接调用handlerCallback(msg)处理预设好的callback。至此，满足该条件的的消息处理流程结束。
2. 其次，如果不符合1.中的情况，看该Handler在被创建时，是否有设定Handler级别的Callback，如果有，处理之。这里和1.中所描述情况的区别是，Handler级别的Callback是有返回值的，处理完后会根据返回值看是否需要进一步处理。
3. 如果Message没有被预设Callback，也没有Handler级别的Callback（或者有但需要进一步处理），必须在 由子类重写的handleMessage(Message msg)中做最后处理。大多数情况下的消息都在这里处理。

根据Handler中的发送消息的方法源码可知，Post系列方法的都会调用getPostMessage(Runnable r)函数将一个Runnable对象封装成一条Message，封装时，会将该runnable参数作为消息的callback。所以，我们可以得出结论：post runnable系列方法消息的最终都在handleCallback(msg)中处理。

移除消息

根据消息入列的区别，移除消息也分为removeMessages和removeCallbacks两系列。和发送消息类似，
Handler的移除消息最终还是对其对应的MessageQueue的操作，从中移除符合条件的消息。

使用Handler的过程中，为避免Activity调用onDestroy后，Handler的MessageQueue中仍存在Message，一般会在onDestroy中调用removeCallbacksAndMessages()方法。

几个问题

2. 为什么Handler的构造函数需要一个Callback
   从Handler的消息处理逻辑可以看出,一旦一个Handler在构造时，Handler级别的Callback 被初始化。是所有没有单独预设Callback的Message(post系列方法发送的消息除外的消息)都会被该Callback处理。
   我们可以在Handler级别的Callback中加入由该Handler处理的所有类型消息的共同逻辑。
3. Handler是如何与Looper和MessageQueue联系起来的。
   是通过构造函数中联系起来的，Handler的一堆构造函数，其实最终目的就是设置Handler中的几个重要的成员变量：mLooper,mQueue,mCallback,mAsynchronous。首先设置好mLooper，mLooper中有一个和其一一对应的变量：mQueue。
   所以，Hander是通过其对应的mLooper，进而和线程中的消息队列mQueue联系起来的。
4. post系列方法传入的Runnable中若持有Context的引用，会造成内存泄漏吗？
   显然是会的。Runnable会被封装成Message加入到消息队列中，只要该消息不被处理或者移除，消息队列就会间接持有Context的强引用，造成内存溢出，所以，如果该Handler是针对一个Activity的操作，在Activity的 onDestory()回调函数中中一定要调用removeCallbacksAndMessages()来防止内存泄漏。