前言
本來想寫一下廣播的，發(fā)現(xiàn)查閱后有整理的不錯的骑脱，只好轉(zhuǎn)載圖個簡便，日后好復(fù)習(xí)
轉(zhuǎn)載：http://www.cnblogs.com/lwbqqyumidi/p/4168017.html
1.[Android]廣播機(jī)制概述
Android廣播分為兩個方面：廣播發(fā)送者和廣播接收者磕洪，通常情況下鸵荠，BroadcastReceiver指的就是廣播接收者（廣播接收器）。廣播作為Android組件間的通信方式榕订，可以使用的場景如下：
- 1.同一app內(nèi)部的同一組件內(nèi)的消息通信（單個或多個線程之間）店茶；
- 2.同一app內(nèi)部的不同組件之間的消息通信（單個進(jìn)程）；
- 3.同一app具有多個進(jìn)程的不同組件之間的消息通信劫恒；
- 4.不同app之間的組件之間消息通信贩幻；
-
5.Android系統(tǒng)在特定情況下與App之間的消息通信。
從實現(xiàn)原理看上两嘴，Android中的廣播使用了觀察者模式丛楚，基于消息的發(fā)布/訂閱事件模型。因此憔辫，從實現(xiàn)的角度來看趣些，Android中的廣播將廣播的發(fā)送者和接受者極大程度上解耦，使得系統(tǒng)能夠方便集成贰您，更易擴(kuò)展喧务。具體實現(xiàn)流程要點粗略概括如下：
(1)廣播接收者BroadcastReceiver通過Binder機(jī)制向AMS(Activity Manager Service)進(jìn)行注冊；
(2)廣播發(fā)送者通過binder機(jī)制向AMS發(fā)送廣播枉圃；
(3)AMS查找符合相應(yīng)條件（IntentFilter/Permission等）的BroadcastReceiver功茴，將廣播發(fā)送到BroadcastReceiver（一般情況下是Activity）相應(yīng)的消息循環(huán)隊列中；
(4)消息循環(huán)執(zhí)行拿到此廣播孽亲，回調(diào)BroadcastReceiver中的onReceive()方法坎穿。
對于不同的廣播類型，以及不同的BroadcastReceiver注冊方式返劲，具體實現(xiàn)上會有不同玲昧。但總體流程大致如上。
由此看來篮绿，廣播發(fā)送者和廣播接收者分別屬于觀察者模式中的消息發(fā)布和訂閱兩端孵延，AMS屬于中間的處理中心。廣播發(fā)送者和廣播接收者的執(zhí)行是異步的亲配，發(fā)出去的廣播不會關(guān)心有無接收者接收尘应，也不確定接收者到底是何時才能接收到惶凝。顯然，整體流程與EventBus非常類似犬钢。
<br />
在上文說列舉的廣播機(jī)制具體可以使用的場景中苍鲜，現(xiàn)分析實際應(yīng)用中的適用性：
第一種情形：同一app內(nèi)部的同一組件內(nèi)的消息通信（單個或多個線程之間），實際應(yīng)用中肯定是不會用到廣播機(jī)制的（雖然可以用）玷犹，無論是使用擴(kuò)展變量作用域混滔、基于接口的回調(diào)還是Handler-post/Handler-Message等方式，都可以直接處理此類問題歹颓，若適用廣播機(jī)制坯屿，顯然有些“殺雞牛刀”的感覺，會顯太“重”巍扛；
第二種情形：同一app內(nèi)部的不同組件之間的消息通信（單個進(jìn)程）愿伴，對于此類需求，在有些教復(fù)雜的情況下單純的依靠基于接口的回調(diào)等方式不好處理电湘，此時可以直接使用EventBus等，相對而言鹅经，EventBus由于是針對統(tǒng)一進(jìn)程寂呛，用于處理此類需求非常適合，且輕松解耦瘾晃〈荆可以參見文件《Android各組件/控件間通信利器之EventBus》。
第三蹦误、四劫拢、五情形：由于涉及不同進(jìn)程間的消息通信，此時根據(jù)實際業(yè)務(wù)使用廣播機(jī)制會顯得非常適宜强胰。下面主要針對Android廣播中的具體知識點進(jìn)行總結(jié)舱沧。
2.BroadcastReceiver
自定義BroadcastReceiver
自定義廣播接收器需要繼承基類BroadcastReceivre，并實現(xiàn)抽象方法onReceive(context, intent)方法偶洋。廣播接收器接收到相應(yīng)廣播后熟吏，會自動回到onReceive(..)方法。默認(rèn)情況下玄窝，廣播接收器也是運(yùn)行在UI線程牵寺，因此，onReceive方法中不能執(zhí)行太耗時的操作恩脂。否則將因此ANR帽氓。一般情況下，根據(jù)實際業(yè)務(wù)需求俩块，onReceive方法中都會涉及到與其他組件之間的交互黎休，如發(fā)送Notification浓领、啟動service等。下面代碼片段是一個簡單的廣播接收器的自定義：
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注冊類型
BroadcastReceiver總體上可以分為兩種注冊類型：靜態(tài)注冊和動態(tài)注冊奋渔。
1).靜態(tài)注冊：直接在AndroidManifest.xml文件中進(jìn)行注冊镊逝。規(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ā)出的廣播嫉鲸，這個屬性默認(rèn)值有點意思撑蒜，其默認(rèn)值是由receiver中有無intent-filter決定的，如果有intent-filter玄渗，默認(rèn)值為true座菠，否則為false。（同樣的藤树，activity/service中的此屬性默認(rèn)值一樣遵循此規(guī)則）同時浴滴，需要注意的是，這個值的設(shè)定是以application或者application user id為界的岁钓，而非進(jìn)程為界（一個應(yīng)用中可能含有多個進(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)程【螅可以指定獨立的進(jìn)程（Android四大基本組件都可以通過此屬性指定自己的獨立進(jìn)程）
常見的注冊形式有：
<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)改變或開啟啟動時系統(tǒng)自身所發(fā)出的廣播啊央。當(dāng)此App首次啟動時眶诈，系統(tǒng)會自動實例化MyBroadcastReceiver，并注冊到系統(tǒng)中瓜饥。
之前常說：靜態(tài)注冊的廣播接收器即使app已經(jīng)退出逝撬，主要有相應(yīng)的廣播發(fā)出，依然可以接收到乓土，但此種描述自Android 3.1開始有可能不再成立球拦，具體分析詳見本文后面部分。
2).動態(tài)注冊：
動態(tài)注冊時帐我，無須在AndroidManifest中注冊<receiver/>組件坎炼。直接在代碼中通過調(diào)用Context的registerReceiver函數(shù)，可以在程序中動態(tài)注冊BroadcastReceiver拦键。registerReceiver的定義形式如下：
1 registerReceiver(BroadcastReceiver receiver, IntentFilter filter)
2 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è)計中谣光，一旦涉及到register，必定在相應(yīng)的時機(jī)需要unregister芬为。因此萄金，上例在onDestroy()回到中需要unregisterReceiver(mBroadcastReceiver)蟀悦。
當(dāng)此Activity實例化時，會動態(tài)將MyBroadcastReceiver注冊到系統(tǒng)中氧敢。當(dāng)此Activity銷毀時日戈，動態(tài)注冊的MyBroadcastReceiver將不再接收到相應(yīng)的廣播。
3.廣播發(fā)送及廣播類型
經(jīng)常說”發(fā)送廣播“和”接收“孙乖，表面上看廣播作為Android廣播機(jī)制中的實體浙炼，實際上這一實體本身是并不是以所謂的”廣播“對象存在的，而是以”意圖“（Intent）去表示唯袄。定義廣播的定義過程弯屈，實際就是相應(yīng)廣播”意圖“的定義過程，然后通過廣播發(fā)送者將此”意圖“發(fā)送出去恋拷。被相應(yīng)的BroadcastReceiver接收后將會回調(diào)onReceive()函數(shù)资厉。
下段代碼片段顯示的是一個普通廣播的定義過程，并發(fā)送出去蔬顾。其中setAction(..)對應(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ā)送方式及其特點。
1).Normal Broadcast：普通廣播
此處將普通廣播界定為：開發(fā)者自己定義的intent且叁，以context.sendBroadcast_"AsUser"(intent, ...)形式。具體可以使用的方法有：sendBroadcast(intent)/sendBroadcast(intent, receiverPermission)/sendBroadcastAsUser(intent, userHandler)/sendBroadcastAsUser(intent, userHandler,receiverPermission)秩伞。普通廣播會被注冊了的相應(yīng)的感興趣（intent-filter匹配）接收逞带，且順序是無序的。如果發(fā)送廣播時有相應(yīng)的權(quán)限要求纱新，BroadCastReceiver如果想要接收此廣播展氓，也需要有相應(yīng)的權(quán)限。
2).System Broadcast: 系統(tǒng)廣播
Android系統(tǒng)中內(nèi)置了多個系統(tǒng)廣播脸爱，只要涉及到手機(jī)的基本操作遇汞，基本上都會發(fā)出相應(yīng)的系統(tǒng)廣播。如：開啟啟動簿废，網(wǎng)絡(luò)狀態(tài)改變空入，拍照，屏幕關(guān)閉與開啟族檬，點亮不足等等歪赢。每個系統(tǒng)廣播都具有特定的intent-filter，其中主要包括具體的action单料，系統(tǒng)廣播發(fā)出后埋凯，將被相應(yīng)的BroadcastReceiver接收点楼。系統(tǒng)廣播在系統(tǒng)內(nèi)部當(dāng)特定事件發(fā)生時，有系統(tǒng)自動發(fā)出白对。
3)Ordered broadcast：有序廣播
有序廣播的有序廣播中的“有序”是針對廣播接收者而言的掠廓，指的是發(fā)送出去的廣播被BroadcastReceiver按照先后循序接收。有序廣播的定義過程與普通廣播無異甩恼，只是其的主要發(fā)送方式變?yōu)椋簊endOrderedBroadcast(intent, receiverPermission, ...)蟀瞧。
對于有序廣播，其主要特點總結(jié)如下：
1>多個具當(dāng)前已經(jīng)注冊且有效的BroadcastReceiver接收有序廣播時媳拴，是按照先后順序接收的黄橘，先后順序判定標(biāo)準(zhǔn)遵循為：將當(dāng)前系統(tǒng)中所有有效的動態(tài)注冊和靜態(tài)注冊的BroadcastReceiver按照priority屬性值從大到小排序，對于具有相同的priority的動態(tài)廣播和靜態(tài)廣播屈溉，動態(tài)廣播會排在前面塞关，前面的可以終止廣播，終止廣播(abortBroadcast())子巾，后面的就收不到了帆赢。
2>先接收的BroadcastReceiver可以對此有序廣播進(jìn)行截斷，使后面的BroadcastReceiver不再接收到此廣播线梗，也可以對廣播進(jìn)行修改椰于，使后面的BroadcastReceiver接收到廣播后解析得到錯誤的參數(shù)值。當(dāng)然仪搔，一般情況下瘾婿，不建議對有序廣播進(jìn)行此類操作，尤其是針對系統(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直接通信饥脑，且注冊是exported對于有intent-filter的情況下默認(rèn)值是true，由此將可能出現(xiàn)安全隱患如下：
1.其他App可能會針對性的發(fā)出與當(dāng)前App intent-filter相匹配的廣播懦冰，由此導(dǎo)致當(dāng)前App不斷接收到廣播并處理灶轰；
2.其他App可以注冊與當(dāng)前App一致的intent-filter用于接收廣播，獲取廣播具體信息刷钢。
無論哪種情形框往，這些安全隱患都確實是存在的。由此闯捎，最常見的增加安全性的方案是：
1.對于同一App內(nèi)部發(fā)送和接收廣播椰弊，將exported屬性人為設(shè)置成false许溅，使得非本App內(nèi)部發(fā)出的此廣播不被接收；
2.在廣播發(fā)送和接收時秉版，都增加上相應(yīng)的permission贤重，用于權(quán)限驗證；
3.發(fā)送廣播時清焕，指定特定廣播接收器所在的包名并蝗，具體是通過intent.setPackage(packageName)指定在，這樣此廣播將只會發(fā)送到此包中的App內(nèi)與之相匹配的有效廣播接收器中秸妥。
App應(yīng)用內(nèi)廣播可以理解成一種局部廣播的形式滚停，廣播的發(fā)送者和接收者都同屬于一個App。實際的業(yè)務(wù)需求中粥惧，App應(yīng)用內(nèi)廣播確實可能需要用到键畴。同時，之所以使用應(yīng)用內(nèi)廣播時突雪，而不是使用全局廣播的形式起惕，更多的考慮到的是Android廣播機(jī)制中的安全性問題。
相比于全局廣播咏删，App應(yīng)用內(nèi)廣播優(yōu)勢體現(xiàn)在：
1.安全性更高惹想；
2.更加高效。
為此督函，Android v4兼容包中給出了封裝好的LocalBroadcastManager類嘀粱，用于統(tǒng)一處理App應(yīng)用內(nèi)的廣播問題，使用方式上與通常的全局廣播幾乎相同辰狡，只是注冊/取消注冊廣播接收器和發(fā)送廣播時將主調(diào)context變成了LocalBroadcastManager的單一實例锋叨。
代碼片段如下：
//registerReceiver(mBroadcastReceiver, intentFilter);
//注冊應(yīng)用內(nèi)廣播接收器
localBroadcastManager = LocalBroadcastManager.getInstance(this);
localBroadcastManager.registerReceiver(mBroadcastReceiver, intentFilter);
//unregisterReceiver(mBroadcastReceiver);
//取消注冊應(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.不同注冊方式的廣播接收器回調(diào)onReceive(context, intent)中的context具體類型
1).對于靜態(tài)注冊的ContextReceiver，回調(diào)onReceive(context, intent)中的context具體指的是ReceiverRestrictedContext搓译；
2).對于全局廣播的動態(tài)注冊的ContextReceiver悲柱，回調(diào)onReceive(context, intent)中的context具體指的是Activity Context锋喜；
3).對于通過LocalBroadcastManager動態(tài)注冊的ContextReceiver些己，回調(diào)onReceive(context, intent)中的context具體指的是Application Context。
注：對于LocalBroadcastManager方式發(fā)送的應(yīng)用內(nèi)廣播嘿般，只能通過LocalBroadcastManager動態(tài)注冊的ContextReceiver才有可能接收到（靜態(tài)注冊或其他方式動態(tài)注冊的ContextReceiver是接收不到的）段标。
5.不同Android API版本中廣播機(jī)制相關(guān)API重要變遷
1).Android5.0/API level 21開始粘滯廣播和有序粘滯廣播過期，以后不再建議使用炉奴；
2).”靜態(tài)注冊的廣播接收器即使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)本身則增加了對所有app當(dāng)前是否處于運(yùn)行狀態(tài)的跟蹤璧南。在發(fā)送廣播時掌逛，不管是什么廣播類型，系統(tǒng)默認(rèn)直接增加了值為FLAG_EXCLUDE_STOPPED_PACKAGES的flag司倚，導(dǎo)致即使是靜態(tài)注冊的廣播接收器豆混，對于其所在進(jìn)程已經(jīng)退出的app，同樣無法接收到廣播动知。
詳情參加Android官方文檔：http://developer.android.com/about/versions/android-3.1.html#launchcontrols
由此皿伺，對于系統(tǒng)廣播，由于是系統(tǒng)內(nèi)部直接發(fā)出盒粮，無法更改此intent flag值鸵鸥，因此，3.1開始對于靜態(tài)注冊的接收系統(tǒng)廣播的BroadcastReceiver拆讯，如果App進(jìn)程已經(jīng)退出脂男，將不能接收到廣播。
但是對于自定義的廣播种呐，可以通過復(fù)寫此flag為FLAG_INCLUDE_STOPPED_PACKAGES宰翅，使得靜態(tài)注冊的BroadcastReceiver，即使所在App進(jìn)程已經(jīng)退出爽室，也能能接收到廣播汁讼，并會啟動應(yīng)用進(jìn)程，但此時的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：對于動態(tài)注冊類型的BroadcastReceiver嘿架，由于此注冊和取消注冊實在其他組件（如Activity）中進(jìn)行，因此啸箫，不受此改變影響耸彪。
注2：在3.1以前，相信不少app可能通過靜態(tài)注冊方式監(jiān)聽各種系統(tǒng)廣播忘苛，以此進(jìn)行一些業(yè)務(wù)上的處理（如即時app已經(jīng)退出蝉娜，仍然能接收到，可以啟動service等..）,3.1后扎唾，靜態(tài)注冊接受廣播方式的改變召川，將直接導(dǎo)致此類方案不再可行。于是胸遇，通過將Service與App本身設(shè)置成不同的進(jìn)程已經(jīng)成為實現(xiàn)此類需求的可行替代方案荧呐。
