寫給Android App開發人員看的Android底層知識（6）

（十一）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。