Android(Gradle) 库依赖版本统一管理

简述

依赖版本统一管理主要用于多模块的项目，表现为在一个地方定义使用到的依赖库的版本，在各个模块内引用该版本。主要好处一个是统一各个模块之间依赖的版本，降低发生依赖冲突的概率，一个是升级依赖库时只需要在一个地方修改，所有模块都生效，不用去各个模块内部手动修改。

一 Gradle全局变量

1. 在项目根目录定义一个xxx.gradle比如version.gradle,内容示例如下：

ext {
    glide_version = "4.15.1"
}

2. 然后在项目根目录的build.gradle内添加如下内容引用我们上面的gradle脚本

apply from: "version.gradle"

3. 完成上面工作后我们就能在各个模块内使用上面定义的全局变量，示例如下：

    implementation "com.github.bumptech.glide:glide:$glide_version"

这样我们更新依赖库版本时只需要更新version.gradle,所有模块的依赖都会统一更新，不需要一个个手动改。

不足：

1.不支持代码提示
2.不支持单击跳转
3.多模块开发时，不同模块相同的依赖需要复制粘贴。

二 buildSrc

gradle在编译项目的时候会检索项目根目录，如果发现项目根目录下有名为buildSrc的目录，会编译测试该目录下的代码并将其添加到脚本文件的classpath路径。也就是说你在buildSrc目录下定义的类和函数可以像调用JDK的API一样直接调用（当然有包结构的要导包）。更多关于buildSrc的说明可以查看gradle文档。我们这里只讲下依赖管理的代码示例：

1. 在项目根目录新建buildSrc/src/main/java,然后gradle同步一下AndroidStudio就能正确识别buildSrc。
2. 根据需要创建包结构和类，buildSrc支持java和kotlin。比如创建Versions.java内容如下：

public class Versions {
    public static final String testVersion = "4.10.0";
}

或Libs.java内容如下：

public class Libs {
    public static final String okhttp_interceptor = "com.squareup.okhttp3:logging-interceptor:4.9.3";
}

3. 然后在需要的模块内使用

    implementation("com.squareup.okhttp3:okhttp:${Versions.testVersion}")
    implementation Libs.okhttp_interceptor

如果定义了包结构比如com.test，那就要在使用的gradle文件内导包，示例如下：

import com.test.Versions

buildSrc貌似主要是用来管理自定义插件的，用于依赖版本管理相对于上面的方式一支持了代码提示和单击跳转，不足是buildSrc发生更改会导致所有的缓存失效，需要重新build整个项目，比较浪费时间。

三 Gradle version catalog(推荐)

version catalog是在Gradle 7.0 引入，Gradle 7.4 标记为稳定特性的一种依赖统一管理方法，也是目前gradle和Android官方推荐的方式。因为在Gradle 7.4才标记为稳定特性，所以Gradle 7.4 之前需要在项目的settings.gradle中增加以下代码开启version catalog。

enableFeaturePreview("VERSION_CATALOGS")

version catalog有两种使用方式DSL和配置文件(libs.versions.toml)，根据谷歌工作人员的说法(来源)，在一些比如代码提示，依赖升级提示等方面IDE只会支持配置文件方式，DSL方式也能正常生效，但是得不到IDE方面的相关支持，我们下面只讲配置文件方式的用法，DSL方式可以看下参考文档里面的Gradle 文档。

1. 创建配置文件

在项目根目录的gradle目录下创建libs.versions.toml文件，即目录结构为project_root/gradle/libs.versions.toml 。示例内容如下：

[versions]
core-ktx = { prefer = "1.10.1" }
appcompat = "1.6.1"
androidGradlePlugin = "8.0.2"

[libraries]
androidx-core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "core-ktx" }
androidx-appcompat = { group = "androidx.appcompat", name = "appcompat", version.ref = "appcompat" }


[bundles]
androidx = ["androidx-core-ktx", "androidx-appcompat"]

[plugins]
android-application = { id = "com.android.application", version.ref = "androidGradlePlugin" }

上面的配置文件主要有三块内容，[versions]主要是定义插件和普通依赖的版本，支持版本约束。[libraries]主要是定义普通依赖。[bundles]主要是定义依赖组合。[plugins]主要是定义插件。

2. 使用配置文件内容

基于我们上面定义的配置文件
普通依赖库使用

    //module build.gralde
    implementation libs.androidx.core.ktx
    implementation 'androidx.appcompat:appcompat:1.6.1' //只是方便理解，不是说要和这个库一起使用

插件(plugin)使用

//project build.gradle
plugins {
    alias libs.plugins.android.application apply false
    id 'com.android.library' version '8.0.2' apply false  //只是方便理解，无意义
}

//module build.gradle
plugins {
    alias libs.plugins.android.application
    id 'org.jetbrains.kotlin.android'   //只是方便理解，无意义
}

如果使用kotlin,并且gradle版本低于8.1那需要在使用插件的地方增加一个注解来压制报错 issue #22797，代码示例如下

@Suppress("DSL_SCOPE_VIOLATION")
plugins {
    alias(libs.plugins.android.library)
    alias(libs.plugins.kotlin)
}

打包(bundle)使用
bundle主要是用于将一些常常一起出现的依赖打包一起，这样一句话就能导入很多依赖，不用一个一个的添加。下面两段代码实现的效果是一样的。
使用bundle

    implementation libs.bundles.androidx

和不使用bundle

    implementation libs.androidx.core.ktx
    implementation libs.androidx.appcompat

3. 其他说明

AndroidStudio可能会在一些gradle文件上提示some editor tools may not work as expected. 这是因为AS IDE对version catalog的IDE支持还不够完善，但是仅限于代码提示等编辑器工具，不影响version catalog的实际效果，可以从这里看AS对version catalog的已知缺陷。截止目前为止AS对version catalogs的支持还不是很完善，所以如果项目本身就有依赖管理的不用迁移到version catalogs，如果是新项目或者原来没有依赖管理的可以考虑使用version catalogs，毕竟相比原来的管理方法还是有一点进步的。而且这是官方受支持的，未来会越来越完善。

参考文档

Android 文档
Gradle 文档