「Gradle Tips 系列」如何查看模块的所有依赖

前言

有时，我们需要查看某个模块所有的依赖（Dependencies），或者是在 CI 构建时，检测是否有依赖变更。

方法

方法一：./gradlew :app:dependencies

在项目根目录下，执行命令：

./gradlew :app:dependencies

注意：请将上述命令中的 app 替换成想查询依赖的那个模块名。

输出示例：

Configuration on demand is an incubating feature.
Type-safe project accessors is an incubating feature.
> Task :buildSrc:compileKotlin UP-TO-DATE
> Task :buildSrc:compileJava NO-SOURCE
> Task :buildSrc:compileGroovy NO-SOURCE
> Task :buildSrc:pluginDescriptors UP-TO-DATE
> Task :buildSrc:processResources NO-SOURCE
> Task :buildSrc:classes UP-TO-DATE
> Task :buildSrc:inspectClassesForKotlinIC UP-TO-DATE
> Task :buildSrc:jar UP-TO-DATE
> Task :buildSrc:assemble UP-TO-DATE
> Task :buildSrc:compileTestKotlin NO-SOURCE
> Task :buildSrc:pluginUnderTestMetadata UP-TO-DATE
> Task :buildSrc:compileTestJava NO-SOURCE
> Task :buildSrc:compileTestGroovy NO-SOURCE
> Task :buildSrc:processTestResources NO-SOURCE
> Task :buildSrc:testClasses UP-TO-DATE
> Task :buildSrc:test NO-SOURCE
> Task :buildSrc:validatePlugins UP-TO-DATE
> Task :buildSrc:check UP-TO-DATE
> Task :buildSrc:build UP-TO-DATE

> Task :app:dependencies

------------------------------------------------------------
Project ':app'
------------------------------------------------------------

_internal-unified-test-platform-android-device-provider-ddmlib - A configuration to resolve the Unified Test Platform dependencies.
\--- com.android.tools.utp:android-device-provider-ddmlib:30.1.2
     +--- com.android.tools:common:30.1.2
     |    +--- com.android.tools:annotations:30.1.2
     |    \--- com.google.guava:guava:30.1-jre
     |         +--- com.google.guava:failureaccess:1.0.1
     |         +--- com.google.guava:listenablefuture:9999.0-empty-to-avoid-conflict-with-guava
     |         +--- com.google.code.findbugs:jsr305:3.0.2
     |         +--- org.checkerframework:checker-qual:3.5.0
     |         +--- com.google.errorprone:error_prone_annotations:2.3.4
     |         \--- com.google.j2objc:j2objc-annotations:1.3
     +--- com.android.tools.ddms:ddmlib:30.1.2
     |    +--- com.android.tools:common:30.1.2 (*)
     |    +--- net.sf.kxml:kxml2:2.3.0
     |    \--- com.google.protobuf:protobuf-java:3.10.0
     +--- com.google.protobuf:protobuf-java:3.10.0
     +--- com.android.tools.utp:android-device-provider-ddmlib-proto:30.1.2
     |    \--- com.google.protobuf:protobuf-java:3.10.0
     +--- org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.8
     |    +--- org.jetbrains.kotlin:kotlin-stdlib:1.3.71
     |    |    +--- org.jetbrains.kotlin:kotlin-stdlib-common:1.3.71
     |    |    \--- org.jetbrains:annotations:13.0
     |    \--- org.jetbrains.kotlin:kotlin-stdlib-common:1.3.71
     \--- com.google.testing.platform:android-device-provider-local:0.0.8-alpha07
# 以下省略

方法二：./gradlew :app:androidDependencies「仅 Android」

这个方法仅对 Android 项目生效：

./gradlew :app:androidDependencies

输出示例：

Configuration on demand is an incubating feature.
Type-safe project accessors is an incubating feature.
> Task :buildSrc:compileKotlin UP-TO-DATE
> Task :buildSrc:compileJava NO-SOURCE
> Task :buildSrc:compileGroovy NO-SOURCE
> Task :buildSrc:pluginDescriptors UP-TO-DATE
> Task :buildSrc:processResources NO-SOURCE
> Task :buildSrc:classes UP-TO-DATE
> Task :buildSrc:inspectClassesForKotlinIC UP-TO-DATE
> Task :buildSrc:jar UP-TO-DATE
> Task :buildSrc:assemble UP-TO-DATE
> Task :buildSrc:compileTestKotlin NO-SOURCE
> Task :buildSrc:pluginUnderTestMetadata UP-TO-DATE
> Task :buildSrc:compileTestJava NO-SOURCE
> Task :buildSrc:compileTestGroovy NO-SOURCE
> Task :buildSrc:processTestResources NO-SOURCE
> Task :buildSrc:testClasses UP-TO-DATE
> Task :buildSrc:test NO-SOURCE
> Task :buildSrc:validatePlugins UP-TO-DATE
> Task :buildSrc:check UP-TO-DATE
> Task :buildSrc:build UP-TO-DATE

> Task :app:androidDependencies
debug
debugCompileClasspath - Dependencies for compilation
+--- /Users/lee/code/github/LibChecker/app/ohos/ohos-2.1.1.21.jar
+--- com.github.CymChad:BaseRecyclerViewAdapterHelper:3.0.7@aar
+--- androidx.databinding:databinding-adapters:4.2.2@aar
+--- androidx.databinding:databinding-runtime:4.2.2@aar
+--- androidx.databinding:viewbinding:7.1.2@aar
+--- :hidden-api (variant: debug)
+--- org.jetbrains.kotlin:kotlin-parcelize-runtime:1.6.20@jar
+--- androidx.preference:preference-ktx:1.2.0@aar
+--- androidx.preference:preference:1.2.0@aar
+--- androidx.fragment:fragment-ktx:1.4.1@aar
+--- androidx.activity:activity-ktx:1.4.0@aar
+--- com.github.zhaobozhen:LibChecker-Rules-Bundle:21.3@aar
+--- com.drakeet.about:about:2.5.0@aar
+--- dev.rikka.rikkax.material:material:1.6.6@aar
+--- com.google.android.material:material:1.5.0@aar
+--- androidx.viewpager2:viewpager2:1.1.0-alpha01@aar
+--- dev.rikka.rikkax.appcompat:appcompat:1.4.1@aar
+--- androidx.fragment:fragment:1.4.1@aar
+--- androidx.fragment:fragment:1.4.1@aar
+--- androidx.core:core-ktx:1.7.0@aar
+--- androidx.browser:browser:1.4.0@aar
+--- com.drakeet.multitype:multitype:4.3.0@aar
+--- androidx.recyclerview:recyclerview:1.2.1@aar
+--- androidx.recyclerview:recyclerview:1.2.1@aar
+--- androidx.activity:activity:1.4.0@aar
+--- androidx.coordinatorlayout:coordinatorlayout:1.1.0@aar
+--- androidx.drawerlayout:drawerlayout:1.1.1@aar
# 以下省略

笔者推荐在安卓项目中，优先使用第二种方法。

Q&A

Compile Classpath vs Runtime Classpath

注意到，在 ./gradlew :app:androidDependencies 输出中，出现了 debugCompileClasspath 和 debugRuntimeClasspath，前缀 debug 猜测是指编译类型，那它们的后缀含义上有什么区别呢？

以下面的例子来理解。
假设现在一个 Gradle 项目有一个模块 app，在它的 build.gradle 中声明了它对模块 B 的依赖。并且模块 B 实际上依赖了模块 C。那么：

• 模块 C 出现在模块 app 和模块 B 的 Runtime Classpath 中。因为运行时需要它。
• 仅模块 B 出现在模块 app 的 Compile Classpath 中，因为我们需要调用模块 B 的接口实现模块 app 的功能。

根据上述信息可以总结出：

模块名	模块 app	模块 B	模块 C
Compile Classpath	B	C	/
Runtime Classpath	B、C	C	/