脚本宝典收集整理的这篇文章主要介绍了Android 实战中提高Handler发送消息的优先级，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。
在阅读分析AndROId 绘制原理的源码时，挺多文章指出绘制消息message的执行肯定优先所有的message,这个优先机制是利用Handler的同步屏障机制和异步消息，但是这些机制对开发者不开放的,相关方法也标注为@hide，我猜测如果对开发者开放，那么为了使得自己的消息优先执行，绘制的消息不能抢先执行，很有可能会导致卡顿.分析同步屏障和异步消息的原理文章已经很多，大牛们分析的肯定比我透彻很多，哈哈.
但是实战中，会有需求，虽然绘制这一类有同步屏障机制的消息的还是优先执行.但在之后的消息中我们是否可以让自己的消息优先执行呢，查阅Handler的源码中，有如下几个方法可以实现这样的效果
Handler 类F1a;
public final boolean postatFrontOfQueue(@NonNull Runnable r) {
return sendMessageAtFrontOfQueue(getPostMessage(r));
}
public final boolean sendMessageAtFrontOfQueue(@NonNull Message msg) {
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, 0);
}
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);
}二其余发送消息的API 无论是post,sendMessage等，最终也会调用enqueueMessage(),不过区别就在enqueueMessage()方法中的第三个参数uptimeMillis，postAtFrontOfQueue最终调用sendMessageAtFrontOfQueue，所以只要看sendMessageAtFrontOfQueue调用enqueueMessage方法，传入uptimeMillis是0，而其余的要么是系统当前时间，要么系统当前时间加延迟的时间.
Handler 类
public final boolean sendMessage(@NonNull Message msg) {
return sendMessageDelayed(msg, 0);
}
public final boolean sendMessageDelayed(@NonNull Message msg, long delayMillis) {
if (delayMillis < 0) {
delayMillis = 0;
}
return sendMessageAtTime(msg, Systemclock.uptimeMillis() + delayMillis);
}
public boolean sendMessageAtTime(@NonNull 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;
}
// uptimeMillis是系统时间或者系统时间加上延迟的时间
return enqueueMessage(queue, msg, uptimeMillis);
}
看下MessageQueue的enqueueMessage方法传0和不传0的区别
MessageQueue类
boolean enqueueMessage(Message msg, long when) {
//when 接收了uptimeMillis的值
if (msg.target == null) {
throw new IllegalargumentException(";message must have a target.");
}
synchronized (this) {
if (msg.isInUse()) {
throw new IllegalStateException(msg + " This message is already in use.");
}
if (mQuitting) {
IllegalStateException e = new IllegalStateException(
msg.target + " sending message to a Handler on a dead thread");
Log.w(TAG, e.getMessage(), e);
msg.recycle();
return false;
}
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.
//当when == 0的时候，是走这个逻辑的，相当于msg作为新的链表的头结点
//这里还有一个when<p.when的条件，什么时候触发，后面在分析
msg.next = p;
mMessages = msg;
needWake = mBlocked;
} else {
//else的执行中逻辑当正常post,sendMessage的时候，when接收的时间值是大于等于系统
时间，肯定也比头结点所在的时间要大
// Inserted within the middle of the queue. Usually we don't have to wake
// up the event queue unless there is a barrier at the head of the queue
// and the message is the earliest asynchronous message in the queue.
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; // inVARiant: p == prev.next
prev.next = msg;
}
// We can assume mPtr != 0 because mQuitting is false.
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}分析得到，如果uptimeMillis是0的话，那么会让当前的消息成为头结点.所以这个消息除了采用同步屏障的异步消息外，肯定优先执行.理论上是这样，实操中是如此吗?demo过于简单，只贴出核心方法.
fun postDemos(){
//1 post
handler.post {
Log.i(TAG,"1 post")
}
//2 send message
val msg = Message.oBTain()
msg.what = 1
msg.obj = "2 send message"
handler.sendMessage(msg)
//3 post
handler.post {
Log.i(TAG,"3 post")
}
//4 post
handler.post {
Log.i(TAG,"4 post")
}
//5 send message
val msg1 = Message.obtain()
msg1.what = 1
msg1.obj = "5 send message"
handler.sendMessage(msg1)
//6 postFirset
handler.postAtFrontOfQueue {
Log.i(TAG,"6 postFirst")
}
//7 sendMessageAtTime
val msg2 = Message.obtain()
msg2.what = 1
msg2.obj = "7 send message"
handler.sendMessageAtFrontOfQueue(msg2)
}这个方法输出的日志是这样的
2021-09-19 08:48:45.251 6532-6532/com.hy.learndemo I/MainActivity: 7 send message
2021-09-19 08:48:45.251 6532-6532/com.hy.learndemo I/MainActivity: 6 postFirst
2021-09-19 08:48:45.252 6532-6532/com.hy.learndemo I/MainActivity: 1 post
2021-09-19 08:48:45.252 6532-6532/com.hy.learndemo I/MainActivity: 2 send message
2021-09-19 08:48:45.252 6532-6532/com.hy.learndemo I/MainActivity: 3 post
2021-09-19 08:48:45.252 6532-6532/com.hy.learndemo I/MainActivity: 4 post
2021-09-19 08:48:45.252 6532-6532/com.hy.learndemo I/MainActivity: 5 send message很明显，postAtFrontOfQueue,sendMessageAtFrontOfQueue发送的消息虽然在最后入队列，但优先执行，不过7比6先执行是怎么回事，那是因为sendMessageAtFrontOfQueue后执行，所以最后的头结点就是它发送的消息.在分析enqueueMessage方法执行逻辑的时候，留一个问题。什么时候会触发when<p.when.除了0之外，也就是说存在一种情况需要发送的消息的时间值还能比头结点的时间还小，还记得sendMessageAtTime这个方法吗，这个方法是public方法，没有标注为@hide,所以我们也能用，重新贴一下方法
public boolean sendMessageAtTime(@NonNull 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);
}
传入的 uptimeMillis并没有做小于当前时间的校验，是支持传入小于当前时间的消息.所以想要优先执行消息，又有一个方法就是调用sendMessageAtTime方法，传入比当前时间小的时间戳.不过不建议直接调用sendMessageAt()方法，调用现成的postAtFrontOfQueue或者sendMessageAtFrontOfQueue.相反的sendMessageAtTime方法中，如果传入比当前时间值大，效果就是执行某个时间执行消息.所以Handler机制对消息执行的优先级以及时间自由度还是挺大的
以上是脚本宝典为你收集整理的Android 实战中提高Handler发送消息的优先级全部内容，希望文章能够帮你解决Android 实战中提高Handler发送消息的优先级所遇到的问题。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。