Android Studio 的 Gradle 使用简述

Gradle 的编译周期

编译过程分为三个阶段：

• 初始化阶段：创建 Project 对象，如果有多个build.gradle，也会创建多个project.

• 配置阶段：在这个阶段，会执行所有的编译脚本，同时还会创建project的所有的task，为后一个阶段做准备。

• 执行阶段：在这个阶段，gradle 会根据传入的参数决定如何执行这些task,真正action的执行代码就在这里.

Gradle Files

一个项目有一个setting.gradle、一个顶层的 build.gradle文件、每个Module 都有自己的一个build.gradle文件。

• setting.gradle

  这个 setting 文件定义了哪些module 应该被加入到编译过程，对于单个module 的项目可以不用这个文件，但是对于 multimodule 的项目我们就需要这个文件，否则gradle 不知道要加载哪些项目，这个文件的代码在初始化阶段就会被执行。

• root build.gradle

  顶层的build.gradle文件的配置最终会被应用到所有项目中。

• module build.gradle

  针对每个moudle 的配置，如果这里定义的选项和顶层build.gradle定义的相同，后者会被覆盖。

Gradle Wrapper

Gradle 不断的在发展，新的版本难免会对以往的项目有一些向后兼容性的问题，这个时候,gradle wrapper就应运而生了。

gradlw wrapper 包含一些脚本文件和针对不同系统下面的运行文件。在不同操作系统下面执行的脚本不同，在 Mac 系统下执行./gradlew …，在windows 下执行gradle.bat进行编译。

Android tasks

有四个基本的 task, Android 继承他们分别进行了自己的实现：

• assemble：对所有的 buildType 生成 apk 包。

• clean：移除所有的编译输出文件，比如apk

• check：执行lint检测编译。

• build：同时执行assemble和check命令

这些都是基本的命令，在实际项目中会根据不同的配置，会对这些task 设置不同的依赖。

比如 默认的 assmeble 会依赖 assembleDebug 和assembleRelease，如果直接执行assmeble，最后会编译debug和release 的所有版本出来。如果我们只需要编译debug 版本，我们可以运行assembleDebug。

除此之外还有一些常用的新增的其他命令，比如 install命令，会将编译后的apk 安装到连接的设备。

我们运行的许多命令除了会输出到命令行，还会在build文件夹下生产一份运行报告。比如check命令会生成lint-results.html.在build/outputs中。

BuildConfig

这个类相信大家都不会陌生，我们最常用的用法就是通过BuildConfig.DEBUG来判断当前的版本是否是debug版本，如果是就会输出一些只有在 debug 环境下才会执行的操作。

这个类就是由gradle 根据配置文件生成的。为什么gradle 可以直接生成一个Java 字节码类，这就得益于我们的 gradle 的编写语言是Groovy, Groovy 是一种 JVM 语言，JVM 语言的特征就是，虽然编写的语法不一样，但是他们最终都会编译成JVM 字节码文件。同是JVM 语言的还有 Scala,Kotlin 等等。

这个功能非常强大，我们可以通过在这里设置一些key-value对，这些key-value 对在不同编译类型的 apk 下的值不同，比如我们可以为debug 和release 两种环境定义不同的服务器。

Repositories

Repositories 就是代码仓库，这个相信大家都知道，我们平时的添加的一些 dependency 就是从这里下载的，Gradle 支持三种类型的仓库：Maven、Ivy和一些静态文件或者文件夹。

在编译的执行阶段，gradle 将会从仓库中取出对应需要的依赖文件，当然，gradle 本地也会有自己的缓存，不会每次都去取这些依赖。

gradle 支持多种 Maven 仓库，一般我们就是用共有的jCenter就可以了，有一些项目，可能是一些公司私有的仓库中的，这时候我们需要手动加入仓库连接。

Dependencies

我们在引用库的时候，每个库名称包含三个元素：组名:库名称:版本号

Library projects

如果我们要写一个library项目让其他的项目引用，我们的bubild.gradle的plugin 就不能是android plugin了，需要引用如下plugin
apply plugin: 'com.android.library'

引用的时候在setting文件中include即可。

如果我们不方便直接引用项目，需要通过文件的形式引用，我们也可以将项目打包成aar文件

Build Variants

在开发中我们可能会有这样的需求：

• 我们需要在debug 和 release 两种情况下配置不同的服务器地址；

• 当打市场渠道包的时候，我们可能需要打免费版、收费版，或者内部版、外部版的程序。

• 渠道首发包通常需要要求在欢迎页添加渠道的logo等等

• 为了让市场版和debug版同时存在于一个手机，我们需要编译的时候自动给debug版本不一样的包名。

这些需求都需要在编译的时候动态根据当前的编译类型输出不同样式的apk文件，这时候就是我们的buildType大展身手的时候了。

• Build Type

  android 默认的带有Debug和Release两种编译类型。

• Source sets

  每当创建一个新的build type 的时候，gradle 默认都会创建一个新的source set。我们可以建立与main文件夹同级的文件夹，根据编译类型的不同我们可以选择对某些源码直接进行替换（同文件名不同内容）。

Product flavors

前面我们都是针对同一份源码编译同一个程序的不同类型，如果我们需要针对同一份源码编译不同的程序（包名也不同），比如免费版和收费版，我们就需要Product flavors。

注意，Product flavors和Build Type是不一样的，而且他们的属性也不一样，所有的 product flavor 版本和defaultConfig 共享所有属性！

像Build type 一样，product flavor 也可以有自己的source set文件夹。除此之外，product flavor 和 build type 可以结合，他们的文件夹里面的文件优先级甚至高于单独的built type 和product flavor 文件夹的优先级。

如果你想对于 blue类型的release 版本有不同的图标，我们可以建立一个文件夹叫blueRelease，注意，这个顺序不能错，一定是 flavor+buildType 的形式。

更复杂的情况下，我们可能需要多个product 的维度进行组合，比如我想要 color 和 price 两个维度去构建程序，这时候我们就需要使用flavorDimensions

Signing configurations

如果我们打包市场版，一般需要输入我们的keystore数据。如果是debug版本，系统默认会帮我们配置这些信息。