github开源地址 github.com/beyondxia/m…
传统组件化方案介绍
组件化的核心问题为组件间的解耦，而解耦就不可避免的要面临解决组件间的通信问题，即通信机制。按照通信机制的维度来区分，可以大致概括为如下两种方案：协议通信、接口通信。二者的基本实现原理如下。
1、协议通信
协议通信典型的方式就是使用scheme的方式进行通信。这种方式可以将组件间的依赖降低至最小，甚至可以完全隔离。其核心思想为：组件间按照特定的通信协议进行数据传递，框架底层通过反射的方式进行服务方法的调用，从而实现进行组件间的通信。
2、接口通信
上面我们介绍的协议通信的设计到协议+反射，由于反射会带来的天然问题，如：性能、混淆、代码可读性、服务变更对调用者无感知等，所以我们更倾向于接口下沉的实现方式。
那么什么是接口通信呢，接口通信方式也就是我们前文所提的，通过接口下沉的方式进行模块间的数据通信，我们的框架也是基于这种方式进行组件间交互的，具体做法如下：
- 组件需要向外提供一个或多个中间接口文件以暴露自己的服务，接口中包含本组件需向外暴露的具体方法。
public interface ITrainTicketService {
String SERVICE_NAME = FFServiceConstants.SERVICE_TRAIN_TICKET;
TrainTicketNavigator navigator();
void registerJSHandlers(IBridgeFragment fragment);
int getTicketCount();
}
复制代码- 为了避免组件间的直接耦合依赖，所以的暴露接口和一些共享的类需要下沉至业务之下的服务层。宿主项目需提供一个这样的公共目录或者公共模块用于存放被暴露服务的相关的类文件。
- 注册服务：调用框架提供的注册服务方法，将本组件的实现类注册进框架中，以供其他组件调用。
- 服务调用：通过调用框架提供的特定方法，得到被调用组件中间接口的实例，此接口即包含被调用组件暴露的所有服务方法，所以调用此接口的实例即可实现对被调用组件的服务的调用。
传统组件化优缺点分析
协议通信的不足在上文中已简单说明，这里主要分析一下接口通信机制的优缺点。 优点：
- 组件服务的变更对调用者有感知。若组件提供的服务有升级或者变更，则调用者在编译器即可感知，避免将问题带到运行期暴露。
- 服务的调用不依赖反射，所以相比于组件总线的通信机制，不存在性能、混淆、可读性上的问题。 不足：
- 需要提供一个公共的目录或者公共模块用作为服务层，所有接口文件和中间共享的文件都需要手动拷贝至服务层。
- 组件若需要提供服务，除了本身的实现类，还需要提供一个或多个中间接口文件，增加了开发量和组件集成的复杂度以及维护成本。
- 与接口相关的一些中间类（特别是model）也需要同步移动至公共目录。
- 由于服务实现类与服务接口存在依赖关系，所以业务方需要实现暴露的接口，并要实现具体需要暴露的业务功能。。
- 所有的组件服务的注册都需要手动进行，增加了开发量与风险。
针对这几个问题，我们的modules框架给出了相应的解决方案，具体见下一篇