本地广播LocalBroadcastManager
说到组件间通信第一个肯定想到广播BroadcastReceiver，但是这里要说的是一个更优的选择---本地广播LocalBroadcastManager；优点：只在app内传播, 信息不会泄露,也不会被别人的广播干扰, 且比全局广播更高效;
缺点：但是本地广播传输消息时将一切都交给系统负责,无法干预传输中的步骤；
使用观察者模式
使用demo：
本质：看一下LocalBroadcastManager源码
事件总线组件化层级障碍:
由组件化架构图可以看出,组件间相互独立,没有依赖,也就没有关系,也就无法传递信息,那么要如何交流呢?
这时就需要用到基础层base module, 因为组件层的模块都依赖于基础层;事件总线
Android中activity,fragment,service间信息传递相对复杂, 如果用系统级别的广播, 有耗时,容易被捕捉,无法干预,可传输数据类型少等弊端,
于是大佬们就搞出了事件总线;
下面是三种目前常用的事件总线框架:
1. EventBus:
一款针对Android优化的发布/订阅事件总线,主要功能是替代handler,intent,broadcast;
优点是开销小,代码优雅,将发送者和接收者解耦;
EventBus2.x的版本和3.x是有很大区别的:
1. 2.x使用的是运行时注解,采用了反射的方式对整个注册的类的所有方法进行扫描来完成注册，因而会对性能有一定影响;
2. 3.x使用的是编译时注解，Java文件会编译成.class文件，再对class文件进行打包等一系列处理。在编译成.class文件时， EventBus会使用EventBusAnnotationProcessor注解处理器读取@Subscribe()注解并解析、处理其中的信息， 然后生成Java类来保存所有订阅者的订阅信息。这样就创建出了对文件或类的索引关系，并将其编入到apk中。
3. 从EventBus3.0开始使用了对象池缓存减少了创建对象的开销。 EventBus给Android开发者世界带来了一种新的框架和思想，就是消息的发布和订阅。这种思想在其后很多框架中都得到了应用。
2. RxBUs
RxBus不是一个库，而是一个文件，实现只有短短30行代码。RxBus本身不需要过多分析，它的强大完全来自于它基于的RxJava技术。
RxBus有很多实现，如：
下面是使用RxBus的demo：
与EventBus相比的优点，其实也就是rxJava的优点:
1、RxJava的Observable有onError、onComplete等状态回调。
2、RxJava使用组合而非嵌套的方式，避免了回调地狱。
3、RxJava的线程调度设计的更加优秀，更简单易用。
4、RxJava可使用多种操作符来进行链式调用来实现复杂的逻辑。
5、RxJava的信息效率高于EventBus2.x，低于EventBus3.x。
那么技术选型时如何取舍呢？如果项目中使用了RxJava，则使用RxBus，否则使用EventBus3.x
3. LiveDataBus
LiveDataBus是基于LiveData实现的类似EventBus的消息通信框架，它是基于LiveData实现的，完全可以代替EventBus，RxBus；
为什么会有他呢？
Handler : 容易导致内存泄漏，空指针，高耦合，不利于维护
EventBus ：原理实现复杂，无法混淆，需要手动绑定生命周期
RxBus：依赖于RxJava，包太大，影响apk大小，app启动时间
其项目地址如下：
另外的项目SmartEventBus，基于LiveEventBus实现，能让你定制自己的消息总线
4. 组件化事件总线的考量
其实目前常用的各种事件总线xxBus原理都差不多
那么在组件化项目中如何使用这些事件总线呢
1.EventBus,RxBus: 将xxEvent消息容器和事件总线框架的依赖放到base module，其他模块组件依赖于base module;
但是这样每个模块改动都需要增删改baseModule中的消息容器, 组件化要求功能模块独立, 各组件应该尽量避免影响base module；LiveDataBus: 无需建立消息模型，但无法像前两者一样拥有类名索引，无法引导正确的编写代码，也无法传递自定义实体到其他模块；
组件化中使用EventBus,RxBus，为了更大程度的解耦，可以独立出一个事件总线module，添加事件的实体都在这个module中，base module依赖 这个事件总线module对事件通信的解耦, 抽离事件到事件总线module中减少对base module的影响；
