Gradle 依赖配置:实现 vs api vs runtimeonly vs compileonly [英] Gradle dependency configuration : implementation vs api vs runtimeonly vs compileonly

问题描述

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

Unable to understand the latest gradle dependency configurations which are introduced in Android Studio 3.0 i.e. implementation, api , compileonly and runtimeonly.

推荐答案

请参考链接:Android Studio 3.0 新 Gradle 配置可在 android 开发者官方网站上获得.

Please refer the link : Android Studio 3.0 New Gradle Configuration available at android developers official site.

基于以上链接中提到的描述:

Based on description mentioned in above link:

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

• Implementation: When your module configures an implementation dependency, it's letting Gradle know that the module does not want 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 can result in significant build time improvements because it reduces the amount of projects 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: 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), and you should typically use this only in library modules. 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 times. Unless you want to expose a dependency's API to a separate test module, app modules should instead use implementation dependencies.
• compileOnly: Gradle adds the dependency to the compilation classpath only (it is not added to the build output). This is useful when you're creating an Android library module and you need the dependency during compilation, but it's optional to have present at runtime. That is, if you use this configuration, then your library module must include a runtime condition to check whether the dependency is available, and then gracefully change its behavior so it can still function if it's not provided. This helps reduce the size of the final APK by not adding transient dependencies that aren't critical. This configuration behaves just like provided (which is now deprecated).
• runtimeonly: Gradle adds the dependency to the build output only, for use during runtime. That is, it is not added to the compile classpath. This configuration behaves just like apk (which is now deprecated).

这篇关于Gradle 依赖配置:实现 vs api vs runtimeonly vs compileonly的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！