导读
<a name="label">1、初识build.gradle</a>
<a name="label">2、使用build.gradle文件</a>
<a name="label">3、settings.gradle文件</a>
（ps：由于Markdown在简书里对锚点的支持效果不是很好，就没设置跳转）
一、初识build.gradle
在一个标准的AS工程中，最少都会有两个build.gradle文件，其一在项目的根目录，而另一个在module的根目录里面。如下图：
我们先来理了解下两个build.gradle文件的区别？
AS的工程结构其实可以理解为就是由module组成，但是只运行有一个主module作为我们实际运行的项目，其他module都是以依赖module形式存在，如上图中所示：就仅有module——app，并且是我们当前Demo的主module。AS中，每一个module都必须会有一个属于自己的build.gradle文件<br />
主module：有个手机图片标识<br />
依赖module：有个类似列表柱状图片标识<br >
了解了module后，回到我们问题，其实就很好理解两个build.gradle文件的区别了<br />
工程根目录的build.gradle文件
项目构建时，会先找到该文件执行构建，里面的配置对整个工程全局有效，我们可以在这里做些全局性的配置，在创建一个新AS工程时，会默认创建该文件，并且添加相关默认配置，如:gralde插件，jcenter仓库，maven仓库。当然也可以在这里自定义一些全局的设置，后面我们会提到<br >
module的build.gradle文件
构建具体到每一个module时，会执行该文件，里面的配置仅对当前module生效。在创建一个新module时，也会默认创建该文件，并且添加相关默认配置，如我们Demo中主module app的build.gradle文件：
apply plugin: 'com.android.application'//声明主module，com.android.application
android {//android工程配置
compileSdkVersion 25 //编译sdk版本号
buildToolsVersion "25.0.2"//编译工具版本
defaultConfig {//工程默认配置
applicationId "com.example.myapplication"//程序运行时真正的包名，可以与java中包名不同
minSdkVersion 15//最小sdk版本号
targetSdkVersion 25//目标sdk版本号
versionCode 1//应用程序的版本号，以这里修改为准，manifest文件中配置无效
versionName "1.0"//应用程序的版本名，以这里修改为准，manifest文件中配置无效
}
buildTypes {//运行方式配置，可以配置debug，release或者其他自定义
release {//release运行方式执行的配置
minifyEnabled false //混淆开关
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'//混淆文件
}
}
}
dependencies {//依赖配置
compile fileTree(dir: 'libs', include: ['*.jar'])
androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
exclude group: 'com.android.support', module: 'support-annotations'
})
compile 'com.android.support:appcompat-v7:25.2.0'
compile 'com.android.support.constraint:constraint-layout:1.0.2'
testCompile 'junit:junit:4.12'
}
二、使用build.gradle文件
清楚了两种build.gradle文件的区别后，那么我们就可以进行些我们自定义的配置了；假想下这么一种场景，自己的工程如果有好几个module，而每一个module都会有自己的build.gradle文件，因为是android工程，所以都会存在compileSdkVersion 、buildToolsVersion等一些默认配置，有时候自己项目中明明是配置ok了，而且一直编译没有问题，或许突然某一天，其他同时把他自己环境的一些配置提交上来了，那么可能就会出现原来好好的可以跑，突然就报错勒，当然这解决起来也非常简单，会说了，我把他改回来不就好了。但是我们能不能通过一些简单配置，这种问题尽可能的减少出现呢？<br />
1.使用根目录build.gradle文件，配置共有的属性
build.gradle文件代码，ext里面就是我们自定义的一些配置
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:2.3.0'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
ext {
compileSdkVersion=25
buildToolsVersion="25.0.2"
minSdkVersion=14
targetSdkVersion=25
versionCode=1
versionName="1.0"
}
allprojects {
repositories {
jcenter()
}
}
task clean(type: Delete) {
delete rootProject.buildDir
}
使用代码：
compileSdkVersion rootProject.ext.compileSdkVersion
buildToolsVersion rootProject.ext.buildToolsVersion
defaultConfig {
applicationId "com.example.myapplication"
minSdkVersion rootProject.ext.minSdkVersion
targetSdkVersion rootProject.ext.targetSdkVersion
versionCode rootProject.ext.versionCode
versionName rootProject.ext.versionName
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
}
2.自动使用签名配置
在主module的build.gradle文件的android区域里面添加如下代码，下面配置中，debug和release都配置了同一签名
signingConfigs {
debugConfig {
keyAlias 'debug'
keyPassword '123456'
storeFile file('/debug.keystore')
storePassword '123456'
}
releaseConfig {
keyAlias 'debug'
keyPassword '123456'
storeFile file('/debug.keystore')
storePassword '123456'
}
}
3.快速区分调试环境和生产环境
上面仅仅配置好了签名信息，运行起来实际上仍然是没效果的，这是因为我们还需要在运行类型配置上进行添加相关配置才能生效，同样的也是在主module的build.gradle文件中进行添加代码，添加区域在buildTypes里面
buildTypes {
//调试环境
debug {
buildConfigField "boolean", "isDebug", "true"//debug标识，方便项目里面一些只在debug模式下生效代码做区分标识
buildConfigField "String", "HOST", '"https://www.baidu.com/"'//项目里面，测试服务器地址
resValue "string", "app_name", "**测试版"//配置了该属性，需要在values中strings.xml里面把app_name删掉，否则编译会报错，测试版本的APK名字，以区分正式测试不同版本
//混淆
minifyEnabled false
//前一部分代表系统默认的android程序的混淆文件，该文件已经包含了基本的混淆声明，后一个文件是自己的定义混淆文件
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
signingConfig signingConfigs.debugConfig//使用上面签名配置中的debugConfig配置
applicationIdSuffix'.debug'//区分debug版本的包名，会自动在正式包名后面带上.debug，方便测试服务器版本和正式服务器版本APK同时安装
}
//发布环境
release {
buildConfigField "boolean", "isDebug", "true"
buildConfigField "String", "HOST", '"http://www.jianshu.com/"'//项目里面，正式服务器地址
resValue "string", "app_name", "*****"//配置了该属性，需要在values中strings.xml里面把app_name删掉，否则编译会报错，正式版本的APK名字，以区分正式测试不同版本
//混淆
minifyEnabled true
//前一部分代表系统默认的android程序的混淆文件，该文件已经包含了基本的混淆声明，后一个文件是自己的定义混淆文件
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'//混淆配置文件
signingConfig signingConfigs.releaseConfig//使用上面签名配置中的releaseConfig配置
}
}
app_name的特殊处理
当我们配置了app_name时，需要去values中找到strings.xml文件，把里面的app_name删除掉，否则编译项目会报如下错误，解决方案就是删除strings.xml里面的app_name后重新构建下就好了
有些配置我们该如何在项目代码中使用呢？<br />
比如测试正式服务器地址，debug标识状态，我们该如何使用呢。首先任何一个build.gradle修改了，都要重新构建下才能生效。构建完成后，我们就可以直接通过BuildConfig.配置的属性名，进行使用了，例如上述中的HOST：BuildConfig.HOST就可以取出我们上边配置的url勒。<br />
配置了两个，具体什么时候取哪个呢？
这个具体取决于你运行程序时AS里Build Variant设置了，点开该设置，找到我们的主module，根据下图我们可以看到默认是debug配置，此时我们如果需要使用release的配置时，只需要在此处进行切换就好了
4.自动按规范更改打包命名
在主module的build.gradle文件里，添加区域为android{}
applicationVariants.all { variant ->
variant.outputs.each { output ->
output.outputFile = new File(
output.outputFile.parent,
"demo-${variant.buildType.name}-${defaultConfig.versionName}.apk")//打包的命名为：demo-debug-1.0.apk(debug配置下)
// demo-release-1.0.apk(release配置下)
}
}
三、settings.gradle文件
这个文件里面所配置的是我们项目module信息，如果新导入进来的module无法进行添加依赖，那么需要检查一下，在该文件中是否有添加该module，添加语法：
include ':app'//当前Demo因为只有一个app主module，所以就在打开该文件只能看到这一条配置，如果需要添加其他module，直接把app替换成module名即可