Gradle第11课：Gradle 实现多工程的编译打包

需要准备

• 一个熟悉的 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的配置文件，我们在之前的单工程中并没有介绍过，因为在单工程中它不是必须的，而在多工程中则是必须的，它指