一种低侵入性的组件化方案 之 传统组件化方案的问题

github开源地址 github.com/beyondxia/m…

传统组件化方案介绍

    组件化的核心问题为组件间的解耦，而解耦就不可避免的要面临解决组件间的通讯问题，即通讯机制。按照通讯机制的维度来区分，能够大体归纳为以下两种方案：协议通讯、接口通讯。两者的基本实现原理以下。

一、协议通讯

    协议通讯典型的方式就是使用scheme的方式进行通讯。这种方式能够将组件间的依赖下降至最小，甚至能够彻底隔离。其核心思想为：组件间按照特定的通讯协议进行数据传递，框架底层经过反射的方式进行服务方法的调用，从而实现进行组件间的通讯。

二、接口通讯

    上面咱们介绍的协议通讯的设计到协议+反射，因为反射会带来的自然问题，如：性能、混淆、代码可读性、服务变动对调用者无感知等，因此咱们更倾向于接口下沉的实现方式。

    那么什么是接口通讯呢，接口通讯方式也就是咱们前文所提的，经过接口下沉的方式进行模块间的数据通讯，咱们的框架也是基于这种方式进行组件间交互的，具体作法以下：

1. 组件须要向外提供一个或多个中间接口文件以暴露本身的服务，接口中包含本组件需向外暴露的具体方法。

public interface ITrainTicketService {
    String SERVICE_NAME = FFServiceConstants.SERVICE_TRAIN_TICKET;
    TrainTicketNavigator navigator();
    void registerJSHandlers(IBridgeFragment fragment);
    int getTicketCount();
}
复制代码

2. 为了不组件间的直接耦合依赖，因此的暴露接口和一些共享的类须要下沉至业务之下的服务层。宿主项目需提供一个这样的公共目录或者公共模块用于存放被暴露服务的相关的类文件。

3. 注册服务：调用框架提供的注册服务方法，将本组件的实现类注册进框架中，以供其余组件调用。
4. 服务调用：经过调用框架提供的特定方法，获得被调用组件中间接口的实例，此接口即包含被调用组件暴露的全部服务方法，因此调用此接口的实例便可实现对被调用组件的服务的调用。

传统组件化优缺点分析

协议通讯的不足在上文中已简单说明，这里主要分析一下接口通讯机制的优缺点。 优势：

1. 组件服务的变动对调用者有感知。若组件提供的服务有升级或者变动，则调用者在编译器便可感知，避免将问题带到运行期暴露。
2. 服务的调用不依赖反射，因此相比于组件总线的通讯机制，不存在性能、混淆、可读性上的问题。 不足：
3. 须要提供一个公共的目录或者公共模块用做为服务层，全部接口文件和中间共享的文件都须要手动拷贝至服务层。
4. 组件若须要提供服务，除了自己的实现类，还须要提供一个或多个中间接口文件，增长了开发量和组件集成的复杂度以及维护成本。
5. 与接口相关的一些中间类（特别是model）也须要同步移动至公共目录。
6. 因为服务实现类与服务接口存在依赖关系，因此业务方须要实现暴露的接口，并要实现具体须要暴露的业务功能。。
7. 全部的组件服务的注册都须要手动进行，增长了开发量与风险。

针对这几个问题，咱们的modules框架给出了相应的解决方案，具体见下一篇

上一篇：一种低侵入性的组件化方案 之 组件化须要考虑的几个问题

下一篇：一种简单的低侵入性的组件化方案