目前在App开发中的消息全局通知方案有以下几种:系统广播,观察者和eventbus等第三方开源工具。
观察者和eventbus都只能用于应用内的消息通信,他们之间的区别主要在于实现方式的不同
。观察者是由用户通过handler自己实现一套,维护和扩展方便,但是一般不支持优先级和sticky等
原生广播特性,而且随着业务逻辑复杂度增加,监听接口会迅速膨胀
。eventbus等第三方开源工具功能使用简单,功能也要强大一些,支持优先级和sticky等原生广播特性
。但是由于是使用第三方库所以在不了解其实现原理的情况下bug调试跟踪会变得困难,
而且更新库(接口或者一些属性有变动的话)可能会影响到代码的大面积改动
。broadcast不仅支持应用内通信也支持不同应用进程之间的通信。但是由于其底层使用binder来实现,
所以效率上与前两者相比要低一些。当然broadcast最大的优势还是在对系统事件的监听上,
这是其他两个方案没法办到的。所以关于消息通信方案的选择上,
需要根据自己的需求来选择合适的方案。当需要App应用内通信时,优先选择观察者或者Eventbus,
当需要进程间通信或者监听系统广播事件时,选择Broadcast。
另外再提一下LocalBroadcastManager这个类,它是一个本地广播管理器,
估计是Android考虑到原生Broadcast的效率问题而提供的一个轻量级的广播。
它主要是解决App应用内通信的问题,采用handler实现,跟观察者的实现方案类似,
什么是广播:
广播广播。广而告之。比如通知栏里显示的QQ啊。音乐啊。未接来电啊、
、都是从他们各自的软件广播出来的事件。android系统接收广播显示。
一、广播的分类,按有无顺序区分,可以分为:标准广播、有序广播。
(1)标准广播。就是多个广播接收者,接收到广播是无序的,没有规定谁先谁后。
按理想状况来说,是同一时间接收到系统发出的广播。
(2)有序广播。在广播接收者,注册添加这条广播时,有增加了优先熟悉的设置。优先级高的先接收,优先级高的广播接收者,还可以控制是否将广播往下继续传递;
为什么用广播:
在Android中,有一些操作完成以后,会发送广播,比如说发出一条短信,
或打出一个电话,如果某个程序接收了这个广播,就会做相应的处理。
这个广播跟我们传统意义中的电台广播有些相似之处
在那里用广播:
关于消息通信方案的选择上,需要根据自己的需求来选择合适的方案。
当需要App应用内通信时,优先选择观察者或者Eventbus,
当需要进程间通信或者监听系统广播事件时,选择Broadcast
如何用广播:
广播的两种注册方式:
静态注册和动态注册
两种注册广播的区别:
1)第一种是常驻型,也就是说当应用程序关闭后,如果有信息广播来,程序也会被系统调用自动运行。
2)第二种不是常驻型广播,也就是说广播跟随程序的生命周期。
*动态注册优先级
广播的生命周期:
广播接收器仅有一个回调方法:
voidonReceive(ContextcurContext, Intent broadcastMsg)
当一个broadcast信息到达该receiver,Android调用它的onReceive()方法并将含有该广播信息的intent 对象传递它。Broadcast receiver仅仅在执行该方法时才被认为是活跃的。当onReceive()返回后,它又处于非活跃状态。也就是说,它的生命周期为从回调onReceive()方法开始到该方法返回结果后结束。
一个包含活跃的broadcast receiver的进程会被保护起来不被杀死。但是一个仅仅含有非活跃组件的进程,在它消耗的内存被其它进程需要时可能随时被系统杀死。
广播接收器的生命周期只有十秒左右,如果在 onReceive() 内做超过十秒内的事情,就会报ANR(Application No Response) 程序无响应的错误信息。当该broadcast信息的响应很耗时时会存在问题,这时应该单独给他一个线程运行,而不是在其他组件所在的与用户交互的线程中。如果onReceive()生成该线程后返回,整个进程,包括那个新的线程,都被判断为非活跃的(除非该进程里的其他组件是活跃的),归入了可以被杀死的一类。解决该问题的答案是使用onReceive()开始一个service,让该service进行该处理,那样一来,系统就会知道该进程里仍有活跃的处理在进行。