Android消息机制 2 - Java层源码分析

最新推荐文章于 2024-07-15 22:27:12 发布

2401_84688516

最新推荐文章于 2024-07-15 22:27:12 发布

阅读量710

点赞数 17

文章标签： java 面试学习

本文链接：https://blog.csdn.net/2401_84688516/article/details/138937766

版权

Java高频面试专题合集解析：

阿里Java岗面试百题：Spring 缓存 JVM 微服务数据库 RabbitMQ等

当然在这还有更多整理总结的Java进阶学习笔记和面试题未展示，其中囊括了Dubbo、Redis、Netty、zookeeper、Spring cloud、分布式、高并发等架构资料和完整的Java架构学习进阶导图！

阿里Java岗面试百题：Spring 缓存 JVM 微服务数据库 RabbitMQ等

更多Java架构进阶资料展示

阿里Java岗面试百题：Spring 缓存 JVM 微服务数据库 RabbitMQ等

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

private Looper(boolean quitAllowed) {
//见2.2
mQueue = new MessageQueue(quitAllowed);
mThread = Thread.currentThread();
}

其中Looper的构造函数创建了MessageQueue，并设置mThread为currentThread。

2.2 new MessageQueue

[-> MessageQueue.java]

MessageQueue(boolean quitAllowed) {
mQuitAllowed = quitAllowed;
//Native层分析见Android消息机制第三章
mPtr = nativeInit();
}

初始化Java层MessageQueue，并设置是否允许退出，并初始化Native层MessageQueue。

Looper.prepare初始化了Looper和MessageQueue，属于一对一的关系。

三. 初始化Handler，与Looper挂钩

先来回顾一下如何初始化Handler。

[-> 初始化Handler]

public Handler mSubHandler = new Handler(Looper.myLooper()) {
@Override
public void handleMessage(@NonNull Message msg) {
Log.i(TAG, "mSubHandler handler handleMessage thread : " + Thread.currentThread());
switch (msg.what) {
case MSG_GET:
double number = Math.random();
Message message = new Message();
message.what = MSG_RESULT;
message.obj = "dopezhi : " + number;
mUiHandler.sendMessage(message);
break;
default:
break;
}
}
};

为什么发送消息时，只需要mSubHandler.sendMessage就可以发送消息了？

按照正常的做法，主线程想往子线程发送消息，主线程需要拿到子线程的Looper，再拿到其对应的MessageQueue，往MessageQueue扔一个消息就行了。

但是这样太麻烦了，所以Handler除了处理消息，还有一个作用：帮助我们发消息到Handler对应的MessageQueue中，简化操作，这就是挂钩的目的。

[-> Handler.java]

public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) {
mLooper = looper;
mQueue = looper.mQueue;
mCallback = callback;
mAsynchronous = async;
}

所谓的挂钩，就是在new Handler的时候，传入对应的Looper，MessageQueue等，后续我们通过Handler.sendMessaage实际上等于向之前挂钩的MessageQueue发送消息。

四. Looper.loop

[-> Looper.java]

public static void loop() {
//获得TLS存储的Looper
final Looper me = myLooper()；
final MessageQueue queue = me.mQueue;
Binder.clearCallingIdentity();
//获取本次通信的一个令牌，后续会跟发送完消息的令牌进行比较，判断进程或者线程状态有没有发生改变
final long ident = Binder.clearCallingIdentity();

for (;😉 {
//死循环获取消息，见4.1
Message msg = queue.next(); // might block
if (msg == null) {
// No message indicates that the message queue is quitting.
return;
}
…
//通过Handler去处理消息见4.3
msg.target.dispatchMessage(msg);
…
final long newIdent = Binder.clearCallingIdentity();

//回收消息见4.4
msg.recycleUnchecked();
}
}

Looper.loop本质上是通过一个死循环来不断next来获取待处理的消息，那么这种死循环会引起消耗CPU资源吗？

不会，底层用了Linux的epoll机制，epoll机制是Linux的I/O复用技术，可以监听一个或者多个文件描述符fd是否发生了自己感兴趣的事件（epoll_ctl），在没有感兴趣的时间发生之前，会让出CPU资源，直到fd写入感兴趣的事件，立马快速唤醒epoll_wait处理。

4.1 queue.next()

[-> MessageQueue.java]

Message next() {
//ptr为Native层的NativeMessageQueue的地址
final long ptr = mPtr;
if (ptr == 0) {
return null;
}
//idleHandler内容将在后续章节讲解
int pendingIdleHandlerCount = -1; // -1 only during first iteration
int nextPollTimeoutMillis = 0;
for (;😉 {
if (nextPollTimeoutMillis != 0) {
Binder.flushPendingCommands();
}
//nextPollTimeoutMillis为0时无需等待直接返回，-1则无限等待
//真正阻塞在这里，这里后续到Native层进行epoll_wait
nativePollOnce(ptr, nextPollTimeoutMillis);

synchronized (this) {
final long now = SystemClock.uptimeMillis();
Message prevMsg = null;
//mMessages变量为Message链表的头结点
Message msg = mMessages;
//同步屏障，见5
if (msg != null && msg.target == null) {
// Stalled by a barrier. Find the next asynchronous message in the queue.
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;
//下面是单链表的操作，把头结点断开作为msg返回
if (prevMsg != null) {
prevMsg.next = msg.next;
} else {
mMessages = msg.next;
}
msg.next = null;
if (DEBUG) Log.v(TAG, "Returning message: " + msg);
msg.markInUse();
return msg;
}
} else {
nextPollTimeoutMillis = -1;
}
//如果Looper退出，则返回null
if (mQuitting) {
dispose();
return null;
}
//下面都属于idelHandler的内容
…
}
}

调用queue.next时，会在nativePollOnce中一直等待事件的发生，先来看一下事件是怎么入队的？

4.2 handler.sendMessage

发送消息的调用链：

发送消息调用链(form gityuan).png

可以看到即便我们通过各种的方式，都用调用MessageQueue.enqueueMessage方法。

[-> MessageQueue.enqueueMessage]

boolean enqueueMessage(Message msg, long when) {
//表明了App端不能通过设置target==null来post同步屏障
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.");
}
…
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; // invariant: p == prev.next
prev.next = msg;
}

// We can assume mPtr != 0 because mQuitting is false.
//如果需要wake，则wake
if (needWake) {
nativeWake(mPtr);
}
}
return true;
}

在发送完消息之后，会通过needWake判断是否需要唤醒（nativeWake）来处理事件。

看到这里你或许感觉到意犹未尽，具体是怎么唤醒的？具体内容可在Native层这一部分看到，这里也可以稍微剧透一下。

实际上，当初始化native层的NativeMessageQueue时，会通过epoll_ctl监听管道的输入事件，一旦管道被写入事件（就是nativeWake干的事，写入了一个字符1），epoll_wait就会醒来处理，底层只是简单清除管道数据，但是底层函数就能返回，反应到上层就是queue.next()中的nativePollOnce能返回，进而处理提取事件进行处理。

4.3 msg.target.dispatchMessage

此处的target为Handler。

[-> Handler.java]

public void dispatchMessage(@NonNull Message msg) {
if (msg.callback != null) {
handleCallback(msg);
} else {
if (mCallback != null) {
if (mCallback.handleMessage(msg)) {
return;
}
}
handleMessage(msg);
}
}

处理规则：

如果Message Callback不为null，则处理Message Callback
如果Message Callback为null
如果Handler Callback不为null，则处理Handler Callback
如果Handler Callback为null，则正常处理消息

y1u1有点乱，什么跟什么，一个个解答！

4.3.1 Message Callback？

发送消息除了刚才的sendMessage，还有一个Handler.post。

[-> Handler.java]

public final boolean post(@NonNull Runnable r) {
return sendMessageDelayed(getPostMessage®, 0);
}

private static Message getPostMessage(Runnable r) {
Message m = Message.obtain();
m.callback = r;
return m;
}

喔，原来使用Handler.post发送消息，是提交runnable对象，把对应的Message.callback设置该runnable对象。让该Message优先执行。

4.3.2 Handler Callback？

[-> Test.java]

Handler.Callback callback = new Handler.Callback() {
@Override
public boolean handleMessage(@NonNull Message msg) {
switch (msg.what){
case MSG_PASS:
return true;
default:
return false;
}
}
};

Handler Callback就是让Handler有拦截消息的能力，比如我判断初该信息的what是MSG_PASS，则return true跳过该消息。

4.3.3 handleMessage

如果该消息没有被Handler过滤掉，则执行我们写的handleMessage方法。

4.4 msg.recycleUnchecked

[-> Message.java]

@UnsupportedAppUsage
void recycleUnchecked() {
flags = FLAG_IN_USE;
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = UID_NONE;
workSourceUid = UID_NONE;
when = 0;
target = null;
callback = null;
data = null;

synchronized (sPoolSync) {
if (sPoolSize < MAX_POOL_SIZE) {
next = sPool;
sPool = this;
sPoolSize++;
}
}
}

Message内部其实是有维护一个缓存消息池，这个池子的大小是50个。当回收消息时，如果消息池大小还没超过最大值时，会加入到缓存消息池中，并让sPool指向消息池的第一个消息，后续就可以拿他。

但是很奇怪，一直以来我都是new Message的啊，new Message构造函数啥都没干，按道理它应该去消息池获取消息才对，要不然每次我都new，消息池都只能缓存50个，不就浪费很多，触发GC吗？

后来才发现获取消息最恰当的方法是Message.obtain().

[-> Message.java]

/** Constructor (but the preferred way to get a Message is to call {@link #obtain() Message.obtain()}).
*/
public Message() {
}

/**

Return a new Message instance from the global pool. Allows us to
avoid allocating new objects in many cases.
*/
public static Message obtain() {
synchronized (sPoolSync) {
if (sPool != null) {
Message m = sPool;
sPool = m.next;
m.next = null;
m.flags = 0; // clear in-use flag
sPoolSize–;
return m;
}
}
return new Message();
}

从注释也可以看得出来官方是更推荐我们使用Message.obtain()来获取Message的，避免使用new Message的方式分配多余的对象。

五. 同步屏障机制

5.1 原理

首先先思考一个问题，假如我有一个很急的消息，我想MessageQueue立马帮我处理，怎么做呢？只要把消息添加到队列的头部就可以了，但是MessageQueue是基于处理时间排序的，那在这时间点之前还有很多消息堆积，你发的消息也没办法第一时间执行。

因此就有了同步屏障机制。

所有的消息默认都是同步消息，只有设置了异步消息的标志才是异步消息，当不断queue.next()提取消息，只要发现某个消息的target为null，则进入同步屏障的机制，接下来遍历剩余的所有消息，只要消息设置了异步标志，则优先提取消息处理，直到removeBarrier。

[-> MessageQueue.java]

//返回值为表明该barrier的一个token，这个token的值就是当前MessageQueue维护的一个同步屏障的数量的值。
@UnsupportedAppUsage
public int postSyncBarrier() {
return postSyncBarrier(SystemClock.uptimeMillis());
}

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;
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;
}
return token;
}
}

可以看到，post一个同步屏障，就是Message的target为null，这个是App测无法做到的。

[-> Message.java]

public void setAsynchronous(boolean async) {
if (async) {
flags |= FLAG_ASYNCHRONOUS;
} else {
flags &= ~FLAG_ASYNCHRONOUS;
}
}

通过 | 设置异步消息。

5.2 同步屏障的应用

Choreographer 里所有跟 message 有关的代码都设置了异步标志。这样是为了尽可能的保证在上层app收到vsync时都能第一时间执行遍历以及绘制view树的工作。

这里的第一时间是指执行ViewRootImpl.scheduleTraversals之后。
[-> ViewRootImpl.java]

void scheduleTraversals() {
if (!mTraversalScheduled) {
mTraversalScheduled = true;
//post同步屏障
mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
//提交mTraversalRunnable，主要做doTraversal
mChoreographer.postCallback(
Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
notifyRendererOfFramePending();
pokeDrawLockIfNeeded();
}
}

可以看到在scheduleTraversals中提交了一个同步屏障，后续该MessageQueue优先执行异步消息。

[-> Choreographer.java]

private void postCallbackDelayedInternal(int callbackType,
Object action, Object token, long 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 Callback，提高优先级
Message msg = mHandler.obtainMessage(MSG_DO_SCHEDULE_CALLBACK, action);
msg.arg1 = callbackType;
//设置异步消息
msg.setAsynchronous(true);
mHandler.sendMessageAtTime(msg, dueTime);
}
}
}

设置Message Callback为mTraversalRunnable（doTraversal），并设置该消息为异步消息，得到优先处理。

5.3 关于View的一些前瞻

由于现在对View这块不是很熟，现在粗略写这块，以后会出详细分析的文章。

通过WindowManagerGlobal.addView时,会初始化ViewRootImpl。
[-> WindowManagerGlobal.java]

public void addView(View view, ViewGroup.LayoutParams params,
Display display, Window parentWindow, int userId) {
…
ViewRootImpl root;
root = new ViewRootImpl(view.getContext(), display);

…
root.setView(view, wparams, panelParentView, userId);
}

执行setView。

[-> ViewRootImpl.java]

最后

针对最近很多人都在面试，我这边也整理了相当多的面试专题资料，也有其他大厂的面经。希望可以帮助到大家。

上述的面试题答案都整理成文档笔记。也还整理了一些面试资料&最新2021收集的一些大厂的面试真题（都整理成文档，小部分截图）

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

y);

…
root.setView(view, wparams, panelParentView, userId);
}

执行setView。

[-> ViewRootImpl.java]

最后

针对最近很多人都在面试，我这边也整理了相当多的面试专题资料，也有其他大厂的面经。希望可以帮助到大家。

[外链图片转存中…(img-onThZHVN-1715809130277)]

上述的面试题答案都整理成文档笔记。也还整理了一些面试资料&最新2021收集的一些大厂的面试真题（都整理成文档，小部分截图）

[外链图片转存中…(img-n76g18QB-1715809130277)]

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

2401_84688516

关注

17
点赞
踩
27

收藏

觉得还不错? 一键收藏
0
评论
Android消息机制 2 - Java层源码分析

针对最近很多人都在面试，我这边也整理了相当多的面试专题资料，也有其他大厂的面经。希望可以帮助到大家。上述的面试题答案都整理成文档笔记。也还整理了一些面试资料&最新2021收集的一些大厂的面试真题（都整理成文档，小部分截图）以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录需要这份系统化的资料的朋友，可以点击这里获取y);执行setView。
复制链接

扫一扫