转载注明出处：http://www.jianshu.com/p/e72aba99012a
简介
在Android开发中经常会遇见异步消息处理的情况，特别是网络请求成功或者失败之后需要更新UI，但是更新UI只能在UI线程里面进行，否则就会报错，这个时候就需要通知UI线程去更新UI，于是Handler出现了。
Handler的使用
Handler的使用非常简单，直接看例子。
private static final int KEY_REQUEST_SUCCESS = 0x01;
private Handler mHandler = new Handler() {
@Override
public void handleMessage(Message msg) {
//这里是在UI线程了
if(msg.what == KEY_REQUEST_SUCCESS) {
//更改UI
}
}
};
... ...//一些其他操作
private void changeUI() {
Message message = mHandler.obtainMessage();
message.what = KEY_REQUEST_SUCCESS;
mHandler.sendMessage(message);
}
声明了一个Handler成员变量mHandler，并复写了其中的handleMessage(Message msg)方法，然后使用mHandler发送一条消息，最终会调用到handleMessage方法，然后进行UI更新操作。
看见这么好用的异步消息处理方法，肯定会去看看内部是怎么实现消息的调度的。
Handler内部信息调度
消息进入队列
所有的消息都是使用sendMessage方法发送出去(还有其他类似方法)，就从sendMessage开始查看。
public final boolean sendMessage(Message msg)
{
return sendMessageDelayed(msg, 0);
}
...
public final boolean sendMessageDelayed(Message msg, long delayMillis)
{
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, SystemClock.uptimeMillis() + delayMillis);
}
...
public boolean sendMessageAtTime(Message msg, long uptimeMillis) {
MessageQueue queue = mQueue;
if (queue == null) {
//异常处理
}
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);
}
我们可以看到，Handler发送消息最终都会调用到sendMessageAtTime方法，在这个方法里面就做了一件事，将消息放入一个消息队列中。记住msg.target这个赋值操作，然后我们去看看在放入队列时候都做了些什么。
boolean enqueueMessage(Message msg, long when) {
//异常处理
synchronized (this) {
//异常处理
msg.markInUse();
msg.when = when;
Message p = mMessages;
boolean needWake;
if (p == null || when == 0 || when < p.when) {
// New head, wake up the event queue if blocked.
msg.next = p;
mMessages = msg;
needWake = 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 = p;
prev.next = msg;
}
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}
从代码中很清晰的可以看见。
- 如果新消息首次加入队列，或者新消息延迟时间要小于队列首个消息延迟时间，就将新消息放在队列首部。
- 如果队列不为空，新消息延迟时间并不是最短，就将新消息插入到队列的某个位置。
总之，新消息插入队列后，消息队列是按延迟时间长短排序的一个有序队列，延迟时间越短，越靠近队列首部。这样，就可以猜测，系统一次拿去队列中的消息，然后进行分发处理。
消息调度分发
我们都知道了消息被加入了一个按延迟长短排序的有序队列，消息仅仅加入了队列还需要有地方处理才行，那我们就看看哪里处理了这个队列。
首先我们来查看一下Handler的成员变量中的MessageQueue是在哪里初始化或者赋值的，从源头开始查找，顺藤摸瓜。
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;
}
原来是直接用Looper赋值的，那会不会对这个消息队列的处理就在Lopper当中呢？赶紧去看看。Looper的代码不多，很快就看到了loop()这个方法。
public static void loop() {
final Looper me = myLooper();
//异常处理
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
Printer logging = me.mLogging;
if (logging != null) {
logging.println(">>>>> Dispatching to " + msg.target + " " +
msg.callback + ": " + msg.what);
}
msg.target.dispatchMessage(msg);
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();
}
}
就是在这里！！在loop()方法中有一个循环一直在取出消息队列中的消息然后进行分发工作。我们注意这一行代码msg.target.dispatchMessage(msg)，调用了msg.tartget中的一个分发消息的方法，还记得在上面消息进入消息队列时候，注意的msg.target的赋值操作吗？msg.target其实就是我们发送消息的Handler！！！赶紧去查看一下消息分发和处理过程吧。
消息处理
直接去查看Handler中的dispatchMessage(msg)方法，发现这个方法比较简单。
public void dispatchMessage(Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}
很容易理解如果Message和Handler的CallBack成员变量都为空的话，直接调用Handler本身的handlerMessage(Message msg)方法，这个方法就是我们在实例化Handler时候复写的一个方法，最终消息的具体处理过程就回到了我们手中。
调度图
Handler发送Message消息，消息进入消息队列，Looper不断的从消息队列中取出Message，然后交给Handler处理，处理的代码交给用户处理。这样我们就可以在非UI线程中发送Message消息，但是最终的处理回到了UI线程，进行一些UI操作。
其他用法
虽然Handler是用于处理异步消息的，但是由于它本身有一个延迟的功能，所以Handler也可以做一个定时任务处理器，类似广告结束倒计时等等都可以用到Handler。
Tips
Handler虽然看起来使用简单，但是如果仔细的话，会发现，这一套机制对Message的管理是非常严格的。将消息从消息队列中删除或者消息处理完毕之后，并不是直接将Message舍弃，而是调用了Message本身的recycleUnchecked()方法。
void recycleUnchecked() {
// Mark the message as in use while it remains in the recycled object pool.
// Clear out all other details.
flags = FLAG_IN_USE;
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = -1;
when = 0;
target = null;
callback = null;
data = null;
synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) {
next = sPool;
sPool = this;
sPoolSize++;
}
}
}
首先将Message里面一些成员变量进行了重置操作，在最后面我们发现了MAX_POOL_SIZE这个属性！！这说明在这一套机制中，Message数量是有上限的。心细的人就会发现，如果每次使用Message时候都使用new实例化一个的话，总会有一个时间点，Message数量会超出最大限制数。
所以我们在获取Message的时候，一定要使用Handler.obtainMessage()方法或者Message.obtain(Handler h)方法。
如果使用new去实例化Message的话，这里面有坑，慎重。
Q&A
Looper类的loop()方法处理完队列之后就会停止循环，如果有新的消息加入，系统是怎么调用到Looper的loop()的呢？
在将信息加入到消息队列后，会运行nativeWake(mPtr)这一行代码，nativeWake()是一个本地的方法，是通过这个方法在系统的底层去调用Looper.loop()方法。
由Handler发送出一个延迟任务消息，这个消息还未被处理，怎么撤回？
Handler撤回消息有五种方法。
- removeCallbacks(Runnable r)
- removeCallbacks(Runnable r, Object object)
- removeMessages(int what)
- removeMessages(int what, Object object)
- removeCallbacksAndMessages(Object object)
但是实际上是在MessageQueue队列中删除了消息，MessageQueue提供了三种删除消息方法
- removeMessages(Handler h, int what, Object object)
- removeMessages(Handler h, Runnable r, Object object)
- removeCallBackAndMessage(Handle h, Runnable r, Object object)
参数都是Message中的成员变量(Handler参数会在Handler调用MessageQueue删除消息方法传入，也就是Handler本身)，当传入参数与Message中属性相等时候会将消息从消息队列中删除。参数object是补充条件，object传入null，则前面条件满足即可；object不为空，所有条件都需要满足。
void removeCallbacksAndMessages(Handler h, Object object) {
if (h == null) {
return;
}
synchronized (this) {
Message p = mMessages;
// Remove all messages at front.
while (p != null && p.target == h
&& (object == null || p.obj == object)) {
Message n = p.next;
mMessages = n;
p.recycleUnchecked();
p = n;
}
// Remove all messages after front.
while (p != null) {
Message n = p.next;
if (n != null) {
if (n.target == h && (object == null || n.obj == object)) {
Message nn = n.next;
n.recycleUnchecked();
p.next = nn;
continue;
}
}
p = n;
}
}
}
从代码中很容易看出来，如果调用MessageQueue的removeCallbacksAndMessage方法时候，object传入是null，会将消息队列中所有消息都给清空。所以这样调用mHandler.removeCallbacksAndMessage(null)时候，会清空消息队列中所有信息。
待完善...
