android广播机制
① android 什么时候用到广播
1.正常情况下我们选择handler消息机制来进行单向的线程间的通信；（工作线程向主线程发送消息）
因为主线程有现成的handler，而工作线程没有现成的handler，这样的话，主线程将handler交给工作线程而让工作线程将工作的结果交给主线程；
相反，工作线程中没有现成的handler（事实上是没有消息队列，也就是handler没有绑定到工作线程），那么，如果开辟的话，代码角度上是挺麻烦的（相对应广播机制来说）；
2.广播机制本身就是双向的（工作线程向主线程发送广播，主线程向工作线程发送广播）；
另外，对于像一个activity中通过fragment来进行界面的处理； 我们大多数情况下是采用广播的机制来实现fragment中adapter的数据的更新；这样做主要是考虑到工作线程的任务加载完成，而具体的对应刷新的activity可能还没有启动；
另外，基于接口隔离原则，如果用handler进行通信的话，则不能很好的满足这一原则
② 简述在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
③ 为什么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的世界，到处都充满着广播，就是为了用来监听手机的各种状态，给用户提醒，这是一种很好的用户体验，不过任何事情都是如此，广播也不可以多用哦，
④ android广播机制的广播的生命周期
广播接收器仅在它执行这个方法时处于活跃状态。当onReceive()返回后，它即为失活状态。
拥有一个活跃状态的广播接收器的进程被保护起来而不会被杀死，但仅拥有失活状态组件的进程则会在其它进程需要它所占有的内存的时候随时被杀掉。所以，如果响应一个广播信息需要很长的一段时间，我们一般会将其纳入一个衍生的线程中去完成，而不是在主线程内完成它，从而保证用户交互过程的流畅。
⑤ Android怎样通过广播机制唤醒后台服务
[mw_shl_code=java,false] <receiver
android:name="com.test.DataChangeReceiver" >
<intent-filter>
<action
android:name="android.intent.action.DATE_CHANGED" />
</intent-filter>
</receiver>[/mw_shl_code]
这个是一个接收日期改变后的广播的例子；
对应的 java文件
就一个receive
[mw_shl_code=java,true]public class DataChangeReceiver extends
BaseReceiver {
@Override
public void onReceive(Context
context, Intent intent) {}
}[/mw_shl_code]
⑥ 注册广播有几种方式，这些方式有何优缺点请谈谈Android引入广播机制的用意。
android中，不同进程之间传递信息要用到广播，可以有两种方式来实现。
第一种方式：在Manifest.xml中注册广播，是一种比较推荐的方法，因为它不需要手动注销广播（如果广播未注销，程序退出时可能会出错）。
具体实现在Manifest的application中添加：上面两个android:name分别是广播名和广播的动作（这里的动作是表示系统启动完成），如果要自己发送一个广播，在代码中为：
Intent i = new Intent(“android.intent.action.BOOT_COMPLETED”);
sendBroadcast(i);
这样，广播就发出去了，然后是接收。
接收可以新建一个类，继承至BroadcastReceiver，也可以建一个BroadcastReceiver的实例，然后得写onReceive方法，实现如下：
protected BroadcastReceiver mEvtReceiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
if (action.equals(“android.intent.action.BOOT_COMPLETED”)) {
//Do something
}
}
};
第二种方式，直接在代码中实现，但需要手动注册注销，实现如下：
IntentFilter filter = new IntentFilter();
filter.addAction(“android.intent.action.BOOT_COMPLETED”);
registerReceiver(mEvtReceiver, filter); //这时注册了一个recevier ,名为mEvtReceiver，然后同样用上面的方法以重写onReceiver，
最后在程序的onDestroy中要注销广播，实现如下：
@Override
public void onDestroy() {
super.onDestroy();
unregisterReceiver(mPlayerEvtReceiver);
}
⑦ android中什么时候会选择用广播来进行线程间的通信
android中什么时候会选择用广播来进行线程间的通信 Android 多线程 通信
线程中通信就不要用广播了吧 进程中通信可以用广播或者aidl
可是，这两天看到的项目都是这么做的；然后，自己分析了下，觉得一下的理由也是可以成立的；
1.正常情况下我们选择handler消息机制来进行单向的线程间的通信；（工作线程向主线程发送消息）
因为主线程有现成的handler，而工作线程没有现成的handler，这样的话，主线程将handler交给工作线程而让工作线程将工作的结果交给主线程；
相反，工作线程中没有现成的handler（事实上是没有消息队列，也就是handler没有绑定到工作线程），那么，如果开辟的话，代码角度上是挺麻烦的（相对应广播机制来说）；
2.广播机制本身就是双向的（工作线程向主线程发送广播，主线程向工作线程发送广播）；
//另外，对于像一个activity中通过fragment来进行界面的处理； 我们大多数情况下是采用广播的机制来实现fragment中adapter的数据的更新；这样做主要是考虑到工作线程的任务加载完成，而具体的对应刷新的activity可能还没有启动；
另外，基于接口隔离原则，如果用handler进行通信的话，则不能很好的满足这一原则；
你要是周期比较长 用广播好些吧
应该与周期关系不是很密切。最主要的原因是两条线成是双向通信。
Handler类似于P2P的通信。
广播则类似于一个server端，用来处理分发不同线程的请求，从控制器的角度来说用广播更好一点。
一般使用Handler的，多用于子线程处理事务，完成时告知主线程这一类的情况。
而类似楼主所说的多条线程之间需要频繁交互的话，广播是个很好的选择，并且结构清晰，只是不知道广播的性能与handler相比会怎么样。
⑧ 12、注册广播有几种方式，这些方式有何优缺点请谈谈Android引入广播机制的用意。
注册广播的分类：静态注册和动态注册。
静态注册：在清单文件里直接注册，从app开启到app销毁，一直在接收广播，接收广播时间长，但是接收广播的优先级低于动态注册广播。
动态注册：动态注册，动态销毁，从onCreate到取消注册，期间接收广播，接收广播时间是短且可控，接收广播的优先级高。例如：
发送广播：
Intent i = new Intent();
i.setAction("ACTION_CLOSE");
sendBroadcast(i);
接受广播：
onCreate(){
//注册广播的接受者
IntentFilter filter = new IntentFilter();
filter.addAction("ACTION_CLOSE_ACTIVITY");
receiver = new InnerReceiver();
registerReceiver(receiver, filter);
}
private class InnerReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
//TODO 当前Activity接收到广播 需要做的事情
}
}
}
//注销广播
@Override
protected void onDestroy() {
super.onDestroy();
unregisterReceiver(receiver);
}
2.引入广播的原因：
a) 不同的app之间传信通用
b)发出一条指定，需要多个Activity都需要有反应
注意：以上仅供参考，如有疑问，请追问，谢谢。
⑨ . Android引入广播机制的用意
从MVC的角度考虑(应用程序内)
其实回答这个问题的时候还可以这样问，android为什么要有那4大组件，现在的移动开发模型基本上也是照搬的web那一套MVC架构，只不过 是改了点嫁妆而已。android的四大组件本质上就是为了实现移动或者说嵌入式设备上的MVC架构，它们之间有时候是一种相互依存的关系，有时候又是一 种补充关系，引入广播机制可以方便几大组件的信息和数据交互。
b：程序间互通消息(例如在自己的应用程序内监听系统来电)
c：效率上(参考UDP的广播协议在局域网的方便性)
d：设计模式上(反转控制的一种应用，类似监听者模式)
转自：http://www.cnmsdn.com/html/201101/1295431222ID9251.html
⑩ 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本身设置成不同的进程已经成为实现此类需求的可行替代方案。