android 廣播機制(2) 粘性廣播

android的粘性廣播，是指廣播接收器一注冊馬上就能接收到廣播的一種機制，當然首先系統要存在廣播。而普通廣播就是要先注冊廣播接收器，然后廣播被發送到系統，廣播接收器才能接收到廣播。

10年積累的成都網站建設、網站建設經驗，可以快速應對客戶對網站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網絡服務。我雖然不認識你，你也不認識我。但先網站設計后付款的網站建設流程，更有灞橋免費網站建設讓你可以放心的選擇與我們合作。

所以他們的區別是：

粘性廣播調用registerReceiver能馬上接受廣播，而普通廣播不行。

對于粘性廣播：

1.系統首先存在粘性廣播

2.注冊廣播接收器

3.處理廣播

下面用一個例子展示下他們的區別

主Acitivity

布局

布局有兩個按鈕，一個是注冊粘性廣播，一個是注冊普通廣播。點擊注冊粘性廣播按鈕會馬上返回結果。而點擊注冊普通廣播按鈕則沒有反應

說說Android的廣播(1)

對于Activity的啟動流程，我們已經有了幾個版本的分析了。這里我們分析一個更容易一些的，四大組件中最簡單的Broadcast Receiver。

關于Broadcast，有幾點需要了解。首先是廣播的類型，然后是廣播的發送方法，最后是廣播是如何被接收的。這三者相輔相承的，比如普通廣播和有序廣播只有在詳細了解了廣播的接收過程了之后，才能真正明白它的含義。

普通的廣播是不在意順序的，最簡單的理解是同時可以收到這個廣播。如果應用是動態注冊這個廣播的，且廣播發送時這個進程還活著，那么當然可以并發的把廣播盡快地傳送出去是最好的。

但是，如果是通過AndroidManifest.xml靜態注冊的情況，也就是說這個廣播首先要把一個進程啟動起來，這時并發啟動很多進程就是個問題了。Android目前的做法是，對這種靜態的廣播接收者，自動按有序廣播的方式來串行處理。但是這對應用是透明的，應用不能假設系統已經把靜態的無序廣播當成有序廣播來處理。

這個時候講粘性廣播有福了，因為從Android 5.0(API 21)開始，因為安全性的問題，官方已經正式廢棄了粘性廣播。

Context類提供兩個方法可以用于發送普通廣播：

差別是第二個設置權限。

發給特定的用戶：

有序廣播因為要處理消息的處理結果，所以要復雜一些。

如果只是想讓廣播可以按優先級來收取，并不在意處理的結果，可以用下面的版本：

同樣，在多用戶環境下，也可以選擇給哪個用戶發廣播：

不管是普通的還是有序的廣播都對應有粘性的版本：

以上的API都是定義于Context類中：

首先我們先看看發送端是如何發送的。

我們首先先放一個大圖，讓大家先有一個直觀的印象，不管普通廣播、有序廣播、粘性廣播如何組合，最終都匯集到一個大方法中。

我們先看應用發送普通廣播的一個簡單的例子：

非常簡單，調用ContentWrapper的sendBroadcast方法就可以了。

然后我們順藤摸瓜就好了。

Activity中的sendBroadcast，實際上調用的是：

我們來看frameworks/base/core/java/android/content/ContextWrapper.java中對sendBroadcast的定義：

ContextWrapper只是一個包裝，真正的實現在ContextImpl中

我們來看/frameworks/base/core/java/android/app/ContextImpl.java中真正實現sendBroadcast的功能：

它會通過IPC去調用AMS的broadcastIntent。由于我們這個普通的廣播的方法參數最少，所以好多都是傳null。

加鎖，定參數，然后調用真正的邏輯的實現。

我們先把broadcastIntentLocked的真正邏輯放一下，先看看有序廣播是如何發送的。

ContextWrapper.sendOrderedBroadcast

Context是abstract方法，調用的是ContextWrapper的實現：

跟普通廣播一樣，還是會調用到ContextImpl.sendOrderedBroadcast

有序廣播調用broadcastIntent的區別在于serialized參數，普通廣播為false，有序廣播為true.

原型為：

前面講過帶有回調的版本，我們看看它是如何實現的：

當然還是調用ContextImpl.sendOrderedBroadcast

這次變成只是一個封裝了，它會調用一個更多參數的版本：

這次是一個全參數調用broadcastIntent的版本了，除了sticky就齊了

我們也不繞圈子了，直接看ContextImpl.sendStickyBroadcast.

Android動態廣播（Android8.0）

(a).動態注冊 ? ? ? ? ? ? 在UI中注冊的廣播，例如：

（b).靜態注冊 ? ? ? ? ? ??

需要在manifest中進行注冊（在安卓8.0后系統廢除了大部分靜態廣播，最好使用動態注冊）。

（a).系統廣播 ? ? ? ? ? ??

系統中已經定義的廣播，此類廣播只能由系統發出，并且需要在intent-filter中加上系統已經寫的action。? ? ? ? ? ? ?

（b).自定義廣播 ? ? ? ??

顧名思義，是用戶自己定義的廣播。

（a）我們首先需要一個廣播接收類 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

（b）其次注冊動態廣播

（c）最后需要通過send方法發送一個廣播供廣播接收者接受

另外還有有序廣播和無序廣播，這篇博客寫的比較詳細，供大家參考： Android的有序廣播和無序廣播（解決安卓8.0版本之后有序廣播的接收問題） - ming3 - 博客園 (cnblogs.com)

Android系統廣播(Broadcast)注冊，發送，接收流程解析

以下廣播簡稱Broadcast

?? 是Android四大組件之一，在四大組件的另外兩個組件 和 擁有發送和接收廣播的能力。Android 是在 進程間通信機制的基礎上實現的，內部基于消息發布和訂閱的事件驅動模型，廣播發送者負責發送消息，廣播接收者需要先訂閱消息，然后才能收到消息。 進程間通信與 的區別在于：

?? 有三種類型

?? 存在一個注冊中心，也可以說是一個調度中心，即 。廣播接收者將自己注冊到 中，并指定要接收的廣播類型；廣播發送者發送廣播時，發送的廣播首先會發送到 ， 根據廣播的類型找到對應的 ，找到后邊將廣播發送給其處理。

?? 這里以普通廣播為例子， 接收者有兩種注冊方式，一種是 ，一種是 ：

（廣播的發送分為 兩種，這里針對有序的廣播） 中的android:priority=""和 中的IntentFilter.setPriority(int)可以用來設置廣播接收者的優先級，默認都是0 , 范圍是[-1000, 1000]，值越大優先級越高，優先級越高越早收到。

?? 在相同優先級接收同個類型廣播時， 的廣播接收器比 的廣播接收者更快的接收到對應的廣播，這個之后會進行分析。

?? 注：以下源碼基于rk3399_industry Android7.1.2

?? 的流程可分為 ， 和 三個部分，這里依次分析下

?? 在Android系統的 機制中，前面提到， 作為一個注冊和調度中心負責注冊和轉發 。所以 的注冊過程就是把它注冊到 的過程。

?? 這里我們分析 廣播的過程， 和 有一個共同的父類 ，所以它們對應的注冊過程其實是調用 ，接下來我們按照流程逐步分析調用流程的源碼。

frameworks/base/core/java/android/content/ContextWrapper.java

?? 在之前的 Android應用程序啟動入口ActivityThread.main流程分析 分析過，在我們啟動 Activity 時會創建一個 對象，然后通過 傳給我們啟動的 ，其內部就會將該對象賦值給 ； 的 方法也是類似的賦值流程，這里放個簡易的源碼應該更好理解

?? 可以看到最后都會將生成的 對象賦值給對應的

對象。接下來繼續分析 ， 即 函數。

/frameworks/base/core/java/android/app/ContextImpl.java

?? 這里我們首先看下如何將廣播接收者 封裝成一個 接口的 本地對象

/frameworks/base/core/java/android/app/LoadedApk.java

?? 每一個注冊過廣播接收者的 或 組件在font color='Crimson' LoadedApk /font類中都有個對應的 對象，該對象負責將 與 組件關聯起來。這些對象，以關聯的 作為關鍵字保存在一個 中。之后對應的 又以 的 作為關鍵字保存在 的成員變量 對象中。最后通過 對應的 方法獲得其 接口的 本地對象。之后再回到 注冊方法內，將 對象發給 進行注冊。

/frameworks/base/core/java/android/app/ActivityManagerNative.java

/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

?? 在的 或 注冊一個 時，并不是將其注冊到font color='OrangeRed'AMS/font中，而是將與它關聯的font color='OrangeRed'InnerReceiver/font對象注冊到font color='OrangeRed'AMS/font中，當font color='OrangeRed'AMS/font接收到廣播時，會根據 在內部找到對應的font color='OrangeRed'InnerReceiver/font對象，然后在通過這個對象將這個廣播發送給對應的 處理。

?? 注冊過程這邊畫了一個簡單的流程圖:

?? font color='OrangeRed'Broadcast/font的發送過程可簡單描述為以下幾個過程：

frameworks/base/core/java/android/content/ContextWrapper.java

/frameworks/base/core/java/android/app/ContextImpl.java

/frameworks/base/core/java/android/app/ActivityManagerNative.java

/frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java

Android BroadcastReceiver詳解

BroadcastReceiver（廣播接收器）是Android四大組件之一，顧名思義，通過廣播的方式進行消息傳遞，其本質是一個全局的監聽器，可以監聽到各種廣播，可以用來實現不同組件之間的通信。廣播最大的特點就是發送方并不關心接收方是否接到數據，也不關心接收方是如何處理數據的，通過這樣的形式來達到接、收雙方的完全解耦合。

又稱無序廣播，這種廣播完全是異步的，所有與廣播Intent匹配的BroadcastReceiver，都可以收到這條廣播，并且不分先后順序，視為同時收到，通過Context.sendBroadcast()方法發送。這種廣播的效率比較高，但缺點是接收器不能將處理結果傳遞給下一個接收器，并且無法在中途終止廣播。

這是一種同步執行的廣播，通過Context.sendOrderedBroadcast()方法發送，這種廣播發出后，通過receiver的intent-filter中的android:priority屬性來設置優先級，優先級從-1000～1000，數越大，優先級越高，使用setResult()方法把結果傳遞給下一個接收者，通過getResult()方法獲取上一個接收者傳遞過來的結果，并可以通過abortBroadcast()方法丟棄該廣播，使該廣播不再傳遞給下一個接收者。

粘性廣播通過Context.sendStickBroadcast()方法來發送，用此方法發送的廣播會一直滯留，當有匹配此廣播的接收器被注冊后，該廣播接收器就會收到此廣播。使用此廣播時，需要獲得BROADCAST_STICKY權限。（在 android 5.0/api 21后不再推薦使用）

Android系統中內置了多個系統廣播，只要涉及到手機的基本操作，基本上都會發出相應的系統廣播。如：開啟啟動，網絡狀態改變，拍照，屏幕關閉與開啟，點亮不足等等。每個系統廣播都具有特定的intent-filter，其中主要包括具體的action，系統廣播發出后，將被相應的BroadcastReceiver接收。系統廣播在系統內部當特定事件發生時，有系統自動發出。

以上廣播都屬于全局廣播，發出去的廣播，只要有匹配的接收者，就可以收到廣播。這樣一來會造成一些問題，一是消耗性能，二是容易引起安全性的問題，為了能夠簡單的解決這方面的問題，Android引入了一套廣播本地廣播機制，使用該機制發出的廣播只能夠在本應用內部進行傳遞，并且廣播接收器也只能接收來自本應用發出的廣播。

使用方法

1.注冊本地廣播接收器

2.發送本地廣播

3.注銷本地廣播接收器

本文用到的BroadcastReceiver

Android 8.0（API級別26）取消大部分靜態注冊廣播，建議使用動態廣播

當前題目：android廣播的使用,android廣播機制
鏈接分享：http://vcdvsql.cn/article40/dsdgiho.html

成都網站建設公司_創新互聯，為您提供外貿網站建設、移動網站建設、手機網站建設、App開發、網站設計公司、網站設計

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯