api与implementation的区别

Posted 2023-05-16

参考技术A 一、从3.4版本的gradle开始，compile已经被api与implementation取代，官网也给出了三者之间的区别：

从官网介绍可以看出，implementation可以让module在编译时隐藏自己使用的依赖，但是在运行时这个依赖对所有模块是可见的。而api与compile一样，无法隐藏自己使用的依赖。
具体通过例子来看，下图为项目结构：

mylibrary3如下：

当mylibrary1 使用api依赖mylibrary3时，

在App中可以直接调用MyClass3类，也就是依赖可以传递。

当mylibrary1使用implemention依赖mylibrary3时，

在App中，无法直接调用mylibrary3

从上面的例子可以看出，在多module中，implementation确实可以起到隐藏依赖的作用，网上很多的文章都只讲到了这点，那么这样做的目的是什么呢？其实这并不是Google设计implemention与api的目的，因为官方文档中说这样设计的目的在于减少build的时间，那么implemention是如何减少build time的呢？

二、我们再新建一个module：mylibrary4，现在的项目结构如图：

那么现在的项目层级如下图所示：

为此我验证了两种依赖下项目的build time，每次重新编译前clean project，改变mylibrary4，然后rebuild project，再查看build time。

使用implemention的build time：

使用api的build time

三、现在在回过头来看一下依赖传递的问题，之前验证了使用implemention，app不能拿到MyClass3，这是在本地依赖的情况下，而现在的模块化开发多采用远程依赖的模式进行合作。那么如果采用maven远程依赖呢？
同样采用之前的例子，我们新建一个module ：mylibrary2

我们将其上传到我们的本地maven

然后我们再将mylibrary1上传到本地maven，然后在app中远程依赖mylibrary1

也就是app远程implementation mylibrary1，mylibrary1远程implemention mylibrary2，这时候app就可以直接拉到mylibrary2中的myClass2类（命名不规范，别学我）

而如果app本地implementation mylibrary1，mylibrary1远程implemention mylibrary2，这时候app则不能获取到mylibrary2中的myClass2类，依然起到了依赖隔离的作用。

由以上可以看到在全部远程依赖模式下，无论是api还是implemention都起不到依赖隔离的作用。不过，在远程依赖模式下，依赖的一个模块如果版本发生变化，implemention与api的构建速度谁快谁慢还需要进一步研究。

综上，在多层次模块化（大于等于三层module）开发时，如果都是本地依赖，implementation相比api，主要优势在于减少build time。如果只有两层module，api与implemention在build time上并无太大的差别。

参考资料：
1、 https://jeroenmols.com/blog/2017/06/14/androidstudio3/
2、 https://www.jianshu.com/p/dd932f951137

Java使用 Gradle 依赖配置compile，implementation和api的区别

这个主要看Java项目所使用的Gradle的版本。

Gradle 3.4 新增了Java-library插件，java-library插件使用了新的依赖配置implementation和api。旧的依赖配置compile被废弃。

Gradle 3.4 之前的版本

java插件

apply plugin: 'java'

添加依赖

dependencies {
  compile 'commons-httpclient:commons-httpclient:3.1'
  compile 'org.apache.commons:commons-lang3:3.5'
}

Gradle 3.4+

使用java-library插件替换java插件

apply plugin: 'java-library'

新的依赖配置：implementation和api

dependencies {
  api 'commons-httpclient:commons-httpclient:3.1'
  implementation 'org.apache.commons:commons-lang3:3.5'
}

api和implementation两种依赖的不同点在于：它们声明的依赖其他模块是否能使用。

api：当其他模块依赖于此模块时，此模块使用api声明的依赖包是可以被其他模块使用。

implementation：当其他模块依赖此模块时，此模块使用implementation声明的依赖包只限于模块内部使用，不允许其他模块使用。

api： 跟 2.x 版本的 compile完全相同

implementation：使用了该命令编译的依赖，它仅仅对当前的Module提供接口。例如我们当前项目结构如下

LibraryA 中引用了 LibraryC 的库，如果对 LibraryC 的依赖用的是 implementation 关键字。 如下：

dependencies {
    . . . . 
    implementation project(path：'：libraryC')
}

那么LibraryC 中的接口，仅仅只能给 LibraryA 使用，而我们的 App Module 是无法访问到 LibraryC 提供的接口的，也就是将该依赖隐藏在内部，而不对外部公开。这就是implementation关键字的作用。

最佳实践建议

在Google IO 相关话题的中提到了一个建议，就是依赖首先应该设置为implement的，如果没有错，那就用implement，如果有错，那么使用api指令，这样会使编译速度有所增快。

那为什么要这么做呢？

答案是： 1. 加快编译速度。2. 隐藏对外不必要的接口。

为什么能加快编译速度呢？

这对于大型项目含有多个Module模块的， 以上图为例，比如我们改动 LibraryC 接口的相关代码，这时候编译只需要单独编译LibraryA模块就行， 如果使用的是api或者旧时代的compile，由于App Module 也可以访问到 LibraryC,所以 App Module部分也需要重新编译。当然这是在全编的情况下。

版本依赖关键字详解(2.0与3.0所有关键字)

compile(api)
这种是我们最常用的方式，使用该方式依赖的库将会参与编译和打包。
当我们依赖一些第三方的库时，可能会遇到com.android.support冲突的问题，就是因为开发者使用的compile依赖的com.android.support包，而他所依赖的包与我们本地所依赖的com.android.support包版本不一样，所以就会报All com.android.support libraries must use the exact same version specification (mixing versions can lead to runtime crashes这个错误。

provided(compileOnly)
只在编译时有效，不会参与打包
可以在自己的module中使用该方式依赖一些比如com.android.support，gson这些使用者常用的库，避免冲突。

apk(runtimeOnly)
只在生成apk的时候参与打包，编译时不会参与，很少用。

testCompile(testImplementation)
testCompile 只在单元测试代码的编译以及最终打包测试apk时有效。

debugCompile(debugImplementation)
debugCompile 只在 debug 模式的编译和最终的 debug apk 打包时有效

releaseCompile(releaseImplementation)
Release compile仅仅针对 Release 模式的编译和最终的 Release apk 打包。

参考资料：

https://www.jianshu.com/p/6d807591b95b

以上是关于api与implementation的区别的主要内容，如果未能解决你的问题，请参考以下文章

Gradle中implementation和api的区别

Android compile、implementation和api的区别

gradle中api、implementation和compile的区别

gradle implementation runtimeOnly 和api 区别

Java中，接口继承接口时，用implements与extends有啥区别？

依赖方式implementation、api、compile only等的区别