Android组件化方案及组件消息总线modular-event实战(1)

1. 更进一步的解耦

基于接口调用的ServiceLoader框架的确实现了解耦，但是消息总线能够实现更彻底的解耦。接口调用的方式调用方需要依赖这个接口并且知道哪个组件实现了这个接口。消息总线方式发送者只需要发送一个消息，根本不用关心是否有人订阅这个消息，这样发送者根本不需要了解其他组件的情况，和其他组件的耦合也就越少。

2. 多对多的通信

基于接口的方式只能进行一对一的调用，基于消息总线的方式能够提供多对多的通信。

消息总线的优点和缺点

总的来说，消息总线最大的优点就是解耦，因此很适合组件化这种需要对组件间进行彻底解耦的场景。然而，消息总线被很多人诟病的重要原因，也确实是因为消息总线容易被滥用。消息总线容易被滥用一般体现在几个场景：

1. 消息难以溯源

有时候我们在阅读代码的过程中，找到一个订阅消息的地方，想要看看是谁发送了这个消息，这个时候往往只能通过查找消息的方式去“溯源”。导致我们在阅读代码，梳理逻辑的过程不太连贯，有种被割裂的感觉。

2. 消息发送比较随意，没有强制的约束

消息总线在发送消息的时候一般没有强制的约束。无论是EventBus、RxBus或是LiveDataBus，在发送消息的时候既没有对消息进行检查，也没有对发送调用进行约束。这种不规范性在特定的时刻，甚至会带来灾难性的后果。比如订阅方订阅了一个名为login_success的消息，编写发送消息的是一个比较随意的程序员，没有把这个消息定义成全局变量，而是定义了一个临时变量String发送这个消息。不幸的是，他把消息名称login_success拼写成了login_seccess。这样的话，订阅方永远接收不到登录成功的消息，而且这个错误也很难被发现。

组件化消息总线的设计目标

1. 消息由组件自己定义

以前我们在使用消息总线时，喜欢把所有的消息都定义到一个公共的Java文件里面。但是组件化如果也采用这种方案的话，一旦某个组件的消息发生变动，都会去修改这个Java文件。所以我们希望由组件自己来定义和维护消息定义文件。

2. 区分不同组件定义的同名消息

如果消息由组件定义和维护，那么有可能不同组件定义了重名的消息，消息总线框架需要能够区分这种消息。

3. 解决前文提到的消息总线的缺点

解决消息总线消息难以溯源和消息发送没有约束的问题。

基于LiveData的消息总线

组件化消息总线框架modular-event基于LiveData构建，使用LiveData构建消息总线有很多优点：

1. 使用LiveData构建消息总线具有生命周期感知能力，使用者不需要调用反注册，相比EventBus和RxBus使用更为方便，并且没有内存泄漏风险。
2. 使用普通消息总线，如果回调的时候Activity处于Stop状态，这个时候进行弹Dialog一类的操作就会引起崩溃。使用LiveData构建消息总线完全没有这个风险。

组件消息总线modular-event的实现

解决不同组件定义了重名消息的问题

其实这个问题还