Gradle 自动化项目构建-Gradle 核心之 Project

一、前言

从明面上看，Gradle 是一款强大的构建工具，但 Gradle 不仅仅是一款强大的构建工具，它更像是一个编程框架。Gradle 的组成可以细分为如下三个方面：

groovy 核心语法：包括 groovy 基本语法、闭包、数据结构、面向对象等等。
Android DSL（build scrpit block）：Android 插件在 Gradle 所特有的东西，我们可以在不同的 build scrpit block 中去做不同的事情。
Gradle API：包含 Project、Task、Setting 等等。

可以看到，Gradle 的语法是以 groovy 为基础的，而且它还有自己独有的 API，所以我们可以把 Gradle 认作是一款编程框架，利用 Gradle 我们可以在编程中去实现项目构建过程中的所有需求。想要随心所欲地使用 Gradle，我们必须提前掌握好 groovy。需要注意的是，Groovy 是一门语言，而 DSL 一种特定领域的配置文件，Gradle 是基于 Groovy 的一种框架工具，而 gradlew 则是 gradle 的一个兼容包装工具。

Gradle 有以下优势：

灵活性：相对于 Maven、Ant 等构建工具，Gradle 提供了一系列的 API 让我们有能力去修改或定制项目的构建过程。例如我们可以利用 Gradle 去动态修改生成的 APK 包名。
粒度性：使用 Maven、Ant 等构建工具时，我们的源代码和构建脚本是独立的，而且我们也不知道其内部的处理是怎样的。但是 Gradle 则不同，它从源代码的编译、资源的编译、到生成 APK 的过程中都是一个接一个来执行的。此外，Gradle 构建的粒度细化到了每一个 task 之中。并且它所有的 Task 源码都是开源的，在我们掌握了这一整套打包流程后，我们就可以通过修改它的 Task 去动态改变其执行流程。例如 Tinker 框架的实现过程中，它通过动态地修改 Gradle 的打包过程生成 APK 的同时，也生成了各种补丁文件。
扩展性：Gradle 支持插件机制，所以我们可以复用这些插件，就如同复用库一样简单方便。
兼容性：Gradle 不仅自身功能强大，而且它还能兼容所有的 Maven、Ant 功能，也就是说，Gradle 吸取了所有构建工具的长处。

可以看到，Gradle 相比于其它构建工具，其好处不言而喻，而其最核心的原因就是因为 Gradle 是一套编程框架。

二、Gradle 的生命周期

所谓 Gradle 的生命周期，即 gradle 的执行流程，也就是 Gradle 先执行什么后执行什么。我们看下它的流程图：

可以看到，gradle 的执行流程分了初始化、配置、执行三个阶段，上图中的 project、task 我们接下来几篇会详细介绍。下面我们看看这几个阶段。

2.1、初始化阶段

初始化阶段会读取根工程中的 setting.gradle 中的 include 信息，确定有多少工程加入构建，然后会为每一个项目（build.gradle 脚本文件）创建一个个与之对应的 Project 实例，最终形成一个项目的层次结构。

与初始化阶段相关的脚本文件是 settings.gradle，而一个 settings.gradle 脚本对应一个 Settings 对象，我们最常用来声明项目的层次结构的 include 就是 Settings 对象下的一个方法，在 Gradle 初始化的时候会构造一个 Settings 实例对象，以执行各个 Project 的初始化配置。

此外，在 settings.gradle 文件中，我们可以指定其它 project 的位置，这样就可以将其它外部工程中的 moudle 导入到当前的工程之中了。示例代码如下所示：

if (useSpeechMoudle) {
    // 导入其它 App 的 speech 语音模块
    include "speech"
    project(":speech").projectDir = new File("../OtherApp/speech")
}

2.2、配置阶段

配置阶段的任务是执行各项目下的 build.gradle 脚本，完成 Project 的配置，与此同时，会构造 Task 任务依赖关系图以便在执行阶段按照依赖关系执行 Task。而在配置阶段执行的代码通常来说都会包括以下三个部分的内容，如下所示：

1)、build.gralde 中的各种语句。
2)、闭包。
3)、Task 中的配置段语句。

需要注意的是，执行任何 Gradle 命令，在初始化阶段和配置阶段的代码都会被执行。

2.3、执行阶段

在配置阶段结束后，Gradle 会根据各个任务 Task 的依赖关系来创建一个有向无环图，我们可以通过 Gradle 对象的 getTaskGraph 方法来得到该有向无环图。并且当有向无环图构建完成之后，所有 Task 执行之前，我们可以通过 whenReady(groovy.lang.Closure) 或者 addTaskExecutionGraphListener(TaskExecutionGraphListener) 来接收相应的通知，其代码如下所示：

gradle.getTaskGraph().addTaskExecutionGraphListener(new TaskExecutionGraphListener() {
    @Override
    void graphPopulated(TaskExecutionGraph graph) {
    }
})

然后，Gradle 构建系统会通过调用 gradle <任务名> 来执行相应的各个任务。

可以看到，整个 Gradle 生命周期的流程包含如下四个部分：

首先，解析 settings.gradle 来获取模块信息，这是初始化阶段。
然后，配置每个模块，配置的时候并不会执行 task。
接着，配置完了以后，有一个重要的回调 project.afterEvaluate，它表示所有的模块都已经配置完了，可以准备执行 task 了。
最后，执行指定的 task 及其依赖的 task。

在 Gradle 构建命令中，最为复杂的命令可以说是 gradle build 这个命令了，因为项目的构建过程中需要依赖很多其它的 task。这里，我们以 Java 项目的构建过程看看它所依赖的 tasks 及其组成的有向无环图，如下所示：

2.4、生命周期监听

上面我们学习了 Gradle 的执行生命流程，下面我们在它的监听回调中做一些输出。

首先在项目根目录的 build.gradle 中添加如下监听代码：

在根目录的 setting.gradle 中添加如下代码：

接下来我们执行一个简单的 gradle 命令：gradle clean

Gradle 核心之 Project

一、前言

Project 是 Gradle 构建整个应用程序的入口，所以它非常重要。我们看下面这张图：

上图是我创建的一个 Android 工程，并添加了一个 test module。我们在命令行中输入 gradle projects 命令看看有哪些 project：

可以看到输出了三个 project，其中 GradleTextProject 是根 project，而 app、test 是子 project。根 project 的作用是管理所有的子 project。准确来说有 build.gradle 文件的目录即是 project。一个子 project 对应一个输出，具体输出什么由 build.gradle 配置去决定。

二、project 核心 api

在 Project 中有很多的 API，但是根据它们的属性和用途我们可以将其分解为六大部分，如下图所示：

对于 Project 中各个部分的作用，我们可以先来大致了解下，以便为 Project 的 API 体系建立一个整体的感知能力，如下所示：

Project 相关 API：让当前 Project 拥有了操作它的父 Project 以及管理它的子 Project 的能力。
Task 相关 API：为当前 Project 提供了新增 Task 以及管理已有 Task 的能力。由于 task 非常重要，我们将在下一篇进行讲解。
属性相关的 Api：Gradle 会预先为我们提供一些 Project 属性，而属性相关的 api 让我们拥有了为 Project 添加额外属性的能力。
File 相关 Api：Project File 相关的 API 主要用来操作我们当前 Project 下的一些文件处理。
Gradle 生命周期 API：即我们在上一篇讲解过的 Gradle 核心之生命周期。
其它 API：添加依赖、添加配置、引入外部文件等等零散 API 的聚合。

2.1、Project 相关 API

通过 gradle 管理的工程都会有一个根工程 project，根工程用来管理子工程。下面我们来看看 Project 相关的 API。

2.1.1 getAllprojects()

getAllprojects 表示获取所有 project 的实例，示例代码如下所示：

我们调用了 getAllprojects 方法返回一个包含根 project 与其子 project 的 Set 集合，并链式调用了 eachWithIndex 遍历 Set 集合。接着，我们会判断当前的下标 index 是否是0，如果是则表明当前遍历的是 rootProject，则输出 rootProject 的名字，否则输出 child project 的名字。

然后我们在命令行执行 gradle clean，其运行结果可以看到，会先配置我们的 rootProject，并输出了对应的工程信息。接着便会执行子工程 app 的配置。rootProject 与其旗下的各个子工程组成了一个树形结构。

2.1.2 getSubprojects()

getSubprojects 表示获取当前工程下所有子工程的实例，示例代码如下所示：

同 getAllprojects 的用法一样，getSubprojects 方法返回了一个包含子 project 的 Set 集合。

2.1.3 getParent()

getParent() 是获取父 project 的方法。

可以看到，执行 gradle clean 后输出了 test module 这个 project 的父 project，也就是 GradleTextProject。需要注意的是，如果在根目录的 build.gradle 中调用 getParent() ，由于根 project 没有父节点了，所有返回的是 null。

2.1.4 getRootProject()

getRootProject() 获取的是根节点 project。

形成的 project 树中肯定是有根节点的，所以在任意子节点 project 中调用 getRootProject 都返回的是根节点 project，所以肯定不会返回空。

2.1.5 project()

project 表示的是指定工程的实例，然后在闭包中对其进行操作。可以看到，在 project 方法中两个参数，一个是指定工程的路径，另一个是用来配置该工程的闭包。下面我们看看如何灵活地使用 project，示例代码如下所示：

2.1.6 allprojects()

allprojects 表示用于配置当前 project 及其每一个子 project，在 allprojects 中我们一般用来配置一些通用的配置，比如最常见的全局仓库配置。如下所示：

当我们用熟练后，可以省略闭包的参数：

2.1.7 subprojects()

subprojects 用于统一配置当前 project 下的所有子 project，给所有的子工程引将 aar 文件上传置 Maven 服务器的配置脚本，示例代码如下所示：

subprojects {
if (project.plugins.hasPlugin("com.android.library")) {
apply from: '../publishToMaven.gradle'
}
}

在上述示例代码中，我们会先判断当前 project 下的子 project 是不是库，如果是库才有必要引入 publishToMaven 脚本。需要注意与 allprojects() 的区别是，subprojects() 不包含当前 project。

2.2 属性相关API

Project 提供了默认的 7 个属性，我们先来看看这些属性：

第一个属性 DEFAULT_BUILD_FILE = "build.gradle" 表明默认读取的配置文件是 build.gradle，这也证明了上面说有 build.gradle 的文件夹就是一个 project 的结论。

第二个属性 PATH_SEPARATOR 表示的是分隔符。

第三个属性 DEFAULT_BUILD_DIR_NAME 表示默认的输出文件夹，每个工程都会有一个 build 文件夹存放 project 输出。

后面几个属性不常用到，就不详细说明了。这么少的属性显然无法满足我们各种各样的构建需求，gradle 为我们提供了一种去扩展 project 属性的方式。主要有两种扩展方式，下面我们来看看。

2.2.1 ext 扩展属性

我们可以使用 ext 扩展属性修改默认情况下 app 或其他 module 的 build.gradle 配置，如下所示：

project 中 ext 加闭包即定义扩展属性，我们可以在每个 project 的 build.gradle 文件中定义 ext 扩展属性，但当我们有多个 project 的时候这种写法也很麻烦。这时候我们可以把 ext 放到上一节我们学习的 allprojects()、subprojects() 中，然后在子 project 中用 this 关键字引用即可。

另外，我们也可以去掉 subprojects()，在根目录中直接设置 ext，然后在子 project 中通过 this.rootProject 来引用。

另外也可以直接通过 this 来直接使用，因为子 project 是继承父 project 的，所以父 project 中定义的属性，子 project 可以直接使用。随着版本的迭代，演变出了最优方案：将扩展属性单独定义到一个新的 gradle 文件中，这样就可以减少根工程的配置代码，同时也更模块化了我们的变量。这里我们通常会将其命名为 config.gradle，如下：

可以看到，在 config.gradle 中分了各个区块，在每个区块中定义了一个 map，在 map 中定义各种 key、value。然后在我们的根目录下的 build.gradle 中引入这个 gradle：

引用完成后就可以在我们的子 project 的 build.gradle 中按区块引用即可：

2.2.2 gradle.properties 里定义扩展属性

除了使用 ext 扩展属性定义额外的属性之外，我们也可以在 gradle.properties 下定义扩展属性，其示例代码如下所示：

// 在 gradle.properties 中
mCompileVersion = 27
// 在 app moudle 下的 build.gradle 中
compileSdkVersion mCompileVersion.toInteger()

2.3 文件相关API

2.3.1 路径获取相关API

关于路径获取的 API 常用的有三种，其示例代码如下所示：

2.3.2 文件操作API

groovy 中的文件操作 API 可以用在 project 中，而本节讲解的 project 中文件操作 API 可以在 project 下去更方便的对文件进行操作。下面我们来看看有哪些操作。

文件定位：常用的文件定位 API 有下面两个方法：

//定位单个文件
File file(Object path);
//定位多个文件
ConfigurableFileCollection files(Object... paths);

使用如下所示：

文件拷贝：常用的文件拷贝 API 为 copy，不仅可以对文件进行拷贝，也可以对文件夹进行拷贝。其示例代码如下所示：

在实际项目中的使用一般如下：

tasks.whenTaskAdded { task ->
if (task.name.equalsIgnoreCase("assembleRelease")) {
// 如果是assembleRelease任务，在最后执行导出apk以及mapping目录到指定目录
task.doLast {
outputReleaseFile()
}
}
}
void outputReleaseFile() {
android.applicationVariants.all { variant ->
// 如果是正式版打包
if (variant.name.equalsIgnoreCase("release")) {
File outputPath = new File("$rootDir" + File.separator + "release_app" + File.separator
+ android.defaultConfig.versionName)
println(String.format('拷贝生成文件到指定目录[%s]', outputPath.getAbsolutePath()))
// 拷贝apk文件
copy {
from variant.outputs[0].outputFile
into outputPath
// 重命名导出名称
rename {
'account_system' + variant.name + '_' + android.defaultConfig.versionName + ".apk"
}
}
// 拷贝mapping目录
copy {
from variant.mappingFile.getParentFile()
into new File(outputPath, 'mapping')
}
}
}
}

变体其实就是我们的 apk，变体我们后面再介绍。

2.3.3 文件树的遍历

我们可以使用 fileTree 将当前目录转换为文件数的形式，然后便可以获取到每一个树元素（节点）进行相应的操作，其示例代码如下所示：

2.4 其他API

其他API包含两部分：

2.4.1 依赖相关API

根项目下的 buildscript 用于配置项目核心的依赖，使用如下：

当我们熟练使用闭包后可以简写如下：

需要注意的是不同于根项目 buildscript 中的 dependencies 是用来配置我们 Gradle 工程的插件依赖的，而 app moudle 下的 dependencies 是用来为应用程序添加第三方依赖的。关于 app moudle 下的依赖使用这里我们需要注意下 exclude 与 transitive 的使用即可，示例代码如下所示：

implementation(rootProject.ext.dependencies.glide) {
// 排除依赖：一般用于解决资源、代码冲突相关的问题
exclude module: 'support-v4'
// 传递依赖：A => B => C ，B 中使用到了 C 中的依赖，且 A 依赖于 B，如果打开传递依赖，则 A 能使用到 B 中所使用的 C 中的依赖
//默认都是不打开，即 false 禁止传递依赖
transitive false
}