Gradle 与网络瀑布图概述

先聊点实在的。Gradle 是什么？说白了，它就是个构建工具。你写 Java、Kotlin、Android 代码，最后总得打包、测试、部署吧？Gradle 就是干这个的。但比 Maven 和 Ant 灵活得多。我刚开始用 Gradle 那会儿，最大的感受就是——这玩意儿是真能折腾，也是真能救场。

为什么一个构建工具的要跟「网络瀑布图」扯上关系？嗯，这里得先卖个关子。你想想看，一个项目跑起来，背后有多少任务在排队、并行、等待？Gradle 的任务依赖图其实就是一个有向无环图（DAG）。瀑布图呢，就是把这张 DAG 按时间串起来，让你一眼看明白——哪一步慢、哪一步卡、哪一步其实可以跳过。

Gradle 到底是个什么东西

先看个最简单的例子。一个 Java 项目，要编译、打 jar、再跑单元测试。用 Gradle 怎么写？

tasks.register('compile') {
    doLast {
        println '编译中...'
    }
}
tasks.register('test') {
    dependsOn 'compile'
    doLast {
        println '测试中...'
    }
}
tasks.register('jar') {
    dependsOn 'test'
    doLast {
        println '打 jar 包...'
    }
}

你看，这三个任务之间用 dependsOn 串起来了。Gradle 会自动分析这些关系，然后决定先跑谁、后跑谁。我在项目中遇到过最典型的问题——有人把依赖写成了循环依赖，结果 Gradle 直接报错。嗯，当时找了好久才找到是哪个任务自己依赖自己。

Gradle 的三大核心部件：

• Project：一个项目对应一个 build.gradle，定义任务和配置
• Task：原子的工作单元（编译、测试、打包等）
• Dependency：任务之间或者模块之间的依赖关系

说白了，Gradle 就是一个精细的「任务调度器」。你告诉它做什么、做完之后才能做什么，它自己算出一条最优的执行路径。

瀑布图在构建中的意义

好，那瀑布图又是什么？我们把 Gradle 的执行过程录下来，每个任务都有开始时间、结束时间。把这些时间画成横向条状图，你就得到了一张瀑布图。为什么叫瀑布？因为任务从上往下流，时间从左往右走，看起来像水流一样。

我个人习惯在构建慢的时候，第一个动作就是生成瀑布图。别瞎猜哪里慢，数据会告诉你。比如下面的场景：

你看这个表格，一眼就能发现 :test 任务耗时 8 秒，占整个构建的 70%。那优化重点就非常明确了。我曾经遇到一个项目，构建要跑 20 分钟，瀑布图一看——有个静态代码分析任务跑了 12 分钟，而且它并不需要在每次构建都执行。后面改成增量扫描，构建时间直接降到 6 分钟。

任务依赖图与瀑布图的映射关系

这里得说清楚两个图的关系。

任务依赖图是静态的——它描述的是「谁先谁后」的约束关系。比如 test 依赖 classes，那么只有当 classes 跑完了，test 才能开始。

瀑布图是动态的——它记录的是实际执行时的时间线。即使两个任务理论上可以并行执行（没有依赖关系），但实际执行时可能因为资源竞争（比如 CPU、内存）导致其中一个等了一会儿才真正开跑。

映射关系很简单：

• 依赖图里的每个节点 → 瀑布图里的一条横条（任务执行区间）
• 依赖图里的边（有向箭头）→ 瀑布图里的水平对齐关系（上游任务结束，下游任务开始）
• 并行执行 → 瀑布图里多条横条在同一个时间轴上同时存在

举个例子。假设有三个任务：A、B、C。A 没有依赖，B 依赖 A，C 也依赖 A。依赖图就是一个 A 分叉到 B 和 C。那在瀑布图上，A 跑完后，B 和 C 会同时开始跑（如果资源足够）。如果 B 和 C 都跑得很慢，那瀑布图就会看到两条平行的长条。

一张图串起本章核心

下面这张图展示了整个章节的知识体系。你看它从 Gradle 构建系统出发，延伸出任务依赖图，再映射到瀑布图。瀑布图又反过来帮助我们分析构建性能，最终指导优化动作。

实际案例：从依赖图到瀑布图的转换

假设你有一个 Android 项目，部分 build.gradle 是这样的：

tasks.register('lint') {
    doLast { println 'lint检查' }
}
tasks.register('compileDebug') {
    dependsOn 'lint'
    doLast { println '编译debug' }
}
tasks.register('runUnitTests') {
    dependsOn 'compileDebug'
    doLast { println '跑单元测试' }
}
tasks.register('compileRelease') {
    dependsOn 'lint'
    doLast { println '编译release' }
}
tasks.register('assembleRelease') {
    dependsOn 'compileRelease', 'runUnitTests'
    doLast { println '打release包' }
}

手动画一下依赖图：lint 被两个编译任务依赖，编译release和单元测试并行执行（都依赖 compileDebug? 不，这里 runUnitTests 依赖 compileDebug，compileRelease 依赖 lint，它们之间没有依赖，所以可以并行）。但实际在瀑布图上，如果机器只有两个 CPU 核，它们可能会轮流占用资源，出现交错执行。通过瀑布图就能精确分析这些调度影响。

嗯，说到这，你应该已经明白了：Gradle 的依赖图是「骨架」，瀑布图是「血肉」。没有骨架，任务无法可靠执行；没有血肉，你看不到性能问题出在哪。

./gradlew build --profile

这一章的核心其实就三句话：Gradle 是个任务调度器，依赖图定义了任务之间的拓扑关系，瀑布图把这个拓扑关系加上了时间轴，让你能直观地看见哪里慢、哪里堵。后面的章节我们会一步步深入，从怎么生成瀑布图开始，讲到怎么用瀑布图诊断问题、怎么优化你的 Gradle 构建。