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

问题描述

无法理解在 Android Studio 3.0 中引入的最新gradle依赖项配置，即实现，api，compileonly和only runtime.

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 New Gradle Configuration 可在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依赖项更改了 外部API，Gradle重新编译所有可以访问该模块的模块 编译时的依赖.因此，拥有大量的api 依赖关系可能会大大增加构建时间.除非你想要 将依赖项的API暴露给单独的测试模块，即应用程序模块 相反，应该使用实现依赖项.
• compileOnly::Gradle仅将依赖项添加到编译类路径中(不将其添加到构建输出中).这很有用 在创建Android库模块时，您需要 编译期间的依赖关系，但是出现在 运行.也就是说，如果您使用此配置，则您的库 模块必须包含运行时条件，以检查 依赖项可用，然后适当地更改其行为，以便它 如果未提供，仍可以运行.这有助于减小尺寸 最终的APK，方法是不添加非瞬态依赖项 批判的.此配置的行为与提供的行为相同(现在是 已弃用).
• 仅运行时: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屋！