📚 课程目录第4章时间线阶段详解

第4章时间线阶段详解

咱们拿到一张 Gradle 构建的瀑布图，第一反应往往是——“这么多条条框框，到底在看什么？”

其实没那么复杂。你只需要抓住三个核心阶段：配置阶段、依赖解析阶段、任务执行阶段。这三段就是 Gradle 构建的骨架。搞懂了它们，瀑布图就成了一本翻开的账本，每一笔花费都清清楚楚。

我先说说我的经历。最早我在分析一个微服务项目构建慢的问题时，看着瀑布图里一大片空白时间，完全摸不着头脑。后来才发现，那是依赖解析阶段在狂拉远程仓库。嗯，当时如果早点看懂这三个阶段，至少能省半天排查时间。

  核心概念：Gradle 构建过程严格按「配置 → 依赖解析 → 任务执行」的顺序推进，但依赖解析和任务执行可以部分重叠（并行下载 + 执行）。瀑布图的 X 轴就是时间线，每个阶段会对应一组不同颜色的条形。

配置阶段，说白了就是 Gradle 读取你的 build.gradle（或 .kts）文件，生成一个任务图谱（Task Graph）。它不执行任何任务逻辑，只是“搭架子”。

干了什么：解析脚本、应用插件、声明依赖仓库与坐标、注册任务。
瀑布图表现：通常显示为一小段深蓝色条形，位于整个时间线的起始。如果配置阶段特别长，说明你的构建脚本里有什么耗时的操作（比如执行了外部命令、读取大文件等）。
常见坑：我曾见过有人把远程下载逻辑写在配置阶段——每次运行构建都下载一次，导致配置时间高达几十秒。这完全违反了 Gradle 的设计原则。

建议：配置阶段应该只做声明性操作。凡是需要 IO 或计算的，请移到任务执行阶段。

这个阶段 Gradle 开始下载依赖。它会根据 dependencies 块里的声明，去你配置的仓库（Maven Central、jcenter、自定义仓库等）拉取 JAR 包。

干了什么：解析依赖坐标、下载远程构件、缓存到本地 ~/.gradle/caches。
瀑布图表现：紫红色条形，通常在配置阶段结束后立即出现。如果网络慢或仓库多，这个条会拉得很长。而且注意看——它可能和任务执行阶段有重叠，因为 Gradle 在解析完一部分依赖后就会开始执行任务，不必等全部下载完。
我踩过的坑：曾有一个项目配置了 6 个仓库，每次构建都去轮询，网络延时叠加起来多花了 30 秒。后来改成只保留一个主仓库加一个阿里云镜像，依赖解析时间直接砍半。

注意：如果依赖解析阶段出现大量“retrying”或“timeout”信息，检查仓库地址是否可访问，或者本地代理是否配置正确。我曾经因为公司内网代理没设好，构建卡了整整一小时。

这是真正干活的阶段。Gradle 会按任务依赖关系，顺序或并行执行各个任务（编译、测试、打包等）。

  关键观察：如果任务执行阶段里某个任务条特别突出（比如 test 占了 80% 的时间），那基本就是瓶颈所在。我通常用它来定位到底是编译慢还是单测慢。

阶段	主要工作	瀑布图颜色	常见耗时代价
配置阶段	解析脚本，构建任务图	深蓝（#3498db）	脚本中有 IO 或计算
依赖解析阶段	下载远程依赖	紫红（#9b59b6）	网络延迟、仓库过多
任务执行阶段	编译、测试、打包等	绿色（#2ecc71）	任务未并行、测试效率低

拿到瀑布图，我一般先扫一眼条形颜色：哪个阶段颜色最长、最亮，就盯着那个阶段去找原因。比如紫色很长，那大概率是依赖下载慢；绿色段宽，那任务本身需要优化。

当然，三个阶段不是完全孤立的。依赖解析和任务执行有可能重叠，但配置阶段一定是排头的。记住这个顺序，你就能像读故事一样读懂每一行瀑布图。

实战技巧：在 build.gradle 顶部添加 gradle.beforeSettings { ... } 来监听配置阶段耗时。我习惯搭配 --profile 参数生成 HTML 报告，比单纯看瀑布图更直观。

现在你对这三个阶段应该心里有数了。下次打开瀑布图，别被满屏的条形吓到——按颜色把时间线拆分，哪里需要优化一目了然。

第4章 时间线阶段详解