1.Project的build.gradle文件
2. Module下的build.gradle（android{}闭包）：这个闭包主要为了配置项目构建的各种属性：
2.1 添加signingConfigs{}闭包：
2.2、compileSdkVersion：设置编译时用的Android版本
2.3、buildToolsVersion：设置编译时使用的构建工具的版本，Android Studio3.0后去除此项配置
2.4、defaultConfig{}闭包：
applicationId：指定了项目的包名。
minSdkVersion：指定项目最低兼容的版本，如果设备小于这个版本或者大于maxSdkVersion(一般不用)将无法安装这个应用，这里指定为16，表示最低兼容到Android 4.1系统。
targetSdkVersion：指定项目的目标版本，表示在该目标版本上已经做过充分测试，系统会为该应用启动一些对应该目标系统的最新功能特性，Android系统平台的行为变更，只有targetSdkVersion的属性值被设置为大于或等于该系统平台的API版本时，才会生效。例如，若指定targetSdkVersion值为22，则表示该程序最高只在Android5.1版本上做过充分测试，在Android6.0系统上（对应targetSdkVersion为23）拥有的新特性如系统运行时权限等功能就不会被启用。
versionCode：表示版本号，一般每次打包上线时该值只能增加，打包后看不见。
versionName：表示版本名称，展示在应用市场上。
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"表明要使用 AndroidJUnitRunner进行单元测试。
2.5、 buildTypes{}闭包：这个闭包主要指定生成安装文件的主要配置，一般包含两个子闭包，一个是debug闭包，用于指定生成测试版安装文件的配置，可以忽略不写；另一个是release闭包，用于指定生成正式版安装文件的配置。两者能配置的参数相同，最大的区别默认属性配置不一样，两种模式支持的属性配置如下图：
2.6、sourceSets{}闭包：配置目录指向
配置 jniLibs.srcDirs = ['libs']，可以在Android studio的Android视图下生成jniLibs文件夹，可以方便我们存放jar包和库文件，其中Android视图下的jniLibs和project视图下的libs指向同一文件夹（app→libs）
2.7、packagingOptions{}闭包：打包时的相关配置
当项目中依赖的第三方库越来越多时，有可能会出现两个依赖库中存在同一个（名称）文件。如果这样，Gradle在打包时就会提示错误（警告）。那么就可以根据提示，然后使用以下方法将重复的文件剔除，比较常用的是通过exclude去除重复的文件，例如：
2.8、productFlavors{}闭包：多个渠道配置
这个配置是经常会使用到的，通常在适配多个渠道的时候，需要为特定的渠道做部分特殊的处理，比如设置不同的包名、应用名等。场景：当我们使用友盟统计时，通常需要设置一个渠道ID，那么我们就可以利用productFlavors来生成对应渠道信息的包，如：
当然也有更简洁的方式：
配置完之后，在命令行窗口中（Terminal）中输入gradlew assembleRelease（windows）即可开始打包，在Mac系统中对应指令应该是./gradlew assembleRelease。当然，如果想要debug版本的包，将指令中assembleRelease改为assembleDebug即可。最后生成的包还是在app/build/outputs/apk中，默认命名格式如app-wandoujia-release-unsigned.apk，在module的Build Variants中可以选择相应的渠道。
注：Android Studio3.0需在主app的build.gradle里面的
defaultConfig {
targetSdkVersion：***
minSdkVersion ：***
versionCode：***
versionName ：***
//版本名后面添加一句话，意思就是flavor dimension 它的维度就是该版本号，这样维度就是都是统一的了
flavorDimensions "versionCode"
}
2.9、lintOptions{}闭包：代码扫描分析
Lint 是Android Studio 提供的 代码扫描分析工具，它可以帮助我们发现代码结构/质量问题，同时提供一些解决方案，而且这个过程不需要我们手写测试用例。
Lint 发现的每个问题都有描述信息和等级（和测试发现 bug 很相似），我们可以很方便地定位问题，同时按照严重程度进行解决。
3、dependencies{}闭包：
该闭包定义了项目的依赖关系，一般项目都有三种依赖方式：本地依赖、库依赖和远程依赖。本地依赖可以对本地的jar包或目录添加依赖关系，库依赖可以对项目中的库模块添加依赖关系，远程依赖可以对jcener库上的开源项目添加依赖关系。从Android Studio3.0后compile引入库不在使用，而是通过api和implementation，api完全等同于以前的compile，用api引入的库整个项目都可以使用，用implementation引入的库只有对应的Module能使用，其他Module不能使用，由于之前的项目统一用compile依赖，导致的情况就是模块耦合性太高，不利于项目拆解，使用implementation之后虽然使用起来复杂了但是做到降低偶合兴提高安全性。