1.广播Broadcast

注册广播有几种方式，这些方式有什么特点和区别?

两种方式，首先这两种方式都要先写继承自broadcastreceive的类
答: 第一种:在清单文件中声明,添加




第二种使用代码进行注册如:
IntentFilter filter = new IntentFilter("android.provider.Telephony.SMS_RECEIVED");
IncomingSMSReceiver receiver = new IncomgSMSReceiver();
registerReceiver(receiver,filter);
两种注册类型的区别是：
1)第二种不是常驻型广播，也就是说广播跟随程序的生命周期。
2)第一种是常驻型，也就是说当应用程序关闭后，如果有信息广播来，程序也会被系统调用自动运行。

广播类型

sendBroadcast Normal broadcasts无序广播，会异步的发送给所有的Receiver，接收到广播的顺序是不确定的，有可能是同时。
sendOrderBroadcast Ordered broadcasts有序广播，广播会先发送给优先级高(android:priority)的Receiver，而且这个Receiver有权决定是继续发送到下一个Receiver或者是直接终止广播。
sendStickyBroadcast发送Sticky类型的广播，Sticky简单说就是，在发送广播时Reciever还没有被注册，但它注册后还是可以收到在它之前发送的那条广播。发这个广播需要权限
去掉是用这个方法removeStickyBroadcast(intent);

BroadcastReceiver的生命周期

Receiver也是有生命周期的，而且很短，当它的onReceive方法执行完成后，它的生命周期就结束了。这时BroadcastReceiver已经不处于active状态，被系统杀掉的概率极高，也就是说如果你在onReceive去开线程进行异步操作或者打开Dialog都有可能在没达到你要的结果时进程就被系统杀掉。因为这个进程可能只有这个Receiver这个组件在运行，当Receiver也执行完后就是一个empty进程，是最容易被系统杀掉的。替代的方案是用Notificaiton或者Service（这种情况当然不能用bindService）。

使用广播来更新界面是否合适？

更新界面也分很多种情况:
如果不是频繁地刷新，使用广播来做也是可以的。
但对于较频繁地刷新动作，建议还是不要使用这种方式。广播的发送和接收是有一定的代价的，它的传输是通过Binder进程间通信机制来实现的（细心人会发现Intent是实现了Parcelable接口的），那么系统定会为了广播能顺利传递做一些进程间通信的准备。

LocalBroadcastManager

LocalBroadcastManager相对 BroadcastReceiver，它只能用于应用内通信，安全性更好，同时拥有更高的运行效率。也是需要发送应用内广播时的官方推荐。

大家也都知道BroadcastReceiver的通信是走 Binder 机制的，而 LocalBroadcastManager 因为叫LocalBroadcast，可能让人产生一种它也是以 Binder 通讯方式为底层实现的错觉，点进源码，我们会发现这个更安全高效的实现原来如此熟悉。

LocalBroadcastManager 的核心实现实际还是 Handler，只是利用到了 IntentFilter 的 match 功能，至于 BroadcastReceiver 换成其他接口也无所谓，顺便利用了现成的类和概念而已。
因为是 Handler 实现的应用内的通信，自然安全性更好，效率更高。
LocalBroadcastManager 的实现原理，还是 Binder？

引入Broadcast的意图

1. 从MVC的角度考虑(应用程序内) 其实回答这个问题的时候还可以这样问，android为什么要有那4大组件，现在的移动开发模型基本上也是照搬的web那一套MVC架构，只不过是改了点嫁妆而已。android的四大组件本质上就是为了实现移动或者说嵌入式设备上的MVC架构，它们之间有时候是一种相互依存的关系，有时候又是一种补充关系，引入广播机制可以方便几大组件的信息和数据交互。

2. 程序间互通消息(例如在自己的应用程序内监听系统来电)
3. 效率上(参考UDP的广播协议在局域网的方便性)
4. 设计模式上(反转控制的一种应用，类似监听者模式)