一、先给构建过程做个“体检”：找到慢在哪里
在动手优化之前，我们得先知道时间都花在哪了。盲目优化就像无头苍蝇，效果甚微。
Gradle贴心地为我们提供了性能分析工具。最直接的方法就是使用 --profile 参数。在命令行中执行你的构建命令时加上它，比如：
技术栈：Java + Gradle
./gradlew assembleDebug --profile
构建完成后，Gradle会在 项目根目录/build/reports/profile/ 下生成一个HTML报告文件。打开它，你会看到一个清晰的“体检报告”：
- 总结视图：告诉你整个构建花了多少时间，配置阶段和任务执行阶段各占多少。
- 任务执行时间线：像音乐播放器进度条一样，直观展示每个任务什么时候开始、花了多久。那些又长又粗的“色块”，就是我们的重点怀疑对象。
- 任务耗时排序：直接列出最耗时的任务，比如
:app:compileDebugJavaWithJavac（Java编译）常常名列前茅。
应用场景：任何感觉构建变慢的项目，第一步都应该用它来诊断。这是科学优化的基础。
二、优化“准备工作”：配置阶段提速
构建开始前，Gradle需要读取并解析所有 build.gradle 脚本，这叫做配置阶段。如果这里就卡顿，那后面只会更慢。
常见瓶颈与解决：
- 避免在配置阶段执行“重活”：不要在
build.gradle的顶层或闭包中执行耗时操作（如网络请求、大文件读取）。// 错误示例：在配置阶段读取大文件 def bigConfigFile = new File('large-config.json').text // 这会拖慢每次构建的启动速度 android { ... } // 正确做法：将耗时操作移到任务执行时或使用惰性属性 tasks.register('printConfig') { doLast { // doLast 内的代码只在任务执行时运行 def bigConfigFile = new File('large-config.json').text println "Config: ${bigConfigFile}" } } - 应用按需配置：使用
gradle.startParameter.configureOnDemand=true。这个设置让Gradle只配置与请求任务相关的模块，对于多模块项目提速明显。你可以在命令行加--configure-on-demand，或更推荐在全局配置文件~/.gradle/gradle.properties中设置：# 全局启用按需配置 org.gradle.configureondemand=true # 同时增加并行构建线程数，充分利用多核CPU org.gradle.parallel=true org.gradle.workers.max=4 # 通常设置为CPU核心数 - 管理插件依赖：检查是否应用了不必要的插件，或者插件版本过旧。社区插件质量参差不齐，有些可能在配置阶段做太多事情。
技术优缺点：按需配置和并行构建是Gradle的“王牌”优化手段，对于模块化项目几乎有立竿见影的效果，且配置简单。但需要注意，极少数老旧插件可能与并行模式不兼容。
三、优化“核心生产”：任务执行阶段提速
这是构建耗时的大头，尤其是编译、资源处理等任务。
1. 拥抱构建缓存：别再重复劳动
Gradle构建缓存能将任务输出（如.class文件）缓存起来。当输入不变时，下次构建直接复用，跳过执行。这是提升增量构建和干净构建速度的神器。
- 本地缓存：默认开启，缓存位置在
~/.gradle/caches/。 - 远程缓存（团队共享）：更强大，团队成员可以共享缓存输出，新人拉取代码后首次构建也能极速完成。
启用与配置示例：
在 settings.gradle 或 gradle.properties 中启用：
// 在 settings.gradle 中
settings.gradle.startParameter.buildCache {
local {
enabled = true
// 设置本地缓存大小，避免磁盘被占满
removeUnusedEntriesAfterDays = 7
}
// 如需远程缓存（如使用自建HTTP服务或Gradle Enterprise）
// remote(HttpBuildCache) {
// url = 'https://our-cache-server.example.com/cache/'
// credentials { ... }
// }
}
注意事项：确保任务定义正确，输入/输出声明准确，否则缓存可能失效或产生错误缓存。对于非绝对确定的任务（如某些代码生成任务），可以显式禁用缓存：tasks.named(‘someTask’) { outputs.cacheIf { false } }。
2. 增量构建与UP-TO-DATE检查 Gradle的增量构建是其核心智能之一。任务需要正确声明其输入和输出，Gradle才能判断文件是否变化，跳过“最新”的任务。
- 问题：自定义任务如果没声明
inputs/outputs，它永远无法被跳过。 - 示例：我们写一个处理模板文件的任务。
// 一个自定义任务，用于将模板文件中的占位符替换为实际值
task generateConfigFiles(type: Copy) {
from 'src/templates'
into 'build/generated/configs'
expand([projectName: project.name, version: project.version])
// 这个任务隐式地拥有正确的输入（from的文件）和输出（into的目录）
// 因此Gradle能自动进行UP-TO-DATE检查，如果模板和参数没变，任务会被跳过。
}
3. 优化Java/Kotlin编译
- 使用最新编译器：JDK本身的编译性能在持续提升。
- 调整JVM参数：在
gradle.properties中为Gradle守护进程分配更多内存。# 提升Gradle守护进程堆内存，避免GC频繁影响编译 org.gradle.jvmargs=-Xmx4096m -XX:MaxMetaspaceSize=1024m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8 - 对于Kotlin：确保使用最新Gradle插件，并考虑启用Kotlin编译守护进程和增量编译（通常默认开启）。
4. 管理依赖项
- 使用动态版本号需谨慎：如
1.+'，这会导致Gradle频繁检查远程仓库是否有新版本，破坏构建缓存和可重复性。尽量使用固定版本。 - 依赖下载优化：配置稳定的国内镜像仓库（如阿里云Maven仓库）可以大幅提升依赖下载速度。
// 在项目的 build.gradle 或 settings.gradle 的 repositories 块中添加 repositories { maven { url 'https://maven.aliyun.com/repository/public/' } mavenCentral() // ... 其他仓库 }
四、高级“手术”与日常习惯
1. 分析特定任务：如果报告显示某个任务（如 :app:mergeDebugResources）特别慢，可以使用 --dry-run 先看看有哪些任务会被执行，或者用 gradlew 任务名 --info 查看该任务的详细日志。
2. 使用Gradle扫描：Gradle官方提供的免费服务（--scan），生成比 --profile 更详细、交互性更强的在线报告，能深入分析依赖解析、缓存命中等问题。
bash ./gradlew build --scan
3. 保持构建脚本整洁：
* 定期清理 build 目录：./gradlew clean。但注意，这会清空本地构建缓存外的所有输出，导致下次全量构建。
* 升级Gradle Wrapper和插件版本。新版本往往包含性能改进和Bug修复。
文章总结： Gradle性能调优是一个系统工程，从诊断到优化，需要有的放矢。我们的优化路径可以概括为：一测（Profile） -> 二配（优化配置阶段） -> 三缓（善用构建缓存） -> 四编（优化编译依赖） -> 五习（养成好习惯）。记住，没有银弹，最适合你项目的优化组合，需要基于 profiling 报告来持续调整。优化后，记得对比优化前后的构建时间，享受那种“速度与激情”带来的成就感吧！
应用场景：本攻略适用于所有使用Gradle作为构建工具的中大型项目，尤其是Android、Java后端、多模块库项目等。在CI/CD流水线中，优化构建速度能直接节省计算资源和等待时间，提升开发效率。
注意事项：
- 任何优化都要在保证构建正确性的前提下进行。
- 团队协作时，构建缓存、并行设置等最好通过项目配置文件或约定来统一，避免环境差异。
- 远程构建缓存服务器的搭建和维护需要一定成本，适合大型团队。
- 过度优化可能增加构建脚本的复杂度，需权衡可维护性。
评论