諸多無(wú)奈，最近在改一個(gè)項(xiàng)目的bug的時(shí)候银萍，腦子老是一片空白变勇，可能是最近腦子不夠用，總之贴唇，好多東西忘了搀绣，閱讀一些別人的文章，或者書籍戳气，做個(gè)記錄链患，時(shí)常翻翻，免得一味的研究新技術(shù)物咳，把自己架空了锣险。

本文是閱讀后轉(zhuǎn)載自http://www.cnblogs.com/lwbqqyumidi/p/4168017.html，自己方便后續(xù)閱讀鞏固!

1.Android廣播機(jī)制概述

Android廣播分為兩個(gè)方面：廣播發(fā)送者和廣播接收者览闰，通常情況下芯肤，BroadcastReceiver指的就是廣播接收者（廣播接收器）。廣播作為Android組件間的通信方式压鉴，可以使用的場(chǎng)景如下：

• 1.同一app內(nèi)部的同一組件內(nèi)的消息通信（單個(gè)或多個(gè)線程之間）崖咨；

• 2.同一app內(nèi)部的不同組件之間的消息通信（單個(gè)進(jìn)程）；

• 3.同一app具有多個(gè)進(jìn)程的不同組件之間的消息通信油吭；

• 4.不同app之間的組件之間消息通信击蹲；

• 5.Android系統(tǒng)在特定情況下與App之間的消息通信署拟。

從實(shí)現(xiàn)原理看上，Android中的廣播使用了觀察者模式歌豺，基于消息的發(fā)布/訂閱事件模型推穷。因此，從實(shí)現(xiàn)的角度來看类咧，Android中的廣播將廣播的發(fā)送者和接受者極大程度上解耦馒铃，使得系統(tǒng)能夠方便集成，更易擴(kuò)展痕惋。具體實(shí)現(xiàn)流程要點(diǎn)粗略概括如下：

• 1.廣播接收者BroadcastReceiver通過Binder機(jī)制向AMS(Activity Manager Service)進(jìn)行注冊(cè)区宇；

• 2.廣播發(fā)送者通過binder機(jī)制向AMS發(fā)送廣播；

• 3.AMS查找符合相應(yīng)條件（IntentFilter/Permission等）的BroadcastReceiver值戳，將廣播發(fā)送到BroadcastReceiver（一般情況下是Activity）相應(yīng)的消息循環(huán)隊(duì)列中议谷；

• 4.消息循環(huán)執(zhí)行拿到此廣播，回調(diào)BroadcastReceiver中的onReceive()方法堕虹。

對(duì)于不同的廣播類型卧晓，以及不同的BroadcastReceiver注冊(cè)方式，具體實(shí)現(xiàn)上會(huì)有不同鲫凶。但總體流程大致如上禀崖。

由此看來，廣播發(fā)送者和廣播接收者分別屬于觀察者模式中的消息發(fā)布和訂閱兩端螟炫，AMS屬于中間的處理中心波附。廣播發(fā)送者和廣播接收者的執(zhí)行是異步的，發(fā)出去的廣播不會(huì)關(guān)心有無(wú)接收者接收昼钻，也不確定接收者到底是何時(shí)才能接收到掸屡。顯然，整體流程與EventBus非常類似然评。

在上文說列舉的廣播機(jī)制具體可以使用的場(chǎng)景中仅财，現(xiàn)分析實(shí)際應(yīng)用中的適用性：

• 第一種情形：同一app內(nèi)部的同一組件內(nèi)的消息通信（單個(gè)或多個(gè)線程之間），實(shí)際應(yīng)用中肯定是不會(huì)用到廣播機(jī)制的（雖然可以用）碗淌，無(wú)論是使用擴(kuò)展變量作用域盏求、基于接口的回調(diào)還是Handler-post/Handler-Message等方式，都可以直接處理此類問題亿眠，若適用廣播機(jī)制碎罚，顯然有些“殺雞牛刀”的感覺，會(huì)顯太“重”纳像；

• 第二種情形：同一app內(nèi)部的不同組件之間的消息通信（單個(gè)進(jìn)程）荆烈，對(duì)于此類需求，在有些教復(fù)雜的情況下單純的依靠基于接口的回調(diào)等方式不好處理，此時(shí)可以直接使用EventBus等憔购，相對(duì)而言宫峦，EventBus由于是針對(duì)統(tǒng)一進(jìn)程，用于處理此類需求非常適合玫鸟，且輕松解耦导绷。可以參見文件《Android各組件/控件間通信利器之EventBus》屎飘。

第三诵次、四、五情形：由于涉及不同進(jìn)程間的消息通信枚碗，此時(shí)根據(jù)實(shí)際業(yè)務(wù)使用廣播機(jī)制會(huì)顯得非常適宜。下面主要針對(duì)Android廣播中的具體知識(shí)點(diǎn)進(jìn)行總結(jié)铸本。

2.BroadcastReceiver

自定義BroadcastReceiver

自定義廣播接收器需要繼承基類BroadcastReceivre肮雨，并實(shí)現(xiàn)抽象方法onReceive(context, intent)方法。廣播接收器接收到相應(yīng)廣播后箱玷，會(huì)自動(dòng)回到onReceive(..)方法怨规。默認(rèn)情況下，廣播接收器也是運(yùn)行在UI線程锡足，因此波丰，onReceive方法中不能執(zhí)行太耗時(shí)的操作。否則將因此ANR舶得。一般情況下掰烟，根據(jù)實(shí)際業(yè)務(wù)需求，onReceive方法中都會(huì)涉及到與其他組件之間的交互沐批，如發(fā)送Notification纫骑、啟動(dòng)service等。
下面代碼片段是一個(gè)簡(jiǎn)單的廣播接收器的自定義：

public class MyBroadcastReceiver extends BroadcastReceiver {
public static final String TAG = "MyBroadcastReceiver";
public static int m = 1;

  @Override
  public void onReceive(Context context, Intent intent) {
      Log.w(TAG, "intent:" + intent);
      String name = intent.getStringExtra("name");
      Log.w(TAG, "name:" + name + " m=" + m);
     m++;

     Bundle bundle = intent.getExtras();

 }

}

BroadcastReceiver注冊(cè)類型

BroadcastReceiver總體上可以分為兩種注冊(cè)類型：靜態(tài)注冊(cè)和動(dòng)態(tài)注冊(cè)九孩。

• 1).靜態(tài)注冊(cè)：
  直接在AndroidManifest.xml文件中進(jìn)行注冊(cè)先馆。規(guī)則如下：

<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的發(fā)出的廣播躺彬，這個(gè)屬性默認(rèn)值有點(diǎn)意思煤墙，其默認(rèn)值是由receiver中有無(wú)intent-filter決定的，如果有intent-filter宪拥，默認(rèn)值為true仿野，否則為false。（同樣的江解，activity/service中的此屬性默認(rèn)值一樣遵循此規(guī)則）同時(shí)设预，需要注意的是，這個(gè)值的設(shè)定是以application或者application user id為界的犁河，而非進(jìn)程為界（一個(gè)應(yīng)用中可能含有多個(gè)進(jìn)程）鳖枕；
android:name —— 此broadcastReceiver類名魄梯；
android:permission ——如果設(shè)置，具有相應(yīng)權(quán)限的廣播發(fā)送方發(fā)送的廣播才能被此broadcastReceiver所接收宾符；
android:process ——broadcastReceiver運(yùn)行所處的進(jìn)程酿秸。默認(rèn)為app的進(jìn)程∥禾蹋可以指定獨(dú)立的進(jìn)程（Android四大基本組件都可以通過此屬性指定自己的獨(dú)立進(jìn)程）

常見的注冊(cè)形式有：

<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由于指定此廣播接收器將用于接收特定的廣播類型。本示例中給出的是用于接收網(wǎng)絡(luò)狀態(tài)改變或開啟啟動(dòng)時(shí)系統(tǒng)自身所發(fā)出的廣播哄褒。當(dāng)此App首次啟動(dòng)時(shí)稀蟋，系統(tǒng)會(huì)自動(dòng)實(shí)例化MyBroadcastReceiver，并注冊(cè)到系統(tǒng)中呐赡。

之前常說：靜態(tài)注冊(cè)的廣播接收器即使app已經(jīng)退出退客，主要有相應(yīng)的廣播發(fā)出，依然可以接收到链嘀，但此種描述自Android 3.1開始有可能不再成立萌狂，具體分析詳見本文后面部分。

• 2).動(dòng)態(tài)注冊(cè)：
  動(dòng)態(tài)注冊(cè)時(shí)怀泊，無(wú)須在AndroidManifest中注冊(cè)<receiver/>組件茫藏。直接在代碼中通過調(diào)用Context的registerReceiver函數(shù)，可以在程序中動(dòng)態(tài)注冊(cè)BroadcastReceiver霹琼。registerReceiver的定義形式如下：

  • registerReceiver(BroadcastReceiver receiver, IntentFilter filter)

  • registerReceiver(BroadcastReceiver receiver, IntentFilter filter, String broadcastPermission, Handler scheduler)

典型的寫法示例如下：

public class MainActivity extends Activity {
public static final String BROADCAST_ACTION = "com.example.corn";
private BroadcastReceiver mBroadcastReceiver;

  @Override
  protected void onCreate(Bundle savedInstanceState) {
      super.onCreate(savedInstanceState);
      setContentView(R.layout.activity_main);

     mBroadcastReceiver = new MyBroadcastReceiver();
     IntentFilter intentFilter = new IntentFilter();
     intentFilter.addAction(BROADCAST_ACTION);
     registerReceiver(mBroadcastReceiver, intentFilter);
 }

 @Override
 protected void onDestroy() {
     super.onDestroy();
     unregisterReceiver(mBroadcastReceiver);
 }

}

注：Android中所有與觀察者模式有關(guān)的設(shè)計(jì)中务傲，一旦涉及到register，必定在相應(yīng)的時(shí)機(jī)需要unregister碧囊。因此树灶，上例在onDestroy()回到中需要unregisterReceiver(mBroadcastReceiver)。

當(dāng)此Activity實(shí)例化時(shí)糯而，會(huì)動(dòng)態(tài)將MyBroadcastReceiver注冊(cè)到系統(tǒng)中天通。當(dāng)此Activity銷毀時(shí)，動(dòng)態(tài)注冊(cè)的MyBroadcastReceiver將不再接收到相應(yīng)的廣播熄驼。

3.廣播發(fā)送及廣播類型

經(jīng)常說”發(fā)送廣播“和”接收“像寒，表面上看廣播作為Android廣播機(jī)制中的實(shí)體，實(shí)際上這一實(shí)體本身是并不是以所謂的”廣播“對(duì)象存在的瓜贾，而是以”意圖“（Intent）去表示诺祸。定義廣播的定義過程，實(shí)際就是相應(yīng)廣播”意圖“的定義過程祭芦，然后通過廣播發(fā)送者將此”意圖“發(fā)送出去筷笨。被相應(yīng)的BroadcastReceiver接收后將會(huì)回調(diào)onReceive()函數(shù)。

下段代碼片段顯示的是一個(gè)普通廣播的定義過程，并發(fā)送出去胃夏。其中setAction(..)對(duì)應(yīng)于BroadcastReceiver中的intentFilter中的action轴或。

Intent intent = new Intent();
intent.setAction(BROADCAST_ACTION);
intent.putExtra("name", "qqyumidi");
sendBroadcast(intent);
根據(jù)廣播的發(fā)送方式，可以將其分為以下幾種類型：

• 1.Normal Broadcast：普通廣播

• 2.System Broadcast: 系統(tǒng)廣播

• 3.Ordered broadcast：有序廣播

• 4.Sticky Broadcast：粘性廣播(在 android 5.0/api 21中deprecated,不再推薦使用仰禀，相應(yīng)的還有粘性有序廣播照雁，同樣已經(jīng)deprecated)

• 5.Local Broadcast：App應(yīng)用內(nèi)廣播

下面分別總結(jié)下各種類型的發(fā)送方式及其特點(diǎn)。

• 1).Normal Broadcast：普通廣播

此處將普通廣播界定為：開發(fā)者自己定義的intent答恶，以context.sendBroadcast_"AsUser"(intent, ...)形式饺蚊。具體可以使用的方法有：
sendBroadcast(intent)/sendBroadcast(intent, receiverPermission)/sendBroadcastAsUser(intent, userHandler)/sendBroadcastAsUser(intent, userHandler,receiverPermission)。
普通廣播會(huì)被注冊(cè)了的相應(yīng)的感興趣（intent-filter匹配）接收悬嗓，且順序是無(wú)序的污呼。如果發(fā)送廣播時(shí)有相應(yīng)的權(quán)限要求，BroadCastReceiver如果想要接收此廣播包竹，也需要有相應(yīng)的權(quán)限曙求。

• 2).System Broadcast: 系統(tǒng)廣播

Android系統(tǒng)中內(nèi)置了多個(gè)系統(tǒng)廣播，只要涉及到手機(jī)的基本操作映企，基本上都會(huì)發(fā)出相應(yīng)的系統(tǒng)廣播。如：開啟啟動(dòng)静浴，網(wǎng)絡(luò)狀態(tài)改變堰氓，拍照，屏幕關(guān)閉與開啟苹享，點(diǎn)亮不足等等双絮。每個(gè)系統(tǒng)廣播都具有特定的intent-filter，其中主要包括具體的action得问，系統(tǒng)廣播發(fā)出后囤攀，將被相應(yīng)的BroadcastReceiver接收。系統(tǒng)廣播在系統(tǒng)內(nèi)部當(dāng)特定事件發(fā)生時(shí)宫纬，有系統(tǒng)自動(dòng)發(fā)出焚挠。

• 3)Ordered broadcast：有序廣播

有序廣播的有序廣播中的“有序”是針對(duì)廣播接收者而言的，指的是發(fā)送出去的廣播被BroadcastReceiver按照先后循序接收漓骚。有序廣播的定義過程與普通廣播無(wú)異蝌衔，只是其的主要發(fā)送方式變?yōu)椋簊endOrderedBroadcast(intent, receiverPermission, ...)。

對(duì)于有序廣播蝌蹂，其主要特點(diǎn)總結(jié)如下：

* 1>多個(gè)具當(dāng)前已經(jīng)注冊(cè)且有效的BroadcastReceiver接收有序廣播時(shí)噩斟，是按照先后順序接收的，先后順序判定標(biāo)準(zhǔn)遵循為：將當(dāng)前系統(tǒng)中所有有效的動(dòng)態(tài)注冊(cè)和靜態(tài)注冊(cè)的BroadcastReceiver按照priority屬性值從大到小排序孤个，對(duì)于具有相同的priority的動(dòng)態(tài)廣播和靜態(tài)廣播剃允，動(dòng)態(tài)廣播會(huì)排在前面。

* 2>先接收的BroadcastReceiver可以對(duì)此有序廣播進(jìn)行截?cái)啵购竺娴腂roadcastReceiver不再接收到此廣播斥废，也可以對(duì)廣播進(jìn)行修改椒楣，使后面的BroadcastReceiver接收到廣播后解析得到錯(cuò)誤的參數(shù)值。當(dāng)然营袜，一般情況下撒顿，不建議對(duì)有序廣播進(jìn)行此類操作，尤其是針對(duì)系統(tǒng)中的有序廣播荚板。

• 4)Sticky Broadcast：粘性廣播(在 android 5.0/api 21中deprecated,不再推薦使用凤壁，相應(yīng)的還有粘性有序廣播，同樣已經(jīng)deprecated)跪另。

既然已經(jīng)deprecated拧抖，此處不再多做總結(jié)。

• 5)Local Broadcast：App應(yīng)用內(nèi)廣播（此處的App應(yīng)用以App應(yīng)用進(jìn)程為界）

由前文闡述可知免绿，Android中的廣播可以跨進(jìn)程甚至跨App直接通信唧席，且注冊(cè)是exported對(duì)于有intent-filter的情況下默認(rèn)值是true，由此將可能出現(xiàn)安全隱患如下：

• 1.其他App可能會(huì)針對(duì)性的發(fā)出與當(dāng)前App intent-filter相匹配的廣播嘲驾，由此導(dǎo)致當(dāng)前App不斷接收到廣播并處理淌哟；

• 2.其他App可以注冊(cè)與當(dāng)前App一致的intent-filter用于接收廣播，獲取廣播具體信息辽故。

無(wú)論哪種情形徒仓，這些安全隱患都確實(shí)是存在的。由此誊垢，最常見的增加安全性的方案是：

• 1.對(duì)于同一App內(nèi)部發(fā)送和接收廣播掉弛，將exported屬性人為設(shè)置成false，使得非本App內(nèi)部發(fā)出的此廣播不被接收喂走；

• 2.在廣播發(fā)送和接收時(shí)殃饿，都增加上相應(yīng)的permission，用于權(quán)限驗(yàn)證芋肠；

• 3.發(fā)送廣播時(shí)乎芳，指定特定廣播接收器所在的包名，具體是通過intent.setPackage(packageName)指定在帖池，這樣此廣播將只會(huì)發(fā)送到此包中的App內(nèi)與之相匹配的有效廣播接收器中秒咐。

App應(yīng)用內(nèi)廣播可以理解成一種局部廣播的形式，廣播的發(fā)送者和接收者都同屬于一個(gè)App碘裕。實(shí)際的業(yè)務(wù)需求中携取，App應(yīng)用內(nèi)廣播確實(shí)可能需要用到。同時(shí)帮孔，之所以使用應(yīng)用內(nèi)廣播時(shí)雷滋，而不是使用全局廣播的形式不撑，更多的考慮到的是Android廣播機(jī)制中的安全性問題。

相比于全局廣播晤斩，App應(yīng)用內(nèi)廣播優(yōu)勢(shì)體現(xiàn)在：

• 1.安全性更高焕檬；

• 2.更加高效。

為此澳泵，Android v4兼容包中給出了封裝好的LocalBroadcastManager類实愚，用于統(tǒng)一處理App應(yīng)用內(nèi)的廣播問題，使用方式上與通常的全局廣播幾乎相同兔辅，只是注冊(cè)/取消注冊(cè)廣播接收器和發(fā)送廣播時(shí)將主調(diào)context變成了LocalBroadcastManager的單一實(shí)例腊敲。

代碼片段如下：

//registerReceiver(mBroadcastReceiver, intentFilter);
//注冊(cè)應(yīng)用內(nèi)廣播接收器
localBroadcastManager = LocalBroadcastManager.getInstance(this);
localBroadcastManager.registerReceiver(mBroadcastReceiver, intentFilter);

//unregisterReceiver(mBroadcastReceiver);
//取消注冊(cè)應(yīng)用內(nèi)廣播接收器
localBroadcastManager.unregisterReceiver(mBroadcastReceiver);

Intent intent = new Intent();
intent.setAction(BROADCAST_ACTION);
intent.putExtra("name", "qqyumidi");
//sendBroadcast(intent);
//發(fā)送應(yīng)用內(nèi)廣播
localBroadcastManager.sendBroadcast(intent);

4.不同注冊(cè)方式的廣播接收器回調(diào)onReceive(context, intent)中的context具體類型

• 1).對(duì)于靜態(tài)注冊(cè)的ContextReceiver，回調(diào)onReceive(context, intent)中的context具體指的是ReceiverRestrictedContext维苔；

• 2).對(duì)于全局廣播的動(dòng)態(tài)注冊(cè)的ContextReceiver碰辅，回調(diào)onReceive(context, intent)中的context具體指的是Activity Context；

• 3).對(duì)于通過LocalBroadcastManager動(dòng)態(tài)注冊(cè)的ContextReceiver介时，回調(diào)onReceive(context, intent)中的context具體指的是Application Context没宾。

注：對(duì)于LocalBroadcastManager方式發(fā)送的應(yīng)用內(nèi)廣播，只能通過LocalBroadcastManager動(dòng)態(tài)注冊(cè)的ContextReceiver才有可能接收到（靜態(tài)注冊(cè)或其他方式動(dòng)態(tài)注冊(cè)的ContextReceiver是接收不到的）沸柔。

5.不同Android API版本中廣播機(jī)制相關(guān)API重要變遷

• 1).Android5.0/API level 21開始粘滯廣播和有序粘滯廣播過期循衰，以后不再建議使用；

• 2).”靜態(tài)注冊(cè)的廣播接收器即使app已經(jīng)退出褐澎，主要有相應(yīng)的廣播發(fā)出羹蚣，依然可以接收到，但此種描述自Android 3.1開始有可能不再成立“

Android 3.1開始系統(tǒng)在Intent與廣播相關(guān)的flag增加了參數(shù)乱凿，分別是FLAG_INCLUDE_STOPPED_PACKAGES和FLAG_EXCLUDE_STOPPED_PACKAGES。

FLAG_INCLUDE_STOPPED_PACKAGES：包含已經(jīng)停止的包（停止：即包所在的進(jìn)程已經(jīng)退出）

FLAG_EXCLUDE_STOPPED_PACKAGES：不包含已經(jīng)停止的包

主要原因如下：

自Android3.1開始咽弦，系統(tǒng)本身則增加了對(duì)所有app當(dāng)前是否處于運(yùn)行狀態(tài)的跟蹤徒蟆。在發(fā)送廣播時(shí)，不管是什么廣播類型型型，系統(tǒng)默認(rèn)直接增加了值為FLAG_EXCLUDE_STOPPED_PACKAGES的flag，導(dǎo)致即使是靜態(tài)注冊(cè)的廣播接收器闹蒜，對(duì)于其所在進(jìn)程已經(jīng)退出的app寺枉，同樣無(wú)法接收到廣播。

詳情參加Android官方文檔：http://developer.android.com/about/versions/android-3.1.html#launchcontrols

由此绷落，對(duì)于系統(tǒng)廣播姥闪，由于是系統(tǒng)內(nèi)部直接發(fā)出，無(wú)法更改此intent flag值砌烁，因此筐喳，3.1開始對(duì)于靜態(tài)注冊(cè)的接收系統(tǒng)廣播的BroadcastReceiver催式，如果App進(jìn)程已經(jīng)退出，將不能接收到廣播避归。

但是對(duì)于自定義的廣播荣月，可以通過復(fù)寫此flag為FLAG_INCLUDE_STOPPED_PACKAGES，使得靜態(tài)注冊(cè)的BroadcastReceiver梳毙，即使所在App進(jìn)程已經(jīng)退出哺窄，也能能接收到廣播，并會(huì)啟動(dòng)應(yīng)用進(jìn)程账锹，但此時(shí)的BroadcastReceiver是重新新建的萌业。

 Intent intent = new Intent();
 intent.setAction(BROADCAST_ACTION);
 intent.addFlags(Intent.FLAG_INCLUDE_STOPPED_PACKAGES);
 intent.putExtra("name", "qqyumidi");
 sendBroadcast(intent);

注1：對(duì)于動(dòng)態(tài)注冊(cè)類型的BroadcastReceiver，由于此注冊(cè)和取消注冊(cè)實(shí)在其他組件（如Activity）中進(jìn)行牌废，因此咽白，不受此改變影響。

注2：在3.1以前鸟缕，相信不少app可能通過靜態(tài)注冊(cè)方式監(jiān)聽各種系統(tǒng)廣播晶框，以此進(jìn)行一些業(yè)務(wù)上的處理（如即時(shí)app已經(jīng)退出，仍然能接收到懂从，可以啟動(dòng)service等..）,3.1后授段，靜態(tài)注冊(cè)接受廣播方式的改變，將直接導(dǎo)致此類方案不再可行番甩。于是侵贵，通過將Service與App本身設(shè)置成不同的進(jìn)程已經(jīng)成為實(shí)現(xiàn)此類需求的可行替代方案。