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

@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。

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数初中级Android工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则近万的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Android移动开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

img

img

img

img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Android开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:Android)

最后

希望本文对你有所启发,有任何面试上的建议也欢迎留言分享给大家。

好了,今天的分享就到这里,如果你对在面试中遇到的问题,或者刚毕业及工作几年迷茫不知道该如何准备面试并突破现状提升自己,对于自己的未来还不够了解不知道给如何规划,来看看同行们都是如何突破现状,怎么学习的,来吸收他们的面试以及工作经验完善自己的之后的面试计划及职业规划。

好了~如果你看到了这里,觉得文章写得不错就给个赞呗?如果你觉得那里值得改进的,请给我留言。一定会认真查询,修正不足。谢谢。

为什么某些人会一直比你优秀,是因为他本身就很优秀还一直在持续努力变得更优秀,而你是不是还在满足于现状内心在窃喜!希望读到这的您能点个小赞和关注下我,以后还会更新技术干货,谢谢您的支持!

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!

迎留言分享给大家。

好了,今天的分享就到这里,如果你对在面试中遇到的问题,或者刚毕业及工作几年迷茫不知道该如何准备面试并突破现状提升自己,对于自己的未来还不够了解不知道给如何规划,来看看同行们都是如何突破现状,怎么学习的,来吸收他们的面试以及工作经验完善自己的之后的面试计划及职业规划。

[外链图片转存中…(img-FFFyV1Wz-1712723453129)]

好了~如果你看到了这里,觉得文章写得不错就给个赞呗?如果你觉得那里值得改进的,请给我留言。一定会认真查询,修正不足。谢谢。

[外链图片转存中…(img-e1cK3Pus-1712723453129)]

为什么某些人会一直比你优秀,是因为他本身就很优秀还一直在持续努力变得更优秀,而你是不是还在满足于现状内心在窃喜!希望读到这的您能点个小赞和关注下我,以后还会更新技术干货,谢谢您的支持!

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!

  • 5
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值