gradle 新的依赖方式 implementation、api、compileOnly

最新推荐文章于 2025-03-26 15:23:48 发布
最新推荐文章于 2025-03-26 15:23:48 发布
阅读量10w+ 收藏 61
点赞数 16
分类专栏： Android 文章标签： gradle 依赖 Android Studio
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/wangliblog/article/details/81366095
版权

gradle升级之后，有了新的依赖方式，下面我来介绍一下他们的使用

先看看之前的
old
再看看现在的

区别和使用

implementation和api

implementation和api是取代之前的compile的，其中api和compile是一样的效果，implementation有所不同，通过implementation依赖的库只能自己库本身访问，举个例子，A依赖B，B依赖C，如果B依赖C是使用的implementation依赖，那么在A中是访问不到C中的方法的，如果需要访问，请使用api依赖

compile only

compile only和provided效果是一样的，只在编译的时候有效， 不参与打包

runtime only

runtimeOnly 和 apk效果一样，只在打包的时候有效，编译不参与

test implementation

testImplementation和testCompile效果一样，在单元测试和打包测试apk的时候有效

debug implementation

debugImplementation和debugCompile效果相同， 在debug模式下有效

release implementation

releaseImplementation和releaseCompile效果相同，只在release模式和打包release包情况下有效

大概就是这些了，需要更多请上车

Gradle sync failed: Received fatal alert: handshake_failure；gradle中api、implementation和compile的区别
ZJQ的博客
02-26 2178
链接: https://pan.baidu.com/s/1Veayh5dfsyrAirndBwF-vA 提取码: uubc 翻译下就是：gradle编译失败，寿宴严重警告，握手失败。 造成的原因肯能会很多，但是我的原因是由于gradle下载很慢造成的。 百度网盘有地址是gradle的，很多版本，一般4.4的...
Android Studio Gradle: Implementation vs API dependency
KKkeep的专栏
01-03 1703
升级到Android Studio 3.0 后有没有发现编译项目的速度提高了？为什么会这样呢？是因为Stuido 3.0 中支持了 Gradle plugin 3.0， Gradle plugin 3.0 在 dependencise 块中为我们带了一下新的API: compile 被api 所代替。 provided被compileOnly 代替 apk 被runtimeOnly代替 引入了新的i
【Android Gradle 插件】Android 依赖管理 ④ ( 常用依赖配置分析 | implementation 依赖作用 | api 依赖作用 | compileOnly 依赖作用 )
浪漫之圣
01-12 1900
api 依赖弊端 : 使用 api 依赖时要特别小心 , 由于这种 依赖会进行传递 , 如果修改了这个依赖库 , 沿途所有依赖与该库的项目模块 , 都需要重新编译 , 会极大增加编译构建时间 , 能不用就不用;由于依赖传递构建效率低 : compile 依赖 的 构建效率 会 非常低 , 构建时会 不停的检查依赖树 , 发现依赖传递后 , 还要 添加依赖的依赖;使用场景 : 应用中使用的 基础依赖库 , 如 : 公用模块 , 工具库 , 底层库等 , 每个项目都需要该依赖库 , 适合使用依赖传递;
gradle-api和implementation区别
最新发布
以爱护甲,爱满枫林。
03-26 612
是用于声明依赖项的两种不同的配置方式，特别是在使用 Android Gradle Plugin 或 Java 库项目时。它们的主要区别在于依赖项的可见性和传递性。，因为它有助于保持项目的清晰度和减少潜在的问题。只有当你确实需要将某个依赖公开给其他模块时，才应考虑使用。主要取决于你希望如何管理你的依赖项以及这些依赖项的使用范围。通常情况下，推荐尽可能使用。在 Gradle 构建系统中，
implementation、api、compileOnly区别详解
热门推荐
喻志强的博客
10-27 15万+
Android Studio3.x 中implementation、api、compileOnly区别详解以及对比2.x依赖的区别
Gradle 的implementation，api，compileOnly，compile 区别
wulong756273的博客
01-14 1663
compile依赖关系已被弃用，被implementation和api替代;provided被compile only替代;apk被runtime only替代;api：跟2.x版本的 compile完全相同。
Gradle中implementation、api、compileOnly区别详解
lixpjita39的专栏
03-04 4286
在gadle3.0之后，默认的依赖由之前的compile更改为implementation了。 如果我们依然使用compile的话会有如下提示 Configuration ‘compile’ is obsolete and has been replaced with ‘implementation’ and ‘api’. It will be removed at the end of 2018. For more information see: http://d.android.com/r/tools
gradle依赖implementation，api，compileOnly，compile及依赖管理
ezconn的博客
01-19 9013
新旧依赖对比 Android studio 版本更新至3.0时，连带着com.android.tools.build:gradle 插件工具也升级到了3.0.0，在插件3.0.0中使用了最新的Gralde 4.0 里程碑版本作为gradle 的编译版本，该版本gradle编译速度有所加速，更加欣喜的是，完全支持Java8。当然，对于Kotlin的支持，在这个版本也有所体现，Kotlin插件默认是安装的。依赖关键字也有所改变： Android Studio 3.X Andro
gradle 部分jar导入报错_弄懂Gradle依赖 Android依赖导入全攻略
weixin_33599503的博客
12-24 1282
原标题：弄懂Gradle依赖 Android依赖导入全攻略本文作者作者：大头呆链接：https://juejin.im/post/5acd6daaf265da238a30ca73本文由作者授权发布。在我们开发安卓项目的时候，不会所有的功能都自己去造轮子，经常要使用到各种的其他包，其中有谷歌给我们提供的各种support包，也有各种第三方的功能库，有时候我们自己也会将一些功能封装成包。这些包存在和导...
构建洞察：精通Gradle项目依赖传递性的配置艺术
2401_85761003的博客
07-15 1038
通过本文的详细步骤和代码示例，你应该能够掌握如何在Gradle中配置项目依赖的传递性。合理配置依赖传递性对于管理大型项目、避免依赖冲突和优化构建性能至关重要。依赖管理是项目构建中的一门艺术，也是一项科学。Gradle提供了丰富的工具和选项来帮助我们精确控制依赖传递性。希望本文能够帮助你在项目构建中游刃有余，无论是简单的依赖声明还是复杂的依赖优化，都能够运用Gradle的功能达到最佳效果。注意：本文中的代码示例为教学目的，实际应用中应根据具体需求和项目标准进行选择和实现。
Gradle系列——Gradle文件操作，Gradle依赖（基于Gradle文档7.5）day3-1
qq_51553982的博客
08-01 3758
通常一个项目会有很多的Jar包，我们希望把项目打包成一个WAR,ZIP或TAR包进行发布，这时我们就可以使用Zip，Tar，Jar，War和Ear任务来实现，不过它们的用法都一样，不同的地方只在修改。指定任务类型为Copy，使用from指定需要复制的目录或者文件，使用into指定拷贝的目标地址，同样我们可以使用include和exclude进行包含或排除。使用文件树可以直接获取指定目录下的树结构中的所有文件，使用include或exclude方法进行包含或排除。如下就依赖了junit5的依赖。...
gradle 的 implementation、api 和 compile
Gdeer 的专栏
10-20 4969
区别 在 android gradle 插件 3.0 之前，我们使用 compile 来依赖第三方库或 module。 在 3.0 后，废弃了 compile，使用 implementation 和 api 来代替。 api 等同于 compile，意思是：我会把你暴露给第三方。 implementation 意思是：我不会把你暴露给第三方。 比如有三个 module，app、lib1、lib2，...
一文详解 implementation api embed
bjxiaxueliang的CODING茶馆
08-10 2713
最近使用 Android Studio 从事项目开发时，发现对 implementation、api、embed 的用法了解的不是很清楚，这里准备一篇文章对其使用场景或者说是使用方式进行一个总结。
Android --- complieonly 和implement的区别
梁同学与Android
09-10 1493
‌implementation‌：与compileOnly不同，implementation依赖的库不仅参与编译，还参与打包。这意味着，当项目依赖了一个implementation的库时，这个库不仅在编译时可用，而且在运行时也是必须的。这意味着，如果一个项目依赖了某个compileOnly的库，那么在编译时这个库是必须的，以确保代码能够成功编译。然而，在打包时，这个库不会被包含在内，因此，如果其他模块或工程没有显式地添加这个库作为依赖，那么在运行时就会出现问题，因为运行时找不到这个库。
gradle中api、implementation和compile的区别
qq_29446447的博客
03-21 827
gradle中api、implementation和compile的区别 我们在gradle中引用第三方maven库时，一般通过下面的语句去引用: compile 'com.android.support:appcompat-v7:26.1.0' 然后sync project，就能成功引用对应的包到项目之中了，十分方便。除了使用compile关键字，使用implementation和api也能将...
Gradle 模块依赖中，使用 implementation 与 api 的区别
暗诺星刻的博客
05-05 4853
声明的依赖项表示该模块将向其依赖的其他模块公开此依赖项的 API。这意味着其他模块可以使用该依赖项提供的所有公共类和方法，以及该依赖项的传递依赖项提供的所有公共类和方法。声明的依赖项表示该模块将不向其依赖的其他模块公开此依赖项的 API。这意味着该依赖项只对该模块本身可见，并且不会被传递到依赖该模块的其他模块。换句话说**，如果想令本模块能传递性地获得依赖模块的依赖，那么应该在依赖模块的相应依赖中使用关键字。如果项目中有模块 A、B、C、D，且 A 依赖 B、B 依赖 C、C 依赖 D。
classpath、compileOnly、implementation、api、apply plugin
b1tb1t的博客
01-29 505
classpath、implementation、api、apply plugin
implementation和api的区别
u010227042的博客
04-27 712
关于implementation和api的区别，一共分为两个方面： 一、编译范围 关于这一部分，[参考官网]，说的很清楚： implementation： Gradle 会将依赖项添加到编译类路径，并将依赖项打包到构建输出。不过，当您的模块配置 implementation 依赖项时，会让 Gradle 了解您不希望该模块在编译时将该依赖项泄露给其他模块。也就是说，其他模块只有在运行时才能使用该依赖项。 使用此依赖项配置代替 api 或 compile（已弃用）可以显著缩短构建时间，因为这样可以减少
gradle间接依赖
03-19
### Gradle 中的间接依赖管理 在 Gradle 构建工具中，`indirect dependencies` 或者称为传递性依赖（transitive dependencies），是指项目中的某个模块所引入的库会自动将其自身的依赖也一并引入到项目的构建环境中。这种机制简化了依赖声明的工作量，但也可能导致版本冲突或其他复杂问题。 #### 1. 默认行为 Gradle 的 `DependencyHandler` 提供了一种默认支持传递性依赖的方式[^1]。当通过 `implementation`, `api`, `compileOnly`, 或其他配置来定义依赖项时，默认情况下这些依赖会被解析为其所有的传递性依赖。例如： ```groovy dependencies { implementation 'com.example.library:module-name:version' } ``` 上述代码不仅会将指定的模块作为直接依赖引入，还会尝试加载该模块所需的任何间接依赖。 --- #### 2. 解决版本冲突 如果多个依赖之间存在版本不一致的情况，可以利用 Gradle 自带的功能进行控制。以下是几种常见的方法： ##### （1）强制指定特定版本 可以通过 `resolutionStrategy` 来统一某些包的版本号。例如，在根级 `build.gradle` 文件中设置如下规则： ```groovy configurations.all { resolutionStrategy.eachDependency { DependencyResolveDetails details -> if (details.requested.group == 'org.apache.commons') { details.useVersion 'specific-version-here' } } } ``` 此策略适用于所有具有相同组名 (`group`) 的依赖项，并确保它们始终使用相同的版本[^3]。 --- ##### （2）排除不必要的间接依赖 有时为了减少潜在的风险或者优化性能，可以选择手动移除不需要的部分。语法结构如下所示： ```groovy dependencies { implementation('groupId:artifactId:version') { exclude group: 'unwantedGroup', module: 'unwantedModule' } } ``` 这样做的好处是可以避免因第三方库带来的冗余组件而引发兼容性隐患[^2]。 --- #### 3. 查看当前项目的实际依赖树 要清楚了解整个应用究竟包含了哪些级别的外部资源以及其间的关联关系，则可运行命令行指令查看完整的依赖图谱： ```bash ./gradlew :app:dependencies ``` 它将以分层形式展示每一个节点及其子集的信息，便于开发者定位具体位置上的差异之处。 --- #### 4. 使用新的插件增强功能 随着技术的发展，官方还推出了专门用于改善这方面体验的新特性——如 Plugin Portal 上提供的各种扩展方案之一：“dependency-lock”。启用之后能够记录下每次成功的编译过程中确切使用的各部分清单文件(`lockfile`)，从而实现更稳定的长期维护效果。 --- ### 总结 通过对以上几个方面的介绍可以看出，Gradle 不仅提供了强大的基础框架去自动化处理大部分场景下的间接依赖需求，同时也赋予使用者足够的灵活性来自定义特殊条件下的解决方案。合理运用这些手段可以帮助我们更好地掌控复杂的多模块工程项目架构。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值