Gradle|Gradle For Android(2)--基础的定制构建 GradleForAndroid(2)--基础的定制构

理解Gradle文件当创建一个新的Project的时候，会默认生成3个Gradle文件。在项目的根目录(在Project的Top-Level)下会生成settings.gradle和build.gradle。而在Android app模块中会创建一个build.gradle文件。目录结构如下：

MyApp ├── build.gradle ├── settings.gradle └── app └── build.gradle

Settings文件对于一个新的Project，settings.gradle文件只会有一行

include ':app'

这个setting.gradle在初始化阶段被执行，并且定义了哪些Module应该在构建中被包含。在该例中，只有:app模块被包含。只有一个模块的Project可以不需要该文件，而多个模块的Project的必须要该文件，否则Gradle不知道哪些模块需要被包含(include)。
在这种场景下，Gradle创建了为每个Settings文件都创建了一个Serttings对象，并且可以从该对象中调用所需要的Methods。我们不需要知道Settings类的细节，但是最好关注一下。
顶层的build.gradle 顶层的build.gradle文件中，我们可以配置一些options，这些options可以应用于所有在这个Project中的Module。它默认包含以下两个代码块：

buildscript { repositories { jcenter() } dependencies { classpath 'com.android.tools.build:gradle:1.2.3' } } allprojects { repositories { jcenter() } } }

buildscript代码块中是真正构建的配置的地方。respositories代码块配置了JCenter作为仓库。在这种情况下，仓库代表了这个Project所依赖的资源或者说我们所需要的一些可下载的Libraries都是保存在这个仓库中。JCenter是一个知名的Maven仓库。
dependencies代码块用来配置构建过程的依赖。也就是说，我们不应该在Top-Level的build.gradle中包含Application或者Libraries的依赖。它唯一的依赖关系应该为是默认定义的Android Plugin。它会去遍历每一个Android Module，因为它是会执行Android-Related Tasks的插件。
allprojects代码块用来定义需要被应用到每一个Module中的属性。我们甚至可以在这个代码块中创建Task，而这些Task可以在各个Module中被应用。
Module中的build.gradle Module层的build.gradle文件包含了一些options，这些options只能应用在Android app module中。它也能够覆盖Project层的build.gradle文件中的属性。该模块的file如下：

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' }

其中三个主要的代码块：

plugin：第一行应用了Android的application plugin，配置在顶层的build.gradle中。这个插件主要由Android工具团队写并且维护的，提供了所有需要构建application以及libraries的build，test，package任务
android：这个代码块主要包括了Android特殊的配置。只有两个属性需要配置compileSdkVersion以及buildToolsVersion。负责编译的sdk api版本以及build tools的版本。其中build tools包括了很多命令行的工具，比如说aapt，zipalign，dx，renderscript等等，使用这些工具我们可以生产出各种各样的中间件。我们可以通过SDK Manager下载build tools。

【Gradle|Gradle For Android(2)--基础的定制构建】defaultConfig代码块配置了App核心的属性。在这个代码块中的属性会重写AndroidManifest.xml中相对应的属性。
applicationId属性会重写Manifest.xml中的packageName。在Gradle之前的构建系统中，PackageName有两个作用，唯一表示一个App以及用于为R.java赋予包名。而通过Gradle使用build variants使得构建不同版本的App变得更加简单了。比如，很容易构建一个付费/免费的版本。而这两个版本需要两个单独的PackageName，这样才能够被一起装到一个手机上。但是源代码以及R文件包名都还保持着相同的PackageName，以至于在构建多个版本的时候，需要把所有的源文件都进行修改。
因此，这也就是为什么Android Tool团队减弱了packageName的这两个用途。定义在Manifest中的PackageName仍然会用于SourceCode以及R文件。而Google Play则会使用application id作为唯一标识符来区分App。
包括minSdkVersion，targetSdkVersion，versionCode，versionName等等在内的所有值都会覆盖掉Manifest.xml中的值，如果在build.gradle中定义了这些值，Manifest.xml中就可以不定义了，但是以防万一最好还是在Manifest.xml中定义好，避免遗漏出错。
buildType代码块定义了构建不同类型的App的地方。后续会再详细说明。
dependencies代码块是标准Gradle配置的一部分，这也就是它为什么会在android代码块之外的原因。并且它定义了app或者library中所有的依赖关系。默认一个新的Android App会对libs目录下的所有jar包有依赖。取决于新Project的启动项配置。
了解Tasks 为了了解整个Project中哪些Task是可用的，我们可以通过gradlew tasks来列出所有可用的Tasks。如下图所示：

文章图片
可用的Tasks
在一个新创建的Android Project中，它包括了:

Android tasks
build tasks
build setup tasks
help tasks
install Tasks
verification Tasks
...

如果不止想看到Tasks，而是各个Task之间的依赖关系，可以使用gradlew tasks --all。当你希望打印出执行一个特殊的Task的所有步骤时，可以加上参数-m或者--dry-run。
Android Tasks Android Plugin继承自基础的Task，并且实现了自己一些功能。这些Tasks在Android中会有如下表现：

assemble：为每个Build Type构建APK
clean：移除所有Build中间件以及Apk文件等等
check：执行Lint的检查，并且如果Lint出现问题的时候，会打断Build过程
build：执行assemble以及check任务

Assemble任务默认由assembleDebug以及assembleRelease构成，如果有更多的Build Type的话，则会有更多的任务。也就是说，执行Aseemble将会为每个Build Type触发一个构建。
除了继承了这些Tasks之外，Android Plugin也添加了一些新的Task。以下为最重要的新的Tasks：

connectedCheck：在已经连接的设备或者模拟器上执行tests任务
deviceCheck：为其他插件在远程设备上调试提供的占位任务
installDebug/installRelease：在已经连接的设备或者模拟器上安装一个特定的版本
所有的install任务都会有相对应的uninstall任务

build任务依赖于check任务，而不是connectedCheck或者deviceCheck。这保证了常规的检查不需要连接设备。执行完check任务后，会生成一个Lint Report文件，其中保存着warnings以及errors，可以在app/build/outputs/lint-results.html中找到。

文章图片
Lint Report
当Assemble一个Release版本时，Lint将检查可能会导致App Crash的问题。如果找到的话，就会中断Build，并且在Command-Line中打印出错误。并且也会在app/build/outputs中生成lint-results-release-fatal.html文件。如果有多个错误，则通过HTML的Report报告然后滑动到报错的位置就可以看到了。
在Android Studio中，右侧的Gradle窗口双击对应的Task即可开始执行。也就不用在命令行工具中输入命令了。

文章图片
Gradle窗口
BuildConfig以及Resources
从SDK Tool版本17之后，Build Tool会生成一个名为BuildConfig的类，其中包含了根据build type生成的DEBUG常量。这对控制日志打印是非常有利的。而且，这也为Debug或者Release的常量区分带来了很多的方案，比如我们需要根据Build Type来开启/关闭一些Features，或者设置Server的URLs等等，例如：

android { buildTypes { debug { buildConfigField "String", "API_URL","\"http://test.example.com/api\"" buildConfigField "boolean", "LOG_HTTP_CALLS", "true" } release { buildConfigField "String", "API_URL","\"http://example.com/api\"" buildConfigField "boolean", "LOG_HTTP_CALLS", "false" } } }

通过双引号中添加的String值会被生成一个真实的String。通过添加了buildConfigField这一行，我们可以使用BuildConfig.API_URL和BuildConfig.LOG_HTTP来引用不同的值。
而最近，Android Tool团队也会通过以下方式来配置资源：

android { buildTypes { debug { resValue "string", "app_name", "Example DEBUG" } release { resValue "string", "app_name", "Example" } } }

Project级别的Settings 如果拥有多个Android Modules的话，它可以非常简便的修改每个Module中的build.gradle中的值，而不用手动的去修改了。我们已经看到了allprojects代码块在顶层的build.gradle中定义了reositories，并且你可以使用相同的方式来应用Android指定的Settings：

allprojects { apply plugin: 'com.android.application' android { compileSdkVersion 22 buildToolsVersion "22.0.1" } }

这段代码块只会应用于所有的Android App Project，因为需要应用Android Plugin去使用Android特殊的Settings。一种更好的方案是在顶层的build.gradle中定义这些值，然后在各个Module中应用。也就意味着，我们可以在build.gradle文件中绑定ext代码块，其中定义一些自定义的属性：

ext { compileSdkVersion = 22 buildToolsVersion = "22.0.1" }

通过这种方式来在Module级别的build.gradle中使用rootProject来获取使用的值。

android { compileSdkVersion rootProject.ext.compileSdkVersion buildToolsVersion rootProject.ext.buildToolsVersion }

Project properties 定义Project的Properties有几种方式，最常用的三种：

使用ext代码块
使用gradle.properties文件
通过-P的命令行参数

以下为这三种方式的示例代码：

ext { local = 'Hello from build.gradle' } task printProperties << { println local// Local extra property println propertiesFile// Property from file if (project.hasProperty('cmd')) { println cmd// Command line property } }

在gradle.properties文件中定义如下：

propertiesFile = Hello from gradle.properties

如果通过命令行参数执行printProperties任务的话，输出如下：

$ gradlew printProperties -P cmd='Hello from the command line' :printProperties Hello from build.gradle Hello from gradle.properties Hello from the command line

默认的任务
如果使用gradle没有指定具体的任务的话，则会执行help任务。如果需要指定默认的任务的话，则需要在顶层的build.gradle中加入默认任务：