Android Gradle 插件Android 依赖管理 ④ ( 常用依赖配置分析 | implementation 依赖作用 | api 依赖作用 | compileOnly 依赖作用 )

Posted 2022-11-27 韩曙亮

文章目录

• 一、compile 依赖作用
• 二、implementation 依赖作用
• 三、api 依赖作用
• 四、compileOnly 依赖作用
• 五、annotationProcessor 依赖作用
• 六、lintChecks 依赖作用

在本篇博客中逐一分析以下依赖配置 :

• implementation
• api
• compileOnly
• runtimeOnly
• annotationProcessor
• lintChecks
• lintPublish
• apk ( 已废弃 )
• compile ( 已废弃 )
• provided ( 已废弃 )

Android 依赖参考文档 : https://developer.android.google.cn/studio/build/dependencies

一、compile 依赖作用

---

compile 依赖作用:

• 编译打包 : 为 自己的项目模块 添加依赖 , 该依赖会参与到 编译 构建过程 , 并且会 打包到 Apk 文件 中 ;
• 依赖传递 : 如果其它工程依赖本模块 , 则会 将依赖传递到其它工程 中 ;

示例 : A 项目 中使用 compile 依赖 B 依赖库 , 即 A 在 编译构建时需要 B 依赖库 , 最终 B 依赖库会打包到 A 项目的 Apk 文件中 ;

如果 C 项目 依赖 A 项目 , 由于 compile 配置会 传递依赖 , C 项目也需要将 B 依赖库导入到自己的依赖中 , 这就使得 构建效率 变低 ;

已废弃 : 该配置已经 废弃 , 使用 api 依赖 替代 ; 该依赖在没有废弃时使用频率最高 ;

由于依赖传递构建效率低 : compile 依赖 的 构建效率 会 非常低 , 构建时会 不停的检查依赖树 , 发现依赖传递后 , 还要 添加依赖的依赖 ;

二、implementation 依赖作用

---

implementation 依赖作用 :

• 编译打包 : 使用 implementation 添加的依赖 , 会 参与到 编译过程 , 并会 打包到 Apk 文件中 ;
• 不会传递 : 此类依赖 , 不会传递给其它模块 ;

示例 : A 项目 中使用 compile 依赖 B 依赖库 , 即 A 在 编译构建时需要 B 依赖库 , 最终 B 依赖库会打包到 A 项目的 Apk 文件中 ;

如果 C 项目 依赖 A 项目 , 由于 implementation 配置不会传递依赖 , C 项目是不知道 A 项目的 B 依赖库的 , 也无法访问 B 依赖库 ;

如果使用 compile 或者 api 添加依赖 , 则会有大量的依赖传递 , 构建效率 会 非常低 , 构建时会 不停的检查依赖树 , 发现依赖传递后 , 还要 添加依赖的依赖 ;因此 这两个 依赖方式 不常用 , implementation 依赖是当前最常见的依赖方式 ;

三、api 依赖作用

---

api 依赖作用 : 与 compile 依赖 作用类似 ,

• 编译打包 : 依赖会参与到 编译 构建过程 , 并且会 打包到 Apk 文件 中 ;
• 依赖传递 : 如果其它工程依赖本模块 , 则会 将依赖传递到其它工程 中 ;

使用场景 : 应用中使用的 基础依赖库 , 如 : 公用模块 , 工具库 , 底层库等 , 每个项目都需要该依赖库 , 适合使用依赖传递 ;

api 依赖弊端 : 使用 api 依赖时要特别小心 , 由于这种 依赖会进行传递 , 如果修改了这个依赖库 , 沿途所有依赖与该库的项目模块 , 都需要重新编译 , 会极大增加编译构建时间 , 能不用就不用 ;

推荐使用 implementation 依赖 代替 api 或 compile 依赖 ;

尽量不使用 api 或 compile 依赖 , 经常使用的是 implementation 依赖 ;

四、compileOnly 依赖作用

---

compileOnly 依赖作用 :

• 编译过程 : 依赖只会 添加到编译路径中 , 参与 编译 构建过程 , 但是不会 打包到 Apk 文件 中 ;
• 作用时机 : 该类型依赖 , 只在编译过程中做一些辅助类的工作 , 在工程中没有使用该依赖库 ;

compileOnly 依赖 的作用与 已废弃的 provided 依赖 类似 , 都是 将依赖库添加到编译路径中 ;

在 根目录的 build.gradle 顶层构建脚本 中的 buildScript 脚本块 中 , 使用了 classpath 依赖 , 该类型的依赖只应用在 buildScript 脚本块 , 其作用也是 将依赖库添加到编译路径中 , 与 compileOnly 依赖 和 provided 依赖 类似 ;

classpath 依赖 只用于 Gradle 运行时 为 Gradle 构建过程添加依赖 , compileOnly 依赖 和 provided 依赖 是 编译时 为工程添加的依赖 ;

五、annotationProcessor 依赖作用

---

annotationProcessor 依赖作用 : 该依赖用于设置 注解处理器 依赖 , 在 APT ( Annotation Processing Tool ) 注解处理工具 中使用该依赖 ;

可参考 Android APT 专栏 ;

注解处理器依赖处理流程 :

首先 , 在 程序中添加注解 ;

然后 , 在 Gradle 构建中配置注解处理器 , 自定义注解处理器执行一些编译时操作 ;

最后 , 运行构建过程中 , 在注解处理器中 , 处理一些编译时操作的内容 , 如 : ButterKnife , ARoute , DataBinding 等一般是用于根据注解生成一些 Java 源码 ;

注解处理器依赖示例 :

dependencies 
    annotationProcessor 'com.google.auto.service:auto-service:1.0-rc4'
    compileOnly 'com.google.auto.service:auto-service:1.0-rc3'

参考 【Android APT】注解处理器 ( 配置注解依赖、支持的注解类型、Java 版本支持 ) 博客 ;

六、lintChecks 依赖作用

---

lintChecks 依赖作用 : 在 Gradle 构建过程中 , 添加 lint 检查 ;