理解Gradle任务生命周期
gradle构建过程包含两个主要阶段：配置阶段（configuration phase）和执行阶段（execution phase）。理解这两个阶段对于正确处理任务中的逻辑至关重要。
配置阶段 (Configuration Phase) 在这个阶段，Gradle会评估所有的构建脚本（如build.gradle），定义所有的项目、任务和依赖关系。所有在任务定义块中，但不在doFirst {}或doLast {}闭包内的代码，都会在这个阶段被执行。这意味着，即使某个任务最终不会被执行，其配置阶段的代码也会运行。
执行阶段 (Execution Phase) 在配置阶段完成后，Gradle会根据用户请求和任务依赖图来决定哪些任务需要运行。只有被选中的任务，其doFirst {}和doLast {}闭包中的代码才会在这个阶段被执行。
错误示例：配置阶段抛出异常
当开发者试图在任务定义块中直接检查条件并抛出异常时，问题就会出现。考虑以下代码片段：
task('myRandomTask', type: Zip) {
// 这里的代码在配置阶段执行
if(!(new File("$projectDir/../../some-other-dir/")).exists()) {
throw new GradleException("dependent dir not kept at relative path");
}
// do my stuff (这些配置会继续，但如果上面抛出异常，则不会被执行)
}
// 假设还有一个独立的任务
task('anotherTask') {
doLast {
println "This is another task."
}
}在上述示例中，myRandomTask的任务定义中包含了一个文件存在性检查。如果"$projectDir/../../some-other-dir/"路径不存在，GradleException会在Gradle的配置阶段被抛出。这意味着：
- 无论用户是否请求执行myRandomTask（例如，只运行./gradlew anotherTask），这个检查都会在配置所有任务时立即进行。
- 一旦异常在配置阶段抛出，整个构建过程就会停止，导致anotherTask等其他任务也无法被配置和执行。这会造成构建流程中断，即使请求的任务与myRandomTask无关。
正确实践：将异常逻辑放入执行阶段
为了确保条件检查和异常抛出只在myRandomTask实际执行时发生，我们应该将这些逻辑放入doLast {}或doFirst {}闭包中。
- doFirst {}: 在任务的主要动作之前执行。
- doLast {}: 在任务的主要动作之后执行。
在大多数情况下，将条件检查放在doLast {}是更常见的做法，因为它通常代表了任务完成前的一个最终检查或清理步骤。
task('myRandomTask', type: Zip) {
// 任务的配置，例如设置归档名称、源文件等
// from 'src/main/resources'
// archiveFileName = 'my-archive.zip'
doLast {
// 这里的代码只在 myRandomTask 被执行时才运行
if(!(new File("$projectDir/../../some-other-dir/")).exists()) {
throw new GradleException("dependent dir not kept at relative path");
}
println "myRandomTask executed successfully."
}
}
task('anotherTask') {
doLast {
println "This is another task."
}
}通过将文件存在性检查和异常抛出逻辑放入doLast {}块中，我们实现了以下目标：
- 延迟执行： 检查逻辑只会在./gradlew myRandomTask被调用时执行。
- 构建健壮性： 如果用户执行./gradlew anotherTask，即使myRandomTask中的条件不满足，anotherTask也能正常配置并运行，因为myRandomTask的doLast {}块不会被触发。
- 清晰的职责分离： 任务定义块用于配置任务属性，而doFirst/doLast块用于定义任务的实际执行逻辑。
总结与注意事项
- 核心原则： 区分Gradle任务的配置阶段和执行阶段。任何需要在任务实际运行时才进行的条件判断、文件操作或可能抛出异常的逻辑，都应放置在doFirst {}或doLast {}闭包中。
- 避免全局中断： 在配置阶段抛出异常会导致整个构建失败，影响所有任务。
- 提高可维护性： 将执行逻辑封装在doFirst/doLast中，使任务定义更清晰，也更容易调试。
- 选择doFirst还是doLast： 根据逻辑的实际需求选择。如果条件检查是任务执行的先决条件，且失败应阻止后续操作，则使用doFirst。如果检查是任务完成后的验证或清理，则使用doLast。
遵循这些最佳实践，可以有效管理Gradle任务中的异常，确保构建过程的稳定性和可靠性。
