15、增量编译与持续构建：增量Java编译、--continuous模式、提升开发效率

说实话，很多开发者在用Gradle时，最头疼的就是编译太慢。尤其是项目大了以后，改一行代码，等个十几秒甚至半分钟，那种感觉……嗯，就像你刚想好思路，结果被硬生生打断。

我自己也经历过这种痛苦。记得有一次，我在一个微服务项目里改了一个工具类的静态方法，结果整个项目重新编译，花了将近40秒。我当时就想：这不合理啊，明明只改了一个文件，为什么要把所有代码都重新编译一遍？

后来我才发现，Gradle其实早就提供了解决方案——增量编译和持续构建。说白了，就是让构建工具变得“聪明”一点，只做必要的事情，不做无用功。

15.1 增量Java编译：只编译你改过的文件

增量编译，顾名思义，就是只重新编译那些发生了变化的源文件，以及受它们影响的文件。而不是把整个项目从头到尾编译一遍。

Gradle从3.4版本开始，默认就开启了增量Java编译。但很多人并不知道这个机制是怎么工作的，也不知道如何验证它是否生效。

15.1.1 增量编译的工作原理

Gradle的增量编译基于一个核心概念：输入快照。每次编译时，Gradle会记录所有源文件的哈希值、类路径、注解处理器等输入信息。当下次编译时，它会对比这些快照，只处理那些发生变化的部分。

我画了一张图，帮你理解这个过程：

你可能会问：那Gradle怎么知道哪些文件受影响了？它靠的是类依赖分析。比如你改了A.java，而B.java引用了A，那么B.java也需要重新编译。Gradle会通过字节码级别的分析，精确地找出这个依赖链。

15.1.2 如何验证增量编译是否生效

我个人习惯在调试构建性能时，先跑一次全量编译，再改一个文件跑第二次，看看时间差。你可以用--info日志级别来观察：

./gradlew compileJava --info

如果增量编译生效，你会看到类似这样的日志：

Changes detected - recompiling the module!
Incremental compilation of 1 source file.
Skipping 48 source files that did not change.

看到“Skipping”这个词，就说明增量编译在干活了。如果每次都是“Compiling 49 source files”，那说明增量编译没生效，你得检查一下配置。

15.2 --continuous模式：让构建自动触发

增量编译解决了“编译慢”的问题，但还有一个痛点：每次改完代码，你都得手动敲一次构建命令。一天下来，光敲命令就浪费不少时间。

Gradle的--continuous模式（简称-t）就是干这个的。它会让Gradle进入“监听模式”，一旦检测到源文件发生变化，就自动触发构建。

15.2.1 基本用法

./gradlew build --continuous
# 或者简写
./gradlew build -t

启动后，终端会显示：

Waiting for changes to input files... (ctrl-d to exit)

这时候你只管改代码，保存后Gradle会自动重新构建。我一般在开发微服务时，会同时开两个终端：一个跑--continuous，一个跑应用。改完代码，构建自动完成，然后重启应用就行。

15.2.2 适用场景与注意事项

说实话，--continuous模式并不是所有场景都适合。我总结了一下：

场景	推荐使用	原因
纯Java/Kotlin项目	✅ 强烈推荐	编译快，依赖清晰
Android项目	⚠️ 谨慎使用	资源处理、AAPT等步骤可能不稳定
多模块大型项目	✅ 推荐	配合增量编译效果极佳
需要运行集成测试	❌ 不推荐	测试可能占用端口或资源，冲突风险高

我曾经在一个Android项目里用过--continuous，结果因为资源文件变动频繁，导致构建被反复触发，反而更慢了。后来我改成只对Java模块启用持续构建，资源模块手动触发，效果好了很多。

15.3 提升开发效率的组合拳

增量编译和持续构建，单独用已经能提升不少效率。但把它们组合起来，效果是1+1>2的。

15.3.1 最佳实践配置

我个人习惯在build.gradle里做如下配置：

// 确保增量编译开启（Gradle 3.4+ 默认开启）
tasks.withType(JavaCompile) {
    options.incremental = true
    // 设置编译缓存
    options.cache = true
}

// 配置持续构建的监听路径
tasks.named('compileJava') {
    inputs.dir('src/main/java')
    inputs.dir('src/main/resources')
}

然后启动持续构建：

./gradlew compileJava -t

这样，你每次保存Java文件，Gradle只会重新编译受影响的类，而且编译结果会被缓存。下次即使重启Gradle守护进程，也能复用之前的编译结果。

15.3.2 配合IDE使用

你可能会问：IDE不是自带自动编译吗？为什么还要用Gradle的持续构建？

嗯，这里有个关键区别：IDE的自动编译（比如IntelliJ的“Build project automatically”）用的是IDE自己的编译器，不是Gradle。如果你用了Lombok、MapStruct这类注解处理器，或者有复杂的Gradle插件逻辑，IDE的编译结果可能和Gradle不一致。

我遇到过好几次：IDE里编译通过，但Gradle构建报错。原因就是IDE的编译器和Gradle的编译器对注解处理器的处理方式不同。所以，如果你依赖Gradle的构建结果（比如部署到测试环境），建议用Gradle的持续构建，而不是IDE的自动编译。

15.4 性能调优：让增量编译更快

增量编译虽然快，但也不是没有优化空间。这里分享几个我常用的调优手段：

• 调整守护进程内存：在gradle.properties里设置org.gradle.jvmargs=-Xmx2048m -XX:MaxMetaspaceSize=512m，避免GC频繁触发导致编译变慢。
• 启用并行编译：org.gradle.parallel=true，让多模块项目并行编译。
• 使用构建缓存：org.gradle.caching=true，跨机器共享编译结果。
• 减少不必要的任务：持续构建时只跑compileJava，不要跑build，避免触发测试和打包。

好了，这一章的内容就到这里。增量编译和持续构建，说白了就是让Gradle变得更“聪明”、更“勤快”。你不需要每次都等它做完所有事情，它自己会判断该做什么。这种“按需构建”的思路，其实也是现代构建工具的核心设计哲学。

---