谷歌官方Android项目审计：50分背后的构建陷阱

周三下午，一位开发者在GitHub上运行了一条命令，结果让Google的招牌项目亮起了红灯。

这个开发者叫I，他写了一个叫Gradle Lighthouse的开源插件，专门给Android项目的构建系统做体检。为了验证工具是否靠谱，他选了Android开发者的"圣经"——Google官方的Now in Android（NIA）项目。这个项目用Jetpack Compose、高度模块化架构、Kotlin Multiplatform，是现代Android开发的标杆。

安装插件只需在根目录build.gradle.kts加一行代码，运行./gradlew lighthouseAudit。引擎扫完全部模块图，跑了20多项架构检查。I原本期待满分，结果屏幕弹出：50/100，"At Risk"（风险等级）。

Google的官方样板工程，怎么会在构建健康度上不及格？答案藏在Lighthouse的严格规则里。以下是它从NIA代码中挖出的三个关键问题。

第一，Configuration Cache被亲手堵死。

Lighthouse标记了一项严重错误：根build.gradle.kts使用了allprojects{}或subprojects{}代码块。这迫使Gradle无论只编译哪个模块，都必须预先配置全部模块。更糟的是，它直接阻断了向Configuration Cache的迁移，也封死了Gradle 9.x即将推出的Isolated Projects功能。

修复方案是用convention plugins替代。根据Lighthouse的数据，这能让配置时间压缩50%到90%。

第二，存在"黑暗模块"。

Lighthouse扫描"Dark Modules"——图谱中存在但完全零测试文件的模块。NIA的根模块nowinandroid被标记为未经测试的风险点。I在报告中写道，大型企业项目里这类模块会不断累积，最终让安全重构变成不可能任务。

第三，版本目录的隐性浪费。

NIA用了现代的libs.versions.toml，但Lighthouse发现两处卫生问题：103条库定义中，有多条在图谱中实际未被使用，升级依赖时制造噪音；同时存在9个可打包成bundle的机会被错过。

这场审计的讽刺在于：NIA作为"最佳实践"展示，恰恰暴露了现代Android构建的普遍困境。模块化带来灵活性，也让依赖关系变成黑箱。开发者每天面对5分钟构建时间，却难以定位是循环依赖、Configuration Cache失效，还是KAPT在空转。

I的动机很直接——Web开发者有Google Lighthouse秒审网站健康，Android开发者也需要同样的工具。他的插件零配置、开源，试图把Gradle构建扫描的考古工作变成一键诊断。

50分不是NIA的耻辱，而是整个Android生态的镜子。当Google自己的样板工程都在allprojects{}上栽跟头，普通团队的构建系统里还埋着多少雷？