Android 注册广播的两种方式区别

最新推荐文章于 2024-08-04 14:58:36 发布

haima1998

最新推荐文章于 2024-08-04 14:58:36 发布

阅读量2.9k

点赞数

分类专栏： android系统

android系统专栏收录该内容

162 篇文章 5 订阅

订阅专栏

转自：http://blog.sina.com.cn/s/blog_8417aea801010ulr.html

之前一直碰到这个问题，都没有证明回答，现在总结如下：

通过在配置文件里面注册广播属于常驻型广播，意思就是即便你应用程序结束，一旦有了对应的广播过来，其还是会被激活；而在代码里注册的广播则是非常驻型广播，比如在oncreate方法里面注册一个广播，那么在ondestroy里就可以BroadcastReceiver.abortBroadcast()，比如注册一个监听SD卡的广播。

之前有一个概念经常混淆，就是发送广播sendBroadCast或sendOrderBroadCast是要发送自己定义的广播时，才用到的，如果是系统的广播，根本不需要用到它们，系统的广播，我们只需要注册广播监听，如定义intent_filter监听就可以了，所以abortBroadcast终止广播就更用不到了。

     1.常驻型广播
  常驻型广播，当你的应用程序关闭了，如果有广播信息来，你写的广播接收器同样的能接受到，
  他的注册方式就是在你的应用程序中的AndroidManifast.xml进行注册。通常说这种方式是静态注册
  下面是配置例子

Java代码

<receiver android:name=".widget.DeskWidgeWeather">
<meta-data android:name="android.appwidget.provider" android:resource="@xml/widget_weather_provider" />
<intent-filter>
<action android:name="android.appwidget.action.APPWIDGET_UPDATE"/>
<action android:name="action_weather"/>
</intent-filter>
lt;/receiver>

  2.非常驻型广播
   当应用程序结束了，广播自然就没有了，比如你在activity中的onCreate或者onResume中注册广播接收器
   在onDestory中卸载广播接收器。这样你的广播接收器就一个非常驻型的了。这种也叫动态注册。
   比如写一个监听SDcard状态的广播接收器

Java代码

SdcardStateChanageReceiver sdcardStateReceiver;
@Override
protected void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
IntentFilter filter = new IntentFilter();
filter.addAction(Intent.ACTION_MEDIA_REMOVED);
filter.addAction(Intent.ACTION_MEDIA_EJECT);
filter.addAction(Intent.ACTION_MEDIA_MOUNTED);
filter.addDataScheme("file");
sdcardStateReceiver = new SdcardStateChanageReceiver();
registerReceiver(sdcardStateReceiver,filter);
}
@Override
protected void onDestroy(){
unregisterReceiver(sdcardStateReceiver);
}
class SdcardStateChanageReceiver extends BroadcastReceiver{
@Override
public void onReceive(Context context, Intent intent)
{
String state=android.os.Environment.getExternalStorageState();
System.out.println("SDCard 发生改变! 状态："+state);
//checkSDCard();
}
public void checkSDCard(){
String state=android.os.Environment.getExternalStorageState();
System.out.println(state);
if(state.equals(android.os.Environment.MEDIA_REMOVED ) || state .equals(android.os.Environment.MEDIA_UNMOUNTED)){
System.out.println("SDCard 已卸载!");
}
}
}

以下转自：http://blog.csdn.net/yinkai1205/article/details/8646220

本文主要介绍BroadcastReceiver的概念、使用、生命周期、安全性、分类、特殊的BroadcastReceiver（本地、粘性、有序、粘性有序广播）。代码地址BroadcastReceiverDemo@GoogleCode

1、概念介绍及两种注册方式的区别

BroadcastReceiver作为Android四大组件之一，不像Activity，没有可显示的界面。BroadcastReceiver包括两个概念，广播发送者和广播接收者(Receiver)，这里的广播实际就是指Intent，程序可以自己发送广播自己接收，也可以接受系统或其他应用的广播或是发送广播给其他应用程序。

发送者可以通过类似Context.sendBroadcast接口发送广播，接收者通过Context.registerReceiver()动态注册或在AndroidManifest.xml文件中通过<receiver>标签静态注册，注册完成后，当发送者发送某个广播时系统会将发送的广播(Intent)与系统中所有注册的符合条件的接收者(Receiver) 的IntentFilter进行匹配，若匹配成功则执行相应接收者的onReceive函数，匹配规则见Intent和IntentFilter的匹配规则。

关于registerReceiver动态注册和通过<receiver>标签静态注册广播的区别如下：

a.对bindService的调用，<receiver>注册的广播，在onReceive结束后广播即不存在，所以不能在其中给自己异步传递结果，如bindService而只能使用startService，如果想跟service交互可使用peekService。

b. 手动控制。registerReceiver为动态注册，自己可以手动注册或是取消注册；<receiver>标签为静态注册，由系统开机时自动扫描注册，所以无法手动控制，开机一直运行中。

c. 资源消耗不同。registerReceiver可以手动控制，所以适当的注册和取消注册能节省系统资源，<receiver>标签系统开机后一直有效。

d. 有效期不同。通过registerReceiver注册的BroadcastReceiver在对其进行注册的Context对象"销毁"了或者调用了unregisterReceiver方法时也就失效了，而通过<receiver>标签注册的BroadcastReceiver只要应用程序没有被删除就一直有效。

e. 对registerReceiver函数的调用许可不同。通过registerReceiver注册的BroadcastReceiver在其onReceive函数中可以再次调用某个Context的registerReceiver函数，而通过<receiver>标签注册的BroadcastReceiver不允许再调用某个Context的registerReceiver函数。

f. 使用情况不同。对于自己发送和接受的广播可以通过registerReceiver注册，对于系统常用广播的接收通常用<receiver>标签注册。

2、使用举例

 
  
 BroadcastReceiverDemo 

R.layout.broadcast_receiver_demo的内容为一个简单的id为sendBroadcast的Button

从上面代码可以看到我们

a. 新建BroadcastReceiver只需要继承BroadcastReceiver并重写OnReceiver函数，加上自己的处理逻辑。

b. 通过registerReceiver注册广播，通过unregisterReceiver取消注册广播，通过sendBroadcast发送广播。

其中注册和取消注册广播放在了OnResume和OnPause函数中可以有效的节省系统消耗。如果希望广播一直运行中可以在Activity的OnCreate函数中注册，在OnDestrory函数中取消注册。

这里的MyBroadcastReceiver也可以在AndroidManifest.xml文件中静态注册，这样程序安装后便一直运行中。比如希望接收到短信到来时的广播，如下：

<receiver android:name="MyBroadcastReceiver">
    <intent-filter>
        <action android:name="android.provider.Telephony.SMS_RECEIVED" />
    </intent-filter>
</receiver>

3、生命周期

BroadcastReceiver在onReceive函数执行结束后即表示生命周期结束，所以不适合在onReceive中做绑定服务操作，结束后若某个进程只含有该BroadcastReceiver，则优先级将降低可能被系统回收，所以BroadcastReceiver中不适合做一些异步操作，如新建线程下载数据，BroadcastReceiver结束后可能在异步操作完成前进程已经被系统kill。

同时由于ANR限制BroadcastReceiver的onReceive函数必须在10秒内完成，而且onReceive默认会在主线程中执行，所以BroadcastReceiver中不适合做一些耗时操作，对于耗时操作需要交给service处理，比如网络或数据库耗时操作、对话框的显示(因为现实时间可能超时，用Notification代替)。

4、安全性

BroadcastReceiver的设计初衷就是从全局考虑的，可以方便应用程序和系统、应用程序之间、应用程序内的通信，所以对单个应用程序而言BroadcastReceiver是存在安全性问题的，相应问题及解决如下：

a、当应用程序发送某个广播时系统会将发送的Intent与系统中所有注册的BroadcastReceiver的IntentFilter进行匹配，若匹配成功则执行相应的onReceive函数。可以通过类似sendBroadcast(Intent, String)的接口在发送广播时指定接收者必须具备的permission。或通过Intent.setPackage设置广播仅对某个程序有效。

b. 当应用程序注册了某个广播时，即便设置了IntentFilter还是会接收到来自其他应用程序的广播进行匹配判断。对于动态注册的广播可以通过类似registerReceiver(BroadcastReceiver, IntentFilter, String, android.os.Handler)的接口指定发送者必须具备的permission，对于静态注册的广播可以通过android:exported="false"属性表示接收者对外部应用程序不可用，即不接受来自外部的广播。

c.上面两个问题其实都可以通过LocalBroadcastManager来解决，LocalBroadcastManager只会将广播限定在当前应用程序中，具体见下面6特殊的BroadcastReceiver中的介绍

d.使用android:protectionLevel

5、分类

BroadcastReceiver可以分为普通和有序两种，下面6特殊BroadcastReceiver中介绍了其他一些种类。

通过Context.sendBroadcast发送的广播即为普通广播，对于普通广播接收者接收到它的顺序是不定的，所以接收者接收到后无法使用其他接收者对它的处理结果也无法停止它。

通过Context.sendOrderedBroadcast发送的广播即为有序广播，与普通广播的不同在于，接收者是有序接收到广播的并且可以对广播进行修改或是取消广播向下传递。系统根据接收者定义的优先级顺序决定哪个接收者先接收到它，接收者处理完后可以将结果传递给优先级低的接收者也可以停止广播使得其他优先级低的接收者无法接收到该广播。优先级通过android:priority属性定义，数值越大优先级别越高，取值范围：-1000到1000，虽然API文档介绍对sendBroadcast发送的广播无效，不过本人测试同样有效，相同优先级的接收者接收到广播的顺序随机。Android系统收到短信、接到电话后发送的广播都是有序广播，所以可以进行短信或电话的拦截，即取消广播。

PS：有序广播可以在onReceive函数中通过BroadcastReceiver的abortBroadcast接口(这个接口对sendBroadcast发送广播无效)取消广播，通过接口sendOrderedBroadcast(Intent, String, BroadcastReceiver, android.os.Handler, int, String, Bundle)发送的广播即便优先级高的广播取消了广播，接口参数中指定的BroadcastReceiver依然可以在其他接收者处理完后接收到广播。通过BroadcastReceiver的getResultExtras接口获得结果的Bundle再通过Bundle的putString和getString方法修改或获取数据，可以见本文最后的实例代码举例。

6、特殊的BroadcastReceiver

a. LocalBroadcastManager本地广播

android引入了LocalBroadcastManager解决在第4部分安全性介绍的一些问题，LocalBroadcastManager除了能解决BroadcastReceiver进程间安全性问题外，相对Context操作的BroadcastReceiver而言还具有更高的运行效率。

使用LocalBroadcastManager需要引入Android Support Library，如何引入见Add Support Package。

本地广播通过LocalBroadcastManager.getInstance(context).sendBroadcast(intent)发送广播，LocalBroadcastManager.getInstance(context).registerReceiver注册服务，通过LocalBroadcastManager.getInstance(context).unregisterReceiver取消注册服务，其他同普通广播.

b. Sticky Broadcast粘性广播

如果发送者发送了某个广播，而接收者在这个广播发送后才注册自己的Receiver，这时接收者便无法接收到刚才的广播，为此Android引入了StickyBroadcast，在广播发送结束后会保存刚刚发送的广播（Intent），这样当接收者注册完Receiver后就可以继续使用刚才的广播。如果在接收者注册完成前发送了多条相同Action的粘性广播，注册完成后只会收到一条该Action的广播，并且消息内容是最后一次广播内容。系统网络状态的改变发送的广播就是粘性广播。

粘性广播通过Context的sendStickyBroadcast(Intent)接口发送，需要添加权限<uses-permission android:name="android.permission.BROADCAST_STICKY"/>

也可以通过Context的removeStickyBroadcast(Intent intent)接口移除缓存的粘性广播。

c. OrderedBroadcastReceiver有序广播

这个在5分类中已经介绍，接收者有序接收广播并可以修改广播结果或是取消广播，通过Context的sendOrderedBroadcast接口发送

d. StickyOrderedBroadcast粘性有序广播

这个就是粘性广播和有序广播的结合了，通过Context的sendStickyOrderedBroadcast接口发送。

各种广播操作Demo示例代码见BroadcastReceiverDemo@GoogleCode，由于本地广播的support library暂时下载不了，不包括本地广播，本地广播操作间上面介绍。

注意AndroidManifest文件中需要添加粘性广播操作权限<uses-permission android:name="android.permission.BROADCAST_STICKY"/>

参考：

http://developer.android.com/reference/android/content/BroadcastReceiver.html

转载：

http://www.cnblogs.com/trinea/archive/2012/11/09/2763182.html

原文连接：http://www.eyeandroid.com/thread-11885-1-70.html

以下转自：http://blog.csdn.net/luoshengyang/article/details/6730748

在Android系统中，广播（Broadcast）是在组件之间传播数据（Intent）的一种机制；这些组件甚至是可以位于不同的进程中，这样它就像Binder机制一样，起到进程间通信的作用；本文通过一个简单的例子来学习Android系统的广播机制，为后续分析广播机制的源代码作准备。

在Android系统中，为什么需要广播机制呢？广播机制，本质上它就是一种组件间的通信方式，如果是两个组件位于不同的进程当中，那么可以用Binder机制来实现，如果两个组件是在同一个进程中，那么它们之间可以用来通信的方式就更多了，这样看来，广播机制似乎是多余的。然而，广播机制却是不可替代的，它和Binder机制不一样的地方在于，广播的发送者和接收者事先是不需要知道对方的存在的，这样带来的好处便是，系统的各个组件可以松耦合地组织在一起，这样系统就具有高度的可扩展性，容易与其它系统进行集成。

在软件工程中，是非常强调模块之间的高内聚低耦合性的，不然的话，随着系统越来越庞大，就会面临着越来越难维护的风险，最后导致整个项目的失败。Android应用程序的组织方式，可以说是把这种高内聚低耦合性的思想贯彻得非常透彻，在任何一个Activity中，都可以使用一个简单的Intent，通过startActivity或者startService，就可以把另外一个Activity或者Service启动起来为它服务，而且它根本上不依赖这个Activity或者Service的实现，只需要知道它的字符串形式的名字即可，而广播机制更绝，它连接收者的名字都不需要知道。

不过话又说回来，广播机制在Android系统中，也不算是什么创新的东西。如果读者了解J2EE或者COM，就会知道，在J2EE中，提供了消息驱动Bean（Message-Driven Bean），用来实现应用程序各个组件之间的消息传递；而在COM中，提供了连接点（Connection Point）的概念，也是用来在应用程序各个组间间进行消息传递。无论是J2EE中的消息驱动Bean，还是COM中的连接点，或者Android系统的广播机制，它们的实现机理都是消息发布/订阅模式的事件驱动模型，消息的生产者发布事件，而使用者订阅感兴趣的事件。