项目里的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的时候参与打包，编译时不会参与，很少用。不能在代码中直接调用依赖包的代码，否则会在编译时出错。
