android廣播的原理
A. 22 AndroidBroadcast廣播機制
廣播(Broadcast)機制用於進程/線程間通信，廣播分為廣播發送和廣播接收兩個過程，其中廣播接收者BroadcastReceiver便是Android四大組件之一。
BroadcastReceiver分為兩類：
從廣播發送方式可分為三類：
廣播在系統中以BroadcastRecord對象來記錄, 該對象有幾個時間相關的成員變數.
廣播注冊，對於應用開發來說，往往是在Activity/Service中調用 registerReceiver() 方法，而Activity或Service都間接繼承於Context抽象類，真正幹活是交給ContextImpl類。另外調用getOuterContext()可獲取最外層的調用者Activity或Service。
[ContextImpl.java]
其中broadcastPermission擁有廣播的許可權控制，scheler用於指定接收到廣播時onRecive執行線程，當scheler=null則默認代表在主線程中執行，這也是最常見的用法
[ContextImpl.java]
ActivityManagerNative.getDefault()返回的是ActivityManagerProxy對象，簡稱AMP.
該方法中參數有mMainThread.getApplicationThread()返回的是ApplicationThread，這是Binder的Bn端，用於system_server進程與該進程的通信。
[-> LoadedApk.java]
不妨令 以BroadcastReceiver(廣播接收者)為key，LoadedApk.ReceiverDispatcher(分發者)為value的ArrayMap 記為 A 。此處 mReceivers 是一個以 Context 為key，以 A 為value的ArrayMap。對於ReceiverDispatcher(廣播分發者)，當不存在時則創建一個。
此處mActivityThread便是前面傳遞過來的當前主線程的Handler.
ReceiverDispatcher(廣播分發者)有一個內部類 InnerReceiver ，該類繼承於 IIntentReceiver.Stub 。顯然，這是一個Binder服務端，廣播分發者通過rd.getIIntentReceiver()可獲取該Binder服務端對象 InnerReceiver ，用於Binder IPC通信。
[-> ActivityManagerNative.java]
這里有兩個Binder服務端對象 caller 和 receiver ，都代表執行注冊廣播動作所在的進程. AMP通過Binder驅動將這些信息發送給system_server進程中的AMS對象，接下來進入AMS.registerReceiver。
[-> ActivityManagerService.java]
其中 mRegisteredReceivers 記錄著所有已注冊的廣播，以receiver IBinder為key, ReceiverList為value為HashMap。
在BroadcastQueue中有兩個廣播隊列mParallelBroadcasts,mOrderedBroadcasts，數據類型都為ArrayList<broadcastrecord style="box-sizing: border-box;">：</broadcastrecord>
mLruProcesses數據類型為 ArrayList<ProcessRecord> ，而ProcessRecord對象有一個IApplicationThread欄位，根據該欄位查找出滿足條件的ProcessRecord對象。
該方法用於匹配發起的Intent數據是否匹配成功，匹配項共有4項action, type, data, category，任何一項匹配不成功都會失敗。
broadcastQueueForIntent(Intent intent)通過判斷intent.getFlags()是否包含FLAG_RECEIVER_FOREGROUND 來決定是前台或後台廣播，進而返回相應的廣播隊列mFgBroadcastQueue或者mBgBroadcastQueue。
注冊廣播：
另外，當注冊的是Sticky廣播：
廣播注冊完, 另一個操作便是在廣播發送過程.
發送廣播是在Activity或Service中調用 sendBroadcast() 方法，而Activity或Service都間接繼承於Context抽象類，真正幹活是交給ContextImpl類。
[ContextImpl.java]
[-> ActivityManagerNative.java]
[-> ActivityManagerService.java]
broadcastIntent()方法有兩個布爾參數serialized和sticky來共同決定是普通廣播，有序廣播，還是Sticky廣播，參數如下：
broadcastIntentLocked方法比較長，這里劃分為8個部分來分別說明。
這個過程最重要的工作是：
BroadcastReceiver還有其他flag，位於Intent.java常量:
主要功能：
這個過主要處於系統相關的10類廣播,這里不就展開講解了.
這個過程主要是將sticky廣播增加到list，並放入mStickyBroadcasts裡面。
其他說明：
AMS.collectReceiverComponents ：
廣播隊列中有一個成員變數 mParallelBroadcasts ，類型為ArrayList<broadcastrecord style="box-sizing: border-box;">，記錄著所有的並行廣播。</broadcastrecord>
動態注冊的registeredReceivers，全部合並都receivers，再統一按串列方式處理。
廣播隊列中有一個成員變數 mOrderedBroadcasts ，類型為ArrayList<broadcastrecord style="box-sizing: border-box;">，記錄著所有的有序廣播。</broadcastrecord>
發送廣播過程:
處理方式：
可見不管哪種廣播方式，都是通過broadcastQueueForIntent()來根據intent的flag來判斷前台隊列或者後台隊列，然後再調用對應廣播隊列的scheleBroadcastsLocked方法來處理廣播；
在發送廣播過程中會執行 scheleBroadcastsLocked 方法來處理相關的廣播
[-> BroadcastQueue.java]
在BroadcastQueue對象創建時，mHandler=new BroadcastHandler(handler.getLooper());那麼此處交由mHandler的handleMessage來處理：
由此可見BroadcastHandler採用的是」ActivityManager」線程的Looper
[-> BroadcastQueue.java]
此處mService為AMS，整個流程還是比較長的，全程持有AMS鎖，所以廣播效率低的情況下，直接會嚴重影響這個手機的性能與流暢度，這里應該考慮細化同步鎖的粒度。
B. android廣播機制的廣播機制的三要素
Android廣播機制包含三個基本要素：廣播(Broadcast) - 用於發送廣播；廣播接收器(BroadcastReceiver) - 用於接收廣播；意圖內容(Intent)-用於保存廣播相關信息的媒介。Broadcast是一種廣泛運用的在應用程序之間傳輸信息的機制。而BroadcastReceiver是對發送出來的Broadcast進行過濾接受並響應的一類組件。
C. android 廣播機制(2) 粘性廣播
android的粘性廣播，是指廣播接收器一注冊馬上就能接收到廣播的一種機制，當然首先系統要存在廣播。而普通廣播就是要先注冊廣播接收器，然後廣播被發送到系統，廣播接收器才能接收到廣播。
所以他們的區別是：
粘性廣播調用registerReceiver能馬上接受廣播，而普通廣播不行。
對於粘性廣播：
1.系統首先存在粘性廣播
2.注冊廣播接收器
3.處理廣播
下面用一個例子展示下他們的區別
主Acitivity
布局
布局有兩個按鈕，一個是注冊粘性廣播，一個是注冊普通廣播。點擊注冊粘性廣播按鈕會馬上返回結果。而點擊注冊普通廣播按鈕則沒有反應
D. 簡述在android中如何發送廣播消息
1.發送廣播
Intent intent = new Intent(BroadcastAction);
Bundle bundle = new Bundle();
bundle.putString("***", SUCCESS);
bundle.putString("FullPathName", mFullPathName);
intent.putExtras(bundle);
sendBroadcast(intent);
2.在Activity中創建一個內部類MyBroadcastReceiver擴展BroadcastReceiver，並在其中實現onReceive方法。
3.在Activity中聲明一個MyBroadcastReceiver類型的成員變數，並注冊：
private MyBroadcastReceiver myBroadcastReceiver;
...
myBroadcastReceiver = new MyBroadcastReceiver();
IntentFilter filter = new IntentFilter();
filter.addAction(BroadcastAction);
registerReceiver(receiver, filter);
4.使用完後要記得釋放
unregisterReceiver(receiver);
註：1和2中的 BroadcastAction要是同一個Action
E. 為什麼Android要使用各種BroadcastReceiver
作為Android四大組件之一的BroadcastReceiver（廣播接收者），同Activity（活動）一樣，經常被大家用到，網上也是一堆對它的講解，那麼為什麼Android要用廣播接收者這種機制呢？
廣播分為：普通廣播和有序廣播
1.Normal broadcasts（普通廣播）：Normal broadcasts是完全非同步的可以同一時間被所有的接收者接收到。消息的傳遞效率比較高。但缺點是接收者不能將接收的消息的處理信息傳遞給下一個接收者也不能停止消息的傳播。可以利用Context.sendBroadcast發送。
2.Ordered broadcasts（有序廣播）：Ordered broadcasts的接收者按照一定的優先順序進行消息的接收。一次傳送到一個接收器。 隨著每個接收器依次執行，它可以將結果傳播到下一個接收器，或者它可以完全中止廣播，使得它不會被傳遞到其他接收器。 命令接收器運行可以用匹配的意圖過濾器的android:priority屬性控制; 具有相同優先順序的接收器將以任意順序運行。可以利用Context.sendOrderedBroadcast發送。
官網上介紹廣播是用的監聽系統網路狀況的例子，其實關鍵字在於「監聽」。
(1) 創建廣播接收者
BroadcastReceiver是一個抽象類，所以我們要創建自己的廣播接收者就要繼承它，繼承後會有提示重寫onReceive方法。
public class NetworkBroadcastReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals(ConnectivityManager.CONNECTIVITY_ACTION)) {
ConnectivityManager manager = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
NetworkInfo activeNetwork = manager.getActiveNetworkInfo();
if (activeNetwork != null && activeNetwork.isAvailable()) {
Toast.makeText(context, "有網路連接", Toast.LENGTH_SHORT).show();
} else {
Toast.makeText(context, "無網路連接", Toast.LENGTH_SHORT).show();
}
}
}
}
廣播接收者的生命周期是從接收廣播開始，到onRecevier方法執行完成結束，時間很短，一般不允許處理大批量耗時操作。這里順便給出列印NetworkInfo的信息以供參考：
NetworkInfo:
type: WIFI[,type_ext: WIFI],
state: CONNECTED/CONNECTED,
reason: (unspecified),
extra: "TP-LINK_EFE8",
roaming: false,
failover: false,
isAvailable: true,
: false,
isIpv4Connected: true,
isIpv6Connected: false
[type: MOBILE[LTE],
state: CONNECTED/CONNECTED,
reason: connected,
extra: cmnet,
roaming: false,
failover: false,
isAvailable: true,
: false]
(2) 靜態注冊廣播
靜態注冊廣播，需要在AndroidManifest.xml中，添加<recevier/> 標簽，將廣播接收者注冊到應用中。要添加過濾器IntentFilter，由於系統網路變化時會發送ConnectivityManager.CONNECTIVITY_ACTION ("android.net.conn.CONNECTIVITY_CHANGE")的廣播，所以我們要監聽這條廣播。
<receiver android:name=".NetworkBroadcastReceiver">
<intent-filter android:priority="1000">
<action android:name="android.net.conn.CONNECTIVITY_CHANGE"/>
</intent-filter>
</receiver>
這里priority代表的是執行順序的優先順序，取值[-1000,1000]，後面的有序廣播會講到。
(3) 動態注冊廣播
i.意圖過濾器 IntentFilter 用於給BroadcastReceiver綁定監聽廣播類型
ii.自定義的BroadcastReceiver，例如上文的
iii.注冊方法 Context.registerReceiver(Receiver, IntentFilter)
iv.反注冊方法 unregisterReceiver(Receiver)
IntentFilter mFilter = new IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION);
mReceiver = new ();
registerReceiver(mReceiver, mFilter);
@Override
public void onDestroy() {
super.onDestroy();
unregisterReceiver(mReceiver);
}
這段代碼是成對出現的，可以在onCreate的時候注冊，在onDestroy的時候反注冊，也可以在onResume和onPause中執行這寫方法。不過Google API推薦的做法，在activity的onResume()中注冊，在onPause()反注冊。效果是當界面pause時，就不接收廣播，從而減少不必要的系統開銷。還有就是一定要主動反注冊你的廣播，否則會出現異常。
動態注冊和靜態注冊的差別：動態注冊後，廣播接收者會依賴Activity的生命周期，而靜態注冊的廣播不會，只要是系統有發出的廣播，它都會接收，與程序是否啟動無關。
(4) 發送普通廣播
具體使用的方法是sendBroadcast(Intent intent)，通過隱式調用就可以，注意action是你自定義的，意思就是不可以發送系統廣播，我試了，直接就崩了。
Intent intent = new Intent();
intent.setAction("com.fleming.chen.mybroadcast");
sendBroadcast(intent);
針對(3)(4)兩點，如果你要用到的廣播僅僅是應用里的，那麼你可以用LocalBroadcastManager這個類，它與上述描述中的區別在於：
LocalBroadcastManager.getInstance(context).registerReceiver(mReceiver, mFilter);
LocalBroadcastManager.getInstance(context).unregisterReceiver(mReceiver);
LocalBroadcastManager.getInstance(context).sendBroadcast(intent);
通過sendBroadcast發送的廣播，不會被通過LocalBroadcastManager類注冊的廣播接收者接收，反之也是如此，兩者是不可以」互通友誼「的，推薦使用LocalBroadcastManager來管理廣播。
(5) 發送有序廣播
上面講了那麼多都是普通廣播，那什麼又是有序廣播呢？
有序廣播關鍵在於這類廣播是有序的，上文中提到priority，這是IntentFilter的屬性，用來讓不同的廣播擁有不同的執行順序，即優先順序不同。
定義三種不同優先順序的廣播接收者：
public class MyBroadcastReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals("com.fleming.chen.myreceiver")) {
String message = getResultData();
Toast.makeText(context, message, Toast.LENGTH_SHORT).show();
setResultData("這是修改後的數據");//第一個接收後處理一下，再交給下一個
}
}
}
public class MyBroadcastReceiver2 extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals("com.fleming.chen.myreceiver")) {
String message = getResultData();//得到上一個的處理結果
Toast.makeText(context, message, Toast.LENGTH_SHORT).show();
abortBroadcast();//主動停止廣播，不再繼續傳下去
}
}
}
public class MyBroadcastReceiver3 extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
if (intent.getAction().equals("com.fleming.chen.myreceiver")) {
//此時雖然該廣播接收者也監聽了，不過也沒有內容
Toast.makeText(context, getResultData(), Toast.LENGTH_SHORT).show();
}
}
}
<receiver android:name=".MyBroadcastReceiver" >
<intent-filter android:priority="1000">
<action android:name="com.fleming.chen.myreceiver"/>
</intent-filter>
</receiver>
<receiver android:name=".MyBroadcastReceiver2">
<intent-filter android:priority="0">
<action android:name="com.fleming.chen.myreceiver"/>
</intent-filter>
</receiver>
<receiver android:name=".MyBroadcastReceiver3">
<intent-filter android:priority="-1000">
<action android:name="com.fleming.chen.myreceiver"/>
</intent-filter>
</receiver>
Intent intent = new Intent();
intent.setAction("com.fleming.chen.myreceiver");
sendOrderedBroadcast(intent, null, null, null, 0, "這是初始的數據", null);
對於廣播的內容，在Android 7.0上做了修改，即Project Svelte：後台優化
Android 7.0 移除了三項隱式廣播，以幫助優化內存使用和電量消耗。此項變更很有必要，因為隱式廣播會在後台頻繁啟動已注冊偵聽這些廣播的應用。刪除這些廣播可以顯著提升設備性能和用戶體驗。
移動設備會經歷頻繁的連接變更，例如在 WLAN 和移動數據之間切換時。目前，可以通過在應用清單中注冊一個接收器來偵聽隱式 CONNECTIVITY_ACTION 廣播，讓應用能夠監控這些變更。由於很多應用會注冊接收此廣播，因此單次網路切換即會導致所有應用被喚醒並同時處理此廣播。
同理，在之前版本的 Android 中，應用可以注冊接收來自其他應用（例如相機）的隱式 ACTION_NEW_PICTURE 和 ACTION_NEW_VIDEO 廣播。當用戶使用相機應用拍攝照片時，這些應用即會被喚醒以處理廣播。
為緩解這些問題，Android 7.0 應用了以下優化措施：
面向 Android 7.0 開發的應用不會收到 CONNECTIVITY_ACTION 廣播，即使它們已有清單條目來請求接受這些事件的通知。在前台運行的應用如果使用 BroadcastReceiver 請求接收通知，則仍可以在主線程中偵聽 CONNECTIVITY_CHANGE。
應用無法發送或接收 ACTION_NEW_PICTURE 或 ACTION_NEW_VIDEO 廣播。此項優化會影響所有應用，而不僅僅是面向 Android 7.0 的應用。
如果您的應用使用任何 intent，您仍需要盡快移除它們的依賴關系，以正確適配 Android 7.0 設備。Android 框架提供多個解決方案來緩解對這些隱式廣播的需求。例如，JobScheler API 提供了一個穩健可靠的機制來安排滿足指定條件（例如連入無限流量網路）時所執行的網路操作。您甚至可以使用 JobScheler 來適應內容提供程序變化。
所以說，在Android的世界，到處都充滿著廣播，就是為了用來監聽手機的各種狀態，給用戶提醒，這是一種很好的用戶體驗，不過任何事情都是如此，廣播也不可以多用哦，
F. Android系統廣播(Broadcast)注冊，發送，接收流程解析
以下廣播簡稱Broadcast
是Android四大組件之一，在四大組件的另外兩個組件 和 擁有發送和接收廣播的能力。Android 是在 進程間通信機制的基礎上實現的，內部基於消息發布和訂閱的事件驅動模型，廣播發送者負責發送消息，廣播接收者需要先訂閱消息，然後才能收到消息。 進程間通信與 的區別在於：
有三種類型
存在一個注冊中心，也可以說是一個調度中心，即 。廣播接收者將自己注冊到 中，並指定要接收的廣播類型；廣播發送者發送廣播時，發送的廣播首先會發送到 ， 根據廣播的類型找到對應的 ，找到後邊將廣播發送給其處理。
這里以普通廣播為例子， 接收者有兩種注冊方式，一種是 ，一種是 ：
（廣播的發送分為 兩種，這里針對有序的廣播） 中的android:priority=""和 中的IntentFilter.setPriority(int)可以用來設置廣播接收者的優先順序，默認都是0 , 范圍是[-1000, 1000]，值越大優先順序越高，優先順序越高越早收到。
在相同優先順序接收同個類型廣播時， 的廣播接收器比 的廣播接收者更快的接收到對應的廣播，這個之後會進行分析。
註：以下源碼基於rk3399_instry 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
G. android中什麼時候會選擇用廣播來進行線程間的通信
android中什麼時候會選擇用廣播來進行線程間的通信 Android 多線程 通信
線程中通信就不要用廣播了吧 進程中通信可以用廣播或者aidl
可是，這兩天看到的項目都是這么做的；然後，自己分析了下，覺得一下的理由也是可以成立的；
1.正常情況下我們選擇handler消息機制來進行單向的線程間的通信；（工作線程向主線程發送消息）
因為主線程有現成的handler，而工作線程沒有現成的handler，這樣的話，主線程將handler交給工作線程而讓工作線程將工作的結果交給主線程；
相反，工作線程中沒有現成的handler（事實上是沒有消息隊列，也就是handler沒有綁定到工作線程），那麼，如果開辟的話，代碼角度上是挺麻煩的（相對應廣播機制來說）；
2.廣播機制本身就是雙向的（工作線程向主線程發送廣播，主線程向工作線程發送廣播）；
//另外，對於像一個activity中通過fragment來進行界面的處理； 我們大多數情況下是採用廣播的機制來實現fragment中adapter的數據的更新；這樣做主要是考慮到工作線程的任務載入完成，而具體的對應刷新的activity可能還沒有啟動；
另外，基於介面隔離原則，如果用handler進行通信的話，則不能很好的滿足這一原則；
你要是周期比較長 用廣播好些吧
應該與周期關系不是很密切。最主要的原因是兩條線成是雙向通信。
Handler類似於P2P的通信。
廣播則類似於一個server端，用來處理分發不同線程的請求，從控制器的角度來說用廣播更好一點。
一般使用Handler的，多用於子線程處理事務，完成時告知主線程這一類的情況。
而類似樓主所說的多條線程之間需要頻繁交互的話，廣播是個很好的選擇，並且結構清晰，只是不知道廣播的性能與handler相比會怎麼樣。
H. android broadreceiver 運行在哪個進程
廣播接收器是運行在UI線程。
下面介紹來自於android學習手冊，android學習手冊包含9個章節，108個例子，源碼文檔隨便看，例子都是可交互，可運行，源碼採用android studio目錄結構，高亮顯示代碼，文檔都採用文檔結構圖顯示，可以快速定位。360手機助手中下載,圖標上有貝殼
1.Android廣播機制概述
Android廣播分為兩個方面：廣播發送者和廣播接收者，通常情況下，BroadcastReceiver指的就是廣播接收者（廣播接收器）。廣播作為Android組件間的通信方式，可以使用的場景如下：
1.同一app內部的同一組件內的消息通信（單個或多個線程之間）；
2.同一app內部的不同組件之間的消息通信（單個進程）；
3.同一app具有多個進程的不同組件之間的消息通信；
4.不同app之間的組件之間消息通信；
5.Android系統在特定情況下與App之間的消息通信。
從實現原理看上，Android中的廣播使用了觀察者模式，基於消息的發布/訂閱事件模型。因此，從實現的角度來看，Android中的廣播將廣播的發送者和接受者極大程度上解耦，使得系統能夠方便集成，更易擴展。具體實現流程要點粗略概括如下：
1.廣播接收者BroadcastReceiver通過Binder機制向AMS(Activity Manager Service)進行注冊；
2.廣播發送者通過binder機制向AMS發送廣播；
3.AMS查找符合相應條件（IntentFilter/Permission等）的BroadcastReceiver，將廣播發送到BroadcastReceiver（一般情況下是Activity）相應的消息循環隊列中；
4.消息循環執行拿到此廣播，回調BroadcastReceiver中的onReceive()方法。
對於不同的廣播類型，以及不同的BroadcastReceiver注冊方式，具體實現上會有不同。但總體流程大致如上。
由此看來，廣播發送者和廣播接收者分別屬於觀察者模式中的消息發布和訂閱兩端，AMS屬於中間的處理中心。廣播發送者和廣播接收者的執行是非同步的，發出去的廣播不會關心有無接收者接收，也不確定接收者到底是何時才能接收到。顯然，整體流程與EventBus非常類似。
在上文說列舉的廣播機制具體可以使用的場景中，現分析實際應用中的適用性：
第一種情形：同一app內部的同一組件內的消息通信（單個或多個線程之間），實際應用中肯定是不會用到廣播機制的（雖然可以用），無論是使用擴展變數作用域、基於介面的回調還是Handler-post/Handler-Message等方式，都可以直接處理此類問題，若適用廣播機制，顯然有些「殺雞牛刀」的感覺，會顯太「重」；
第二種情形：同一app內部的不同組件之間的消息通信（單個進程），對於此類需求，在有些教復雜的情況下單純的依靠基於介面的回調等方式不好處理，此時可以直接使用EventBus等，相對而言，EventBus由於是針對統一進程，用於處理此類需求非常適合，且輕松解耦。可以參見文件《Android各組件/控制項間通信利器之EventBus》。
第三、四、五情形：由於涉及不同進程間的消息通信，此時根據實際業務使用廣播機制會顯得非常適宜。下面主要針對Android廣播中的具體知識點進行總結。
2.BroadcastReceiver
自定義BroadcastReceiver
自定義廣播接收器需要繼承基類BroadcastReceivre，並實現抽象方法onReceive(context, intent)方法。廣播接收器接收到相應廣播後，會自動回到onReceive(..)方法。默認情況下，廣播接收器也是運行在UI線程，因此，onReceive方法中不能執行太耗時的操作。否則將因此ANR。一般情況下，根據實際業務需求，onReceive方法中都會涉及到與其他組件之間的交互，如發送Notification、啟動service等。
下面代碼片段是一個簡單的廣播接收器的自定義：
1 public class MyBroadcastReceiver extends BroadcastReceiver {
2 public static final String TAG = "MyBroadcastReceiver";
3 public static int m = 1;
4
5 @Override
6 public void onReceive(Context context, Intent intent) {
7 Log.w(TAG, "intent:" + intent);
8 String name = intent.getStringExtra("name");
9 Log.w(TAG, "name:" + name + " m=" + m);
10 m++;
11
12 Bundle bundle = intent.getExtras();
13
14 }
15 }
BroadcastReceiver注冊類型
BroadcastReceiver總體上可以分為兩種注冊類型：靜態注冊和動態注冊。
1).靜態注冊：
直接在AndroidManifest.xml文件中進行注冊。規則如下：
<receiver android:enabled=["true" | "false"]
android:exported=["true" | "false"]
android:icon="drawable resource"
android:label="string resource"
android:name="string"
android:permission="string"
android:process="string" >
. . .
</receiver>
其中，需要注意的屬性
android:exported ——此broadcastReceiver能否接收其他App的發出的廣播，這個屬性默認值有點意思，其默認值是由receiver中有無intent-filter決定的，如果有intent-filter，默認值為true，否則為false。（同樣的，activity/service中的此屬性默認值一樣遵循此規則）同時，需要注意的是，這個值的設定是以application或者application user id為界的，而非進程為界（一個應用中可能含有多個進程）；
android:name —— 此broadcastReceiver類名；
android:permission ——如果設置，具有相應許可權的廣播發送方發送的廣播才能被此broadcastReceiver所接收；
android:process ——broadcastReceiver運行所處的進程。默認為app的進程。可以指定獨立的進程（Android四大基本組件都可以通過此屬性指定自己的獨立進程）
常見的注冊形式有：
<receiver android:name=".MyBroadcastReceiver" >
<intent-filter>
<action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.BOOT_COMPLETED" />
</intent-filter>
</receiver>
其中，intent-filter由於指定此廣播接收器將用於接收特定的廣播類型。本示例中給出的是用於接收網路狀態改變或開啟啟動時系統自身所發出的廣播。當此App首次啟動時，系統會自動實例化MyBroadcastReceiver，並注冊到系統中。
之前常說：靜態注冊的廣播接收器即使app已經退出，主要有相應的廣播發出，依然可以接收到，但此種描述自Android 3.1開始有可能不再成立，具體分析詳見本文後面部分。
2).動態注冊：
動態注冊時，無須在AndroidManifest中注冊<receiver/>組件。直接在代碼中通過調用Context的registerReceiver函數，可以在程序中動態注冊BroadcastReceiver。registerReceiver的定義形式如下：
1 registerReceiver(BroadcastReceiver receiver, IntentFilter filter)
2 registerReceiver(BroadcastReceiver receiver, IntentFilter filter, String broadcastPermission, Handler scheler)
典型的寫法示例如下：
1 public class MainActivity extends Activity {
2 public static final String BROADCAST_ACTION = "com.example.corn";
3 private BroadcastReceiver mBroadcastReceiver;
4
5 @Override
6 protected void onCreate(Bundle savedInstanceState) {
7 super.onCreate(savedInstanceState);
8 setContentView(R.layout.activity_main);
9
10 mBroadcastReceiver = new MyBroadcastReceiver();
11 IntentFilter intentFilter = new IntentFilter();
12 intentFilter.addAction(BROADCAST_ACTION);
13 registerReceiver(mBroadcastReceiver, intentFilter);
14 }
15
16 @Override
17 protected void onDestroy() {
18 super.onDestroy();
19 unregisterReceiver(mBroadcastReceiver);
20 }
21
22 }
註：Android中所有與觀察者模式有關的設計中，一旦涉及到register，必定在相應的時機需要unregister。因此，上例在onDestroy()回到中需要unregisterReceiver(mBroadcastReceiver)。
當此Activity實例化時，會動態將MyBroadcastReceiver注冊到系統中。當此Activity銷毀時，動態注冊的MyBroadcastReceiver將不再接收到相應的廣播。
3.廣播發送及廣播類型
經常說」發送廣播「和」接收「，表面上看廣播作為Android廣播機制中的實體，實際上這一實體本身是並不是以所謂的」廣播「對象存在的，而是以」意圖「（Intent）去表示。定義廣播的定義過程，實際就是相應廣播」意圖「的定義過程，然後通過廣播發送者將此」意圖「發送出去。被相應的BroadcastReceiver接收後將會回調onReceive()函數。
下段代碼片段顯示的是一個普通廣播的定義過程，並發送出去。其中setAction(..)對應於BroadcastReceiver中的intentFilter中的action。
1 Intent intent = new Intent();
2 intent.setAction(BROADCAST_ACTION);
3 intent.putExtra("name", "qqyumidi");
4 sendBroadcast(intent);
根據廣播的發送方式，可以將其分為以下幾種類型：
1.Normal Broadcast：普通廣播
2.System Broadcast: 系統廣播
3.Ordered broadcast：有序廣播
4.Sticky Broadcast：粘性廣播(在 android 5.0/api 21中deprecated,不再推薦使用，相應的還有粘性有序廣播，同樣已經deprecated)
5.Local Broadcast：App應用內廣播
下面分別總結下各種類型的發送方式及其特點。
1).Normal Broadcast：普通廣播
此處將普通廣播界定為：開發者自己定義的intent，以context.sendBroadcast_"AsUser"(intent, ...)形式。具體可以使用的方法有：
sendBroadcast(intent)/sendBroadcast(intent, receiverPermission)/sendBroadcastAsUser(intent, userHandler)/sendBroadcastAsUser(intent, userHandler,receiverPermission)。
普通廣播會被注冊了的相應的感興趣（intent-filter匹配）接收，且順序是無序的。如果發送廣播時有相應的許可權要求，BroadCastReceiver如果想要接收此廣播，也需要有相應的許可權。
2).System Broadcast: 系統廣播
Android系統中內置了多個系統廣播，只要涉及到手機的基本操作，基本上都會發出相應的系統廣播。如：開啟啟動，網路狀態改變，拍照，屏幕關閉與開啟，點亮不足等等。每個系統廣播都具有特定的intent-filter，其中主要包括具體的action，系統廣播發出後，將被相應的BroadcastReceiver接收。系統廣播在系統內部當特定事件發生時，有系統自動發出。
3)Ordered broadcast：有序廣播
有序廣播的有序廣播中的「有序」是針對廣播接收者而言的，指的是發送出去的廣播被BroadcastReceiver按照先後循序接收。有序廣播的定義過程與普通廣播無異，只是其的主要發送方式變為：sendOrderedBroadcast(intent, receiverPermission, ...)。
對於有序廣播，其主要特點總結如下：
1>多個具當前已經注冊且有效的BroadcastReceiver接收有序廣播時，是按照先後順序接收的，先後順序判定標准遵循為：將當前系統中所有有效的動態注冊和靜態注冊的BroadcastReceiver按照priority屬性值從大到小排序，對於具有相同的priority的動態廣播和靜態廣播，動態廣播會排在前面。
2>先接收的BroadcastReceiver可以對此有序廣播進行截斷，使後面的BroadcastReceiver不再接收到此廣播，也可以對廣播進行修改，使後面的BroadcastReceiver接收到廣播後解析得到錯誤的參數值。當然，一般情況下，不建議對有序廣播進行此類操作，尤其是針對系統中的有序廣播。
4)Sticky Broadcast：粘性廣播(在 android 5.0/api 21中deprecated,不再推薦使用，相應的還有粘性有序廣播，同樣已經deprecated)。
既然已經deprecated，此處不再多做總結。
5)Local Broadcast：App應用內廣播（此處的App應用以App應用進程為界）
由前文闡述可知，Android中的廣播可以跨進程甚至跨App直接通信，且注冊是exported對於有intent-filter的情況下默認值是true，由此將可能出現安全隱患如下：
1.其他App可能會針對性的發出與當前App intent-filter相匹配的廣播，由此導致當前App不斷接收到廣播並處理；
2.其他App可以注冊與當前App一致的intent-filter用於接收廣播，獲取廣播具體信息。
無論哪種情形，這些安全隱患都確實是存在的。由此，最常見的增加安全性的方案是：
1.對於同一App內部發送和接收廣播，將exported屬性人為設置成false，使得非本App內部發出的此廣播不被接收；
2.在廣播發送和接收時，都增加上相應的permission，用於許可權驗證；
3.發送廣播時，指定特定廣播接收器所在的包名，具體是通過intent.setPackage(packageName)指定在，這樣此廣播將只會發送到此包中的App內與之相匹配的有效廣播接收器中。
App應用內廣播可以理解成一種局部廣播的形式，廣播的發送者和接收者都同屬於一個App。實際的業務需求中，App應用內廣播確實可能需要用到。同時，之所以使用應用內廣播時，而不是使用全局廣播的形式，更多的考慮到的是Android廣播機制中的安全性問題。
相比於全局廣播，App應用內廣播優勢體現在：
1.安全性更高；
2.更加高效。
為此，Android v4兼容包中給出了封裝好的LocalBroadcastManager類，用於統一處理App應用內的廣播問題，使用方式上與通常的全局廣播幾乎相同，只是注冊/取消注冊廣播接收器和發送廣播時將主調context變成了LocalBroadcastManager的單一實例。
代碼片段如下：
1 //registerReceiver(mBroadcastReceiver, intentFilter);
2 //注冊應用內廣播接收器
3 localBroadcastManager = LocalBroadcastManager.getInstance(this);
4 localBroadcastManager.registerReceiver(mBroadcastReceiver, intentFilter);
5
6 //unregisterReceiver(mBroadcastReceiver);
7 //取消注冊應用內廣播接收器
8 localBroadcastManager.unregisterReceiver(mBroadcastReceiver);
9
10 Intent intent = new Intent();
11 intent.setAction(BROADCAST_ACTION);
12 intent.putExtra("name", "qqyumidi");
13 //sendBroadcast(intent);
14 //發送應用內廣播
15 localBroadcastManager.sendBroadcast(intent);
4.不同注冊方式的廣播接收器回調onReceive(context, intent)中的context具體類型
1).對於靜態注冊的ContextReceiver，回調onReceive(context, intent)中的context具體指的是ReceiverRestrictedContext；
2).對於全局廣播的動態注冊的ContextReceiver，回調onReceive(context, intent)中的context具體指的是Activity Context；
3).對於通過LocalBroadcastManager動態注冊的ContextReceiver，回調onReceive(context, intent)中的context具體指的是Application Context。
註：對於LocalBroadcastManager方式發送的應用內廣播，只能通過LocalBroadcastManager動態注冊的ContextReceiver才有可能接收到（靜態注冊或其他方式動態注冊的ContextReceiver是接收不到的）。
5.不同Android API版本中廣播機制相關API重要變遷
1).Android5.0/API level 21開始粘滯廣播和有序粘滯廣播過期，以後不再建議使用；
2).」靜態注冊的廣播接收器即使app已經退出，主要有相應的廣播發出，依然可以接收到，但此種描述自Android 3.1開始有可能不再成立「
Android 3.1開始系統在Intent與廣播相關的flag增加了參數，分別是FLAG_INCLUDE_STOPPED_PACKAGES和FLAG_EXCLUDE_STOPPED_PACKAGES。
FLAG_INCLUDE_STOPPED_PACKAGES：包含已經停止的包（停止：即包所在的進程已經退出）
FLAG_EXCLUDE_STOPPED_PACKAGES：不包含已經停止的包
主要原因如下：
自Android3.1開始，系統本身則增加了對所有app當前是否處於運行狀態的跟蹤。在發送廣播時，不管是什麼廣播類型，系統默認直接增加了值為FLAG_EXCLUDE_STOPPED_PACKAGES的flag，導致即使是靜態注冊的廣播接收器，對於其所在進程已經退出的app，同樣無法接收到廣播。
詳情參加Android官方文檔：http://developer.android.com/about/versions/android-3.1.html#launchcontrols
由此，對於系統廣播，由於是系統內部直接發出，無法更改此intent flag值，因此，3.1開始對於靜態注冊的接收系統廣播的BroadcastReceiver，如果App進程已經退出，將不能接收到廣播。
但是對於自定義的廣播，可以通過復寫此flag為FLAG_INCLUDE_STOPPED_PACKAGES，使得靜態注冊的BroadcastReceiver，即使所在App進程已經退出，也能能接收到廣播，並會啟動應用進程，但此時的BroadcastReceiver是重新新建的。
1 Intent intent = new Intent();
2 intent.setAction(BROADCAST_ACTION);
3 intent.addFlags(Intent.FLAG_INCLUDE_STOPPED_PACKAGES);
4 intent.putExtra("name", "qqyumidi");
5 sendBroadcast(intent);
注1：對於動態注冊類型的BroadcastReceiver，由於此注冊和取消注冊實在其他組件（如Activity）中進行，因此，不受此改變影響。
注2：在3.1以前，相信不少app可能通過靜態注冊方式監聽各種系統廣播，以此進行一些業務上的處理（如即時app已經退出，仍然能接收到，可以啟動service等..）,3.1後，靜態注冊接受廣播方式的改變，將直接導致此類方案不再可行。於是，通過將Service與App本身設置成不同的進程已經成為實現此類需求的可行替代方案。
I. Android本地廣播的使用
為了解決廣播的安全性問題，Android引入了本地廣播機制，使用該機制發出的廣播只能在應用程序的內部進行傳遞，並且廣播接收器也只能接收來自本應用程序發出的廣播。
本地廣播是無法通過靜態注冊的方式來接收的。我們知道靜態注冊主要是為了在程序未啟動的情況下能接收廣播，而當我們發送本地廣播的時候，程序肯定是已經啟動的了，所以我們需要動態注冊方式創建接收器。
在這里我們創建一個繼承於BroadcastReceiver的類LocalReceiver。onReceive()處理你接收到的廣播內容，在這里我用Toast來創建一個提示接收到消息的彈窗
在activity_main.xml文件創建一個用於發送廣播的按鈕
首先通過本地廣播管理器LocalBroadcastManager的getInstance()方法獲取一個實例，並分別創建過濾器IntentFilter和自定義接收器LocalReceiver的實例。給IntentFilter的實例添加一個action：localbroadcast（接收的廣播的名稱），然後調用LocalBroadcastManager的registerReceiver()方法進行注冊，並將LocalReceiver的實例和IntentFilter的實例都傳進去。這樣本地監聽器就創建完成了。
調用LocalBroadcastManager的sendBroadcast()發送本地廣播。運行程序，點擊Send Button按鈕，我們可以看到彈窗顯示「This is in LocalReceiver」，說明本地廣播發送和接收成功了。
當然，我們最後一定不要忘了取消注冊。我們可以通過調用unregisterReceiver()方法來實現。至此，Android的標准廣播發送就完成了。
1.發送的廣播只能在本程序內傳遞，不必擔心數據泄露
2.其它程序廣播無法發送到本程序的內部，不必擔心安全漏洞隱患
3.本地廣播比系統全局廣播更加高效