Android Intent 解析之二

服务端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；