（十一）BroadcastReceiver

BroadcastReceiver，也就是廣播，簡稱Receiver。

     很多App開發人員表示，從來沒用過Receiver。其實吧，對於音樂播放類App，用Service和Receiver還是蠻多的，如果你用過QQ音樂，App退到後臺，音樂照樣播放不會停止，這就是你寫的Service在後臺起作用。

     在前臺的Activity，點選停止按鈕，就會給後臺Service傳送一個Receiver，通知它停止播放音樂；點選播放按鈕，仍然是傳送這個Receiver，只是攜帶的值變了，所以Service收到請求後播放音樂。

     反過來，後臺Service播放每播放完一首音樂，接下來準備播放下一首音樂的時候，就會給前臺Activity發Receiver，讓Activity顯示下一首音樂的名稱。

所以音樂播放器的原理，就是一個前後臺Activity和Service互相傳送和接收Receiver的過程。

     Receiver分靜態廣播和動態廣播兩種。

     在Manifest中宣告的Receiver，是靜態廣播：

     在程式中手動寫註冊程式碼的，是動態廣播：

     二者具有相同的功能，只是寫法不同。既然如此，我們就可以把所有靜態廣播，都改為動態廣播，這就省的在Manifest檔案中聲明瞭，避免了AMS檢查。接下來你想到什麼？對，Receiver的外掛化解決方案，就是這個思路。

     接下來我們看Receiver是怎麼和AMS打交道的，分為兩部分，一是註冊，二是傳送廣播。

     你只有註冊了這個廣播，傳送這個廣播時，才能通知到你，執行onReceive方法。

     我們就拿音樂播放器來舉例，在Activity註冊Receiver，在Service傳送廣播。Service播放下一首音樂時，會通知Activity修改當前正在播放的音樂名稱。

     註冊過程如下所示：

     1）在Activity中，註冊Receiver，並通知AMS。

     這裡Activity使用了Context提供的registerReceiver方法，然後通過AMN/AMP，把一個receiver傳給AMS。

     在建立這個Receiver物件的時候，需要為receiver指定IntentFilter，這個filter就是Receiver的身份證，用來描述receiver。

     在Context的registerReceiver方法中，它會使用PMS獲取到包的資訊，也就是LoadedApk物件。

     就是這個LoadedApk物件，它的getReceiverDispatcher方法，將Receiver封裝成一個實現了IIntentReceiver介面的Binder物件。

     我們就是將這個Binder物件和filter傳遞給AMS。

     只傳遞Receiver給AMS是不夠的，當傳送廣播時，AMS不知道該發給誰啊？所以Activity所在的程序還要把自身物件也傳送給AMS。

     2）AMS收到訊息後，就會把上面這些資訊，存在一個列表中，這個列表中儲存了所有的Receiver。

     注意了，這裡忙活半天，都是在註冊動態receiver。

     靜態receiver什麼時候註冊到AMS的呢？是在App安裝的時候。PMS會解析Manifest中的四大元件資訊，把其中的receiver存起來。

     動態receiver和靜態receiver分別存在AMS不同的變數中，在傳送廣播的時候，會把兩種receiver合併到一起，然後以此傳送。其中動態的排在靜態的前面，所以動態receiver永遠優先於靜態receiver收到訊息。

     此外，Android系統每次啟動的時候，也會把靜態廣播接收者註冊到AMS。因為Android系統每次啟動時，都會重新安裝所有的apk，詳細流程，我們會在後面PMS的相關章節看到。

     - - - - - - - - - - - - - - - 華麗的分界線------------------------

    傳送廣播的流程如下：

     1）在Service中，通過AMM/AMP，傳送廣播給AMS，廣播中攜帶著Filter。

     2）AMS收到這個廣播後，在receiver列表中，根據filter找到對應的receiver，可能是多個，把它們都放到一個廣播佇列中。最後向AMS的訊息佇列傳送一個訊息。

     當訊息佇列中的這個訊息被處理時，AMS就從廣播佇列中找到合適的receiver，向廣播接收者所在的程序傳送廣播。

     3）receiver所在的程序收到廣播，並沒有把廣播直接發給receiver，而是將廣播封裝成一個訊息，傳送到主執行緒的訊息佇列中，當這個訊息被處理時，才會把這個訊息中的廣播發送給receiver。

     我們下面通過圖，仔細看一下這3個階段：

     第1步，Service傳送廣播給AMS

     傳送廣播，是通過Intent這個引數，攜帶了Filter，從而告訴AMS，什麼樣的receiver能接受這個廣播。

第2步，AMS接收廣播，傳送廣播。

     接收廣播和傳送廣播是不同步的。AMS每接收到一個廣播，就把它扔到廣播發送佇列中，至於傳送是否成功，它就不管了。

     因為receiver分為無序receiver和有序receiver，所以廣播發送佇列也分為兩個，分別傳送這兩種廣播。

     AMS傳送廣播給客戶端，這又是一個跨程序通訊，還是通過ATP，把訊息發給APT。因為要傳遞Receiver這個物件，所以它也是一個Binder物件，才可以傳過去。我們前面說過，在把Receiver註冊到AMS的時候，會把Receiver封裝為一個IIntentReceiver介面的Binder物件。那麼接下來，AMS就是把這個IIntentReceiver介面物件傳回來。

     第3步，App處理廣播

     這個流程描述如下：

     1）訊息從AMS傳到客戶端，把AMS中的IIntentReceiver介面物件轉為InnerReceiver物件，這就是receiver，這是一個AIDL跨程序通訊。

     2）然後在ReceiverDispatcher中封裝一個Args物件（這是一個Runnable物件，要實現run方法），包括廣播接收者所需要的所有資訊，交給ActivtyThread來發送

     3）接下來要走的路就是我們所熟悉的了，ActivtyThread把Args訊息扔到H這個Hanlder中，向主執行緒訊息佇列傳送訊息。等到執行Args訊息的時候，自然是執行Args的run方法。

     4）在Args的run方法中，例項化一個Receiver物件，呼叫它的onReceiver方法。

     5）最後，在Args的run方法中，隨著Receiver的onReceiver方法呼叫結束，會通過AMN/AMP傳送一個訊息個AMS，告訴AMS，廣播發送成功了。AMS得到通知後，就傳送廣播給下一個Receiver。

     注意：InnerReceiver是IIntentReceiver的stub，是Binder物件的接收端。

    廣播的種類

     Android廣播按傳送方式分類有三種：無序廣播、有序廣播（OrderedBroadcast）和粘性廣播（StickyBroadcast）。

     1）無序廣播是最普通的廣播。

     2）有序廣播區別於無序廣播，就在於它可以指定優先順序。

這兩種receiver存在AMS不同的變數中，可以認為是兩個receiver集合，傳送不同類別的廣播。

     3）粘性廣播是無序廣播的一種。

     粘性廣播，我們平常見的不多，但我說一個場景你就明白了，那就是電池電量。當電量小於20%的時候，就會提示使用者。

     而獲取電池的電量資訊，就是通過廣播來實現的。

     但是一般的廣播，發完就完了。我們需要有這樣一種廣播，發出後，還能一直存在，未來的註冊者也能收到這個廣播，這種廣播就是粘性廣播。

     由於動態receiver只能在Activity的onCreate()方法呼叫時才能註冊再接收廣播，所以當程式沒有執行就不能接受到廣播；但是靜態註冊的則不依賴於程式是否處於執行狀態。

     至此，關於廣播的所有概念，就全都介紹完了，就連我都比較驚訝的是，我居然沒貼什麼程式碼。希望上述這兩千多字，能引導App開發人員進入一個神奇的世界。

     下一篇文章，我們去看看ContentProvider。