前言
第一次听到Handler中的同步屏障这个问题,之前没有接触到,感觉一脸懵,自己去查阅了一些资料才明白,所以在这里给大家做一下分享。
首先我们先了解一下 Handler Message
在Handler中,大致分为3种Message,分别是同步消息,异步消息和同步屏障,他们三者都是Message,只是成员变量有些区别;
1.同步消息
也就是我一般使用的Message,再通过Handler进行sendMessage到消息队列,前提是构造Handler时候传的构造参数async为false
Handler mHandler = new Handler()
//或者
Handler mHandler = new Handler(true)
通过以上mHandler发送的Message都是同步消息,且Message会与该mHandler绑定,即:
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
//将Handler赋值给Message的target变量
msg.target = this;
//mAsynchronous为false,为同步消息
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
以上就是发送一个同步消息流程
2.异步消息
根据前面同步消息的发送流程可以知道,只要通过构造参async为true的Handler发送的Message都为异步消息,即:
//构造一个发送处理异步消息的Handler
Handler mHandler = new Handle(true)
所以通过这个mHandler发送的Message,在queueMessage时候,都会把Message的asynchronous设置为true,即异步消息
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
//将Handler赋值给Message的target变量
msg.target = this;
//mAsynchronous为true,为异步消息
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
以上就是发送一个异步消息的流程
3.同步屏障
虽然没有消息两字,但是同步屏障本质也是Message对象,同步屏障个人觉得可以把它解释为:屏障同步消息的消息,它和前面同步异步消息的最大区别就是,Message.target变量为null,它的作用就是在消息队列(MessageQueue)取出消息的时候,屏蔽掉同步消息,优先获取异步消息的作用
没有同步屏障
假设下图是没有添加同步屏障的消息队列
graph LR
B[同步消息A] --> C[同步消息B]
C[同步消息B] --> D[异步消息A]
那么在loop()循环从MessageQueue取出消息的顺序是
- 同步消息A
- 同步消息B
- 异步消息A
- 睡眠等待消息插入...
有同步屏障
如果在消息队列中插入同步屏障,如下图所示
graph LR
A[同步屏障]-->B[同步消息A]
B[同步消息A] --> C[同步消息B]
C[同步消息B] --> D[异步消息A]
那么在loop()循环从MessageQueue取出消息的顺序是
- 异步消息A
- 睡眠等待消息插入...
此时消息队列变为
graph LR
A[同步屏障]-->B[同步消息A]
B[同步消息A] --> C[同步消息B]
因为同步屏障在获取消息的时候,屏蔽掉同步消息,只取出异步消息,那同步消息怎么办?只有当同步屏障被屏蔽被移除的时候才能获取到同步消息;
通过代码在消息队列添加同步屏障
//在MessageQueue类中,添加同步屏障可以通过postSyncBarrier方法,该方法是被隐藏的,如果要调用的话只能通过反射机制进行调用
public int postSyncBarrier() {
return postSyncBarrier(SystemClock.uptimeMillis());
}
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) {
final int token = mNextBarrierToken++;
//创建一个Message对象,所以说同步屏障的本质就是Message
//而且在这里看不到Message.target的赋值,所以可以说同步屏障和同步异步消息的区别就是target是否为空
final Message msg = Message.obtain();
msg.markInUse();
msg.when = when;
//记录该同步屏障,后面可以通过token来移除该同步屏障
msg.arg1 = token;
//找到指定插入位置,插入同步屏障
Message prev = null;
Message p = mMessages;
if (when != 0) {
while (p != null && p.when <= when) {
prev = p;
p = p.next;
}
}
if (prev != null) { // invariant: p == prev.next
msg.next = p;
prev.next = msg;
} else {
msg.next = p;
mMessages = msg;
}
//最后返回token,可以根据这个token移除同步屏障
return token;
}
}
//移除同步屏障
//token就是添加同步屏障时候返回的唯一标示
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) {
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);
}
}
}
通过自己代码给消息队列添加同步屏障:这是使用的是反射的方式调用, 因为设置同步屏障和创建异步Handler的方法都是标志为hide,说明谷歌不想要我们去使用他。这里只是简单的列举一下使用
//获取当前线程Looper对象的消息队列
MessageQueue queue=handler.getLooper().getQueue();
//通过反射调用
Method method=MessageQueue.class.getDeclaredMethod("postSyncBarrier");
token= (int) method.invoke(queue);
//移除同步屏障
//获取当前线程Looper对象的消息队列
MessageQueue queue=handler.getLooper().getQueue();
Method method=MessageQueue.class.getDeclaredMethod("removeSyncBarrier",int.class);
method.invoke(queue,token);
通过上面的举例我们已经知道Handler中,3种Message的区别,接下来我们更深入的来了解一下什么是同步屏障机制
什么是同步屏障机制
同步屏障机制是一套为了让某些特殊的消息得以更快被执行的机制。
注意这里我在同步屏障之后加上了机制二字,原因是单纯的同步屏障并不起作用,他需要和其他的Handler组件配合才能发挥作用。
这里我们假设一个场景:我们向主线程发送了一个UI绘制操作Message,而此时消息队列中的消息非常多,那么这个Message的处理可能会得到延迟,绘制不及时造成界面卡顿。同步屏障机制的作用,是让这个绘制消息得以越过其他的消息,优先被执行。
MessageQueue中的Message,有一个变量isAsynchronous
,他标志了这个Message是否是异步消息;标记为true称为异步消息,标记为false称为同步消息。同时还有另一个变量target
,标志了这个Message最终由哪个Handler处理。
我们知道每一个Message在被插入到MessageQueue中的时候,会强制其target
属性不能为null,如下代码:
MessageQueue.class
boolean enqueueMessage(Message msg, long when) {
// Hanlder不允许为空
if (msg.target == null) {
throw new IllegalArgumentException("Message must have a target.");
}
...
}
而android提供了另外一个方法来插入一个特殊的消息,强行让target==null
:
private int postSyncBarrier(long when) {
synchronized (this) {
final int token = mNextBarrierToken++;
final Message msg = Message.obtain();
msg.markInUse();
msg.when = when;
msg.arg1 = token;
Message prev = null;
Message p = mMessages;
// 把当前需要执行的Message全部执行
if (when != 0) {
while (p != null && p.when <= when) {
prev = p;
p = p.next;
}
}
// 插入同步屏障
if (prev != null) {
msg.next = p;
prev.next = msg;
} else {
msg.next = p;
mMessages = msg;
}
return token;
}
}
代码有点长,重点在于:没有给Message赋值target属性,Message是按when的时间插入到一个合适的位置。when的值是SystemClock.uptimeMillis()
MessageQueue在获取下一个Message的时候,如果碰到了同步屏障,那么不会取出这个同步屏障,而是会遍历后续的Message,找到第一个异步消息取出并返回。这里跳过了所有的同步消息,直接执行异步消息。为什么叫同步屏障?因为它可以屏蔽掉同步消息,优先执行异步消息。
我们来看看源码是怎么实现的:
Message next() {
···
if (msg != null && msg.target == null) {
// 同步屏障,找到下一个异步消息
do {
prevMsg = msg;
msg = msg.next;
} while (msg != null && !msg.isAsynchronous());
}
···
}
如果遇到同步屏障,那么会循环遍历整个链表找到标记为异步消息的Message,即isAsynchronous返回true,其他的消息会直接忽视,那么这样异步消息,就会提前被执行了。
注意,同步屏障不会自动移除,使用完成之后需要手动进行移除,不然会造成同步消息无法被处理。我们可以看一下源码:
代码段 小部件
可以看到如果没有即时移除同步屏障,他会一直存在且不会执行同步消息。因此使用完成之后必须即时移除。但我们无需操心这个,后面就知道了。
如何发送异步消息
上面我们了解到了同步屏障的作aotui
用,但是会发现postSyncBarrier
方法被标记为@hide
,也就是我们无法调用这个方法。那,讲了这么多有什么用?
咳咳~不要慌,但我们可以发异步消息啊。在系统添加同步屏障的时候,不就可以趁机上车了,是吧。
添加异步消息有两种办法:
- 使用异步类型的Handler发送的全部Message都是异步的
- 给Message标志异步
给Message标记异步是比较简单的,通过setAsynchronous
方法即可。
Handler有一系列带Boolean类型的参数的构造器,这个参数就是决定是否是异步Handler:
public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) {
mLooper = looper;
mQueue = looper.mQueue;
mCallback = callback;
// 这里赋值
mAsynchronous = async;
}
在发送消息的时候就会给Message赋值:
private boolean enqueueMessage(@NonNull MessageQueue queue, @NonNull Message msg,
long uptimeMillis) {
msg.target = this;
msg.workSourceUid = ThreadLocalWorkSource.getUid();
// 赋值
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
但是异步类型的Handler构造器是标记为hide,我们无法使用,但在api28之后添加了两个重要的方法:
public static Handler createAsync(@NonNull Looper looper) {
if (looper == null) throw new NullPointerException("looper must not be null");
return new Handler(looper, null, true);
}
public static Handler createAsync(@NonNull Looper looper, @NonNull Callback callback) {
if (looper == null) throw new NullPointerException("looper must not be null");
if (callback == null) throw new NullPointerException("callback must not be null");
return new Handler(looper, callback, true);
}
通过这两个api就可以创建异步Handler了,而异步Handler发出来的消息则全是异步的。
public void setAsynchronous(boolean async) {
if (async) {
flags |= FLAG_ASYNCHRONOUS;
} else {
flags &= ~FLAG_ASYNCHRONOUS;
}
}
如何正确使用
上面我们似乎漏了一个问题:系统什么时候添加同步屏障?。
异步消息需要同步屏障的辅助,但同步屏障我们无法手动添加,因此了解系统何时添加和删除同步屏障是非常必要的。只有这样,才能更好地运用异步消息这个功能,知道为什么要用和如何用。
了解同步屏障需要简单了解一点屏幕刷新机制的内容。放心,只需要了解一丢丢就可以了。
我们的手机屏幕刷新频率有不同的类型,60Hz、120Hz等。60Hz表示屏幕在一秒内刷新60次,也就是每隔16.6ms刷新一次。屏幕会在每次刷新的时候发出一个 VSYNC
信号,通知CPU进行绘制计算。具体到我们的代码中,可以认为就是执行onMesure()
、onLayout()
、onDraw()
这些方法。好了,大概了解这么多就可以了。
了解过 view 绘制原理的读者应该知道,view绘制的起点是在 viewRootImpl.requestLayout()
方法开始,这个方法会去执行上面的三大绘制任务,就是测量布局绘制。但是,重点来了:
调用
requestLayout()
方法之后,并不会马上开始进行绘制任务,而是会给主线程设置一个同步屏障,并设置 VSYNC 信号监听。 当 VSYNC 信号的到来,会发送一个异步消息到主线程Handler,执行我们上一步设置的绘制监听任务,并移除同步屏障
这里我们只需要明确一个情况:调用requestLayout()方法之后会设置一个同步屏障,直到VSYNC信号到来才会执行绘制任务并移除同步屏障。(这里涉及到Android屏幕刷新以及绘制原理更多的内容,本文不详细展开,感兴趣的读者可以点击文末的连接阅读。)
那,这样在等待VSYNC信号的时候主线程什么事都没干?是的。这样的好处是:保证在ASYNC信号到来之时,绘制任务可以被及时执行,不会造成界面卡顿。但这样也带来了相对应的代价:
- 我们的同步消息最多可能被延迟一帧的时间,也就是16ms,才会被执行
- 主线程Looper造成过大的压力,在VSYNC信号到来之时,才集中处理所有消息
ps:【在等待VSYNC信号的时候主线程什么事都没干?是的。】插入同步屏障之后会阻止同步消息执行,导致即使有同步消息在队列中,也不会进行处理,也就是“什么都没干”;但如果前面的同步任务的执行延缓了绘制请求任务的执行、或者队列中有异步消息,此时主线程并不会“什么都没干”。这里是为了帮助读者更好理解,牺牲一点严谨性。
改善这个问题办法就是:使用异步消息。当我们发送异步消息到MessageQueue中时,在等待VSYNC期间也可以执行我们的任务,让我们设置的任务可以更快得被执行且减少主线程Looper的压力。
可能有读者会觉得,异步消息机制本身就是为了避免界面卡顿,那我们直接使用异步消息,会不会有隐患?这里我们需要思考一下,什么情况的异步消息会造成界面卡顿:异步消息任务执行过长、异步消息海量。
如果异步消息执行时间太长,那即时是同步任务,也会造成界面卡顿,这点应该都很好理解。其次,若异步消息海量到达影响界面绘制,那么即使是同步任务,也是会导致界面卡顿的;原因是MessageQueue是一个链表结构,海量的消息会导致遍历速度下降,也会影响异步消息的执行效率。所以我们应该注意的一点是:
不可在主线程执行重量级任务,无论异步还是同步。
那,我们以后岂不是可以直接使用异步Handler来取代同步Handler了?是,也不是。
同步Handler有一个特点是会遵循与绘制任务的顺序,设置同步屏障之后,会等待绘制任务完成,才会执行同步任务;而异步任务与绘制任务的先后顺序无法保证,在等待VSYNC的期间可能被执行,也有可能在绘制完成之后执行。因此,我的建议是:如果需要保证与绘制任务的顺序,使用同步Handler;其他,使用异步Handler。
总结:
以上的总结也是为了让大家对同步屏障有一个比较深刻的了解,平时的需求中很少会用到这方面,但是有需要用到同步机制的时候,请一定要谨慎使用,否则就会得不偿失。反而让自己的应用质量倒退。