前言
近期导入了一个项目，因为种种原因始终是失败，各种引入错误，不是这个就是那个，归根到底还是对gradle相关知识不够了解，今天来整理一下。
升级3.x.x变化
Gradle近期变化
android studio版本升级到3.0.0已经有一段时间了，现在使用的是studio 3.1.2.那么(当然默认你的build:gradle:3.1.2，二者要保持一致)。升级到3.x.x之后版本，有啥变化呢？
- 支持java8。
- 支持kotlin,默认安装相关插件。
- gradle编译速度有所加速。
依赖变化
| 3.0.0之前 | 3.0.0之后 | 说明 |
|---|---|---|
| compile | implementation | 将该依赖隐藏在内部，而不对外部公开。比如：app依赖于moudle1，而moudle1 implementation Glide库,那么app如果直接引用moudle1，可以使用moudle1中采用implementation依赖的Glide库吗？答案是：不可以！(之前是可以的)，app需要自己依赖Glide才可以使用.这么做的好处是虽然使用起来复杂了但是做到降低偶合兴提高安全性。 |
| api | 完全等同于compile指令没区别 | |
| provided | compileOnly | 只在编译时有效，不会参与打包 ,可以避免包冲突 |
| apk | runtimeOnly | 只在生成apk的时候参与打包，编译时不会参与 |
| testCompile | testImplementation | testCompile 只在单元测试代码的编译以及最终打包测试apk时有效 |
| debugCompile | debugImplementation | debugCompile 只在debug模式的编译和最终的debug apk打包时有效 |
| releaseCompile | releaseImplementation | Release compile 仅仅针对Release 模式的编译和最终的Release apk打包 |
Project build.gradle
Project build.gradle
咱们一个一个解释其含义：
- buildscript:用来加载gradle脚本自身需要使用的资源,可以声明的资源包括依赖项、第三方插件、maven仓库地址等
- repositories表示代码仓库的下载来源
- jcente 是一个新的中央远程仓库，兼容maven中心仓库，而且性能更优.
- google 是google的代码托管仓库
- dependencies一般是执行Gradle需要的gradle工具。
- classpath 执行gradle需要的工具地址，一般版本号同studio版本保持一致
- allproject 是整个项目的配置，比如allproject 中的repositories和上面buildscript的区别就是：前者allproject是整个项目本身需要的依赖，后者是gradle脚本执行所需依赖（Gradle插件），分别是对应的maven仓库和插件依赖等
- task clear 运行gradle clean时，执行此处定义的task. 该任务继承自Delete，删除根目录中的build目录。
常见的远程依赖方式
方式一
implementation 'com.android.support.constraint:constraint-layout:1.1.2'
方式二
implementation group: 'com.android.support.constraint', name: 'constraint-layout', version: '1.1.2'
方式三
implementation('com.android.support.constraint:constraint-layout:1.1.2') {
//不同版本同时被依赖时，那么强制依赖这个版本的，默认false
force = true
//exclude可以设置不编译指定的模块，有三种写法:
exclude module: 'abc'
exclude group: 'bcd'
exclude group: 'abc', module: 'bcd'
//禁止依赖的传递，gradle自动添加子依赖项,默认为true.
transitive = true
}
当然我们这里的exclude 的‘abc’等内容是不存在的，只是给大家演示，由此也引出了exclude的一个作用，避免依赖包冲突。那么除了采用exclude这种方式，我们还有没有别的方法呢，答案当然是有了，那就是统一为所有依赖指定依赖包的版本，如下：
configurations.all {
resolutionStrategy.eachDependency { DependencyResolveDetails details ->
def requested = details.requested
if (requested.group == 'com.android.support') {
if (!requested.name.startsWith("multidex")) {
details.useVersion '28.0.0-rc01'
}
}
}
}
在 project 的 build.gradle 中添加如下的代码，该代码的意思是：在项目构建时，遍历所有依赖，然后 com.android.support 包下的依赖替换同一个版本。但此方法也有弊端：就是每次构建的时候，多了一个遍历过程，会加长构建时间。因此，推荐使用 exclude 关键字排除。
那我们如何判断是那几个library的文件冲突了呢?
首先studio会先报出该错误，在log日志中会有某个moudle的信息。然后我们需要一个命令：
./gradlew -q <模块名>:dependencies
如：gradlew -q app:dependencies 查看app这个module的依赖其他库的信息，看看有没有冲突。
该命令能打印出该模块所有的依赖树信息,然后我们根据具体log信息，采用exclud方式解决问题。
本地依赖
Jar包依赖
image
arr文件的依赖
- 首先先声明aar包存放的路径声明
repositories {
flatDir {
dirs 'libs' //此处声明存放路径为lib文件夹下
}
}
- 其次依赖引入
implementation(name: 'LibReplayDecode-release', ext: 'aar')
so文件的依赖
声明下so文件的存放路径即可
sourceSets {
main {
//配置so加载目录
jniLibs.srcDirs = ['libs']
}
}
当然也可以在main目录下新建jniLibs目录，这是so文件默认的放置目录，不过本人一般不习惯这样，还有需要注意：并不是将so文件直接放入lib文件夹下，而是需要建立对应的ABI目录下(Android 设备的CPU类型通常称为”ABIs”),也就是说不同的armeabi文件是为了专门针对不同Android手机下CPU架构的兼容，存放so库。如图：
image
其他
用过butterknife的同志一定对annotationProcessor不陌生吧,它是一个编译期注解的依赖。这种方式是只在编译的时候执行依赖的库，但是库最终不打包到apk中。结合编译期注解的作用，他是用来生成代码的，本身在运行时是不需要的，那么它与我们上面说的与compileOnly的区别是什么呢？
annotationProcessor作用是编译时生成代码，编译完真的就不需要了，compileOnly是有重复的库，为的是剃除只保留一个库，最终还是需要的。
