1、断点续传概念与Gradle中的体现

大家好，我是你们的讲师。今天咱们聊聊一个挺有意思的话题——断点续传。你可能会想：“这不是下载工具里的概念吗？跟Gradle有什么关系？”嗯，别急，我慢慢说。

先抛个问题：你写代码的时候，是不是经常改一行代码就要重新编译整个项目？是不是每次构建都感觉像是在“从头再来”？其实，Gradle里早就有了类似的“断点续传”思想——增量构建和构建缓存。说白了，就是让构建过程学会“记住”做过了什么，下次只做那些真正需要做的活。

1.1 什么是断点续传？从下载文件说起

我记得以前用迅雷下载大型游戏，动不动就几个G。网速慢的时候，下到一半断网了，要是从头再来，那得多崩溃。断点续传的思路就是：下载器把文件切成很多小块，每下完一块就记下来。下次继续从断掉的地方接着下，前面下过的就不用再下了。

这里有几个核心要素：

• 切分任务：把大任务拆成小单元
• 记录状态：哪个单元完成了，哪个没完成
• 跳过已完成：只做未完成的部分
• 合并结果：最终拼成完整结果

你想想看，Gradle 构建一个 Java 项目，是不是也是类似的？一个项目有几十个源文件、几百个类、一大堆资源文件。每次改了一行代码，要是把整个项目重新编译一遍，那效率也太低了。

Gradle 的做法其实就是“构建层面的断点续传”。我习惯把它叫作 “智能跳过”——它知道哪些文件没变，哪些任务的结果可以直接复用。

1.2 Gradle 增量构建：任务级别的“断点续传”

Gradle 里每个任务（Task）都可以配置成“增量”的。什么叫增量？就是只处理那些真正发生了变化的输入。

举个例子，你有一个 compileJava 任务，负责把 src 目录下的 .java 文件编译成 .class 文件。如果你只修改了 UserService.java，Gradle 会：

1. 检查每个 .java 文件的最后修改时间（或内容哈希）
2. 只重新编译那些发生变化的文件
3. 跳过那些没变的文件，直接用上次编译好的 .class

听起来是不是跟下载器的断点续传一模一样？只是“下载任务”变成了“编译任务”，“文件块”变成了“源文件”。

我曾经遇到一个团队，项目有 200 多个模块，每次全量编译要 40 分钟。他们死活没开增量构建，每次改一行代码都要等 40 分钟……后来我帮他们检查了 build.gradle，发现是自定义任务没有正确声明 Inputs 和 Outputs。加上注解后，增量编译跑得飞快，平均只花 2 分钟。嗯，这里要注意：如果你自己写的任务没有用 @InputFiles、@OutputDirectory 这些注解，Gradle 就没办法做增量判断，每次都会全量跑。

1.3 构建缓存：跨机器的“断点续传”

增量构建只解决“同一台机器、同一个工作目录”下的问题。如果你换了一台机器，或者把代码 checkout 到另一个目录，增量构建就失效了——因为之前的快照都没了。

这时候就该 构建缓存（Build Cache） 登场了。你可以把缓存想象成一个中央仓库，里面存着每个任务的输出结果。构建时，Gradle 会计算当前所有输入的快照哈希，然后去缓存里找：

• 如果找到 → 直接下载缓存结果，任务跳过
• 如果没找到 → 执行任务，并把结果上传到缓存

说白了，构建缓存让“断点续传”突破了单机限制。你在 Jenkins 上构建过的结果，可以在同事的开发机上直接复用——只要输入完全相同。

1.4 核心知识图谱

我把本章的核心逻辑画成了一张流程图，方便你整体理解。请注意：断点续传只是一个隐喻，Gradle 里真正实现的机制是 增量构建 和 构建缓存，二者互补，共同实现“跳过不必要工作”的目标。

1.5 如何开启这些“断点续传”能力？

增量构建在 Gradle 里是默认开启的，但前提是你的 Task 正确声明了输入输出。我见过太多项目，开发者自定义任务的时候直接写 doLast { ... }，不加任何注解，结果每次构建都全量跑。正确的做法是：

// 使用 @TaskAction 配合增量输入输出
abstract class MyTransformTask extends DefaultTask {
    @InputFiles
    abstract ConfigurableFileCollection getInputFiles()
    
    @OutputDirectory
    abstract DirectoryProperty getOutputDir()
    
    @TaskAction
    void transform(InputChanges inputChanges) {
        // inputChanges 能告诉你哪些文件变了
        // 只处理变化的部分
    }
}

构建缓存的开启稍微麻烦一点：

1. 在 gradle.properties 里设置 org.gradle.caching=true
2. 配置远程缓存地址（比如用 Redis 或文件系统）
3. 确保你的 Task 是“可缓存”的——即输入确定输出确定的纯函数

1.6 一个简单的实验，验证断点续传效果

你可以自己动手试试：

• 创建一个 Gradle 项目，写几个 Java 类
• 第一次运行 ./gradlew build，观察日志（会显示任务被执行）
• 再运行一次同一条命令，看日志里是不是出现了 UP-TO-DATE
• 修改其中一个 .java 文件，再次构建，只看到被修改的文件对应的任务重新执行

这就是增量构建在干活。你可以把 --info 参数加上，能看到更详细的任务跳过理由。比如：

./gradlew build --info | grep "UP-TO-DATE"

输出里会告诉你某个任务为什么是 UP-TO-DATE——因为它的 Inputs 没有变化。这跟下载器里显示“已下载 98%，跳过”是一个道理。