2017-06-09 47 views
6

我正在使用Android Studio 3.0 Preview来启动新的Kotlin项目。当我尝试在build.gradle中添加依赖关系时,我看到了implementation范围,而不是通常的compile什么是Kotlin Gradle依赖关系中的“实现”?

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' 

所以我的问题是..

  • 什么是implementationandroidTestImplementation,并testImplementation范围是什么?
  • 它与compile,testCompileandroidTestCompile有什么不同吗?
  • 哪一个我应该用于我的Kotlin项目?

编辑: 我的不好,这个问题不是Kotlin特有的。这是新的Android Gradle Plugin configuration

回答

17

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

compileprovidedapk现在已被弃用。
使用implementationapi而不是compile,compileOnly而不是providedruntimeOnly而不是apk

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

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

查看Migrate to the new Gradle plugin了解更多信息。

1

较早版本的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_Magic_Image并使用它。因此,Library_Network公开的所有API函数都消失了,并且使用这些函数的任何人都破坏了构建

implementation附带了几个好处:

  • 依赖性不泄漏到消费者的编译类路径中了,所以你永远不会意外取决于传递依赖
  • 更快的编译由于减少了classpath中尺寸
  • 当实现依赖关系发生变化时,重新编译减少:消费者不需要重新编译
  • 清除器发布:当与新的maven-publish插件结合使用时,Java库p这些POM文件可以区分编译库所需的内容和运行时库所需的内容(换言之,不要混合编译库本身所需的内容和编译所需的内容图书馆)。

要了解更多阅读The Java Library Plugin

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

我希望它有帮助。