关于组件化的思考

 为什么需要组件化 ？

1 业务独立，职责分明， 方便各业务人员独立开发与维护

 

组件化需要考虑哪些方面？ 

每个业务组件并不一定是完全独立的，它可能与其他组件存在两个维度上的依赖

垂直方向上： 业务组件依赖一些底层的组件库，如网络组件，图片组件

水平方向上：各业务组件之间的依赖有两种情况：

 1）调用对方的功能

 2） 或者实现UI跳转

所以在组件化的过程中，不仅仅要考虑如何剥离组件，同时还要考虑到组件间通讯

在UI跳转方面，目前业界比较流行的是Arouter，

原生跳转方式的不足

• 显式跳转， Intent intent = new Intent(activity, XXActivity.class);
  由于需要直接持有对应class，从而导致了强依赖关系，提高了耦合度

• 隐式跳转，譬如 Intent intent = new Intent(); intent.setAction(“com.android.activity.MY_ACTION”);
  action等属性的定义在Manifest，导致了扩展性较差
  规则集中式管理，导致协作变得非常困难。

 

功能调用层面： 目前通用的有两种方式：

1）接口下沉方式， 参考DDComponent，这种方式没有完全的接口，调用这仍然耦合了接口，涉及到强制转换

  每个组件作为实现者，需要注册，由第三方公共组件来维护这个注册表，接口的声明定义在公共模块，调用者通过接口调用相应的组件，

2）总线型 参考CC， 这种耦合度更小，调用时，将同步，异步都封装其中

每个组件作为实现者，都实现同一个接口，IComponent, 需要注册，通过组件名查找对应的组件，调用时，将需要的参数，对应的Action都传给对方组件，每个组件根据Action去查找对应的处理者

 

消息总线的优点和缺点

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

1. 消息难以溯源

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

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

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