一、概述
目前有赞移动端的主要工作内容是在“有赞微商城”和“有赞零售”两条公司主要的业务线，随着有赞 Saas 业务的增长，客户端也不断迭代，支持越来越多的功能。 在这个业务快速增长的情况下，移动端技术的整体架构也是一直在不断调整，来保证开发效率和业务的快速迭代。
这篇文章，主要是介绍有赞微商城 Android组件化的一些思路和实现。
1.1 现状
客户端的架构，从一开始的“All IN ONE” 模式（即所有代码都在 App 中），逐渐演变到目前的一个单 Project 多 Module 结构：
1.2 痛点
新的项目架构，也带了了新的问题： - 日益复杂的 Common 模块，逻辑复杂，依赖不清晰，不敢随便改动 Common 代码，造成大量冗余代码和无法维护的业务逻辑 - 随着业务模块的增多，打包速度一发不可收拾；从倒杯水的时间到下楼吃个饭的时间，大大减慢了开发节奏 - 由于业务模块跟项目中的上层（App 壳）和下层（Common 模块）耦合 - 业务模块增多，由于业务模块没有自己的生命周期，无法实现模块之间的隔离，整体模块控制比较混乱
1.3 需要解决的问题
- Common模块轻量化，需要将 Common 层的业务向上抽离，通用的底层和基础组件、公用 UI 组件抽成单独的依赖
- 移动端业务服务化，解耦现有业务，抽象出业务接口，业务模块只向外暴露自己的接口，并实现跨模块之间的调用
- 能够配置单模块或者多模块打包，不用每次调试都全量打包，费时费力，又影响开发的节奏
- 业务模块的依赖和发布管理
二、架构调整
我们之前虽然有在做整个工程模块化的开发，但是目前的模块化框架可以说是不够彻底的：
- 模块只是项目结构的概念（一个模块一个 Module），在逻辑层并没有模块这个概念
- 模块本身并没有生命周期控制
- 公用服务中心化，公用逻辑部分全部都在 Common 模块中
- 模块对外暴露的服务不可知，都是直接依赖模块内部的代码逻辑
- 模块无法单独打包，针对模块的代码改动，只能全量打包之后才能看到效果
为了解决以上的问题，我们需要对现有的架构进行调整。
2.1模块的抽象
将模块的功能抽象出一些基础类，组成了模块化支持组件，它提供的功能有：
- 抽象出模块本身作为某一类业务的容器，即所有业务模块需要实现自己的模块类，继承自我们的 BaseModule，并在 App 壳工程中进行注册
- 模块对象跟 Activity 一样，拥有生命周期的概念，需要在生命周期的不同阶段处理自己相应的逻辑（注册服务、初始化数据等）
- 模块可以注册的对外暴露的服务的实现，在注册模块的时候，模块携带的服务也会被注册到 App 的服务中心
2.2 公共业务去中心化
跟很多客户端的同学聊过，很多 APP 发展到一定阶段之后，必然会诞生一个所谓的 Common 模块。它就像一个大储物柜，每个人都把一些其他人可能用到的东西一股脑儿塞进去。 这么个塞法，会有两个问题：
- 冗余：比如一些工具类，很多时候，当你找不到需要的工具类的时候，你可能会塞一个新的进去
- 维护成本高：所有公用的业务逻辑的实现都在 Common 中，对一些公用业务逻辑的影响面无法掌控
2.2.1 Common 里面都有什么？
- 工具类
- 公用的 UI 组件
- 多个业务模块都公用的业务类
- 基础组件的封装类（图片库、网络库、Webview）
- 封装的一些基类（BaseActivity，BaseFragment 什么的）
2.2.2 解决的思路
- 将公用的业务模块向上抽离到业务模块中（所谓业务模块的服务化）
- 将基础组件抽象到一个独立的组件中
- 将一些基础类下沉到不包含业务逻辑的底层核心库中
2.3 业务模块服务化
“服务化”这个词，在服务端的开发中经常被提到，简单来说，就是根据业务划分为多个模块，模块之间的交互以互相提供服务的方式来完成。 而客户端随着业务模块的增多，也必然存在业务模块之间存在业务依赖的情况，而 Android 端依赖的方式有：
- A 模块直接依赖 B 模块，直接调用 B 模块的代码逻辑
- 将 A 和 B 模块中的公用部分放到 Common 模块中，通过调用 Common 模块的代码实现依赖
2.3.1 业务模块服务依赖的实现
- 后端的服务化是借助于 Dubbo 来构建的 RPC 服务，依赖某个服务，只需要依赖其对外暴露的 API 模块（只包含接口和数据结构的 Maven 依赖），不需要依赖其具体实现，具体服务调用的实现由框架来实现
- 客服端的依赖也可以参考这样的方式来实现模块之间的依赖，例如商品模块，可以提供一个 API 层，用来对外暴露数据结构和服务
2.3.2 API 层实现方式
对外暴露服务的方式有很多种：
- 协议的方式：例如"app://order/detail/get?id=100"，数据可以用 JSON 来进行传递，请求本地服务就像调用一个 Http 服务一样，根据请求协议来获取数据，然后解析数据进行操作
- 接口的方式：像后端使用 Dubbo 服务那样，订单模块对外提供一个独立的 Maven 依赖，里面包含了数据接口和对外提供的服务接口，适用方依赖之后直接调用
2.3.3 接口的方式实现 API
协议的方式的问题：如果服务提供的地方更改了之后，需要手动去查询所有调用到的地方，进行更改，而且没有版本管理，而且数据解析都需要手动进行转换，改动的成本比较高，也有一定稳定性风险。 接口的方式的问题：需要额外提供一个依赖（单独把 API 层打包成一个 aar 包），使用方需要添加 Mave 依赖，所以引入依赖和发布的成本比较高。
我们最终选择了接口的方式，这种方式的稳定性和版本控制做的更好，对于改动来说，编译过程自动会帮你校验改动的影响面，而引入依赖和发布成本高的问题，完全可以交给构建工具（Gradle Plugin）来解决。
2.3.4 业务实现层
业务实现层需要做的，就是实现自己模块本身的业务逻辑，并实现自己提供的 API 接口，暴露对外的服务。
2.4 基础组件抽象
2.4.1 现有的基础组件实现
项目中现在有很多的基础组件都是统一在 Common 里面进行封装的，例如：账号库、网络库、图片加载、Web 容器库等等，这也带来了一些问题：
- Common 太重
- 业务模块跟基础组件强耦合，在开发一些跨团队的组件过程中，如果碰到使用的基础库不同的时候，需要比较多的时间来做封装
- 升级基础组件或替换依赖的成本比较高，一些 API 的更改需要改动每个调用的地方
2.4.2 实现思路
- 将常用的基础组件整理，抽象成单独的一个抽象层，里面定义了一系列基础组件接口（图片加载、Web 容器、JsBridge 调用、账号等等）
- 把统一实现的组件放到另一个依赖里面，可以在 App 中进行具体实现的注册，而业务模块本身，可以只依赖抽象
2.4.3 依赖结构
2.5 单/多模块打包
随着业务量和业务复杂度的增长，还有多个三方组件的引入，客户端工程代码量也变得越来越庞大，直接造成的一个问题是：打包慢！一个简单的场景：当你开发了一个商品模块内部的功能之后，你需要打整个 App 的包才能进行测试，而打一个包的时间可能是 5～10 分钟，如果一天打包 10 次，也是比较酸爽。我们的组件也需要支持单模块或者选定的某些进行打包，其中的思路也是通过自定义 Gradle Plugin 在编译阶段，动态去更改 Module 实际依赖的 Android Gradle 插件来实现的。 经测试，同一台电脑，完整打包（clean之后再安装）耗时 4 分钟，而单模块打包（同样也是 clean 之后安装）耗时 1 分钟，整体打包时间降低了 70% 以上。
2.6 架构图
上面的一些改进点，总结成一张图，就是这样的:
三、实现方案
目前我们的方案提供 3 个基础组件依赖和 1 个 Gradle 插件：
- modular-core: 提供组件模块化生命周期和模块服务注册相关的模块化基础组件
- modular-support: 对项目中二方、三方包接口的抽象
- modular-support-impl:对项目中二方、三方包接口的默认抽象
- modular-plugin: 支持模块生成 API 层目录，生成 APP 运行环境，以及管理模块发布的 Gradle 插件
3.1 Modular-core
3.1.1 实现模块类
业务模块类需要继承 BaseModule：
public class ModuleA extends BaseModule {
@Override
public void onInstalled() {
registerBusinessService(ModuleAService.class, new CachedServiceFetcher() {
@Override
public ModuleAService createService(@NotNull ModularManage manager) {
if (service == null) {
service = new ModuleAServiceImpl();
}
return service;
}
});
}
}
3.1.2 模块生命周期
模块有以下几个生命周期：
- onInstalled() -> 模块被注册的时候调用：Module 在 App 中被注册的时候
- onCreate() -> 模块第一次启动的时候调用：Module 所属的某个 Activity 第一次启动的时候
- onStart() -> 模块启动的时候调用：模块第一次启动之的时候
- onStop() -> 模块停止的时候调用：Activity 栈里面没有模块所属 Activity 的时候
3.1.3 模块生命周期的实现
其实组件内关于生命周期捕获和监听，都是借助于 Google 的 Android Architecture Components 中的 Lifecycle 库来实现的。
- 模块生命周期的捕获：首先需要将 Activity 的类注册到 Module 中，然后全局监听 Activity 的 Lifecycle.Event 事件，就可以获取到模块内 Activity 的运行情况
- 模块生命周期的监听：BaseModule 本身继承了 LifecycleOwner 接口，可以对其添加观察者，来实现对模块生命周期的监听
3.2 Modular-plugin
这里需要依赖对于 Android 的构建工具 Gralde 的扩展，它支持的高度可扩展特性，帮助我们在组件化开发中更加高效，不需要关系一些额外的工作，只需要关注开发的内容即可，对现有的代码逻辑基本没有侵入。
3.2.1 Gralde 的生命周期
这里必须要提一些的就是 Gradle 的生命周期，因为我们的很多扩展功能，都是在对 Gradle 执行的生命周期的各个阶段做一些改动来实现的，大概的生命周期如图：
3.2.2 单模块打包
Android 打包成 Apk 并运行的条件有：
- AndroidManifest.xml 的配置支持（application 标签的配置）
- 主 Activity 的配置
3.2.2.1 实现原理
- 自动生成模块自己的 Application 类
- 自动读取 Module 的 AndroidManifest 文件并修改成可以打包成 App 的配置
- 在打包的时候动态更改 SourceSet，使打包的时候使用生成的文件进行打包
- 在打包的时候动态更改支持的 Plugin 类型（'com.android.application'或是'com.android.library'）
3.2.2.2 修改模块 build.gradle 的配置
将以下配置添加到模块目录下的 build.gradle 文件中
modular {
// 模块包名
packageName = "com.youzan.ebizcore.plugin.demoa"
app {
// 单模块打包开关
asApp = true
// 运行的 App 的名称
appName = "Module A"
// 入口 Activity
launchActivity = "com.youzan.ebizcore.plugin.demoa.ModuleAActivity"
// 配置只在单模块打包时需要引入的依赖
requires {
require "com.squareup.picasso:picasso:2.3.2"
}
}
}
3.2.2.3 生成单模块运行需要的环境
运行 modular 的 createApp Task，就会自动生成需要的类（以 module_a 为例）
自动生成的文件目录结构：
./module_a
--src
----main
------app # 自动生成 app 目录
--------java # 自动生成 Application 类
--------res # 自动生成资源
--------AndroidManifest.xml # 自动生成 Manifest 文件
3.2.2.4 执行单模块打包并安装的 Task
运行 modular 的 runAsApp Task，模块就会被单独达成一个 apk 包，并安装到你的手机上，如果模块有上下文依赖（比如登录）的话可以额外提供依赖，加到模块的 app 的 requires 中。 这里的打包执行是在 build 目录下生成了一个打包脚本，并调用 Gradle 的 API 执行脚本来实现打包安装的。
3.2.3 模块 API 管理
模块 API 层提供的接口和数据结构代码是可以直接在模块内部被引用到的，方便开发，但是在暴露给外部的模块时候的时候是需要打包成 aar 上传到 Maven 来提供的，Modular-Plugin 分别针对这两个步骤提供了两个 Task，方便开发者快速进行开发和发布。
3.2.3.1 在 build.gralde 中添加相关配置
modular {
packageName = "com.youzan.ebizcore.plugin.demoa"
// 模块 API 支持相关参数
api {
// 是否需要提供 API 支持的开关（会影响到是否可以运行自动生成代码的 Task）
hasApi = true
// 对外提供的 API Service 类名
apiService = "ModuleAService"
// API 层的依赖
requires {
require "com.google.code.gson:gson:2.8.2"
}
}
}
3.2.3.2 生成 API 打包需要的文件
运行 modular 的 createApi Task，就会自动生成需要的类（以 module_b 为例）
./module_b
--src
----main
------service # 自动生成 service 目录，用来存放对外接口和数据对象
--------java # 自动生成 Application 类
--------AndroidManifest.xml # 自动生成 Manifest 文件，为了单独打成 aar 包
3.2.4 模块发布
发布功能内部使用了 'maven-publish' 插件来进行依赖的上传，开发者只关心上报的配置就好
3.2.4.1 在 build.gralde 中添加发布配置
modular{
// 模块发布需要的参数
publish {
// 是否打开模块发布
active = true
// 上报地址，支持本地路径和远程 Mave 仓库地址
repo = "../release"
groupId = "com.youzan.ebizmobile.demo"
artifactId = "modular-a"
// 上报的业务模块 aar 包的版本号
moduleVersion = "0.1.4"
// 上报的 API 层 aar 包的版本号
apiVersion = "0.1.5"
// Maven 登录名和密码，可以从 local.properties 中取
userName = ""
password = ""
}
}
3.2.4.2 执行发布的 Task
运行 modular 的 uploadModule Task，Module-Plugin 会执行打包上传的任务，执行顺序是这样的： 1. 首先打包并上传 Module 的 API 模块（SourceSet 只包含 API 的类） 2. 将 Module API 的代码从模块的 SourceSet 中去除，并添加刚才上报的 API 模块的 Maven 依赖到 Module 的 dependencies 中
3.3 Modular-support
3.3.1 基础组件抽象
以图片组件为例，一般业务模块中使用到的图片相关的功能有：图片加载、图片选择等，可以把这些功能抽象成接口
interface IImageLoadSupport {
fun <IMAGE : ImageView> loadImage(imageView: IMAGE?, imgUrl: String)
fun <IMAGE : ImageView> loadImage(imageView: IMAGE?, @DrawableRes drawableId: Int)
fun <IMAGE : ImageView> loadImage(imageView: IMAGE?, imgUrl: String, callback: ImageLoadCallback<IMAGE>)
fun imagePicker(activity: Activity?, selectedImgUris: List<Uri>)
fun onImagePickerResult(requestCode: Int, resultCode: Int, intent: Intent?): List<String>?
}
3.3.2 基础组件的实现
基础组件的实现可以在 App 中进行注册，如果需要单模块组件中使用 Support 相关功能，可以提供一套默认实现，在但模块运行时引入，在全局有一个 Support 注册中心，以 Map 的形式维护运行中的 Support 对象：
fun <SUPPORT : Any, SUPPORTIMPL : SUPPORT> registerProvider(supportCls: Class<SUPPORT>, provider: SupportProvider<SUPPORTIMPL>) {
synchronized(Lock) {
supportsProviderMap[supportCls] = provider
if (supportsMap.containsKey(supportCls)) {
supportsMap.remove(supportCls)
}
}
}
四、规划
开发到现在，这边的三个组件已经能够基本完成我们对于组件化核心需求，但是，也是有一些方向可以进一步优化整套方案的使用：
- Modular-Support 组件引入依赖注入的方式实现 API 的调用，使用方可以不再需要关心实例对象的获取
- Modular-Support 组件可以提供给 Weex、RN、H5、Flutter 业务一些原生的功能
- Modular-Plugin 能够进一步压缩打包时间，并且让开发中的依赖配置更加灵活
- Modular-Plugin 继续优化管理和依赖打包的功能，提高效率
五、总结
组件化的道路千万条，项目的架构也是在不断得调整优化，来达到提升团队开发效率，保证项目稳定性的目的。以上的这些想法和在实际项目中的一些方案，希望能给正在进行模块化探索的同学提供一些灵感。
