Gradle 依赖配置：实现 vs api vs runtimeonly vs compileonly

Question

无法理解 Android Studio 3.0 中引入的最新gradle 依赖配置，即 implementation、api、compileonly 和 runtimeonly。

Answer 1

请参考链接：Android Studio 3.0 New Gradle Configuration可在android开发者官方网站上找到。

根据上述链接中的描述：

• 实现： 当您的模块配置实现依赖项时，它会让 Gradle 知道该模块不想 在编译时将依赖项泄漏到其他模块。那就是 依赖项仅在运行时可用于其他模块。使用这个 依赖配置而不是 api 或 compile 可能会导致 显着的构建时间改进，因为它减少了 构建系统需要重新编译的项目。例如，如果一个 实现依赖改变了它的 API，Gradle 只重新编译 依赖和直接依赖它的模块。大多数应用程序和 测试模块应使用此配置。
• api: 当一个模块包含一个 api 依赖项时，它会让 Gradle 知道该模块想要传递地导出它 对其他模块的依赖，以便它们在两个模块中都可以使用 运行时间和编译时间。此配置的行为就像 compile （现在已弃用），您通常应该只在 库模块。那是因为，如果一个 api 依赖改变了它的 外部 API，Gradle 重新编译所有有权访问该 API 的模块 编译时的依赖。所以，拥有大量的api 依赖项可以显着增加构建时间。除非你愿意 将依赖项的 API 暴露给单独的测试模块、应用程序模块 应改为使用实现依赖项。
• compileOnly: Gradle 仅将依赖项添加到编译类路径中（它不会添加到构建输出中）。这很有用 当你创建一个 Android 库模块并且你需要 编译期间的依赖关系，但它是可选的存在于 运行。也就是说，如果你使用这个配置，那么你的库 模块必须包含一个运行时条件来检查是否 依赖是可用的，然后优雅地改变它的行为，所以它 如果没有提供它仍然可以运行。这有助于减小 最终的 APK 通过不添加临时依赖项而不是 危急。此配置的行为就像提供的一样（现在是 已弃用）。
• runtimeonly： Gradle 仅将依赖项添加到构建输出中，以便在运行时使用。也就是说，它没有添加到编译中 类路径。此配置的行为就像 apk（现在是 已弃用）。