- 模块可以注册的对外暴露的服务的实现,在注册模块的时候,模块携带的服务也会被注册到 App 的服务中心。
2. 公共业务去中心化
这里的公共业务是指在 App
中抽取的 Common
模块,这个模块随着项目复杂度的提升,像一个大储物柜,每个人都往里面塞了很多业务代码,造成了该模块代码冗余增多以及维护难度增大。解决思路是:
-
将公用的业务模块向上抽离到业务模块中(所谓业务模块的服务化);
-
将基础组件抽象到一个独立的组件中;
-
将一些基础类下沉到不包含业务逻辑的底层核心库中。
3. 业务模块服务化
简单来说,就是根据业务划分为多个模块,模块之间的交互以互相提供服务的方式来完成。常见的基本方式有:
-
A
模块直接依赖B
模块,直接调用B
模块的代码逻辑; -
将
A
和B
模块中的公用部分放到Common
模块中,通过调用Common
模块的代码实现依赖;
在有赞的组件化中,提出了通过 API
的方式实现,每个模块通过 API
暴露内部的数据和服务,以此来完成通信。常见的 API 实现方式有:
-
协议,类似于
app://order/detail/get?id=100
,通过JSON
传递数据,但是面临的问题维护成本高,服务修改导致引用方无感知; -
接口,通过暴露的接口完成数据的交互,引用方需要依赖该模块,依赖和发布成本高;
这里有赞团队选择通过接口的方式实现,这种方式的稳定性和版本控制做的更好,对于改动来说,编译过程自动会帮你校验改动的影响面,而引入依赖和发布成本高的问题,完全可以交给构建工具(Gradle Plugin
)来解决。
业务实现层需要做的,就是实现自己模块本身的业务逻辑,并实现自己提供的 API
接口,暴露对外的服务。
4. 基础组件抽象
很多的基础组件都是统一在 Common
里面进行封装的,例如:账号库、网络库、图片加载等等,导致该模块臃肿。针对这种情况,需要针对该模块进行重构:
-
将常用的基础组件整理,抽象成单独的一个抽象层,里面定义了一系列基础组件接口(图片加载、
Web
容器、JsBridge
调用、账号等等); -
把统一实现的组件放到另一个依赖里面,可以在
App
中进行具体实现的注册,而业务模块本身,可以只依赖抽象。
5. 单/多模块打包
这部分是通过自定义