Gradle3-依赖详解

不多说直接上一张表格

gradle3 gradle2 说明
implementation compile 依赖项在编译时对模块可用,并且仅在运行时对模块的消费者可用。 对于大型多项目构建,使用 implementation 而不是 api/compile 可以显著缩短构建时间,因为它可以减少构建系统需要重新编译的项目量。 大多数应用和测试模块都应使用此配置。
api compile 依赖项在编译时对模块可用,并且在编译时和运行时还对模块的消费者可用。 此配置的行为类似于 compile(现在已弃用),一般情况下,您应当仅在库模块中使用它。 应用模块应使用 implementation,除非您想要将其 API 公开给单独的测试模块。
compileOnly provided 依赖项仅在编译时对模块可用,并且在编译或运行时对其消费者不可用。 此配置的行为类似于 provided(现在已弃用)
runtimeOnly apk 依赖项仅在运行时对模块及其消费者可用。 此配置的行为类似于 apk(现在已弃用)

第一列是gradle3新Api,第二列为gradle重的api,并且将要在Gradle为5的软件版本重移除。
看到这里,你也许会疑惑。如何区分implementation,api以及compile呢?

如何区分implementation,api以及compile

首先apicompile是同一个东西,那么只需要分辨他们和implementation的区别。一张图来说明

Gradle3-依赖详解_第1张图片
image.png

假如我们的工程是如上所示的依赖关系,如果使用Compile方式进行依赖,修改红色模块,需要编译所有洋红色的模块。相比之下使用Implentation方式进行依赖,只需要编译两个青色的模块。从而大幅度提高编译速度。

理想是丰满的,实际开发中,项目依赖混乱,完全使用Implentation非常困难,尤其是一些公共模块,基本每一模块都会用到。那么只能使用api模块进行依赖。当修改使用api进行依赖的模块的时候,任何依赖他的模块都可以引用他的方法。举个例子:

Gradle3-依赖详解_第2张图片
image.png

第二行第二个使用api的方式依赖红色模块。任何洋红色模块都可以引用红色模块的方法,换言之当红色模块修改的时候,所有洋红色模块都会重新编译。所以api只适用经常不改动的模块,方便其他模块进行引用。
在我们的项目中,抽离compile依赖是很头疼的一件事,在接下来的文档中会提到。
所以:

  • Implentation 通常项目之间的依赖,这个要求我们项目之间要做好解耦。
  • Api 不经常改动的项目,可以使用他进行依赖。

分辨运行时依赖和编译时依赖

在讲compileOnlyruntimeOnly之前,先弄清什么是么是运行时依赖和编译时依赖。
顾名思义,从名称上理解他的意思其实是正确的。

  • 编译时候(coding)的依赖就是编译时依赖
  • 运行时候(building)的依赖就是运行时依赖
    (此时停顿一下,好好理解)
    但是实际项目中错综复杂:还是使用一张图来说明:
Gradle3-依赖详解_第3张图片
image.png

思考一下,D模块那三个版本号是多少呢?
答案是根本编译不过去。
但是这张图理解这个概念已经够了,首先,针对B模块,编译时依赖是gson2.6,support升级22,okhttp是3;其他也是这么理解。
如果单独运行C模块是运行不过去的,你需要需要指定这三个以来的版本号,解决版本依赖冲突。这就是运行时依赖。有很多种方式解决这种重复依赖的方法,比如force或者exclude

compileOnlyruntimeOnly

  • compileOnly 指的是在coding时候进行依赖,实际打包时候,不打入aar,同时他也不报错。
    compileOnly经常会用于子模块,比如A模块要提供对B模块的支持,同时又不能引入B模块(主工程已经引用了),就会用到它。举个例子:假如项目中用到了Retrofit,我们都知道Retrofit对Rx是有支持的,但是他并不包含Rx包。在编译Retrofit代码时候,就要用到compileOnly了,编译时引用Rx,实际不打如包中。注意错误使用可能会找不到类。
  • runtimeOnly 和compileOnly相反,运行时候才会打包进去,编译时候不提供。
    compileOnlyruntimeOnly都提供对子模块的使用,也就是说,在透传依赖方面,他们和api是一致的。

变体依赖

Gradle3 中提供了变体依赖,他是基于风味维度的。比如xxxImplentation,我们项目中没有用到,详情了解,移步gradle官网,简单说一下把: 比如项目工程有一个模块AdModule,名为广告模块,在北美市场接入FB,印度市场接入猎豹,国内接百度。那么就可以定义风味维度为FBLiebaoBaidu。在主工程进行依赖的时候,如果打印度包,只需更改依赖为LieBaoImplentation,那么AdModule就是猎豹广告的风味维度,其他毅然。

如果你注意过,在使用buildType时候也可以这样指定,比如 debugImplentation
之前我们控制渠道信息,都是放到build.gradle的mainfestholder中,然后子项目进行读取,if else切换。风味依赖倒是给了一个很好的解决方案,个人维护起来比较麻烦,这东西主项目和子项目维度匹配起来是个难题。。。适合大项目。

你可能感兴趣的:(Gradle3-依赖详解)