Gradle 几种依赖方式的区别

Posted 小猪快跑22

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Gradle 几种依赖方式的区别相关的知识,希望对你有一定的参考价值。

一、implementation : 依赖项在编译时对模块可用,并且仅在运行时对模块的消费者可用。

什么意思呢?

假设 A 依赖 B,B 以 implementation 方式依赖 C,那么 C 在编译和运行时都对 B 模块可用,即编译和运行时模块 B 都可以调用模块 C 中的代码。但是,模块 A 就无法调用 C 的代码,会在编译时报错。

二、api : 依赖项在编译时对模块可用,并且在编译和运行时对模块的消费者都可用。

假设 A 依赖 B,B 以 api 方式依赖 C,那么 A 在编译和运行时都可调用 C 中的代码。

三、compileOnly : 依赖项仅在编译时对模块可用,并且在编译或运行时对模块的消费者不可用。

假设 A 依赖 B,B 依赖 C。

如果 B 对 C 使用 compileOnly 依赖,则 A 无法调用 C 的代码,且 C 的代码不会被打包到 APK 中,即在 B 中调用 C 的代码编译时不会报错,但是运行时,会报 Didn't find class 的错误。

四、runtimeOnly : 依赖项仅在运行时对模块及其消费者可用。

假设 A 依赖 B,B 依赖 C。

如果 B 对 C 使用 runtimeOnly 依赖,则 A、B 无法调用 C 的代码,但 C 的代码会被打包到 APK 中。这个一般用到组件化开发中配合路由的使用,不可以在编译时调用模块 C 中的代码,但是可用使用 ARouter 今天跳转或调用。

总结:

假设 A 依赖 B,B 依赖 C。

如果 B 对 C 使用 implementation 依赖,则 A 无法调用 C 的代码

如果 B 对 C 使用 api 依赖,则 A 可以调用 C 的代码

如果 B 对 C 使用 compileOnly 依赖,则 A 无法调用 C 的代码,且 C 的代码不会被打包到 APK 中

如果 B 对 C 使用 runtimeOnly 依赖,则 A、B 无法调用 C 的代码,但 C 的代码会被打包到 APK 中。

假设 A 依赖 B,B 依赖 C,还会有如下的问题。

以上是关于Gradle 几种依赖方式的区别的主要内容,如果未能解决你的问题,请参考以下文章

项目集成aar以及gradle依赖冲突解决方式

使用插件检查Gradle依赖更新

Gradle依赖树查看

Gradle 提速几种方式

Android Studio 中的Gradle依赖aar和jar包使用指南

Android Studio 中的Gradle依赖aar和jar包使用指南