组件间通信机制：
1.本地广播:
本地广播特点：（观察者模式的运用）
比全局广播更快，出自于Android.support，（底层实现是handler）；
仅限APP内传播，安全性，保密性，效率远高于全局广播；
不支持静态注册；
缺陷：无法干涉传输途中的任何步骤。
也存在比本地广播更加高效的通信方式：事件总线。
2.EventBus：
替代Intent，Handler，Broadcast，在Fragment,Activity,Service,Thread之间传递消息。
特点：开销小，代码优雅，解耦,。可以动态设置事件处理线程和优先级。
特别注意：onDestory中必须调用取消订阅，强引用。内存泄漏后各种灵异事件，足以让你找不到北，别问我咋知道的，说多了都是泪。
但是EventBus也有缺点：类似策略模式，每个事件都必须自定义一个事件类，造成事件类过多，无形中加大了维护成本。
EventBus3.0与EventBus2.x用法类似，3.0开启索引系统后，速度远快于2.x。
2.x运行时注解，反射耗费效率，低端手机中频繁反射，影响性能。
3.0采用编译时注解，Java文件编译时，变成.class文件时，完成注解。
并且3.0还池化了对象，建立对象池，减少了反复创建对象的开销。
3.RxBus：
RxJava响应式编程的运用，不牵涉反射，效率更高。比监听者模式的EventBus2.x更高效，线程调度和链式操作比EventBus优秀。
如果项目中引入RxJava可以考虑使用RxBus，如未引入，EventBus3.0将是更好的选择。
4.组件化事件总线的考量：
信息容器模板需要放在一个公共位置，例如Base Module，但是通信就会依赖BaseModule，这种设计显然不合理。违背了模块独立，通用的原则。每次增加其他模块 都要修改BaseModule，耦合性太强，就算删除模块，可以不改BaseModule但是无用代码 ，会使之臃肿不堪。这是目前组件化通信遇到的瓶颈问题。
两种比较适合现阶段组件化的通信方式：
4.1 ModuleBus：
ModuleBus能传递一些基础类型的数据，不会影响Base模块的架构，但是自定义的事件信息模板仍需要添加到BaseModule中才能让其他功能模块索引。使用方法类似EventBus。
4.2组件化架构的ModularizationArchitecture库。
每个功能模块中需要使用注解建立Action事件，每个Action完成一个动作，invoke只是方法名为反射，并未用到反射，而是使用接口方式调用。参数是通过HashMap<String,String>传递的，无法传递对象。
以上两种方法都能解决组件化中注册事件到BaseModule的冗余问题。
缺点在于：
- 无法像EventBus拥有类名索引，也无法传递自定义实体类到其他模块，这样无代码提示，无法引导正确编写代码；
- 只能传递基础数据类型和数据结构，无法传递class类型对象。
任何一个工具都不可能是完美的。