Gradle构建速度瓶颈概述：为什么要优化、常见瓶颈类型
嗯，咱们不绕弯子。Gradle构建慢，到底亏在哪？说白了，它消耗的不是机器时间，而是开发者的心流状态和公司的CI预算。我之前带过几个团队，新手常觉得"慢就慢点，反正不耽误干活"，直到构建从1分钟膨胀到10分钟……大家开始上班先点构建，然后起身去倒咖啡、聊闲天。这种情况其实是一种巨大的隐性成本。
为什么要死磕构建性能？
你想想看，假设团队10个人，每人每天因为等构建浪费30分钟。一个月下来就是上百个小时的人力成本，折合RMB不是个小数目。而且频繁被打断思路，写代码的质量也会直线下降。
我个人习惯是把构建时间当成一个"技术债温度计"。时间越长，说明系统的健康度越差。一次干净的增量构建如果超过3分钟，就要拉警报了。
- 减少切换上下文，提升开发幸福感
- 加快CI流水线吞吐，缩短交付周期
- 降低开发机资源占用，告别风扇狂转
常见瓶颈类型
我把日常遇到的Gradle性能问题归为四大类。你可以对照着看看自己项目踩了哪个坑。
| 瓶颈分类 | 典型症状 | 根因猜测 |
|---|---|---|
| 资源配置 | Daemon频繁GC，Build时间波动大 | org.gradle.jvmargs太小 |
| 任务执行 | 每次都全量编译，没命中UP-TO-DATE | 增量编译配置失效，Task输入输出声明不规范 |
| 依赖解析 | Building 80%卡很久，尤其是周一早上 | 动态版本1.+，仓库网络慢 |
| Plugin与I/O | 生成代码慢，Transform耗时高 | APT无缓存，Plugin设计不合理，文件拷贝过多 |
四类瓶颈逐个拆解
1. 资源配置瓶颈
Gradle跑在JVM上，内存给不够，它就开始"世界暂停"做GC。我记得有个项目，把org.gradle.jvmargs=-Xmx2048m改为-Xmx4096m，构建时间直接砍半。其实就是加了一行配置：
# gradle.properties
org.gradle.jvmargs=-Xmx4g -XX:MaxMetaspaceSize=512m
org.gradle.parallel=true
org.gradle.caching=true
但请注意，内存也不是越大越好。我见过有人给Daemon分了8G，结果本机其他应用直接卡死。建议根据项目规模调整，一般4G是个甜点区间。
2. 任务执行瓶颈
这其实是最常见的。Gradle的增量编译和缓存机制非常强大，但前提是你没乱写Task。我曾见过有人自定义Task里用了project.fileTree()做输入，每次都会生成新的File对象，导致Hash不一致，永远无法命中UP-TO-DATE。
为什么会这样？因为Gradle判断一个Task要不要重新执行，核心看它的输入和输出有没有变化。如果你的输入声明是一个File集合，但集合里文件的顺序每次都变，Gradle就会认为输入变了。
// 错误的做法
inputs.files(project.fileTree("src").files)
// 正确的做法
inputs.dir(file("src"))
3. 依赖解析瓶颈
动态版本（如com.google.guava:+27.0-android）听起来很方便，但它会导致Gradle每24小时或每次清除缓存后，都去远程仓库拉取元数据。你想想看，如果网络波动，是不是就堵在这了？
而且，仓库配置的顺序也极其重要。我个人习惯把公司内部的Maven私服写在最前面，其次才是mavenCentral、google等。这样可以减少"先去找远程公网，失败后再查私服"的延迟。
repositories {
maven { url "https://internal.nexus.example.com/repository/maven-public/" }
mavenCentral()
google()
}
4. Plugin与I/O瓶颈
一些重量级Plugin，比如大型的APT框架、Dagger、Glide的Annotation Processor，如果不做增量，每次都是全量处理，非常痛苦。我之前检查过一个项目，kapt编译占了整个构建时间的70%。后来改成kotlin-kapt的增量模式，配合Build Cache，时间降到了20%以下。
另外，文件拷贝操作（Copy任务）如果没有用FileCollection.getBuiltBy()声明依赖，也会破坏缓存链。
瓶颈的本质与排查思路
光靠猜哪慢是不行的。你需要"看见"构建过程中每一步的耗时。这就是我认为网络瀑布图存在的核心价值——它能让你像医生看X光片一样，一眼看出哪个器官（Task）在超负荷运转。
在我自己诊断过的项目中，90%的性能问题都可以通过检查--profile报告或Build Scan的瀑布图来定位。剩下的10%则需要结合GC日志和系统监控。
--scan 参数，Gradle会自动生成一份可在浏览器中查看的详细报告，里面就包含了精确到每个任务的耗时瀑布图。
所以，磨刀不误砍柴工。搞懂瓶颈类型，学会看瀑布图，是Gradle性能优化的必修课。后续我们会一步步深入讲解如何实操定位。嗯，先从了解你的build.gradle和gradle.properties开始吧。