其实这类文章博客网上一搜一大堆，但有些地方可能说的不太清楚（都一样的内容，抄袭太严重），这里只是做个精简的总结和一些其他地方没提到的点。
一、Android Studio 3.0开始使用了新的指令，原来的很多被弃用了，总的来说是为了加快构建编译速度。
下面是一个总结表格：
| Android Studio 2.X | Android Studio 3.X |
|---|---|
| apk | runtimeOnly |
| provided | compileOnly |
| compile | api |
| 没有对应 | implementation |
| debugCompile | debugImplementation |
| releaseCompile | releaseImplementation |
| androidTestCompile | androidTestImplementation |
需要解释的主要是implementation系列指令：
implementation：注意compile是和api对应的，效果相同。implementation的区别在于对外可见性，而且可以加快编译速度（原理在于减少不必要的重复编译过程）。举个例子如下：
A module 依赖 B module，B 依赖 C module。
Android Studio 2.X使用compile：
A compile B
B compile C
A module不仅可以引用B module，还可以引用C module的接口和类。
Android Studio 3.X使用implementation：
A implementation B
B implementation C
A module只可以引用B module，不可以引用C module。C 对 A 是不可见的！
简单来说，从Android Studio 3.X开始，依赖首先应该设置为implement，如果没有错，那就用implement，如果有错，那么使用api指令，这样会使编译速度有所增快。（就这样理解够了，很多文章又是画图又是长篇大论的，完全没有必要，本来就不是多么复杂的东西）。
二、provided（compileOnly）和compile（api）区别
按照几乎所有文章的说法：
provided只提供编译支持，但是不会写入apk。使用provide可以避免支持包版本冲突和重复打包导致安装包体积徒增。
但就我的实践来说（支持包V7,V4之类）：
1、不使用provided也不会导致支持包重复，依赖module编译出来的aar并不包含那些多个module（包括app module）重复使用的支持包。
2、如果依赖module使用的style中引用了支持包（V7,V4之类的）中的主题，那么，使用provided会报错（找不到主题资源）。如果只是引用支持包中的类和接口是可以使用provided的（但意义也不大，反正也不会重复）。
3、可能直接引用jar包的方式会重复把，但现在这种场景不多了。
可以看到在gradle3.0中，compile依赖关系已被弃用，被implementation和api替代，provided被compile only替代，apk被runtime only替代，剩下的看名字就知道了。
我们先来看看implementation和api的区别：
api：跟2.x版本的 compile完全相同
implementation：只能在内部使用此模块，比如我在一个libiary中使用implementation依赖了gson库，然后我的主项目依赖了libiary，那么，我的主项目就无法访问gson库中的方法。这样的好处是编译速度会加快，推荐使用implementation的方式去依赖，如果你需要提供给外部访问，那么就使用api依赖即可
还不熟悉2.x版本依赖的可以看看下面的说明，括号里对应的是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这个错误。
解决办法可以看这篇博客：com.android.support冲突的解决办法
provided（compileOnly）
只在编译时有效，不会参与打包
可以在自己的moudle中使用该方式依赖一些比如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.cnblogs.com/Im-Victor/p/10396343.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。