Gradle 使用技巧 (三) - dependencies 的类型与区别

前言

dependencies 对于 Android 开发人员来说，并不陌生， 它是用来配置当项目的依赖项，接收的是一个 DependencyHandler 的闭包。

dependencies 的类型

dependencies 的类型可以分为以下几种

• compile
  • testCompile
  • androidTestcompile
  • debugCompile
  • releaseCompile
• implementation
  • testImplementation
  • androidTestImplementation
  • debugImplementation
  • releaseImplementation
• provided
• api

就以上类型，针对仔细说明

compile

从依赖上讲，用 compile 修饰的配置会传递依赖，而大多数的依赖冲突都是由 compile 产生的，什么是传递依赖？
打个比方：我们现在有 libA，然后 libB 用 compile 依赖 libA，最后 libC 依赖 libB。那这个时候，libC 自然能够使用 libA 的内容，因为 libA 的内容跟随这个 libB 而传递到了 libC 中。如下图：

而且 compile 得越多，所产生的依赖树也就越长，也就越难控制。

从编译上讲，使用 compile 配置的依赖项，会跟随打包流程将源码打包到 apk 中。

testcompile 和 androidTestcompile

这两个依赖项配置和 compile 是差不多的，也会产生传递依赖，唯一不同的是，testcompile 和 androidTestcompile 不会参与源码打包，只会参与测试包的打包，并且只有在测试模式下启动才会生效，debug 和 release 包不生效。

debugCompile 和 releaseCompile

• debugCompile
  只在 buildType 为 debug 的时候参与打包，release 不参与打包，比方说我们的内存泄露检测工具-LeakCanary，其实我们也只是需要在 debug 模式下打包调试，而发布 release 版本就需要进行打包了，所以用 debugCompile 来进行配置
• releaseCompile
  releaseCompile 和 debugCompile 完全相反，只在 release 模式下参与打包，应用场景不是很多。

implementation

implementation 是 Gradle4.1(Android studio3.0)新增的依赖方式，implementation 和 compile 不同，该依赖方式不会产生传递依赖，implementation 有点像 provided 和、debugCompile 和 releaseCompile 的集合体。
来个具体场景，例如：有 libA 公共库，libB 通过 implementation 依赖 libB，然后 app 无论通过什么方式依赖 libB，lib1 的依赖都不会传递过来，必须要在 app 中重新依赖一次。如下图：

使用 implementation 有什么好处呢？

• 很大程度减少重复依赖的问题
• 在开源 lib 的时候尽量采用 implementation 的方式依赖一些 v4、v7 包

剩余的 implementation

和前面的 compile 一样，只是 implementation 不会产生传递依赖，就不一一阐述了。

provided

只参与编译，不参与打包。例如说有 libB 依赖了 libA，moduleC 又同时依赖了 libA 和 libB，那么 libB 就可以使用 provided 来依赖 libA。

api

api 是 Gradle4.1(Android studio3.0)新增的依赖方式,其作用于 compile 基本一致。

总结

以上是就是 dependencies 的类型讲解，对于使用 Gradle plugin 3.X.X 以上版本的 gradle，我们应该转而使用 implementation，减少 compile 的使用，避免依赖冲突的产生。如果我们有开放的 lib，那么更加应该使用 implementation 依赖一些 v4、v7 的包，尽量少给 lib 的使用者造成困扰。

最后

未完待续、敬请期待！
免为其难的关注一下公众号吧！！