什么是Kotlin Gradle依赖关系中的“实现”?

我正在使用Android Studio 3.0 Preview来启动新的Kotlin项目。 当我尝试在build.gradle添加依赖项时,我看到了implementation范围,而不是通常的compile

 androidTestImplementation('com.android.support.test.espresso:espresso-core:2.2.2', { exclude group: 'com.android.support', module: 'support-annotations' }) implementation 'com.android.support:appcompat-v7:25.3.1' testImplementation 'junit:junit:4.12' 

还有androidTestImplementationtestImplementation作用域。

最后,我添加compile添加第三方依赖关系,它的工作原理。

 compile 'io.reactivex.rxjava2:rxandroid:2.0.1' 

所以我的问题是..

  • 什么是implementationandroidTestImplementationtestImplementation范围?
  • 它与compile ,测试compileandroidTestCompile有什么不同吗?
  • 我应该为我的Kotlin项目使用哪一个?

编辑:我的不好,这个问题不是Kotlin特定的。 这是新的Android Gradle插件配置 。

这不是特定于Kotlin,而是与Android的新的Gradle插件。

compileprovidedapk现在已被弃用。
使用implementationapi而不是compilecompileOnly而不是provided ,和runtimeOnly而不是apk

这是为了加速多模块构建。 给定模块A依赖于依次取决于模块C模块B ,模块C的改变也将触发模块A的重新编译。 如果A不直接使用C ,则在C更改时不需要重新编译A

implementation配置确保如此:如果在B指定implementation project(':C') ,则不能从A访问C ,并且避免构建不必要的模块。 在一个大型多模块项目中,这可以节省大量的时间。

请参阅迁移到新的Gradle插件以获取更多信息。

较早版本的gradle v3.0.0-alpha1曾经使用过compile但现在已经被弃用了。

为什么?

出现在compile配置中的依赖关系将被传递给库的消费者,因此会出现在消费者的编译类路径上。 另一方面,实现配置中的依赖关系不会暴露给消费者,因此不会泄漏到消费者的编译类路径中。

我们举个例子来理解这一点。 比方说,我创建了一个支持Image uploading到服务器的Library_Image_Upload 。 我在Library_Image_Upload中使用了Library_Network lib,它支持所有的网络操作。 我的图书馆只使用图片上传,并提供上传图片的便捷方式。 现在,当我在Library_Image_Upload项目中使用Library_Network lib时,每个使用这个lib的人都将具有Image Uploading功能以及其他所有可能使用的网络操作( 重要 )。 后来我认为Library_Network有一个比Library_Network更好的选择,并使用它。 因此, Library_Network公开的所有API函数都消失了, 而使用这些函数的任何人都破坏了构建

implementation带来几个好处:

  • 依赖关系不再泄漏到消费者的编译类路径中,所以你永远不会意外地依赖传递依赖
  • 更快的编译感谢减少类路径大小
  • 实现依赖关系发生变化时重新编译的次数减少:消费者不需要重新编译
  • 清除器发布:当与新的maven-publish插件一起使用时,Java库会生成POM文件,这些文件可以精确地区分在库中编译所需的内容以及在运行时使用库所需的内容(换句话说,不要混合编译图书馆本身所需要的东西,以及对图书馆编译所需的东西)。

要了解更多信息,请阅读Java库插件

所以我想你有三个问题的答案。

我希望它有帮助。