组件间通信机制:
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类型对象。
任何一个工具都不可能是完美的。