为什么选择网络瀑布图诊断构建归纳输出

说实话，刚开始做 Gradle 性能优化时，我习惯盯着控制台日志看。“Task A 耗时 3 秒，Task B 耗时 5 秒”，然后自己画时间线。但你想想看，一个中型项目几十个 Task，依赖关系像蜘蛛网，日志根本理不清。后来我试了 --profile 报告，嗯，表格确实详细，可我还是看不出“某个依赖是在等网络还是等在 CPU 排队”。直到我接触到网络瀑布图——就是浏览器开发者工具里那种——才恍然大悟：构建过程中的网络请求，完全可以用同样的方式可视化。

为什么非要选瀑布图？因为构建瓶颈里，网络 I/O 是最隐蔽的。本地执行慢你还能用 profiler 定位，可远程仓库下载、插件元数据拉取、HTTP 超时重试，这些在传统日志里只显示一行“Downloaded xxx (10s)”，你根本不知道这 10 秒里到底发生了什么——是带宽不够？是 DNS 解析慢？还是服务器端卡住了？瀑布图能把这些“黑盒”拆开。

网络瀑布图的独特优势

我个人习惯先把瀑布图的独特能力列出来，这样你就能直观理解为什么它不可替代：

• 可视化依赖顺序——哪些请求是串行的？哪些是并发的？瀑布图一条时间轴全看清。
• 识别慢请求——一眼找到那根“最长的柱子”。我在项目中遇到过，一个 Maven 仓库的 artifact 下载花了 40 秒，而其他都是 200 毫秒，这种“异常柱子”在表格里容易被淹没。
• 发现并行问题——理想情况下，互不依赖的请求应该并排走。如果大量请求被挤成一条线，说明存在资源竞争或配置问题。
• 区分网络耗时 vs 本地处理耗时——请求发起与响应首字节之间的间隔是网络；响应体下载时间受带宽影响；后面紧跟着的本地解压、校验则是 CPU 工作。瀑布图帮我们把这几个阶段分开了。
• 定位超时与重试——一个请求突然中断，然后隔了几秒重新发起，瀑布图上能看到“断层+新请求”，而日志里可能只记了最终成功。

常见构建诊断方法对比

我经常用这张表跟团队掰扯为什么必须引入瀑布图：

诊断方法	能做什么	不能做什么
--profile	Task 耗时统计、依赖图	无法分辨网络/本地耗时；看不到请求内部阶段
--scan	详细报告、性能建议	缺少网络请求的时间线视图；依赖外部服务
原始日志 -d	最详细的信息	信息爆炸，难以归纳；对新手极不友好
网络瀑布图	请求级时间线、并行度、各阶段分解	需要额外工具或拦截代理

你看出来了吧？瀑布图补齐了其他工具的短板。尤其是当你想回答“构建到底花了多少时间在网络等待上”时，只有瀑布图能给你一个准确的数字。

如何归纳输出诊断结果

光有瀑布图还不够，你得把它转化成可执行的结论。我建议按下面几步来“归纳输出”：

1. 收集原始数据——使用 curl 结合时间戳、或者专门的代理工具（如 mitmproxy）录制构建期间的 HTTP(S) 请求。当然，最简单的方式是让 Gradle 启用详细的 HTTP 日志并输出为 HAR 格式（如果插件支持）。
2. 标记关键请求——在瀑布图上圈出耗时超过 2 秒、或者重试次数超过 1 次的请求。用一个 红色标记 高亮它们。
3. 计算耗时占比——统计所有网络请求的总耗时与构建总时长的比例。我曾经在一个微服务项目里发现，80% 的构建时间花在下载依赖上，而本地编译只占 15%。这个数据直接推动了 CI 镜像预缓存改造。
4. 输出结构化报告——不要只扔一张图。应该列出：最慢的 5 个请求、它们的目标 URL、耗时分解（DNS / 连接 / TLS / 首字节 / 下载）、以及并行度。

举个例子，我用一个简单的表格来呈现归纳结果：

请求 URL                        | 总耗时 | DNS | 连接 | TLS | 首字节 | 下载 | 重试
https://repo.maven.org/xxx.jar  | 12.3s | 0.2s| 0.1s | 0.3s| 4.5s | 7.2s | 0
https://jcenter.bintray.com/yyy | 8.1s  | 0.1s| 0.1s | 0.2s| 6.0s | 1.7s | 1
...                            | ...   | ... | ...  | ... | ...  | ...  | ...

看到“首字节”那列了吗？4.5 秒和 6.0 秒，这说明服务器响应慢，不是带宽问题。而“下载”列比较长则是带宽瓶颈。这些细节，只有瀑布图才能分解出来。

避坑指南：瀑布图诊断容易踩的坑

我曾经在一个大项目里，看到瀑布图上密密麻麻全是请求，心想“完了，网络瓶颈太严重了”。结果仔细一查，发现是 Artifactory 的认证插件没配好，每次请求都带了额外的重定向——瀑布图上显示为一条请求后面跟了另一条同样 URL 的请求，总耗时翻倍。嗯，这里要注意：瀑布图上的“请求”不一定是真正的 HTTP 请求，也可能是 Gradle 内部的重试或重定向。

另一个我常犯的错误是忽略“空闲间隔”。瀑布图里两个请求之间的空白区域，很可能是在等待本地 I/O 或 Task 依赖解锁，而不是真的空闲。所以分析时，要结合 --profile 的 Task 时间线一起看。

知识体系：为什么选择瀑布图的归纳逻辑

下面这张图总结了从“原始构建”到“瓶颈定位”的核心流程：

你看，从原始构建开始，经过捕获、生成、分解、识别，最后归纳输出——这一套流程才完整。很多人只做到第三步“画图”，然后就停止了，结果发现优化无从下手。记住，归纳输出才是瀑布图诊断的终点。

我的个人经验总结

讲了这么多，我想把最核心的几点再强调一下：

• 不要只看总耗时：一个 8 秒的请求，可能 80% 的时间花在等待服务器（首字节延迟），这时候加带宽没用。瀑布图把各个阶段拆开，你才能对症下药。
• 关注并发度：我遇到过最大的一次优化，就是把并发请求数从 3 调到 8，构建时间从 12 分钟降到 4 分钟。瀑布图上本来挤在一起的请求突然“散开”了，效果立竿见影。
• 重试是信号：如果一个请求出现两次或三次，说明网络不稳定或仓库负载高。我在项目中用瀑布图发现某个镜像仓库的 TLS 证书配置有问题，导致每三次请求就有一次超时——这些东西日志根本看不出来。
• 归纳输出要可执行：别只提交一张图。把最慢的请求、推荐的动作（比如“换仓库 DNS”、“启用连接复用”）列成清单，团队成员才能直接干活。