承接上一篇《错误处理架构：统一异常层设计》，上一篇处理了运行时的错误，这一篇处理构建期的耗时。对很多团队来说，一次完整构建 8 分钟、增量构建 2 分钟这件事带来的痛苦是持续的——每天改几行代码就要等两分钟，一个需求下来能浪费掉一两个小时。结论先行：构建优化只有两条路——减少「需要构建的东西」（增量、配置缓存、缓存命中）和让「必须构建的东西并行起来」（并行执行、能力声明、任务编排）。前者收益通常更大且更稳定，后者收益上限高但要求开发者主动配合声明依赖。绝大多数项目的正确起点是先做前者。一、先量：构建时间花在哪优化之前必须知道时间分布。Android 构建的可观测入口有两个层级。层级一：Gradle 自己的报告。# 输出配置阶段与执行阶段的耗时 ./gradlew assembleDebug --profile # 生成 HTML 报告，路径在 build/reports/profile/--profile的报告会列出每个任务的耗时、是否命中缓存（FROM-CACHE/UP-TO-DATE）、以及串行还是并行。层级二：Build Scan（更实用）。在settings.gradle开启gradleEnterprise { buildScan { publishAlways() } }后构建数据