Android Intent 解析之二

2022-07-13 14:15:21 浏览数 (1)

大家好,又见面了,我是全栈君,祝每个程序员都可以多学几门语言。

服务端Intent运行过程:

Sticky:这个类型的BroadCast表示某些Intent须要被保留,当新的应用起来后,须要关注这个消息,可是呢,又不须要启动这个应用来接收此消息,比方耳机插入等消息。 这个函数的主要作用就是依据这个Intent的特点,构造BroadCastRecord添�到不同的列表,等待被处理; 这样发送就到了以下这个函数中了:

控制到了scheduleBroadcastsLocked这里,它的逻辑非常easy:

private final void scheduleBroadcastsLocked() {

if (mBroadcastsScheduled) {

return;

}

mHandler.sendEmptyMessage(BROADCAST_INTENT_MSG);

mBroadcastsScheduled = true;

}

先 推断mBroadcastsScheduled是否为真,假设为真就直接返回,这个变量主要是实现scheduleBroadcastsLocked和 processNextBroadcast之间的顺序运行,后面会看到在processNextBroadcast函数里面会把它设置为false; 以下就是通过BROADCAST_INTENT_MSG消息放入到消息队列里面,最后传递给mHandler,从这个角度来说Intent最后也是通过线程本身的消息队列来实现Intent的分发的;

消息分发过程:

mHandler收到BROADCAST_INTENT_MSG这个消息后便调用processNextBroadcast(boolean fromMsg)将消息分发出去了。以下介绍一下这个函数的流程: 1, 先推断fromMsg,假设是通过消息发送过来的就为真,否则为假; 假设为真mBroadcastsScheduled = false,这种话在函数scheduleBroadcastsLocked里面就能够再次发送BROADCAST_INTENT_MSG的消息从而触 发processNextBroadcast函数被再次调用;

2, 先推断mParallelBroadcasts是否为空,不为空就開始调用这个列表里面的receivers来接收消息,这个过程后面在串行intent 的时候也会碰到,我们留到后面讨论,这里仅仅须要知道它通过一个while循环把Intent发送给关注这个Intent的全部的receivers;

3, 再推断 mPendingBroadcast是否为空,假设不为空,就表示先前发送的串行的Intent还没有处理完成,一般出现这样的可能是由于我们要发送到的 receiver还没有启动,所以须要先启动这个activity,然后等待起来的这个activity处理,这时候,这个 mPendingBroadcast就为true;假设发送这样的情况须要推断这个Activity是否死了,假设死了,那么就把 mPendingBroadcast设为false,否则就直接返回,继续等待;

4, 接下来就顺序的从 mOrderedBroadcasts里面取出BroadCastRecord消息,然后对这个消息的receiver一个一个的调用其接收流程,注意这 里要把这个BroadCast的全部的receivers串行发送,都发送完了,才会进入到下一个BroadCastRecord消息;对于这个消息的处 理,先推断其接收者是不是BroadFilter,假设是,就调用deliverToRegisteredReceiver来接收,它的处理流程和前面的 处理并行BroadCast一样。

5,假设不是BroadCast Filter,就须要找出这个reiver所在的进程,这时候通常就是一个IntentFilter所在的进程,假设这个进程活着,那么就调用processCurBroadcastLocked(r, app)来处理。否则须要先启动这个进程,这就是startProcessLocked做的事情,然后设置mPendingBroadcast = r,这样等应用起来它会处理这个消息,后面会有进一步的说明;

到这里这个函数就结束了,比較复杂,里面另一些安全的检查等等,上面遗留了三个问题: A)deliverToRegisteredReceiver的处理流程; B)processCurBroadcastLocked的处理流程; C)startProcessLocked以后的进程怎样处理这个唤醒它的Intent;

deliverToRegisteredReceiver 这里也分为这个receiver是否启动,假设已经启动就通过binder调用到了接收 activity的进程里面了。 processCurBroadcastLocked的逻辑 它和deliverToRegisteredReceive的终于区别,仅仅在于一个调用的是ScheduleRegisterdReceiver,一个是scheduleReceiver,这两个函数最后都会进入到目标activity的线程; processCurBroadcastLocked

从这里能够看出最后通过Process.start启动了ActivityThread.java的进程,我们看看这个线程启动后的运行逻辑 首先是在进入主循环之前调用attachApplication通过binder调用进入到activityManagerService.java的进程; 这 个server进程在把我们先前设置的mPendingBroadcast设置为null,表示这个pending的broadcat已经得到处理了,然后调用 processCurBroadcastLocked来处理这个broadcast消息,最后通过 app.thread.scheduleReceiver进入到目标线程的接收流程;:

OK,到这里的话全部的发送分发流程已经结束了,剩下的就是两个接收函数还没有讨论一个就是ScheduleRegisterdReceiver,一个是scheduleReceiver;

发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/118471.html原文链接:https://javaforall.cn

0 人点赞