opoojkk

Android依赖管理解析：从ext到 Version Catalog的演进

lxx
目次

在 Android 多模块项目中，依赖管理（Dependency Management）往往被低估。 最开始你可能只是写几个 implementation "xxx:xxx:1.0.0"，但随着模块数量增长、团队协作增加、版本升级频繁，依赖的统一管理会直接影响项目的可维护性与构建效率。

目前常见的几种依赖管理方式包括：

  1. 最普通的直接写依赖；
  2. ext 属性集中定义；
  3. 使用 buildSrc 代码模块；
  4. 使用 Gradle 7+ 的版本目录（Version Catalog）。

下面我们从示例、优势与不足的角度，依次剖析这些方案。

直接写依赖 #

最朴素的方式是把依赖写在每个模块的 build.gradle 中。

1
2
3
4
5
6

dependencies {
    implementation("androidx.core:core-ktx:1.10.1")
    implementation("com.squareup.retrofit2:retrofit:2.9.0")
    implementation("com.squareup.okhttp3:logging-interceptor:5.0.0-alpha.2")
    testImplementation("junit:junit:4.13.2")
}

优势

不足

这种方式适合 Demo 或临时项目，一旦模块数超过三个，就会让人后悔没早点集中管理。

使用 ext 属性集中管理 #

在根 build.gradle 中用 ext 定义变量：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

ext {
    versions = [
        coreKtx: "1.10.1",
        retrofit: "2.9.0",
        okhttpLogging: "5.0.0-alpha.2",
        junit: "4.13.2"
    ]

    libs = [
        coreKtx: "androidx.core:core-ktx:${versions.coreKtx}",
        retrofit: "com.squareup.retrofit2:retrofit:${versions.retrofit}",
        okhttpLogging: "com.squareup.okhttp3:logging-interceptor:${versions.okhttpLogging}",
        junit: "junit:junit:${versions.junit}"
    ]
}

在子模块中这样使用：

1
2
3
4

dependencies {
    implementation libs.coreKtx
    implementation libs.retrofit
}

优势

不足

ext 是一种“权宜之计”：比纯手写好一点，但距离真正的现代依赖管理还差几步。

使用 buildSrc 模块 #

在根目录下创建 buildSrc 目录，Gradle 会自动编译并加载其中代码。 可以在这里定义依赖与版本常量。

buildSrc/src/main/kotlin/Dependencies.kt：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

object Versions {
    const val coreKtx = "1.10.1"
    const val retrofit = "2.9.0"
    const val okhttpLogging = "5.0.0-alpha.2"
    const val junit = "4.13.2"
}

object Libs {
    const val coreKtx = "androidx.core:core-ktx:${Versions.coreKtx}"
    const val retrofit = "com.squareup.retrofit2:retrofit:${Versions.retrofit}"
    const val okhttpLogging = "com.squareup.okhttp3:logging-interceptor:${Versions.okhttpLogging}"
    const val junit = "junit:junit:${Versions.junit}"
}

在模块中使用：

1
2
3
4

dependencies {
    implementation(Libs.retrofit)
    implementation(Libs.okhttpLogging)
}

优势

不足

buildSrc 是“工程师式”的方案，强大、灵活，但稍有过度设计风险。

使用版本目录（Version Catalog） #

Gradle 7.0 起推荐使用的现代方案。 在 gradle/libs.versions.toml 中集中声明所有依赖。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

[versions]
coreKtx = "1.10.1"
retrofit = "2.9.0"
okhttpLogging = "5.0.0-alpha.2"
junit = "4.13.2"

[libraries]
androidx-core-ktx = { group = "androidx.core", name = "core-ktx", version.ref = "coreKtx" }
retrofit = { group = "com.squareup.retrofit2", name = "retrofit", version.ref = "retrofit" }
okhttp-logging-interceptor = { group = "com.squareup.okhttp3", name = "logging-interceptor", version.ref = "okhttpLogging" }
junit = { group = "junit", name = "junit", version.ref = "junit" }

[bundles]
network = ["retrofit", "okhttp-logging-interceptor"]

在模块中直接使用：

1
2
3
4
5

dependencies {
    implementation(libs.androidx.core.ktx)
    implementation(libs.retrofit)
    implementation(libs.okhttp.logging.interceptor)
}

优势

不足

Version Catalog 已成为新标准，兼顾类型安全、性能与可维护性。

对比与建议 #

方式学习成本版本集中度类型安全构建性能适用场景
直接写依赖最低★无优Demo、小项目
ext低★★弱良中小项目
buildSrc中★★★强一般中大型项目
Version Catalog中等★★★★★强最优大型、多团队项目

建议：

结语 #

依赖管理是 Android 工程化的地基之一。 当项目规模上升、团队扩大、构建频率增加，越早建立清晰、集中、可扩展的依赖管理体系，就越能避免未来的混乱。 选择哪种方式取决于项目规模与团队成熟度，但如果你打算长期维护一个 Android 应用，那就别犹豫——从 Version Catalog 开始。

标签：
Categories：