Android 组件化场景下多module依赖优雅实践方案，原理+实战+视频+源码

这篇博客探讨了Android组件化开发中多module依赖的管理，强调了在发布library时，如何正确处理依赖以避免打包失败或运行异常。通过分析不同类型的依赖声明（如api、implementation、compileOnly），指出compileOnly是最佳选择，同时提出了动态添加依赖的解决方案，以实现编译速度和局部修改的平衡。文章还提到了依赖传递的本质，并提供了自定义依赖规则的示例代码，以简化大型项目中的依赖管理。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

com.google.android.material

material

1.2.1

compile

我们发现，关于测试相关的依赖并没有被收录到pom文件中。这很合理，测试代码是针对该module的，并不需要提供给使用方，其依赖自然也不需要传递。我们知道，AGP中现在有4种声明依赖的方式（除去testXXX这种变种）

api
implementation
compileOnly
runtimeOnly

runtimeOnly对应以前的apk方式声明依赖，我们直接忽略掉，测试一下生成的pom文件。

dependencies {

api “org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version”

implementation ‘androidx.core:core-ktx:1.3.2’

compileOnly ‘androidx.appcompat:appcompat:1.2.0’

compileOnly ‘com.google.android.material:material:1.2.1’

testImplementation ‘junit:junit:4.+’

androidTestImplementation ‘androidx.test.ext:junit:1.1.2’

androidTestImplementation ‘androidx.test.espresso:espresso-core:3.3.0’

}

<?xml version="1.0" encoding="UTF-8"?>

<project xsi:schemaLocation=“http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd” xmlns=“http://maven.apache.org/POM/4.0.0”

xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>

4.0.0

leobert

1.0.0

aar

org.jetbrains.kotlin

kotlin-stdlib

1.4.21

compile

androidx.core

core-ktx

1.3.2

compile

使用compileOnly方式的并没有被收录到pom文件中，而api和implementation 方式，在pom文件中，都表现为采用compile的方案应用依赖。

ps:api和implementation在编码期的不同，不是我们讨论的重点，略。

回到我们开始的问题，将library发布时，按照约定，会将library本身的依赖收录到pom文件中。相应的，使用方使用仓库中的依赖项时，gradle会拉取其对应的pom文件，并添加依赖。

所以，如果我们直接使用一个编译好的静态包，而丢弃了他对应的pom文件时，可能会丢失依赖，出现打包失败或者运行异常。这意味着我们需要人为维护依赖传递

我们记住这些内容，并先放到一边。

下沉后，library会有多个层级

=========================================================