前言

统一依赖管理有很多好处，尤其是在组件化时，对多个module处理依赖比较方便，解决重复导包及包的版本不同等问题。不过统一依赖有很多方法，各有优缺点，可以选择适合自己的方式去使用。目前有以下几种方式：

  1. groovy ext扩展函数(也有称之为:”循环优化”)
  2. kotlin+buildSrc
  3. composing builds
  4. catalog

  5. 自定义插件+includeBuild

    ext 扩展

    这种方式可能是大家最开始或者说是比较常见的一种依赖配置方式。比较老的一种方式，缺点比较多。

    优点

  6. 后续添加依赖不需要改动build.gradle,直接在config.gradle；

  7. 精简了build.gradle的长度；

    缺点

  8. 不支持代码提醒；

  9. 不支持点击跳转；

  10. 多moudle 开发时，不同module的依赖需要ctrl+c/v 导致开发的效率降低；

    参考

    代码示例

    buildSrc + kotlin

    当运行 Gradle 时会检查项目中是否存在一个名为 buildSrc 的目录。然后 Gradle 会自动编译并测试这段代码，并将其放入构建脚本的类路径中, 对于多项目构建，只能有一个 buildSrc 目录，该目录必须位于根项目目录中, buildSrc 是 Gradle 项目根目录下的一个目录，它可以包含我们的构建逻辑，与脚本插件相比，buildSrc 应该是首选，因为它更易于维护、重构和测试代码。详情可以参考gradle官方文档。

    优点

  11. 但这种方式支持IDE,输入代码会有提示，会自动完成，所以非常推荐使用这种方式来管理项目中的依赖包。

  12. 支持 AndroidStudio 单击跳转。
  13. buildSrc是Android默认插件，全局只有这一个地方可以修改。

    缺点

    buildSrc 是对全局的所有 module 的配置依赖更新会重新构建整个项目，项目越大，重新构建的时间就越长，造成不必要的时间浪费。

    参考

    官方的配置信息
    项目使用示例
    什么？项目里gradle代码超过200行了！你可能需要 Kotlin+buildSrc Plugin

    composing builds

    看了很多博客，感觉这个composing builds和includeBuild是同一种方式。这种方式和buildSrc非常相识，只是需要自定义插件。除了buildSrc的优点都有，还解决了buildSrc的缺点。
    摘自 Gradle 文档：复合构建只是包含其他构建的构建. 在许多方面，复合构建类似于 Gradle 多项目构建，不同之处在于，它包括完整的 builds ，而不是包含单个 projects
  • 组合通常独立开发的构建，例如，在应用程序使用的库中尝试错误修复时
  • 将大型的多项目构建分解为更小，更孤立的块，可以根据需要独立或一起工作

注意：使用 groove 在 gradle7.2 版本无法再实现跳转，如果想实现跳转，需要使用 kotlin 去写依赖（kst），这样就可以继续实现跳转。不过build.gradle里需要使用kotlin来编写，kst 的优点是使用kotlin语言，可读性行好。缺点是性能要慢一些。

参考

详细配置
【奇技淫巧】除了 buildSrc 还能这样统一配置依赖版本？巧用 includeBuild
Android Gradle Composing builds 管理三方依赖

Catalog

相对上面几种方式，比较新的一种方式。注意，Catalog仍然是一个孵化中的特性，如需使用，需要在settings.gradle中添加以下内容：

enableFeaturePreview(‘VERSION_CATALOGS’)

从命名上也可以看出，Version Catalog其实就是一个版本的目录,我们可以从目录中选出我们需要的依赖使用，我们可以通过如下方式使用Catalog中声明的依赖：

dependencies { implementation(libs.retrofit) implementation(libs.groovy.core) }

在这种情况下，libs是一个目录，retrofit表示该目录中可用的依赖项。 与直接在构建脚本中声明依赖项相比，Version Catalog具有许多优点：