Gradle依赖管理 & Kotlin DSL解析

公共组件库依赖管理

公共组件库项目采用了单project多module的模块化开发形式, 在这样的项目结构下, 如何去维护模块及外部依赖是一个我们不能回避的问题. 在组件库阶段一及阶段二的研发过程中, 我们遇到了以下与依赖相关的问题:

1. 如何在开发过程中统一各组件模块中的依赖及版本
2. 如何高效的解决, 在开发过程中依赖本地组件模块; 测试/发布过程中使用远端依赖的问题

针对问题一,可以采用通用的组件库，从而实现各个模块中外部依赖及版本统一. 当然目前依赖库还在试用阶段, 我们在使用的期间也踩过一些坑, 后面会详细跟大家分享.

针对问题二, 我们通过使用Gradle buildSrc定义模块动态依赖. 在CI/CD的基础上, 实现了根据开发/测试/发布阶段自动切换本地或远端依赖的功能.

1. 构建工具简史

Gradle是我们在安卓开发中最常用的构建工具, 自Android Studio发布以来, 他一直是默认的构建工具. 但是其实在Gradle之前, 还有很多知名的构建工具, 例如Java开发中常用的Maven等等.

其中最经典的当属Ant了, Ant使用的DSL是xml, xml的进化来源于MakeFile构建的繁琐, 而xml特点是结构化且好理解, 这比写脚本插件简单多了, 所以迅速流行起来.

随着软件行业的迅速发展, 我们的产品功能越来越多, 业务越来越复杂, 开发团队也日益庞大, 这时候工程管理和工程的标准化问题就开始日益突出, 于是Maven诞生了. Maven很好的解决了依赖问题, 引入了标准依赖库对版本进行管理, 并且对工程的目录结构、构建生命周期都做了标准化定义, 极大的方便了工程管理及开发.

但是当Maven流行一段时间之后, 大家又发现了问题, xml逻辑简单是不错, 但是写起来太啰嗦, 而且扩展性不够, 此时, Gradle登场了. Gradle在Maven的基础上, 主要解决了两个问题：

1. 用一种新的DSL, 让语法变的更简洁, 且支持扩展;
2. 定义了扩展方便且不失标准的构建生命周期;

实际上Gradle发展至今, 早已超越了上面这两点, 而且还在不断的进化中, 比如buildSrc的诞生、kts的支持、KSP的演进等等.

2. Gradle依赖管理

在Gradle的日常使用中, 依赖管理其实是非必须的. 但是