Android Intent 解析之二

服務端Intent執行過程:

Sticky：這個類型的BroadCast表示某些Intent需要被保留，當新的應用起來後，需要關注這個消息，但是呢，又不需要啟動這個應用來接收此消息，比如耳機插入等消息。
這個函數的主要作用就是根據這個Intent的特點，構造BroadCastRecord加入到不同的列表，等待被處理；
這樣發送就到了下面這個函數中了：

控制到了scheduleBroadcastsLocked這裡，它的邏輯很簡單：

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的進程； 這 個服務器進程在把我們先前設置的mPendingBroadcast設置為null，表示這個pending的broadcat已經得到處理了，然後調用 processCurBroadcastLocked來處理這個broadcast消息，最後通過 app.thread.scheduleReceiver進入到目標線程的接收流程；：

OK,到這裡的話所有的發送分發流程已經結束了，剩下的就是兩個接收函數還沒有討論一個就是ScheduleRegisterdReceiver,一個是scheduleReceiver；