a.调用graddle wrapper之前可以指定gradle版本（--gradle-version number）和下载gradle的地址(--gradle-distribution-url)他们会影响生成的wrapper.properties中distributionUrl的值（该值规则是https\://services.gradle.org/distributions/gradle-${gradleVersion}-bin.zip）

b.distributionBase:下载的gradle压缩包解压后存储的主目录
  distributionPath:相对于distributionBase解压后的gradle压缩包的路径
  distributionUrl:gradle发行版压缩包的下载地址
  zipStoreBase:同distributionBase，但是是存放zip包的
  zipStorePath:同distributionPath，但是是存放zip包的

a.List<br>
	def numList=[1,2,3,56,'array']<br>
	println numList.getClass().name   java.util.ArrayList<br>
	println numList[-1]		array<br>
	println numList[1]		2<br>
	println numList[-2]    56<br>
	println numList[1..3]  [2,3,56]<br>
b.Map<br>
	def mp=['width':1080,'height':1920]<br>
	println mp.getClass().name<br>
	println mp.width		1080<br>
	println mp['height']	1920<br>

a. task customTask1 {
		doFirst {
			println 'customTask1:doFirst'
		}
		doLast {
			println 'customTask1:doLast'
		}
   }

 b. 另外一种创建方法
 	tasks.create("customTask2") {
 		doFirst {
			println 'customTask1:doFirst'
		}
		doLast {
			println 'customTask1:doLast'
		}
 	}

task Hello{
	doLast{
		println 'Hello'
	}
}

task World{
	doLast{
		println 'World'
	}
}

task Main {
	dependsOn Hello
	doLast{
		println 'Main';
	}
}

task MultiTask{
	dependsOn Hello,World
	doLast {
		println 'MultiTask'
	}
}

task ex36Hello {
	println 'dowLast1'
}

ex36Hello.doFirst {
	println 'doFirst'
}

ex36Hello.doLast {
	println project.hasProperty('ex36Hello')
	println 'doLast2'
}

ext {
	phone = 1334512
	address = ''
}
task customProperty {
	println "年龄是：${age}"
	println "电话是：${phone}"
	println "地址是：${address}"
}
与局部变量相比，自定义属性有更广泛的作用域，只要你能访问这些属性所属的对象，那么这些属性都可以被访问到

自定义属性还可以作用于sourceset中，这样等同于每种sourceset又多了一个可供配置的属性：

sourceSets.all {
	ext.resourcesDir = null
}

sourceSets {
	main {
		resourcesDir = "main/res"
	}
	test {
		resourcesDir = "test/res"
	}
}

def Task mytask = task customTasktype: CustomTask)
mytask.doFirst {
    println("task执行之前")
}

mytask.doLast {
    println("task执行之后")
}

class CustomTask extends DefaultTask{
    @TaskAction
    def doSelfTask(){
        println("执行自己的task")
    }
}
运行结果：
	:customTask
	task执行之前
	执行自己的task
	task执行之后
其中@TaskAction注解标注意思是task本事执行执行的方法

task exTask4 {
    dependsOn missTask
}
如果执行不存在的missTask就会输出上面自定义描述信息

	1>应用二进制插件：二进制插件就是实现了org.gradle.api.Plugin接口的插件，他们可以有plugin id，
	apply plugin:'java'
	应用了java插件到我们的项目，其中'java'就是java插件的plugin id它是唯一的，其实它对应的类型是org.gradle.api.plugins.JavaPlugin,所以通过类型我们也可以使用该插件
	apply plugin:org.gradle.api.plugins.JavaPlugin
	而包org.gradle.api.plugins是默认导入的所以可以简写啊:
	apply plugin:JavaPlugin
	二进制插件一般都是被打包在一个jar文件里发布的，在发布时候我们可以为其指定plugin id，这个plugin id最好是一个全限定名称避免重复

	2>应用脚本插件：
	build.gradle中：

apply from:'version.gradle'

task ex52PrintlnTask <<{
	println "App版本是：${versionName},版本号是：${versionCode}"
}

version.gradle中：
ext {
	versionName = '1.0.0'
	versionCode = 1
}

	buildscript {
		repositories {
			jcenter()
		}
		dependencies {
			classpath 'com.android.tools.build:gradle:1.5.0'
		}
	}
	buildscript{}块是一个在构建项目之前，为项目进行前期准备和初始化相关配置依赖的地方，配置好以后：
	apply plugin: 'com.android.application'
	如果没有配置就会找不到插件

buildscript {

	repositories {
	    google()
	    jcenter()
	}
	dependencies {
	    classpath 		'com.android.tools.build:gradle:3.1.3'
	    

	    // NOTE: Do not place your application 		dependencies here; they belong
	    // in the individual module build.gradle 		files
	}
}

apply plugin: 'com.android.application'

android {
    compileSdkVersion 27
    defaultConfig {
        applicationId 		"com.example.wilsonhan.gradletest"
        minSdkVersion 18
        targetSdkVersion 27
        versionCode 1
        versionName "1.0"
        testInstrumentationRunner "android.support.		test.runner.AndroidJUnitRunner"
    }
    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('p		roguard-android.txt'), 		'proguard-rules.pro'
        }
    }
}

dependencies {
    implementation fileTree(dir: 'libs', include: 		['*.jar'])
    implementation 		'com.android.support:appcompat-v7:27.1.1'
    implementation 'com.android.support.constraint:		constraint-layout:1.1.2'
    testImplementation 'junit:junit:4.12'
    androidTestImplementation 		'com.android.support.test:runner:1.0.2'
    androidTestImplementation 'com.android.support.		test.espresso:espresso-core:3.0.2'
}

		compileSdkVersion 23
		compileSdkVersion 'android-23'
		android.compileSdkVersion = 23
		android.compileSdkVersion = 'android-23'
	以上四种方法等价

android {
  	compileSdkVersion 27
  	defaultConfig {
  	    applicationId 	"com.example.wilsonhan.gradletest"
  	    minSdkVersion 18
  	    targetSdkVersion 27
  	    versionCode 1
  	    versionName "1.0"
  	    testInstrumentationRunner"android.support.test	.runner.AndroidJUnitRunner"
  	}
  	//......
}
1>applicationId：是ProductFlavor的一个属性，用于指定生成的App的包名，默认为null，在构建的时候会从AndroidManifest.xml文件中读取，对应其中的package属性值

2>minSdkVersion:是ProductFlavor的一个方法，指定我们的App最低支持的Android操作系统版本，对应Android SDK的API LEVEL，接受一个整数或字符串。

3>targetSdkVersion：用于配置基于哪个Android SDK开发，可选值和minSdkVersion一样，不配置也是从AndroidManifest.xml中找

4>versionCode：是ProductFlavor的一个属性，用于配置Android App的内部版本号，整数值，不配置也是从AndroidManifest.xml中找

5>versionName：和versionCode类似，是ProductFlavor的一个属性，用于配置Android App的版本名称。供外部查看使用

6>testApplicationId：用于配置测试App的包名，默认情况下是applicationId+".test"。一般情况下默认即可，是ProductFlavor的一个属性

7>testInstrumentationRunner：用于配置单元测试时使用的Runner，默认使用的是android.test.InstrumentationTestRunner,如果你想使用自定义的Runner，修改这个值即可，他也是一个属性

8>signingConfig：配置默认的签名信息，对生成的App签名。它是一个SigningConfig，也是ProductFlavor的一个属性，可以直接对其进行配置。

9>progardFile：用于配置App Proguard混淆所使用的ProGuard配置文件。它是ProductFlavor的一个方法，接受一个文件作为参数。

10>proguardFiles：这个也是配置ProGuard的配置文件，可以同时接受多个配置文件

android {
	compileSdkVersion 27
	buildToolsVersion '27.0.3'
	signingConfigs {

		release {
		    keyAlias 			'keyAlias'
		    keyPassword 		'keyPassword'
		    storeFile file(		'storeFile'
		    storePassword 		'storePassword'
		}
		debug {
		keyAlias 			'keyAlias'
		    keyPassword 		'keyPassword'
		    storeFile file(		'storeFile'
		    storePassword 		'storePassword'
		}
	}

	defaultConfig {
		applicationId "com.example.wilsonhan.gradletest"
		minSdkVersion 18
		targetSdkVersion 27
		versionCode 1
		versionName "1.0"
		testInstrumentationRunner 	"android.support.test.runner.AndroidJUnitRunner"
		signingConfig signingConfigs.debug
	}
}
或者 buildTypes {
	debug {
	    signingConfig signingConfigs.debug
	}
	release {
	    //加载开发者签名
	    signingConfig signingConfigs.release
	}
}
示例：
// Initialize a new Properties() object called keystoreProperties.
def keystoreProperties = new Properties()
// load keystore properties file from root filesystem
keystoreProperties.load(new FileInputStream("/opt/dereleasekey/declient.properties"))
signingConfigs {
	debug {
	}
	release {
	    keyAlias keystoreProperties['keyAlias']
	    keyPassword keystoreProperties['keyPassword']
	    storeFile file(keystoreProperties['storeFile'])
	    storePassword keystoreProperties['storePassword']
	}
}
buildTypes {
	debug {
	    buildConfigField "boolean", "LOG_DEBUG", "true"
	}
	release {
	    //加载开发者签名
	    signingConfig signingConfigs.release
	}
}

2>debuggable：也是BuildType的一个属性，用于配置是否生成一个可供调试的apk。其值可以为true或者false

3>jniDebuggable：和debuggable类似，也是BUildType的一个属性，用于配置是否生成一个可供调试jni代码的apk

4>minifyEnabled：也是BuildType的一个属性，用于配置该BuildType是否启用proguard混淆

5>multiDexEnabled：也是BuildType的一个属性，用于配置该BuildType是否启用自动拆分多个Dex的功能，一般应用程序中代码太多，超过了56635个方法的时候。拆分为多个Dex的处理

6>proguardFile：是BuildType的一个方法用于配置Proguard混淆使用的配置文件。

7>proguardFiles：是BuildType的一个方法，用于配置proguard混淆使用的配置文件，可以同时配置多个Proguard配置文件

8>shrinkResources：是BuildType的一个属性，用于配置是否自动清理未使用的资源

9>signingConfig：配置该BuildType使用的签名配置。

android {
	buildTypes {
		release {
			zipAlignEnabled true
		}
		debug {

		}
	}
}

def releaseTime(){
	def date = new Date();
	def formatDate = date.format('yyyyMMdd')
	return formatDate
}
在android标签中：(Gradle3.0之前版本)

applicationVariants.all { variant ->
	variant.outputs.each { output ->
		if(output.outputFile != null && output.outputFile.name.endsWith('.apk')){
			if('release'.equals(variant.buildType.name)){
				def fileName = "${variant.versionCode}-${variant.versionName}-${releaseTime()}.apk"
                def apkFile=new File(
                	output.outputFile.getParent(),
                	fileName
                )
                output.outputFile = apiFile
			}
		}
	}
}
在android标签中：(Gradle3.0之后版本)
applicationVariants.all { variant ->
	variant.outputs.all { output ->
		if(output.outputFile != null && output.outputFile.name.endsWith('.apk')){
			if('release'.equals(variant.buildType.name)){
				def fileName = "${variant.versionCode}-${variant.versionName}-${releaseTime()}.apk"
                outputFileName = fileName
			}
		}
	}
}
applicationVariants是一个DomainObjectCollection集合，我们可以通过all方法遍历，遍历的每一个variant都是一个生成的产物。针对示例共有googleRelease和googleDebug两个产物，所以遍历variant共有googleRelease和googleDebug两个。
applicationVariants中的variant都是ApplicationVariant，通过查看源码可以知道，它有一个outputs作为他的输出。每一个ApplicationVariant至少有一个输出，也可以有多个，所以这里的outputs属性是一个List集合、我们再遍历它，如果他的名字是以.apk结尾的话，那么就是我们要修改的apk名字了。

	1>分模块的方式：Android支持基于文件的模块化，即apply from
	新建一个version.gradle文件，用于专门存放版本
	version.gradle:
		ext {
			appVersionCode = 1
			appVersionName = '1.0.0'
		}
	ext{}块表明要为当前project创建扩展属性，以供其他脚本引用
	然后在build.gradle中引入文件：apply from: 'version.gradle'
	就可以在文件中任何位置使用appVersionCode和appVersionName

	2>从属性文件中动态获取
		a.在项目目录下新建一个version.properties的属性文件
		b.把版本名称分成三部分major.minor.patch,版本号分成一部分number,然后在version.properties中新增4个KV键值对，其key就是我们上面份好的，value是对应的值
		c.在build.gradle里新建两个方法，用于读取该属性文件，获取对应key的值，然后把major.minor.patch这三个key拼接成版本名称，number用于版本号
		def versionProperties = new Properties()
		versionProperties.load(new FileInputStream(getRootDir().path + "/version.properties"))
		println(versionProperties['major'] + versionProperties['minor'] + versionProperties['patch'])
		println(versionProperties['number'])
		d.以上就达到了获取版本信息的目的

	android {
		compileSdkVersion 23
		buildToolsVersion "23.0.1"

		productFlavors {
			google {
				manifestPlaceholders.put("UMENT_CHANNEL","google")
			}
			baidu {
				manifestPlaceholders.put("UMENT_CHANNEL","baidu")
			}
		}
	}
	例子中我们定义了两个渠道Google和Baidu，并且配置了它们的manifestPlaceholders，留意我们的使用方式，他们的key都是一样的，是UMENG_CHANNEL，这个key就是我们在AndroidManifest文件中的占位符变量。在构建的时候，他会把AndroidManifest文件中所有占位符变量为UMENG_CHANNEL的内容（即${UMENG_CHANNEL}）替换为manifestPlaceholders中对应的value值。
	假如友盟渠道名和我们在Android Gradle中配置的ProductFlavor名字一样的话，可以通过迭代productFlavors批量进行修改。

productFlavors {
	google {
	}
	baidu {
	}
}

productFlavors.all { flavor ->
	manifestPlaceholders.put("UMENG_CHANNEL",name)
}

	/**
	* Automatically generated file. DO NOT MODIFY
	*/
	package com.example.wilsonhan.gradletest;
	
	public final class BuildConfig {
	  public static final boolean DEBUG = 		Boolean.parseBoolean("true");
	  public static final String APPLICATION_ID = 		"com.example.wilsonhan.gradletest";
	  public static final String BUILD_TYPE = "debug";
	  public static final String FLAVOR = "";
	  public static final int VERSION_CODE = 1;
	  public static final String VERSION_NAME = "1.0";
	}
	这些差不多就是我们当前构建渠道的基本应用信息。他们都是常量。
	Android Gradle提供了buildConfigField(String type,String name,String value)让我们可以添加自己的常量到BuildConfig中。
	第一个参数type是要生成字段的类型，第二个参数name是要生成字段的常量名字，第三个参数value是要生成字段的常量值。最终他们生成的字段格式如下：
	<type> <name> = <value>
	假设我们有baidu和google两个渠道，发布时候有两个渠道包，打开百度包是百度首页，打开google包是google首页，我们就可以添加一个字段WEB_URL，在baidu渠道包下它的值时http://www.baidu.com，在google渠道下它的值时http://www.google.com注意下面最后的url引号
	productFlavors {
		google {
			buildConfigField 'String','WEB_URL','"http://www.google.com"'
		}
		baidu {
			buildConfigField 'String','WEB_URL','"http://www.baidu.com"'
		}
	}
	这里需要注意，value这个参数，是单引号中间的部分。尤其对于String类型的值，里面的双引号一定不能省略，不然就会报错。value的值是什么就写什么，要原封不动的写在单引号里

	compileOptions {
		encoding = 'utf-8'
		sourceCompatibility = JavaVersion.VERSION_1_6
		targetCompatibility = JavaVersion.VERSION_1_6
	}
	sourceCompatibility是配置Java源代码的编译级别
	targetCompatibility是配置生成的字节码的版本

	1> incremental属性，这是一个boolean类型的属性，用来配置是否开启dx的增量模式，默认为false，表示不启用。增量模式虽然速度更快，但是目前还有很多限制，要启用设置incremental为true即可：
	android {
		dexOptions {
			incremental true
		}
	}
	
	2>javaMaxHeapSize属性，它是配置执行dx命令时为其分配的最大堆内存，主要用来解决执行dx时内存不够用情况。它接收一个字符串格式的参数，比如1024MB或者1GB。
	android {
		dexOptions{
			javaMaxheapSize '4g'
		}
	}
	
	3>jumboMode属性，boolean类型，它可以用来配置是否开启jumbo模式。项目比较大，代码太多，函数超过了65535个就需要开启该模式才能构建成功
	android {
		dexOptions {
			jumboMode true
		}
	}
	
	4>preDexLibraries属性，boolean类型，用来配置是否预执行dex Libraries库工程，开启后会大大提高增量构建的速度，不过这可能会影响clean构建的速度。默认为true，是开启的。有时候我们需要关闭这个选项，比如我们需要使用dx的--multi-dex选项生成多个dex，这导致和库工程有冲突的时候，需要将该选项设置成false。
	
	5>threadCount属性，它是integer类型，用来配置Android Gradle运行dx命令时使用的线程数量，适当的线程数量可以提高dx的效率：
	android {
		dexOptions {
			threadCount 2
		}
	}

	android {
		defaultConfig {
			multiDexEnabled true
		}
	}

	dependencies {
		compile fileTree(dir:'libs',include:['*.jar'])
		compile 'com.android.support:multidex:1.0.1'
	}
	通过multiDexEnabled配置来决定是否开启Multidex，这是一个boolean类型的属性，可以在defaultConfig、buildType或者productFlavor这些闭包块里使用，以达到我们根据自己的业务，分别配置的目的。
	配置好后，开启了Multidex会让我们的方法多于65535个的时候生成多个DEX文件，其名字为classes.dex,classes(...n).dex，所以要想达到程序可以正常运行的目的，也要让虚拟机把其他几个生成的classes加载进来。要想做到这个必须在程序的入口Application中控制。
	Multidex提供了现成的Application，其名字是MultiDexApplication，如果我们没有自定义的Application的话，直接使用MultiDexApplication即可，在Manifest清单中配置：
	<application
	 	...
	 	android:name="android.support.multidex.MultiDexApplication">
	 	...
	 </application>
	 如果有自定义的Application，并且是直接继承Application，只需要把继承改为MultiDexApplication即可。
	 如果自定义的Application是继承其他第三方提供的Application，就不能改变继承，我们可以通过重写attachBaseContext方法实现：
	 @override
	 protected void attachBaseContext(Context base) {
	 	super.attachBaseContext(base);
	 	MultiDex.install(this);
	 }
	 重写attachBaseContext方法的时候，调用MultiDex.install(this)即可，和我们继承MultiDexApplication的效果一样。
	 虽然有了解决65535问题的方法，但还是尽量避免我们工程中的方法超过65535，要达到这个目的，首先不能滥用第三方库，如果要引用，最好要自己进行精简。精简之后还要使用ProGuard减小DEX的大小，因为DEX安装到机器上的过程比较复杂，尤其是有第二个DEX文件并且过大的时候可能会造成ANR。还有Dalvik linearAlloc的限制，尤其在Android2.2和2.3版本上，只有5MB，到4.0的时候升级到8MB。

	android {
		buildTypes {
			release {
				minifyEnabled true
				shrinkResources true
				proguardFiles getDefaultProguardFile('proguard-android.txt'),'proguard-rules.pro'
			}
		}
	}
	启用Resource Shrinking是通过调用BuildType的shrinkResources来设置的，只要给这个方法传递一个true参数，就可以启用，默认情况是不启用。
	自动清理存在一个问题，会误删代码，尤其是使用了反射去引用资源文件，Android Gradle区分不出来，针对这种情况，Android Gradle提供了keep方法来配置哪些资源不被清理
	keep方法使用，我们需要新建一个xml文件来配置，这个文件是res/raw/keep.xml，然后通过tools:keep属性来配置。这个tools:keep接受一个以逗号（,）分割的配置资源列表，并且支持星号（*）通配符。此外对于res/raw/keep.xml这个文件不用担心会影响程序大小，Android Gradle构建系统最终打包的时候会清理它，不会打进apk中除非在代码中通过R.raw.keep引用了它。以下是示例：
	<?xml version="1.0" encoding="utf-8"?>
	<resources xmlns:tools="http://schemas.android.com/tools"
	tools:keep="@layout/user*_c,@layout/user*_b" />
	keep.xml还有一个属性是tools:shrinkMode,用于配置自动清理资源的模式，默认是safe，是安全的,这种情况下，Android Gradle可以识别代码中类似于如下示例的引用：
	getResources().getIdentifier("unused","drawable",getPackagename());
	这类代码也被构建系统认为是使用了资源文件，不会被清理。如果把清理模式改为strict，那么就没有办法识别了，这个资源会被认为没有被引用，也会被清理掉。
	除了shrinkResources之外，Android Gradle还为我们提供了一个resConfigs，它属于ProductFlavor的一个方法，可以让我们配置哪些类型的资源才被打包到apk中，比如只有中文的资源，只有hdpi格式的图片等，这是非常重要的。比如我们只需要中文的语言，支持hdpi的图片就行了，这时就可以通过resConfigs配置：
  
	android {
		defaultConfig {
			resConfigs 'zh'
		}
	}
	其实这个resConfig有3种配置方法，一般常用的是resConfigs方法，因为可以同时指定多个配置。也可以使用resConfig来指定一个配置，一次添加一个，如果要添加多个，要么调用多次。

	MyProject/
		+ app/
		+ libraries/
			+ lib1/
			+ lib2/
	上面程序中一个App项目，两个库项目lib1和lib2都放在libraries文件夹下，也就是说这里有3个项目：
	:app
	:libraries:lib1
	:libraries:lib2
	其实严格地说应该是4个项目，还有一个根项目MyProject。根项目会有一个settings.gradle配置文件，每个项目里都有一个build.gradle文件，所以它们的结构为：

	MyProject/
		settings.gradle
		app/
			build.gradle
		libraries/
			lib1/
				build.gradle
			lib2/
				build.gradle
	这就是一个完成的工程了，看一下settings.gradle配置文件：
	include ':app',':libraries:lib1',':libraries:lib2'
	就是指定这几个项目，有时候如果项目的路径太多，我们可以用如下方法指定配置：
	include ':example'
	project(':example').projectDir = new File(rootDir,'chapter/example')
	通过如上方法我们直接指定项目的目录即可。

dependencies {
		flavor1Compile project(path: ':lib1',configuration: 'flavor1Release')
		flavor2Compile project(path: ':lib1',configuration: 'flavor2Release')
	}
	对于Lib这个库项目，我们先配置成可以同时发布多个aar包，然后在其他引用工程里面做如上示例的引用，比如flavor1这个渠道包就引用flavor1这个渠道对应的lib1库的release aar包；flavor2这个渠道就引用flavor2这个渠道对应的lib1库的release aar包

android {
		productFlavors{
			google{}
			baidu{}
		}
	}
	Android Gradle为我们提供了productFlavors方法来增加不同的渠道，他接受域对象类型的productFlavor闭包作为其参数。所以我们可以为productFlavors{}闭包添加很多的渠道，每一个都是一个ProductFlavor类型的渠道。

	1>applicationId
		它是ProductFlavor的属性，用于设置改渠道的包名	，如果你的App想为该渠道设置特别的包名，可以使用	applicationId这个属性进行设置。
		
  android {
			productFlavors {
				google {
					applicationId "org.flysnow.	app.example.google"
				}
			}
		}
		以上就可以为google这个渠道设置其特有的包名，这	样打包的时候Google渠道使用的是org.flysnow.a	pp.example.google这个包名，而其他渠道使用的	是android下defaultConfig下的applicationId	的值。

	2>consumerProguardFiles
		既是属性也有一个同名的方法，他只对Android库项目有用。当我们发布库项目生成一个aar包的时候，使用consumerProguardFiles配置的混淆文件列表也会被打包到aar里一起发布，这样当应用项目引用这个aar包，并且启用混淆的时候，会自动使用aar包里的混淆文件对aar包里的代码进行混淆，这样我们就不用对该aar包进行混淆配置了：
		
  android {
			productFlavors {
				google {
					consumerProguardFiles 'proguard-rules.pro','proguard-android.txt'
				}
			}
		}

	3>manifestPlaceholders

	4>multiDexEnabled

	5>proguardFiles

	6>signingConfig

	7>testApplicationId
		一般我们会对Android进行单元测试，这个单元测试有自己的专门的apk测试包。testApplicationId是用来适配测试包的包名，他的使用和applicationId一样：
		
  android {
			productFlavors {
				google {
					testApplicationId "org.flysnow.example.test"
				}
			}
		}
		一般的testApplicationId的值为App的包名+.test。

	8>testFunctionalTest和testHandleProfiling
		boolean型属性，testFunctionalTest表示是否为功能测试，testHandleProfiling表示是否启用分析功能：
		
  android {
			productFlavors {
				testFunctionalTest true
				testHandleProfiling true
			}
		}
		它们主要用来控制测试包生成的AndroidManifest.xml，因为他们最终的配置还要体现在AndroidManifest.xml文件中的instrumentation标签的配置上。

	9>testInstrumentationRunner
		用来配置运行测试使用的Instrumentation Runner的类名，是一个去路径的类名，而且必须是android.app.Instrumentation的子类。一般情况下，我们使用android.test.InstrumentationTestRunner,当然也可以自定义：
		
  android {
			productFlavors {
				google {
					testInstrumentationRunner 'android.test.InstrumenatationTestRunner'
				}
			}
		}

	10>testInstrumentationRunnerArguments
		这个是配合上一个属性用的，用来配置testInstrumentation Runner使用的参数，其实最终使用的都是adb shell am instrument这个命令。其中的参数就是我们使用-e标记指定的那些，所以这里使用testrumentationRunnerArguments参数都会被转换传递给am instrument这个命令使用，也就是转为-e key value这种方式：
		android {
			productFlavors {
				google {
					testInstrumentationRunnerArguments.put ("coverage","true");
				}
			}
		}

	11>versionCode和versionName
		配置渠道的版本号和版本名

	12>useJack
		boolean用于标记是否启用jack和jill这个全新的高性能的编译器，默认为false

	13>dimension
		dimension是productFlavor的一个属性，接受一个字符串作为该ProductFlavor的维度。可以简单理解为对ProductFlavor进行分组，比如free和paid可以认为他们都是属于版本（version）的，而x86和arm是属于架构（abi），这样就把他们分成两组。而dimension接受的参数就是我们分组的组名，也是纬度名称。纬度名称不是随便指定的，我们在使用它们之前，必须要先声明，折合Java的变量声明差不多，要先定义好才能使用，使用Android对象的flavorDimensions方法声明
		flavorDimensions是我们使用android{}里的方法，他和productFlavors{}是平级的，一定要先使用flavorDimensions声明纬度，才能在ProductFlavor中使用：
		该方法可以接受一个可变得字符串类型的参数，所以我们可以同时制定多个维度，但是一定要记住，这些纬度是有顺序的，是有优先级的。第一个参数的优先级最大，其次是第二个，以此类推，所以声明之前一定要根据自己的需求指定好顺序：
		android {
			flavorDimensions "abi","version"
		}
		如上例子，最后生成的variant（构建产物）会被如下几个productFlavor对象配置。
		（1）Android里的defaultConfig配置
		（2）abi维度的ProductFlavor，被dimension配置标记为abi的ProductFlavor。
		（3）version维度的ProductFlavor，被dimension配置标记为version的ProductFlavor。
		维度的优先级很重要，高优先级的flavor会替换掉地优先级的资源、代码、配置等，在例子中，优先级为abi>version>defaultConfig，声明维度之后可以在ProductFlavor中使用：
		
  android {
			flavorDimensions "abi","version"
			productFlavors {
				free {
					demension 'version'
				}
				paid {
					dimension 'version'
				}
				x86 {
					dimension 'abi'
				}
				arm {
					dimension 'abi'
				}
			}
		}
		通过dimension指定ProductFlavor所属的维度，Android Gradle会为我们生成相应的Task、SourceSet、Dependencies等，之前我们说一个构建产物（variant）= BuildTyped+ProductFlavor，现在ProductFlavor这个维度又被我们通过dimension细化分组，所以就多了一些维度，现在构建产物（variant）= BuildType+Abi+Version了

android {
		lintOptions {
			check 'NewApi'
		}
	}
	NewApi就是一个issue id，Lint提供了很多可用的issue id，可以在终端输入lint --list查看所有可用的id
	check属性是一个Set集合，可以直接给它赋值一个Set集合达到配置的目的如下：
	
android {
		lintOptions {
			def checkSet = new HashSet<String>()
			checkSet.add("NewApi");
			checkSet.add("InlinedApi")
			check = checkSet
		}
	}
	或者：
	android {
		lintOptions {
			check 'InlinedApi','NewApi'
		}
	}

android {
		lintOptions {
			htmlOutput new File("${buildDir}/lintReports/lint-results.html")
		}
	}