来自gradle文档:

让我们看一下基于jvm的项目的一个非常简单的构建脚本。

plugins {
    id 'java-library'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.hibernate:hibernate-core:3.6.7.Final'
    api 'com.google.guava:guava:23.0'
    testImplementation 'junit:junit:4.+'
}

实现 编译项目的生产源代码所需的依赖项，这些依赖项不是项目公开的API的一部分。例如，该项目使用Hibernate进行内部持久层实现。 api 编译项目生产源代码所需的依赖项，这些依赖项是项目公开的API的一部分。例如，该项目使用了Guava，并在方法签名中公开了带有Guava类的公共接口。

Gradle的compile关键字已弃用，转而使用api和实现关键字来配置依赖项。

使用api相当于使用已弃用的compile，所以如果你将所有compile替换为api，一切都将一如既往地工作。

要理解实现关键字，请考虑以下示例。

例子

假设您有一个名为MyLibrary的库，它在内部使用另一个名为InternalLibrary的库。就像这样:

// 'InternalLibrary' module
public class InternalLibrary {
    public static String giveMeAString(){
        return "hello";
    }
}

// 'MyLibrary' module
public class MyLibrary {
    public String myString(){
        return InternalLibrary.giveMeAString();
    }
}

假设构建MyLibrary。Gradle在依赖{}中使用API配置，如下所示:

dependencies {
    api(project(":InternalLibrary"))
}

你想在你的代码中使用MyLibrary，所以在你的应用构建中。Gradle你添加这个依赖:

dependencies {
    implementation(project(":MyLibrary"))
}

使用api配置(或已弃用的编译)，您可以在应用程序代码中访问InternalLibrary:

// Access 'MyLibrary' (granted)
MyLibrary myLib = new MyLibrary();
System.out.println(myLib.myString());

// Can ALSO access the internal library too (but you shouldn't)
System.out.println(InternalLibrary.giveMeAString());

通过这种方式，模块MyLibrary可能会“泄露”某些东西的内部实现。你不应该(不能)使用它，因为它不是你直接导入的。

为了防止这种情况，引入了实现配置。 现在如果你在MyLibrary中使用implementation而不是api:

dependencies {
    implementation(project(":InternalLibrary"))
}

你将不能在你的应用程序代码中调用internallibrary . givemeasstring()。

这种装箱策略允许Android Gradle插件知道，如果你在InternalLibrary中编辑一些东西，它必须只触发MyLibrary的重新编译，而不是重新编译你的整个应用程序，因为你没有访问InternalLibrary。

当你有很多嵌套依赖时，这种机制可以大大加快构建速度。(请观看最后链接的视频，以充分了解这一点)

结论

When you switch to the new Android Gradle plugin 3.X.X, you should replace all your compile with the implementation keyword *(1). Then try to compile and test your app. If everything it's ok leave the code as is, if you have problems you probably have something wrong with your dependencies or you used something that now is private and not more accessible. *Suggestion by Android Gradle plugin engineer Jerome Dochez (1)) If you are a library mantainer you should use api for every dependency which is needed for the public API of your library, while use implementation for test dependencies or dependencies which must not be used by the final users.

展示实现和api之间的区别的有用文章

参考文献 (为了节省时间，这是同一段视频)

谷歌I/O 2017 -如何加速Gradle构建(完整视频)

谷歌I/O 2017 -如何加速Gradle构建(新的Gradle插件3.0.0部分仅限)

谷歌I/O 2017 -如何加速Gradle构建(参考1*)

安卓系统文档

我喜欢把api依赖看作是公共的(其他模块可以看到)，而实现依赖则是私有的(只有这个模块可以看到)。

注意，与公共/私有变量和方法不同，api/实现依赖关系不是由运行时强制执行的。这只是一个构建时优化，它允许Gradle知道当某个依赖项更改API时需要重新编译哪些模块。

假设你有一个应用模块，它使用lib1作为库，lib1使用lib2作为库。就像这样:app -> lib1 -> lib2。

现在当在lib1中使用api lib2时，当在app模块中使用api lib1或实现lib1时，app可以看到lib2代码。

但是当在lib1中使用实现lib2时，应用程序无法看到lib2代码。

请参考链接:Android Studio依赖配置可在Android开发者的官方网站。

在dependencies块中，您可以使用几种不同的依赖项配置(如上面所示的实现)之一来声明一个库依赖项。每个依赖项配置都为Gradle提供了关于如何使用依赖项的不同说明。

实现

Gradle adds the dependency to the compile classpath and packages the dependency to the build output. However, when your module configures an implementation dependency, it's letting Gradle know that you do not want the module to leak the dependency to other modules at compile time. That is, the dependency is available to other modules only at runtime. Using this dependency configuration instead of api or compile (deprecated) can result in significant build time improvements because it reduces the number of modules that the build system needs to recompile. For example, if an implementation dependency changes its API, Gradle recompiles only that dependency and the modules that directly depend on it. Most app and test modules should use this configuration.

api

Gradle adds the dependency to the compile classpath and build output. When a module includes an api dependency, it's letting Gradle know that the module wants to transitively export that dependency to other modules, so that it's available to them at both runtime and compile time. This configuration behaves just like compile (which is now deprecated), but you should use it with caution and only with dependencies that you need to transitively export to other upstream consumers. That's because, if an api dependency changes its external API, Gradle recompiles all modules that have access to that dependency at compile time. So, having a large number of api dependencies can significantly increase build time. Unless you want to expose a dependency's API to a separate module, library modules should instead use implementation dependencies.

来自gradle文档:

让我们看一下基于jvm的项目的一个非常简单的构建脚本。

plugins {
    id 'java-library'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.hibernate:hibernate-core:3.6.7.Final'
    api 'com.google.guava:guava:23.0'
    testImplementation 'junit:junit:4.+'
}

实现 编译项目的生产源代码所需的依赖项，这些依赖项不是项目公开的API的一部分。例如，该项目使用Hibernate进行内部持久层实现。 api 编译项目生产源代码所需的依赖项，这些依赖项是项目公开的API的一部分。例如，该项目使用了Guava，并在方法签名中公开了带有Guava类的公共接口。