gradle新的依赖方式你真的了解吗?

在 gradle3.0之前,gradle 依赖项目配置有 compile,apk,provided三种方式

  1. compile:指定编译时依赖项。Gradle 将此配置的依赖项添加到类路径和应用的 APK。这是默认配置。

  2. apk: 指定 Gradle 需要将其与应用的 APK 一起打包的仅运行时依赖项。您可以将此配置与 JAR 二进制依赖项一起使用,而不能与其他库模块依赖项或 AAR 二进制依赖项一起使用。

  3. provided:指定 Gradle 不与应用的 APK 一起打包的编译时依赖项。如果运行时无需此依赖项,这将有助于缩减 APK 的大小。您可以将此配置与 JAR 二进制依赖项一起使用,而不能与其他库模块依赖项或 AAR 二进制依赖项一起使用。

20171130203447062.png

从上面截图可以看到,在AS 的 project structure的添加 dependency 界面,你会看到每个 dependency 后面可以致命 scope, 因为我的 gradle 是3.0版本,compile,apk,provided 这三种依赖方式已经 deprecated. 取而代之的implementation, api, compileOnly, and runtimeOnly几种方式

那新旧之间有什么不同呢?

gradle3.0之前的 build.gradle 文件是这样的,依赖项目默认都是通过compile

20171130210701739.png

而gradle3.0后,module 下的build.gradle 项目依赖可以是这样子

20171130210345047.png

gradle3.0或者以上版本 3.0之前(deprecated) 说明 作用
implementation compile gradle升级到3.0之后,新增了 implementation, 而compile 方式被标记为了deprecated, compile 在3.0之后仍然可以使用,但是 gradle 官方说会在 gradle 后续的某次重要升级后变为不可用. 如果我们使用了implementation方式来依赖项目的话,那么这个库就在编译时期,只对当前的module可见,对其他的module不可见,但是在运行使其是可见的,这种方式的好处是可以显著减少 build项目的时间,因为假如该依赖库有接口或者代码变动,那么Gradle只会去重新编译和它有直接依赖关系的module,也就是该库不存在传递性
api compile 同上 使用api方式来依赖项目或者库的话,那么这个库,在编译时期和运行时期都可以对其他module可见
compileOnly provided 3.0之后版本,使用compileOnly来替代provided 假如在项目中,对某些库你只是想要在编译时期使用,而在运行时期并不需要这个库,你可以使用这种方式!
runtimeOnly apk 3.0之后,使用 runtinmeOnly来替代apk Gradle 在运行时会将该库添加到 build 的 output 中去

也许到此刻,有些同学还是处于懵懵懂懂的状态,下面让我以几个例子来详细说明他们的作用

20171130220450373.png

在我的项目里共有 app,common,factory,lang这4个module
他们的依赖关系是 [app->factory->common->lang]

那么此时如果我的 common这个 module中使用 implementation 来引入 gson 库,那么在 factory 和 app 这两个 module中,你是无法是用Gson 的,编译时期是无法找到这个类的,implementation 不具有传递性,如果使用 api 或者 compile 来引入 gson 库,便可以在 app 和 factory 中直接使用 gson 库,而不必再次引入.


什么时候用到 compileOnly呢?

我们在开发的时候,如果想要查看 PhoneWindow ,WindowManager 这些 framework 层的代码,可以将 sdk 中的 platforms中的 android.jar 放入 lib 文件夹中,然后add as Library,此时会在 build.gradle 文件中生成一句
implementation files('libs/android.jar')
我们可以将 implementation替换为 compileOnly,此时就可以查看 PhoneWindow 这些 framework 层的源码了

以上如有错误,请多指教!

你可能感兴趣的:(gradle新的依赖方式你真的了解吗?)