Android Gradle插件继承于Java插件，具有Java插件的的特性；现在就新建1个 APP工程，演示App的工程目录，以及开发中常用的Gradle配置；
新建了1个APP工程，上图就是工程常用的App工程目录；
其中包括app Project，和rootProject;
每个Project都 包含1个build.gralde文件，其中rootProject还包含1个settings.gralde文件；
现在先来分析rootProject，App工程的根目录
build.gradle 配置文件：
repositories 配置仓库，默认依赖的是google和jcenter，当我们配置依赖仓库的时候，Gradle就会去仓库里寻找我们的依赖；
dependencies:也是配置依赖，由于Gradle是属于第三方的插件，所以需要依赖于他们的classPath
allprojects 是针对于所有的工程项目配置，在根目录配置，子目录就不需要重复配置了
现在我们接着看根目录下的settings.gralde
接着创建1个Moudle，命名为Lib_test;
此时看settings.gralde文件
需要在工程内配置的Moudle都需要此文件中注册
此外工程中还有
local.properties：配置工程的sdk和ndk目录
工程的gradle文件夹
该文件夹下有个wrapper,wrapper其实就是对Gradle的一层包装，我们在项目开发中，其实是有的都是Wrapper这种方式，内部是一堆的脚本，所以我们在工程中没有配置gradle的时候，提示的也不是noFound，而是提示下载并构建；
gradle-wrapper.properties内部是这样的
其中distributionUrl我们需要稍微关注下，决定了我妈妈依赖的是哪个版本的Gradle，上图可以看到我的工程依赖的就是4.6版本；
好了以上计算rootProject目录下的文件解释，现在接着看下我们主工程（app）下的文件
Android Gradle的工程配置，都是在andorid{}中，这个是唯一的1个入口，通过在它内部的配置，我们可以对Android Gradle工程进行自定义的配置；
我们先解释下标准配置，之后在开始对gradle的自定义；
App插件id：com.android.application
Library的插件id:com.android.library
Test插件id:com.android.test
由于我们app的一个APP工程，所以使用apply plugin:'com.android.application' 依赖该插件
接着看android{}中的配置
compileSdkVersion：配置我们编译的Android 工程的SDK
defaultConfig:默认的配置，它是一个ProductFlavor,之后会解释ProductFlavor，现在只需要知道ProductFlavor允许我们根据不同的情况同时生成多个不同的apk包即可；
defaultConfig{
applicationId:包名，默认null,构建的时候是从AndroidManifest.xml文中读取的，也就是manifest中的pack值
minSdkVersion:最低支持的Android系统的ApI
targetSdkVersion:表明我们是基于哪个Andorid 系统开发的
versionCode:App应用内部的版本号
versionName:App应用的版本名称，对外，用户可见
testInstrumentationRunner：默认是android.support.test.runner.AndroidJUnitRunner，配置单元测试时候使用的Runner
}
buildType{}是1个域对象，就跟SourceSet一样，有release,debug等不同 的BuildType；
release{
minifyEnabled:是否启动混淆
proguardFiles:混淆文件
}
dependencies{...}依赖库
以上就是一个APP工程默认创建的文件解释；现在开始我们开始增加1些我们自定义的配置
1：配置测试App的包名，也就是测试包名
2：对生成的App签名
App工程的debug是有个默认的debug签名的，而release版本是没配置签名的，所以我们构建release版本的时候就需要自己签名了；
现在我们就生成2个签名文件，1个debug环境使用，1个在relese环境使用，保存在app目录下；
在build.gradle中配置签名，需要使用到signingConfig{}对生成的app签名
以上就是配置了App的签名，我们只要在之后的构建应用类型中使用即可完成签名
3：构建不同的应用类型
Android Gradle内置了debug和release2种构建类型，这两种的主要差别就在于能否在设备上调试和签名不一样，其他文件和资源都是一致的
构建不同的应用类型主要是在buildTypes里面配置，那我们就接着看看这里面的可配置修改信息
上图是常见的支持的debug和release版本的buildTypes；
minifyEnabled ：是否启动混淆
proguardFiles：混淆文件位置
我们构建下该情况下的apk，
可见，在还为配置签名的情况下，debug模式默认是签名的，而release版本是未签名的；现在配置上签名
配置上签名后，重新Build就多了1个app-release签完名的apk文件了
debuggable：配置该apk是否可供调试
jniDebuggable：配置该apk是否可供调试jni代码
multiDexEnabled：配置是否启用自动拆分多个dex的功能，解决65535
shrinkResources：配置是否自动清理未使用的资源，默认是false
zipAlignEnabled ：这个是Android为我们提供的整理优化apk文件的工具
以上就是基础功能的BuildType，跟BuildType相关的还有多渠道打包，同样是构建不同的包；
参考Android Gradle的多渠道构建
4：自定义BuildConfig
5：源集合-SourceSet
未完待续