📚 课程目录第1章 Gradle构建性能概述与瓶颈诊断意义

Gradle 构建性能概述与瓶颈诊断意义

说实话，我刚接触 Gradle 那会儿，觉得构建慢点就慢点呗。不就是多等两分钟嘛，还能趁这功夫喝口咖啡。

直到有一天，团队从 5 人扩到 15 人，每个开发者每天跑十几次构建。你想想看，一个人多等 5 分钟，全队就是 75 分钟。一个月下来……我算了算，光等待时间就能浪费掉整整 3 个开发人天。

更可怕的是 CI 流水线——每次提交跑一次全量构建，十五分钟打底。遇到发布日，Merge 到 master 的代码需要排队，一堵就是半小时。我记得有一回，就因为构建太慢，线上紧急 Bug 修好了却发不出去，产品经理差点拍桌子。

所以，构建性能绝不是「锦上添花」，而是决定团队交付节奏的硬门槛。说白了，就是跟钱和效率直接挂钩。

核心观点：构建速度每提升 1 分钟，全团队每天就能多出 N 个开发人天。Gradle 构建性能优化，投入产出比极高。

Gradle 构建跑得慢，很少是单一原因。我总结下来，主要有这几大类：

阶段	常见瓶颈	典型表现
配置阶段（Configuration）	大量 apply plugin、动态依赖解析	看一眼 Gradle Console，前 30 秒就在跑配置脚本
依赖解析	远程仓库网络慢、传递依赖冲突	每次构建都要重新下载/校验 jar 包
任务执行	过多的独立任务、未启用并行执行	CPU 一个核心在干活，其他核心在围观
增量编译失效	注解处理器没配好、输出目录乱写	改一行代码，却被迫重新编译整个模块
缓存机制	构建缓存被污染、本地缓存过期策略不合理	每次 clean build，一切从头再来

有些问题一眼就能看出来，比如你跑 gradle build --scan 就能看到哪一步耗时最长。但真正麻烦的是——很多瓶颈是互相叠加的。依赖解析慢了，会拖慢任务调度；配置脚本多了，又会抢占编译资源。这就是为什么我们需要一个系统性的诊断方法。

我第一次用 --profile 生成 Gradle 性能报告时，看到那个瀑布图，真的被震撼到了。

// 在项目根目录运行
gradle clean build --profile --parallel

// 然后在 build/reports/profile 下找到 HTML 报告

瀑布图里，每个任务的执行时间用条形图展示，按时间线排列。你一眼就能看出来：哪个任务像个「路障」——前面的任务等它完成才能开始，这就是串联瓶颈。

我的小技巧：瀑布图里找「最长的深色条」和「任务间空档最大的间隙」。前者是耗时大户，后者可能是配置阶段或依赖解析的隐藏问题。我曾经就靠这个发现了一个 Module 的 build.gradle 里有个蠢蠢的 allprojects { ... }，每次构建都重跑一堆无关配置。

很多团队上来就开干：「改并行编译」「加缓存」「用 API 替换实现」。结果呢？改了半天，构建速度反而更差了。为什么？因为没有对症下药。

举个例子。假设你的构建慢主要是因为配置阶段太长（比如每个子项目都 apply 了所有插件），你就算把 org.gradle.parallel=true 打开也没用——配置阶段是串行的，并行只影响任务执行。

所以诊断必须放在优化前面。而瀑布图就是最直观的诊断工具之一。它能让你看到：

我见过一个项目，团队花了两周优化 Kotlin 编译配置，结果发现 80% 时间浪费在 dexing 任务，根本跟 Kotlin 没关系。要是我没先做瀑布图分析，这两周也就白搭了。

注意：别跳步骤！我见过不少开发者直接拿 --profile 报告看一眼就瞎改。记住：瀑布图是诊断工具，不是终极答案。你需要结合项目结构、插件配置、运行环境综合判断。比如同一个任务慢，可能是代码问题，也可能是 cache 配置问题——瀑布图只能告诉你『哪里慢』，不会告诉你『为什么慢』。

Gradle 构建性能的诊断，说实话就像给项目做体检。你不能上来就开药，得先做 CT。瀑布图就是那个 CT。它能让你用科学的方式找到痛点，而不是凭感觉瞎猜。

后面我们会一步步深入，教你如何读懂瀑布图、如何用 Build Scan 做根因分析、如何针对每个阶段做精准优化。但今天这一章，我希望你记住一件事：诊断比优化更重要。没有诊断的优化，99% 是在浪费时间。