![Gradle：利用 [bundles] 消除冗余的依赖声明](/upload/dT9asdvH-8s81XIdaHVgUSiLs4C2Nn316O1iThnZN_8.webp?id=019c847e-50c1-71eb-ab60-636bcb1c2e51)
Gradle：利用 [bundles] 消除冗余的依赖声明
在大型 Android 项目中，有些依赖库往往是“全家桶”出现的。比如： 网络请求：Retrofit + OkHttp + GSON 转换器 + 日志拦截器。 Jetpack Compose：Compose UI + Material 3 + Tooling + Activity Compose。
Gradle：告别 ext 与 buildscript：老项目平滑迁移到 libs.versions.toml 全记录
接手一个几年历史的老项目，打开 build.gradle，映入眼帘的往往是臃肿的 buildscript 块、散落各处的 ext { ... } 变量，以及各个子模块里相互打架的版本号。 如果你想让项目焕然一新，接入 Gradle 官方推荐的 Version Catalog (TOML) 是必经之路
Gradle：深入理解Version Catalog、libs.versions.toml、alias 与 apply false
升级一个 Gradle 插件或者库的版本，你需要在十几个 build.gradle 文件里疯狂搜索、替换，稍有不慎就会因为版本不一致导致编译失败。为了解决这个问题，Gradle 经历了从 ext 闭包管理到 buildSrc 的演进，最终在 Gradle 7.0+ 拿出了目前的终极方案：Versio
Gradle: Plugins 引入与 Classpath 引入：到底有啥区别？
在配置 Android 或 Java 项目时，你一定见过两种引入插件的方式：一种是在 plugins {} 块里写 id，另一种是在 buildscript {} 里写 classpath。 很多同学会觉得：“能跑就行，管它什么区别？”但当项目变大、构建变慢或者依赖冲突时，搞不清楚这两者的逻辑就会让
