什么是dependencies闭包及其关键字详解

项目里的build.gradle导了很多包，在依赖dependencies里有很多不同的关键字，在此分别记录一下。

dependencies闭包的整体功能是指定当前项目所有依赖关系：本地依赖、库依赖及远程依赖。

本地依赖：可以对本地Jar包或者目录添加依赖关系

库依赖：可以对项目中的库模块添加依赖关系

远程依赖：可以对jcenter库上的开源项目添加依赖，标准的远程依赖格式是：域名：组织名：版本号

implementation fileTree(dir: 'libs', include: ['*.jar']) // 本地依赖

implementation 'com.android.support:appcompat-v7:26.1.0'//远程依赖

implementation 'com.android.support:appcompat-v7:26.1.0'//远程依赖，com.android.support是域名部分，appcompat-v7是组名称，26.1.0是版本号

implementation project(':hello') // 库依赖

testImplementation 'junit:junit:4.12' // 声明测试用列库

androidTestImplementation 'com.android.support.test:runner:1.0.1'

androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.1'

在gadle3.0之后，默认的依赖由之前的compile更改为implementation

对比一下：

Android Studio 2.X	Android Studio 3.X
apk	runtimeOnly
provided	compileOnly
compile	api
没有对应	implementation
debugCompile	debugImplementation
releaseCompile	releaseImplementation
androidTestCompile	androidTestImplementation

• debugImplementation（debugCompile） 只在debug模式的编译和最终的debug apk打包时有效。
• releaseImplementation（releaseCompile）仅仅针对release 模式的编译和最终的release apk打包。
• androidTestImplementation（androidTestCompile） 只在单元测试代码的编译以及最终打包测试apk时有效。
• freeddddffdfsdsfsImplementation（freeddddffdfsdsfsCompile）只有freeddddffdfsdsfs 模式下才有效

api （compile）

依赖向上传递

若A api B, B api C，C module对A module可见

对于各个渠道还可以单独依赖属于渠道特有的包，通过渠道名+api/compile指定，比如debugApi、releaseApi、testApi

implementation （新指令: 具备依赖可见性）

依赖不向上传递

若A implementation B, B implementation C，C module对A module不可见

若A implementation B, B api C，C module对A module可见

功能同api，区别仅仅是增加了依赖可见性

对于各个渠道还可以单独依赖属于渠道特有的包，通过渠道名+implementation指定，
比如debugImplementation、releaseImplementation、testImplementation。

compileOnly（provided）

只在编译时有效，不会参与打包

主要是为了方便程序编译通过的，不会打包到apk中，使用场景：android系统有这个API，但编译时需要引入才能构建通过，比如系统的APK依赖framework.jar、gson库等

若A implementation C，打包后apk（A + C）；

而A compileOnly C，打包后apk（A）；

该指令实质：A module假装依赖了C module通过欺骗编译器编译时检测以避免java.lang.ClassNotFoundException编译报错

使用情形

A implementation C，B implementation C，打包时A module生成aar（A + C），B module生成aar（B + C）

若改成A implementation C，B compileOnlyC，打包时A module生成aar（A + C），B module生成aar（B）

最终apk包（A + B + C），结果一致

虽然aar（B）不真实依赖C module，但B module确实用到了C module的api。

没有运行时错误的原因：aar（A + C）与aar（B）合并生成apk，B module运行时找到并调用aar（A + C）中的C module

runtimeOnly（apk）

只在生成apk的时候参与打包，编译时不会参与，很少用。不能在代码中直接调用依赖包的代码，否则会在编译时出错。