在Gradle中实现和编译有什么区别? [英] What's the difference between implementation and compile in Gradle?

问题描述

在更新到Android Studio 3.0并创建了一个新项目之后，我注意到在build.gradle中，有一种新的方法来添加新的依赖项，而不是compile中是implementation，而不是testCompile中是testImplementation.

After updating to Android Studio 3.0 and creating a new project, I noticed that in build.gradle there is a new way to add new dependencies instead of compile there is implementation and instead of testCompile there is testImplementation.

示例:

 implementation 'com.android.support:appcompat-v7:25.0.0'
 testImplementation 'junit:junit:4.12'

代替

 compile 'com.android.support:appcompat-v7:25.0.0'
 testCompile 'junit:junit:4.12'

它们之间有什么区别，我应该使用什么?

What's the difference between them and what should I be using?

推荐答案

tl; dr

只需替换:

• compile和implementation(如果不需要传递性)或api(如果需要传递性)
• testCompile与testImplementation
• debugCompile与debugImplementation
• androidTestCompile与androidTestImplementation
• compileOnly仍然有效.在3.0中添加了它以替换提供的内容，而不进行编译. (provided在Gradle没有该用例的配置名称时引入，并以Maven提供的作用域命名.)

• compile with implementation (if you don't need transitivity) or api (if you need transitivity)
• testCompile with testImplementation
• debugCompile with debugImplementation
• androidTestCompile with androidTestImplementation
• compileOnly is still valid. It was added in 3.0 to replace provided and not compile. (provided introduced when Gradle didn't have a configuration name for that use-case and named it after Maven's provided scope.)

在Google IO17上宣布Google 这是Gradle 3.0带来的重大变化之一

It is one of the breaking changes coming with Gradle 3.0 that Google announced at IO17.

compile配置为现已弃用，应将其替换为implementation或api

The compile configuration is now deprecated and should be replaced by implementation or api

从 Gradle文档:

dependencies {
    api 'commons-httpclient:commons-httpclient:3.1'
    implementation 'org.apache.commons:commons-lang3:3.5'
}

在api配置中出现的依赖项将是 传递给图书馆的消费者，因此 出现在使用者的编译类路径上.

Dependencies appearing in the api configurations will be transitively exposed to consumers of the library, and as such will appear on the compile classpath of consumers.

依赖项将位于 另一方面，不要暴露给消费者，因此不要泄漏到 消费者的编译类路径.这有几个好处:

Dependencies found in the implementation configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumers' compile classpath. This comes with several benefits:

• 依赖性不再泄漏到使用者的编译类路径中，因此您永远不会意外地依赖于传递对象 依赖
• 由于减小了类路径的大小，编译速度更快
当实现依赖关系发生更改时，
• 无需重新编译:无需重新编译使用者
• 更清洁的发布:与新的maven-publish插件一起使用时，Java库生成的POM文件 准确区分需要针对哪些进行编译 库以及在运行时使用该库所需的内容(其他 的话，不要混用编译库本身所需的内容以及哪些内容 需要针对库进行编译).

• dependencies do not leak into the compile classpath of consumers anymore, so you will never accidentally depend on a transitive dependency
• faster compilation thanks to reduced classpath size
• less recompilations when implementation dependencies change: consumers would not need to be recompiled
• cleaner publishing: when used in conjunction with the new maven-publish plugin, Java libraries produce POM files that distinguish exactly between what is required to compile against the library and what is required to use the library at runtime (in other words, don't mix what is needed to compile the library itself and what is needed to compile against the library).

编译配置仍然存在，但不应使用，因为它不能提供api和implementation配置所提供的保证.

The compile configuration still exists, but should not be used as it will not offer the guarantees that the api and implementation configurations provide.

---

注意::如果您仅在应用程序模块中使用库(常见情况)，则不会有任何区别.
仅当您有一个包含彼此依赖的模块的复杂项目时，或者正在创建一个库时，您才会看到差异.

---

Note: if you are only using a library in your app module -the common case- you won't notice any difference.
you will only see the difference if you have a complex project with modules depending on each other, or you are creating a library.

这篇关于在Gradle中实现和编译有什么区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！