第2部分會分析分發(fā)過程
> 廣播分發(fā)的流程圖
這張圖描述了整個廣播分發(fā)的流程，
為了簡化，
這一節(jié)只從 AMS 的 processNextBroadcast 開始分析
備注：這個方法在6.0的時候移到了 BroadQueue 類中， AMS 的代碼也有相應(yīng)的調(diào)整
> 有序廣播和普通廣播
首先在廣播里有兩種形式，
分別保存在 BroadcastQueue 類的兩個對象里
在廣播分發(fā)邏輯中，
首先會處理并行廣播，也就是普通廣播，
同時把廣播分發(fā)到所有能接收這個廣播的 Receiver 去，
有序廣播就是一個個來了
> processNextBroadcast( ) -- Parallel Broadcast
普通廣播在 processNextBroadcast 一開始就進行分發(fā)，
比較簡單，
每次從 mParallelBroadcasts<> 中取出并同時刪除最前面的 BroadcastRecord 對象，
這個類保存了包括廣播消息內(nèi)容、時間、處理Receiver等信息
在循環(huán)中不斷取出 BroadcastRecord 對象，
用 deliverToRegisteredReceiverLocked 進行分發(fā)，
到了這里就很容易理解了，
app.thread.scheduleRegisteredReceiver ，這里是跨進程調(diào)用，
后面就是到 ActivityThread 中去調(diào)不同的 receiver.performReceive了。
之后的事情概括地解釋就是 post 一個帶有 receiver 的 runnable 對象，去做 onReive 操作。
> processNextBroadcast( ) -- Serialized Broadcast
有序廣播的分發(fā)包括了靜態(tài)和動態(tài)注冊的分發(fā)，
這里就分了兩個邏輯，
在分發(fā)完 Parallel 廣播后，還有一大段的廣播超時機制，
這里略過，直接看 Serialized 廣播的分發(fā)，
前面說過 BroadcastFilter 類型的實例是動態(tài)注冊的 Receiver，
靜態(tài)類型廣播分發(fā)到這里是先把 動態(tài)注冊 的發(fā)出去，然后又看到熟悉的 deliverToRegisteredReceiverLocked() 了，
這個方法接下去的部分照舊，忽略不寫。
然后，
到這里就是有序廣播的靜態(tài)注冊 Receiver 分發(fā)了，
在這段代碼之前有一部分判斷對應(yīng)的 Receiver 有沒有對應(yīng)的 Process 存在，
如果沒有要先把這個 Process 調(diào)起來，
最后會走 processCurBroadcastLocked()，
而這個方法也是通過跨進程調(diào)用去執(zhí)行靜態(tài)注冊的 Receiver 的 onReceive 方法，
上面代碼中的 app, thread, 跨進程調(diào)用，
scheduleReceiver() 在 ActivityThread 中的邏輯是 sendMessage 到 H 中，
然后 handleMessag 會去調(diào) Receiver 的 onReceive 方法。
總結(jié)，
對于廣播注冊來說，分為靜態(tài)注冊和動態(tài)注冊，
分別會用 ResolveInfo 和 BroadcastFilter 來實例化，
對于廣播類型，也分有序廣播和普通廣播。
廣播分發(fā)，是先發(fā)普通廣播，Parallel Broadcast，一次發(fā)給所有 Receiver
然后在發(fā)有序廣播 Serialized Broadcast 的時候，先發(fā)給動態(tài)注冊的Receiver，再發(fā)給靜態(tài)注冊的 Receiver。
而靜態(tài)注冊的 Receiver 通過 H 去分發(fā)消息。
