Gradle for Android应用

概述

我们都已经知道Gradle是基于JVM的一种构建工具。它是基于Groovy语言的声明式构建，还支持java，C，C++等项目。我们在进行Android开发时，需要在Android Studio中对build.gradle文件进行配置。但是AS与Gradle并没有直接的关系，这只是Google在AS中选择了Gradle作为项目的构建工具，为了Gradle能在AS上应用，Google实现了AS上支持Gradle的插件，叫做Andorid Gradle Plugin。因为AS应用了这个插件，所以能够支持Gradle构建项目。我们可以在项目根目录下的build.gradle文件中，看到：
classpath ‘com.android.tools.build:gradle:2.2.2’
这就是依赖gradle插件的代码，后面的版本号代表的是android gradle plugin的版本，并不是Gradle的版本，与Gradle官方没有关系。

Gradle 文件

一个项目中，会有一个setting.gradle，根目录有build.gradle文件，每个Module都有自己的一个build.gradle文件。
setting.gradle：这个文件定义了哪些module应该被加入编译过程，对于单个module的项目可以不用这个文件，但是对于multimodule的项目我们就需要这个文件，否则gradle不知道加载哪些项目，该文件的代码在初始化阶段就会被执行。
根目录的build.gradle：根目录的build.gradle文件配置最终会被应用到所有项目中。典型配置如下：

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

● buildscript ：定义了Android编译工具的类路径，repositories 中，jcenter是一个著名的Maven仓库。
● allprojects：定义的属性会被应用到所有moudle中，但是为了保证每个项目的独立性，我们一般不需要修改。
● 每个module中的build.gradle：针对每个moudle的配置。

下面针对module中build.gradle文件配置信息说明

apply plugin：声明了项目的类型，这里只Android。

android：设置编译Andorid项目的参数，接下来，构建的android项目的所有配置都在这里完成。
● defaultConfig：程序的默认配置，如果在AndroidMainfest.xml里面定义了与这里相同的属性，会以这里的为主。
applicationId：我们曾经在AndroidMainfest.xml中，定义的包名有两个用途：一个是作为程序唯一识别的ID，防止在同一个手机装两个一样的程序；另一个就是作为R资源类的包名。以前修改这个包名，会导致所有引用R资源类的地方都要修改。但是现在我们修改applicationId属性只会修改当前程序的ID，而不会修改源码中资源的引用。
resConfig：针对app的本地化开发进行资源过滤，当工程依赖v7和Google服务时，非常有效。
resConfigs “zh”,”en” //定义包含的语言资源
resConfigs “mdpi”, “hdpi” //定义包含的尺寸资源

● lintOptions：配置lint检查，一般设置：abortOnError false
● sourceSets：配置本地.so库，如下：

    sourceSets {        main {            jniLibs.srcDirs = ['src/main/jniLibs']  //jniLibs 表示.so存放的目录        }    }

● signingConfigs：配置签名信息。
● buildTypes：定义了编译类型，针对每个类型我们可以有不同的编译配置，不同的配置对应有不同的编译命令。默认有debug，release的类型。可以在不同类型中，设置各自的配置要求，如下。
applicationIdSuffix：与applicationId相关，给applicationId添加后缀，用来配置不同的程序 ID，使得在同一部设备中可以安装多个相同的应用。

versionNameSuffix：与上同理，给versionName添加后缀，定义不同的版本名称。获得当 前渠道版本的的名称，通过variant.getVersionName()。

buildConfigField：根据编译版本的不同，动态的控制代码的处理逻辑。设置后会在BuildConfig类中，动态生成对应的属性值。如下：

buildTypes {        debug {            buildConfigField("String","UPDATE_URL","\"http://****/\"")            ...        }        release {            buildConfigField("String","UPDATE_URL","\"https://****/\"")            ...        }        }

manifestPlaceholders：我们可以在AndroidManifest中定义一个变量，在build.gradle中动 态的替换掉。例如，动态替换友盟的appkey。
首先在AndroidManifest中定义一个变量：

<meta-data                android:name="UMENG_APPKEY"                android:value="${umeng_app_key}"/>

然后，在build.gradle文件中根据不同的环境，生成不同的appkey的apk。

buildTypes {        debug {         manifestPlaceholders = [umeng_app_key: "你替代的内容"]        }        release {     　　manifestPlaceholders = [umeng_app_key: "你替代的内容"]        }        develop {    　　 manifestPlaceholders = [umeng_app_key: "你替代的内容"]        }       }

替换多个变量的方法：
AndroidManifest中：

<meta-data            android:name="UMENG_APPKEY"            android:value="${umeng_app_key}"/><meta-data            android:name="UMENG_SECRET"            android:value="${umeng_app_secret}"/>

build.gradle文件中：

buildTypes {        debug {        manifestPlaceholders = [umeng_app_key: "XXX",umeng_app_secret:"XXX"]        }        ... }

● defaultPublishConfig： 通过它可以配置项目在构建时，编译的版本类性，默认是“release”，当在module B 中build文件上配置defaultPublishConfig “debug”时，在发A的release版本时，b的版本仍为debug版本，这点需要注意。
● publishNonDefault：相对于上面defaultPublishConfig，它可以根据编译的版本类型来选择编译版本。如在module B中配置publishNonDefault true，表示b的版本根据module A的编译类型来选择打包版本。

dependencies：定义了项目的依赖库，我们在引用库的时候，每个库名称包含三个元素：组名:库名称:版本号，如下：

dependencies {    compile 'com.android.support:appcompat-v7:23.4.0'    compile 'com.jakewharton:butterknife:8.1.0'}

还可以引用本地的jar包，如下：

dependencies {    //单文件依赖    compile files('libs/umeng-analytics-v6.0.1.jar')    //某个文件夹下面全部依赖    compile fileTree(include: ['*.jar'], dir: 'libs')    //依赖某个项目    compile project(path: ':pickerview')    //依赖某个项目对应的版本    releaseCompile project(path:':repository',configuration:'release')    debugCompile project(path:':repository',configuration:'debug')}

六种依赖类型：
Compile
compile是对所有的build type以及favlors都会参与编译并且打包到最终的apk文件中。
Provided
Provided是对所有的build type 以及favlors只在编译时使用，类似eclipse中的external-libs，只参与编译，不打包到最终的apk。
APK
只会打包到apk文件中，而不参与编译，所以不能在代码中直接调用jar中的类或方法，否则在编译时会报错。
Test compile
Test compile 仅仅是针对单元测试代码的编译以及最终打包测试apk时有效，而对正常的debug或者release apk 包不起作用。
Debug compile
Debug complie 仅仅针对debug模式的编译和最终的debug apk 打包
Release compile
Release compile 仅仅针对Release 模式的编译和最终的Release apk打包。

Gradle Wrapper
Gradle不断的在发展，新的版本难免会出现对以前的项目兼容性的问题，为了避免安装所有的版本gradle，于是推出了Gradle Wrapper。gradlw wrapper包含一些脚本文件和针对不同系统下面的运行文件。wrapper有版本区分，但是并不需要你手动下载，当你运行脚本的时候，如果本地没有会自动下载对应版本文件。通过它每个项目你可以支持不同的Gradle版本来构建项目。我们可以在终端中测试版本好，首先切换到项目所在的目录，然后输入gradlew -v，就可以查看当前项目所用的gradle版本，如果是第一次执行该命令，会去下载对应的版本。
关于gradlew 的几个命令：
● ./gradlew -v 版本号
● ./gradlew clean 清除所有的编译输出文件，比如apk。
● ./gradlew build 检查依赖并编译打包，这里注意的是 ./gradlew build 命令把 debug、release 环境的包都打出来。
● ./gradlew assembleDebug 编译并打Debug包
● ./gradlew assembleRelease 编译并打Release的包
以上命令都是在终端里执行，并且必须要切换到所在项目的根目录下执行。

参考博客：http://www.flysnow.org/2015/03/30/manage-your-android-project-with-gradle.html