Android 组件化场景下多module依赖优雅实践方案，醍醐灌顶

• 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

B

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会有多个层级

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

例如图中：APP => A => B， 即APP依赖A，A依赖B，而A和B都是library

我们知道，对于B，并不会有什么说法，