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，还会有如下的问题。