之前一直用maven，最近换成了gradle,工欲善其事必先利其器，让我们开始学习吧。
和maven都是构建工具,可以帮助我们管理项目中的差异,依赖,编译,打包,部署......,你可以定义满足自己需要的构建逻辑,写入到build.gradle中
实际工作中，生成了gradle项目之后，会有几个配置文件：
1、settings.gradle
用于初始化以及工程树的配置，放在根工程目录下。需要配置子模块就用include标签
2、build.gradle（根目录下 project）
平时开发，需要下载jar包的配置文件就是这个喽
plugins {
id 'java'
}
group 'org.example'
version '1.0-SNAPSHOT'
repositories {
mavenCentral()
}
dependencies {
testCompile group: 'junit', name: 'junit', version: '4.12'
compile 'org.mybatis:mybatis:3.4.5'
compileOnly 'org.projectlombok:lombok:1.16.18'
compile 'org.springframework:spring-context:5.2.3.RELEASE'
implementation 'commons-beanutils:commons-beanutils:1.9.4'
}
我们这里，分为四个标签来讲：
1.buildscript
buildscript中的声明是gradle脚本自身需要使用的资源。可以声明的资源包括依赖项、第三方插件、maven仓库地址等
2.ext
ext是自定义属性，现在很多人都喜欢把所有关于版本的信息都利用ext放在另一个自己新建的gradle文件中集中管理，下面我介绍一下ext是怎么用的：
当我们在build.gradle文件中输入了apply from:’version.gradle’这句话，我们就可以读取到该文件下ext的信息。
现在在项目中我也是这种方法统一管理所有第三方插件的版本号的，有兴趣的朋友也可以试试。
3.repositories
顾名思义就是仓库的意思啦，而jcenter()、maven()和google()就是托管第三方插件的平台
4.dependencies
当然配置了仓库还不够，我们还需要在dependencies{}里面的配置里，把需要配置的依赖用classpath配置上，因为这个dependencies在buildscript{}里面，所以代表的是Gradle需要的插件。
下面我们再看看build.gradle（Project）的另一部分代码
- allprojects
allprojects块的repositories用于多项目构建，为所有项目提供共同所需依赖包。而子项目可以配置自己的repositories以获取自己独需的依赖包。
奇怪，有人会问，为什么同一个build.gradle（Project）文件中buildscript和allprojects里面的内容基本上是一样的呢，他们的区别在哪？
- buildscript和allprojects的作用和区别buildscript中的声明是gradle脚本自身需要使用的资源，就是说他是管家自己需要的资源，跟你这个大少爷其实并没有什么关系。而allprojects声明的却是你所有module所需要使用的资源，就是说如果大少爷你的每个module都需要用同一个第三库的时候，你可以在allprojects里面声明。这下解释应该可以明白了吧。
3、build.gradle（子模块下module）
首先要说下apply plugin：’×××’
这种叫做引入Gradle插件，而Gradle插件大致分为分为两种：
- apply plugin：’×××’：叫做二进制插件，二进制插件一般都是被打包在一个jar里独立发布的，比如我们自定义的插件，再发布的时候我们也可以为其指定plugin id，这个plugin id最好是一个全限定名称，就像你的包名一样；
- apply from：’×××’：叫做应用脚本插件，其实这不能算一个插件，它只是一个脚本。应用脚本插件，其实就是把这个脚本加载进来，和二进制插件不同的是它使用的是from关键字.后面紧跟的坫一个脚本文件，可以是本地的，也可以是网络存在的，如果是网络上的话要使用HTTP URL.
虽然它不是一个真正的插件，但是不能忽视它的作用.它是脚本文件模块化的基础，我们
可以把庞大的脚本文件.进行分块、分段整理.拆分成一个个共用、职责分明的文件，然后使
用apply from来引用它们，比如我们可以把常用的函数放在一个Utils.gradle脚本里，供其他脚本文件引用。
说说Gradle插件的作用
把插件应用到你的项目中，插件会扩展项目的功能，帮助你在项目的构建过程中做很多事情。
1.可以添加任务到你的项目中，帮你完成一些亊情，比如测试、编译、打包。
2.可以添加依赖配置到你的项目中，我们可以通过它们配置我们项目在构建过程中需要的依赖.比 如我们编译的时候依赖的第三方库等。
3. 可以对项目进行一些约定，比如应用Java插 件之后，约定src/main/java目录下是我们的源代码存放位置，在编译的时候也是编译这个目录下的Java源代码文件。
dependencies{}
我们平时用的最多的大概就这个了，
- 首先第一句compile fileTree(include: [‘.jar’], dir: ‘libs’)*，这样配置之后本地libs文件夹下的扩展名为jar的都会被依赖，非常方便。
- 如果你要引入某个本地module的话，那么需要用compile project(‘×××’)。
- 如果要引入网上仓库里面的依赖，我们需要这样写compile group：’com.squareup.okhttp3’,name:’okhttp’,version:’3.0.1’,当然这样是最完整的版本，缩写就把group、name、version去掉，然后以”:”分割即可。
compile ‘com.squareup.okhttp3:okhttp:3.0.1’
各种依赖方式说明
- implementation：这个指令的特点就是，对于使用了该命令编译的依赖，对该项目有依赖的项目将无法访问到使用该命令编译的依赖中的任何程序，也就是将该依赖隐藏在内部，而不对外部公开。
- api：完全等同于compile指令。
- compile：这种是我们最常用的方式，使用该方式依赖的库将会参与编译和打包。
- testCompile：testCompile 只在单元测试代码的编译以及最终打包测试apk时有效。
- debugCompile：debugCompile 只在debug模式的编译和最终的debug apk打包时有效。
- releaseCompile：releaseCompile 仅仅针对Release模式的编译和最终的Release apk打包。
- provided：只在编译时有效，不会参与打包，可以在自己的moudle中使用该方式依赖。比如com.android.support，gson这些使用者常用的库，避免冲突。
- apk（runtimeOnly）：只在生成apk的时候参与打包，编译时不会参与，很少用。
正常我们引入一个库可能直接指定了版本号
compile ‘com.google.code.gson:gson:2.8.0’
那么可以不指定版本号吗?答案是可以的,比如:
compile ‘com.google.code.gson:gson:2.+’ 引入gson 大版本为2的包
compile ‘com.google.code.gson:gson:latest.release’引入gson 最新的包
原文链接：https://blog.csdn.net/jinfulin/article/details/80421927