初探 Android 组件化，四个步骤把握组件化核心要领

• 模块可以注册的对外暴露的服务的实现，在注册模块的时候，模块携带的服务也会被注册到 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. 单/多模块打包

这部分是通过自定义