Handler Message种类
Handler的Messgae种类分为三种：
普通消息
异步消息
屏蔽消息
此中普通消息又称为同步消息，我们平常发的消息根本都是同步消息，在这里不做讨论。
异步消息
通常我们利用Handler想消息队列中添加的Message都是同步的，如果我们想要添加一个异步的Message，有以下两种方式：
1、Handler的构造方法有个async参数，默认的构造方法此参数是false，只要我们在构造handler对象的时间，把该参数设置为true就可以了。
public Handler(Callback callback, boolean async) {
......省略代码
mQueue = mLooper.mQueue;
mCallback = callback;
mAsynchronous = async;
}
可以看到，async设置为true后，对全局的mAsynchronous设置为true。然后在enqueueMessage()方法里，调用msg.setAsynchronous(true)，将message设置为异步的。
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
2、在创建Message对象时，直接调用Message的setAsynchronous()方法。
在一样平常情况下，异步消息和同步消息没有什么区别，但是一旦开启了同步屏蔽以后就有区别了。
同步屏蔽
一样平常来说，MessageQueue内里的全部Message是按照时间从前以后有序分列的。
同步屏蔽消息就是在消息队列中插入一个屏蔽，在屏蔽之后的全部普通消息都会被挡着，不能被处置惩罚。不外异步消息却例外，屏蔽不会挡住异步消息，因此可以以为，屏蔽消息就是为了确保异步消息的优先级，设置了屏蔽后，只能处置惩罚厥后的异步消息，同步消息会被挡住，除非打消屏蔽。
同步屏蔽是通过MessageQueue的postSyncBarrier方法开启的。
private int postSyncBarrier(long when) {
// Enqueue a new sync barrier token.
// We don't need to wake the queue because the purpose of a barrier is to stall it.
synchronized (this) {
// 1
final int token = mNextBarrierToken++;
// 2
final Message msg = Message.obtain();
msg.markInUse();
msg.when = when;
msg.arg1 = token;
// 3
// 指向前一个Message
Message prev = null;
// 消息队列中的第一个Message赋值给p
Message p = mMessages;
if (when != 0) {
// 4 通过p的时间和屏蔽的时间，确定屏蔽消息插入的位置
while (p != null && p.when <= when) {
prev = p;
p = p.next;
}
}
// 5 阐明屏蔽消息不是插入消息队列的头部
if (prev != null) { // invariant: p == prev.next
msg.next = p;
prev.next = msg;
} else {
// 6 屏蔽消息在消息队列的头部
msg.next = p;
mMessages = msg;
}
return token;
}
}
第一步，获取屏蔽的的唯一标示，标示从0开始，自加1。
第二步，从Message消息对象池中获取一个msg，设置msg为正在利用状态，而且重置msg的when和arg1，arg1的值设置为token值。但是这里并没有给tareget赋值。以是msag的target是否为空是判断这个msg是否是屏蔽消息的标记。
第三步，创建变量pre和p，为下一步做预备。此中p被赋值为mMessages，mMessages指向消息队列中的第一个元素，以是此时p指向消息队列中的第一个元素。
第四步，通过对队列中的第一个Message的when和屏蔽的when举行比力，决定屏蔽消息在整个消息队列中的位置，由于消息队列中的消息都是按时间排序的。
第五步，prev != null，代表不是消息的头部，把msg插入到消息队列中。
第六步，prev == null，代表是消息队列的头部，把msg插入消息的头部。
我们通常通过Handler发送消息handler.sendMessage(),终极都会调用Handler.java中的enqueueMessage()方法。
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this;
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
可以看到，enqueueMessage()方法里为msg设置了target字段。
而上面的postSyncBarrier()，也是从Message消息对象池中获取一个msg,插入到消息队列中，唯一的差别是没有设置target字段。以是从代码层面上讲，屏蔽消息就是一个target为空的Message。
屏蔽消息的工作原理
通过postSyncBarrier方法屏蔽就被插入到消息队列中了，那么屏蔽是怎样挡住普通消息只允许异步消息通过的呢？
我们知道Handler的消息处置惩罚是在Looper.loop（）从消息队列中获取消息，并交给Handler处置惩罚的，此中是通过MessageQueue是通过next方法来获取消息的。查察一下next()的源码，
Message next() {
// .....省略代码
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;;) {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
nativePollOnce(ptr, nextPollTimeoutMillis); synchronized (this) { // Try to retrieve the next message. Return if found. final long now = SystemClock.uptimeMillis(); // 指向前一个message Message prevMsg = null; // 初始时指向第一个message Message msg = mMessages; // 1 msg.target == null阐明碰到消息屏蔽 if (msg != null && msg.target == null) { // 能进入这个if，阐明此时的msg是屏蔽消息 // 循环遍历，退出循环的条件是，message到末端了，大概 // msg是异步消息 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 {
// Got a message.
mBlocked = false;
if (prevMsg != null) {
// 将msg从消息链表中移除
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
// 返回msg
return msg;
}
从上面的代码可以看出，msg.target == null时阐明此时的msg是屏蔽消息，此时会进入到循环，遍历移动msg的位置，知道移动到的msg是异步message则退出循环，也就是说，循环的代码会过滤掉全部的同步消息，直到取出异步消息为止。
当设置了同步屏蔽之后，next函数将会忽略全部的同步消息，返回异步消息。换句话说就是，设置了同步屏蔽之后，Handler只会处置惩罚异步消息。再换句话说，同步屏蔽为Handler消息机制增长了一种简单的优先级机制，异步消息的优先级要高于同步消息。
移除同步屏蔽
同步屏蔽的移除是在MessageQueue.java的removeSyncBarrier()方法。
public void removeSyncBarrier(int token) {
// Remove a sync barrier token from the queue.
// If the queue is no longer stalled by a barrier then wake it.
synchronized (this) {
Message prev = null;
Message p = mMessages;
// 循环遍历，直到碰到屏蔽消息时推退出循环
while (p != null && (p.target != null || p.arg1 != token)) {
prev = p;
p = p.next;
}
if (p == null) {
throw new IllegalStateException("The specified message queue synchronization "
+ " barrier token has not been posted or has already been removed.");
}
final boolean needWake;
if (prev != null) {
// 删除屏蔽消息p
prev.next = p.next;
needWake = false;
} else {
mMessages = p.next;
needWake = mMessages == null || mMessages.target != null;
}
p.recycleUnchecked();
// If the loop is quitting then it is already awake. // We can assume mPtr != 0 when mQuitting is false. if (needWake && !mQuitting) { nativeWake(mPtr); }}}
删除屏蔽消息的方法很简单，就是不停遍历消息队列，知道找到屏蔽消息，退出循环的条件有两个，一是p.target == null，阐明是屏蔽消息，二是p.arg1 == token，也阐明p是屏蔽消息，由于在屏蔽消息入队的时间，设置过 msg.arg1 = token。找到屏蔽消息后，把它从消息队列中删除并接纳。
同步屏蔽的应用场景
同步屏蔽一样平常在一样寻常开辟中比力少用，而在体系源码中就有利用。Android体系中的UI更新干系的消息即为异步消息，须要优先处置惩罚。
16ms左右革新UI，而是60hz的屏幕，即1s革新60次。
在Android中什么是异步消息？即给：
Message.setAsynchronous(true);
好比，在View更新时，draw、requestLayout、invalidate等很多地方都调用了。ViewRootImpl#scheduleTraversals()。
@UnsupportedAppUsage
void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
// 开启同步屏蔽
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
// 发送异步消息
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
if (!mUnbufferedInputDispatch) {
scheduleConsumeBatchedInput();
}
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}
在这里，mChoreographer.postCallback终极会实行到了Choreographer#postCallbackDelayedInternal()
private void postCallbackDelayedInternal(int callbackType,
Object action, Object token, long delayMillis) {
if (DEBUG_FRAMES) {
Log.d(TAG, " ostCallback: type=" + callbackType
+ ", action=" + action + ", token=" + token
+ ", delayMillis=" + delayMillis);
}
synchronized (mLock) { final long now = SystemClock.uptimeMillis(); final long dueTime = now + delayMillis; mCallbackQueues[callbackType].addCallbackLocked(dueTime, action, token); if (dueTime <= now) { scheduleFrameLocked(now); } else { // 发送异步消息 Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action); msg.arg1 = callbackType; msg.setAsynchronous(true); mHandler.sendMessageAtTime(msg, dueTime); }}}
可以看到，这里就开启了同步屏蔽，而且发送了异步消息。由于UI干系的消息是优先级最高的，如许体系就会优先处置惩罚这些异步消息。
末了，固然要移除同步屏蔽的时间，调用ViewRootImpl#unscheduleTraversals
void unscheduleTraversals() {
if (mTraversalScheduled) {
mTraversalScheduled = false;
// 移除同步屏蔽
mHandler.getLooper().getQueue().removeSyncBarrier(mTraversalBarrier);
mChoreographer.removeCallbacks(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
}
}
在ViewRootImpl中的doTraversal()方法中也会移除同步屏蔽，这里移除是由于requestLayout大概invalidate的时间，革新之后，在doTraversal()中就会移除同步屏蔽，由于此时消息已经发送而且处置惩罚了。 |
