Android studio会默认为我们创建三个gradle文件，两个build.gradle，一个settings.gradle，build.gradle分别放在了根目录和moudle目录下：
下面是gradle文件的构成图：
MyApp
├─ build.gradle //这个工程下的所有模块的公共属性
├─ settings.gradle //初始化时期执行
└─ app
└── build.gradle//只对该模块起作用，可以重写任何的参数来自于根目录下的gradle文件 |
1.setting.gradle 解析
当app只有一个模块的时候，setting.gradle将会是这样子的：
|
include ':app' |
setting.gradle文件将会在初始化时期执行，并且定义了哪一个模块将会被构建。单模块的项目并不一定需要setting文件，但是多模块必须要有setting文件，否则，gradle 不知道哪个模块应该在构建内。gradle 会为每个settings文件创建一个settings对象，并调用该对象相关的方法。
2.顶层构建文件解析
在项目中，所有模块的通用配置参数都应该在顶层build.gradle 文件配置中。默认情况下其包含如下两个代码块：
|
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.2.3'
}
}
allprojects {
repositories {
jcenter()
}
} |
实际构建配置在buildscript代码块内。
Repositories代码块 将jcenter配置成一个仓库，在这种情况下，一个仓库意味着一些列依赖包，或者说，在我们应用和依赖项目中可以使用的一些列可下载的函数库，JCenter是一个很有名的Maven库。
dependencies 代码块 用于配置构建过程中的依赖包。这意味着你不应该在该方法体内定义子模块的依赖包，你仅仅需要定义默认的Android插件就可以了，因为该插件可以让你执行相关Android的tasks。
allprojects代码块 可用来声明那些需要被用于所有模块的属性。你可以自己创造tasks在allprojects方法体内，这些tasks将会在所有模块中可见。
3.模块的构建文件解析
模块内的gradle文件只对该模块起作用，而且其可以覆盖位于顶层build.gradle文件的任何属性。构建文件示例如下：
apply plugin: 'com.android.application'
android {
compileSdkVersion 22
buildToolsVersion "22.0.1"
defaultConfig {
applicationId "com.gradleforandroid.gettingstarted"
minSdkVersion 14
targetSdkVersion 22
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile
('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.2.0'
} |
(1)插件：该文件的第一行用到了android应用插件，该插件在顶层构建文件中被配置成了依赖。google的android团队负责 此插件的便携和维护，并提供构建、测试和打包android应用以及依赖项目的所有任务。
(2)android：该方法包含了所有的Android特有的属性，这些特有配置之所以被使用，是因为之前使用了android插件。而必须的属性为compileSdkVersion和buildToolsVersion：
· compileSdkVersion：编译该app时候，你想使用到的api版本。
· buildToolsVersion：构建工具的版本号。
· defaultConfig:此方法包含了该APP的核心属性，该属性会重写在AndroidManifest.xml中的对应属性：
apply plugin: 'com.android.application'
android {
compileSdkVersion 22
buildToolsVersion "22.0.1"
defaultConfig {
applicationId "com.gradleforandroid.gettingstarted"
minSdkVersion 14
targetSdkVersion 22
versionCode 1
versionName "1.0"
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile
('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.2.0'
} |
applicationId属性：该属性覆写了AndroidManifest文件中的包名packagename，但是关于applicationId和package name有一些不同。在gradle被用来作为Android构建工具之前，package name在AndroidManifest.xml有两个作用：其作为一个app的唯一标志，以及在R资源文件中被用作包名。
minSdkVersion和targetSdkVersion。这两个和AndroidManifest中的<uses-sdk>很像。minSdkVersion定义为最小支持api。
versionCode 将作为版本标识，而versionname毫无作用。
所有的属性都是重写AndroidManifest 文件中的属性，所以不需再AndroidManifest 中定义这些属性了
• buildTypes方法定义了如何构建不同版本的app
(3)依赖包：
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
compile 'com.android.support:appcompat-v7:22.2.0'
} |
依赖模块作为gradle标准配置的一部分（这也是为什么其放在了android代码块的外面），为你的app模块定义了所有的依赖包。默认情况下，我们依赖了所有在libs文件下的jar文件，同时包含了AppCompat这个aar文件。
本文参考文献：