编译配置已弃用，应由实现或api取代。

你可以在API和实现分离部分阅读文档。

简短的部分是

The key difference between the standard Java plugin and the Java Library plugin is that the latter introduces the concept of an API exposed to consumers. A library is a Java component meant to be consumed by other components. It's a very common use case in multi-project builds, but also as soon as you have external dependencies. The plugin exposes two configurations that can be used to declare dependencies: api and implementation. The api configuration should be used to declare dependencies which are exported by the library API, whereas the implementation configuration should be used to declare dependencies which are internal to the component.

进一步的解释请参考这张图片。

这个答案将演示项目中的实现、api和编译之间的区别。

---

假设我有一个有三个Gradle模块的项目:

app (Android应用程序) myandroidlibrary(一个Android库) myjavalibrary(一个Java库)

应用程序有myandroidlibrary作为依赖项。Myandroidlibrary有myjavlibrary作为依赖项。

myjavlibrary有一个MySecret类

public class MySecret {

    public static String getSecret() {
        return "Money";
    }
}

myandroidlibrary中有MyAndroidComponent类，用于操作MySecret类的值。

public class MyAndroidComponent {

    private static String component = MySecret.getSecret();

    public static String getComponent() {
        return "My component: " + component;
    }    
}

最后，app只对myandroidlibrary的值感兴趣

TextView tvHelloWorld = findViewById(R.id.tv_hello_world);
tvHelloWorld.setText(MyAndroidComponent.getComponent());

---

现在，让我们谈谈依赖关系……

应用需要消耗:myandroidlibrary，所以在应用构建中。Gradle使用实现。

(注意:你也可以使用api/compile。但请稍等片刻。)

dependencies {
    implementation project(':myandroidlibrary')      
}

你认为myandroidlibrary构建了什么?Gradle应该是什么样子?我们应该使用哪个作用域?

我们有三个选择:

dependencies {
    // Option #1
    implementation project(':myjavalibrary') 
    // Option #2
    compile project(':myjavalibrary')      
    // Option #3
    api project(':myjavalibrary')           
}

它们之间的区别是什么，我应该用什么?

编译或Api(选项#2或#3)

如果你使用的是编译器或者api。我们的Android应用现在可以访问myandroidcomponent依赖，这是一个MySecret类。

TextView textView = findViewById(R.id.text_view);
textView.setText(MyAndroidComponent.getComponent());
// You can access MySecret
textView.setText(MySecret.getSecret());

实现(选项#1)

如果您正在使用实现配置，MySecret将不会公开。

TextView textView = findViewById(R.id.text_view);
textView.setText(MyAndroidComponent.getComponent());
// You can NOT access MySecret
textView.setText(MySecret.getSecret()); // Won't even compile

---

那么，应该选择哪种配置呢?那要看你的要求了。

如果你想公开依赖关系，请使用api或compile。

如果你不想公开依赖关系(隐藏你的内部模块)，那么使用实现。

注意:

这只是Gradle配置的一个要点，参见表49.1。Java库插件-用于声明依赖关系的配置，以获得更详细的解释。

这个答案的示例项目可以在https://github.com/aldoKelvianto/ImplementationVsCompile上找到

其他答案解释了这种差异。

只要确保对于Kotlin DSL (build.gradle.kts)，函数应该有圆括号，它们的字符串参数应该用双引号括起来，而不是单引号:

Groovy (build.gradle) 实现“com.android.support: appcompat-v7:25.0.0” testImplementation“junit: junit: 4.12” 芬兰湾的科特林(build.gradle.kts) 实现(“com.android.support: appcompat-v7:25.0.0”) testImplementation(“junit: junit: 4.12”)

门外汉术语的简单区别是:

如果你正在处理一个接口或模块，它通过公开所声明的依赖关系的成员来为其他模块提供支持，你应该使用'api'。 如果你正在创建一个应用程序或模块，要在内部实现或使用声明的依赖项，请使用'implementation'。 'compile'与'api'工作方式相同，但是，如果你只是实现或使用任何库，'implementation'将更好地工作并节省资源。

阅读@aldok的回答以获得一个全面的示例。

implementation: mostly we use implementation configuration. It hides the internal dependency of the module to its consumer to avoid accidental use of any transitive dependency, hence faster compilation and less recompilation. api: must be used very carefully, since it leaks the to consumer’s compile classpath, hence misusing of api could lead to dependency pollution. compileOnly: when we don’t need any dependency at runtime, since compileOnly dependency won’t become the part of the final build. we will get a smaller build size. runtimeOnly: when we want to change or swap the behaviour of the library at runtime (in final build).

我已经创建了一个深入了解每个工作示例的帖子:源代码

https://medium.com/@gauraw.negi/how-gradle-dependency-configurations-work-underhood-e934906752e5

Gradle依赖项配置

Gradle 3.0引入了以下变化:

compile -> api api keyword is the same as deprecated compile which expose this dependency for all levels compile -> implementation Is preferable way because has some advantages. implementation expose dependency only for one level up at build time (the dependency is available at runtime). As a result you have a faster build(no need to recompile consumers which are higher then 1 level up) provided -> compileOnly This dependency is available only in compile time(the dependency is not available at runtime). This dependency can not be transitive and be .aar. It can be used with compile time annotation processor[About] and allows you to reduce a final output file compile -> annotationProcessor Very similar to compileOnly but also guarantees that transitive dependency are not visible for consumer apk -> runtimeOnly Dependency is not available in compile time but available at runtime.

[POM依赖类型]