Broadcast Receiver原理

Broadcast是一种广泛运用的在应用程序 之间传输信息的机制,Android中我们要发送的广播内容是一个Intent,这个Intent可以携带我们要传送的数据。广播类似于我们java当中观察者模式

使用场景

A.同一个App具有多个进程的不同组件之间的信息通信
(比如说,你在app里面,你会开启多个进程,比如说会有定位地图的进程,会有主进程,来进行相应的操作,这时候两个进程之间通信,就可以用到广播 )
B.不同App之间的组件之间消息通信
((比如说几个App之间的通信,在很多大型公司,会开发很多APP,这些APP会有互相的推广啊,运营之类的,会用到广播消息机制)

生命周期

onReceive()

• 1、BroadCastReceiver 的生命周期很短暂，当接收到广播的时候创建，当onReceive()方法结束后销毁

• 2、正因为BroadCastReceiver的声明周期很短暂，所以不要在广播接收器中去创建子线程做耗时的操作，因为广播接受者被销毁后，这个子进程就会成为空进程，很容易被杀死

• 3、因为BroadCastReceiver是运行在主线程的，所以不能直接在BroadCastReceiver中去做耗时的操作，否则就会出现ANR异常

最后建议：耗时的较长的工作最好放到Service中去完成

种类

1)Normal Broadcast : Context.sendBroadcast (普通广播)

2)System Broadcast : Context.sendOrderedBroadcast (有序广播也叫系统广播)

3)Local Broadcast : 只在自身App内传播 (本地广播)

实现广播-receiver

1.静态注册:注册完成就一直运行
直接把广播接收者写到manifest文件当中
特点:

所在的activity销毁了,仍然能够接收到广播,甚至你可以把进程杀死,这个App杀死,仍然能收到广播,但是和动态注册相比不太灵活.

2.动态注册: 跟随Activity的生命周期
在代码中调用registerReceiver方法注册,来进行整个的BroadcastReceiver的注册
注意：一定要在onDestroy()方法里面onRegisterReceiver这方法,否则你会引起内存泄漏
特点：

它的生命周期跟随Activity 的生命周期,所以说当Activity销毁了这个动态注册的广播接收者也就失效了.

广播实现机制

1. 自定义广播接收者BroadcastReceiver,并复用onRecvice()方法;
2. 通过Binder机制向AMS(Activity Manager Service)进行注册;
3. 广播发送者通过Binder机制向AMS发送广播;
4. AMS查找符合相应条件(IntentFilter/Permission等)的BroadcastReceiver,将广播发送到BroadcastReceiver(一般情况下是Activity)相应的消息循环队列中;
5. 消息循环执行拿到此广播回调BroadcastReceiver中的onReceive()方法.**

Ams是贯穿安卓系统组件的核心服务,它负责启动四大组件的启动,切换,调度,以及应用程序的管理和调动工作,所以说Activity Manager Service是负责Broadcast的创建.

Binder机制是安卓进程间通信的一个核心,它的整体设计架构是客户端,服务端结构,cs结构,客户端进程可以获取到服务端进程,并通过代理接口然后通过方法来读取数据,来完成进程间的数据通信.

LocalBroadcastManager详解

1.使用它发送的广播将只在自身的App内传播,因此你不必担心泄漏隐私数据

2.其它App无法对你的App发送该广播,因为你的App根本就不可能接收到非自身引用发送的该广播,因此你不必担心有安全漏洞可以利用

3.比系统的全局广播更加高效

注意：
给大家强调一下隐私漏洞和安全数据,我们知道如果不是本地广播的话,如果别人反编译了你的APK后,知道了你的Action,那么第三方应用就可以发送与该action匹配的广播,而你的应用也能接收到,而不是像本地广播一样,接收不到,这时候,第三方应用就可以拿广播来做很多事情,比如说它可以分享链接让你跳转过去啊,就是植入广告的形式.第二:如果别人知道你的Action,当你使用广播来传送一些数据的时候,别的应用也能接收到广播,通过Action匹配获取到你的私密数据,包括你的用户名,你的地理位置,然后就可以推送信息,给你发送一些恶意的广播信息,这就是本地广播的一个作用.

根据LocalBroadcastManager底层源码,给大家简单总结一下：
1.LocalBroadcastManager高效的原因主要是因为它内部是通过Handler实现的,它的sendBroadcast()方法含义并非和我们平时所用的一样,它的sendBroadcast()方法其实是通过handler发送一个Message实现的

2.既然它内部是通过Handler来实现广播的发送的,那么相比与系统广播通过Binder实现那肯定是更高效了,同时使用Handler来实现,别的应用无法向我们的应用发送该广播,而我们应用内部发送的广播也不会离开我们的应用

3.LocalBroadcastManager内部协作主要是靠这两个Map集合: mReceivers和mActions,当然还有一个List集合mPending

Broadcasts,这个主要就是存储待接收的广播的对象