需要准备
- 一个熟悉的 IDE 开发工具
- JDK 7及以上
- Gradle 3.2以上
Gradle构建的各生命周期
1.初始化阶段
在初始化阶段,Gradle 决定哪些工程将会参与到构建,然后为每一个工程创建一个Project
的对象,通过该对象可以访问到工程的 Gradle 配置的所有功能。
2.配置阶段
在这个阶段,进行工程配置,工程的构建脚本会被执行。在这个阶段会遵循“按需配置”原则,Gradle 仅会配置相关联的工程。
3.执行阶段
在这个阶段,Gradle 会决定哪些分组任务被执行,这些分组任务是在配置阶段创建和配置好的。我们通过在 Gradle 命令行中传递任务的名称和当前目录来执行任务。
按需配置的原则
由于 Gradle 任务执行前所有工程的配置过程都会被执行,所以如果我们的项目有上百个工程(微服务会拆分很多工程)时,每次执行任务都要先进行上百个工程的配置过程,这样会浪费很多的时间,所 Gradle1.4 版本之后引进了“按需配置”功能。
按需配置是指每次执行任务前仅对相关依赖的工程进行配置,这样就节省了很多没必要的时间浪费。具体的配置原则如下:
- 根工程( root project )永远都会进行配置。这样我们就能在根工程中进行一些共享的公共配置,比如使用
allprojects
或者subprojects
进行的配置项。 - 在执行构建命令的当前工程会被进行配置,意思就是我们在哪个子工程中执行了
gradle build
命令,那么该工程也会被进行配置。 - 相关依赖工程会进行配置,比如,A 工程构建时依赖于 B 工程,那么在构建 A 工程之前,也会同时对 B 工程进行配置。
- 声明了相关任务依赖的工程也会进行配置,比如
someTask.dependsOn(":someOtherProject:someOtherTask")
,在进行构建之前 someOtherProject 工程也会同时进行配置。
在介绍了以上工程构建时的理论基础后,我们接下来从具体的配置实例来介绍多工程的构建打包过程。
定义公共的配置方法
首先我们创建根工程为multiproject
的项目,该项目包含三个子工程,分别为:api、core 和 game。其结构如下:
multiproject/
build.gradle
settings.gradle
api/
core/
game/
其中有一个名为settings.gradle
的配置文件,我们在之前的单工程中并没有介绍过,因为在单工程中它不是必须的,而在多工程中则是必须的,它指