丙午🐎年

说起 Gradle 的插件，不得不感叹 Gradle 的设计。Gradle 的设计非常好，它本身提供一些基本的概念和整体核心的框架，其他用于描述真实的使用场景逻辑都以插件扩展的方式来实现，这样 Gradle 的设计者就可以抽象的方式提供一个核心的框架，其他具体的功能和业务等都通过插件扩展的方式来实现，比如构建 Java 应用，就是通过J ava 插件来实现的。

Gradle 本身内置了很多常用的插件，这些插件基本上能帮我们做大部分的工作，但是也有一些Gradle本身没有内置，这时候就需要我们自己去扩展现有的插件或者自己自定义的插件来达到我们的目的，比如Android Gradle插件就是基于内置的Java插件实现的

5.1 插件是什么

插件是为了解决某一问题域构建甚至各种问题，在 Gradle 的基础上，提供的可复用的扩展。

把插件应用到你的项目中，插件会扩展项目的功能，帮助你在项目的构建过程中做很多事情：

1. 可以添加任务到你的项目中，帮你完成一些事情，比如测试，比如编译，比如打包。
2. 可以添加依赖配置到你的项目中，我们可以通过他们配置我们项目在构建过程中需要的依赖，比如我们编译的时候依赖的第三方库等
3. 可以向项目中现有的对象类型添加新的扩展熟悉、方法等，让你可以使用他们帮助我们配置、优化构建。比如 android{}这个配置块就是 Android Gradle 插件为 Project 对象添加的一个扩展。
4. 可以对项目进行一些约定，比如应用Java插件之后，约定src/main/java目录下是我们的源代码存放位置，在编译的时候也是编译这个目录下的Java源代文件。

Android Gradle 为我们提供了大量的 DSL，我们使用这些 DSL 定义配置我们的工程以满足我们项目中不同的需求。这些DSL有很多，在上一章演示 Android Gradle 工程示例的时候，我们已经大概介绍了 compileSdkVersion、buildToolsVersion以及 defaultConfig 等，这一章我们再详细介绍一些常用的 DSL 配置，这些配有有签名信息、构建类型、代码混淆、zipAlign 对齐压缩等。

8.1 defaultConfig 默认配置

defaultConfig 是 android 对象中的一个配置块，负责定义所有的默认配置，它是一个 ProductFlavor，如果一个 ProductFlavor 没有被特殊定义配置的话，默认就会使用 defaultConfig{} 块指定的配置，比如包名、版本号、版本名称等。

一个基本上的 defaultConfig 配置如下：

以上示例配置了Android 开发的基本信息，可以满足一个基本的Android App开发，下面我们对它的一些配置进行一个详细的说明。

我们已经知道，Gradle 是一个非常灵活的构建框架，他提供了构建的基础核心，为了对具体的业务进行构建，Gradle在此基础上提供了插件的概念，这样就能基于 Gradle 进行很好的扩展，而不改变其核心基础，又能满足不同业务的需要，这也是我们在架构中参考的。

我们做过Java开发都了解，它的大体流程都差不多，无非就是依赖第三方库，编译源文件，进行单元测试，打包发布等等，每个Java工程都差不多，Gradle为了不让我们在每个Java工程里都做这些重复的劳动工作，为了我们提供了非常核心、常用的Java,我们只要应用它，就可以非常轻松的构建出一个项目了。

6.1 如何应用

基于我们之前讲的应用插件章节，很容易的应用 Java 插件，我们常用的方式就是使用简称应用：

apply plugin: 'java'

通过以上脚本应用之后，Java 插件会为你的工程添加很多有用的默认设置和约定，比如源代码的位置，单元测试代码的位置，资源文件的位置等等，一般情况下我们最好都遵循它的默认设置，这样做的好处一来是我们不用写太多的脚本来自定义，二来便于团队协作，因为这是约定俗成的，大家都容易理解。

因为我们发布或者推广的渠道不同，就造成了我们的 Android App 可能会有很多个，因为我们需要细分他们，才能针对不同的渠道做不同的处理，比如统计跟踪、是否升级、App 名字是否一致等等。尤其在国内这个各种应用市场百家争鸣的时代，我们需要发布的 App 渠道甚至多个好几百个，而且各有各的特殊处理，所以这就更需要我们有一套自动的满足多渠道构建的工具来帮我们解决这个问题，有了 Android Gradle 的 Flavor 后，我们就可以完美的解决以上问题，并且可以实现批量自动化。这一章主要介绍多渠道构建的基本原理，然后使用 Flurry 和友盟这两个最常用的分析统计平台作为例子来演示多渠道构建，接着我们介绍下 Flavor 的每个配置的用法，让大家可以根据需求定制自己的每个渠道，最后我们会介绍一种快速打包上百个渠道的方法，以提高多渠道构建的效率。

11.1 多渠道构建的基本原理

在Android Gradle中，定义了一个叫 Build Variant 的概念，直译是构建变体，我喜欢叫它为构件-构建的产物(Apk),一个Build Variant=Build Type+Product Flavor，Build Type 就是我们构建的类型，比如 release 和 debug，Product Flavor 就是我们构建的渠道，比如 baidu，google 等等，他们加起来就是 baiduRelease，baiduDebug，googleRelease，googleDebug，共有这几种组合的构件产出，Product Flavor 也就是我们多渠道构建的基础，下面我们看看如何新增一个Product Flavor。

对于研发来说，测试永远都是绕不开的，通过测试我们可以减少 bug 率，提高产品的质量。测试有黑白之分，我们这里主要讲白盒测试，也就是基于现有代码逻辑的测试，比如单元测试等。

Android 为测试提供了很好的支持，既可以使用传统的 Junit 测试，又可以使用 Android 提供的 Instrument 测试，这一章我们主要讲 Android Gradle 和 Android 测试之间的配合和结合，期间会涉及一些单元测试用例或者对一些测试框架的使用，但是主要介绍点还是 Android Gradle 和 Android 测试，对于 Android 测试本身介绍不多，关于 Android 测试本身，比如 Activity 等四大组件测试、UI 自动化测试、espresso UI 测试框架等可以参考官方文档。

12.1 基本概念

在 Android Gradle 中，测试应用相关已经被作为项目的一部分，而不再是一个单元的测试工程了，这对我们一起管理引用代码比较方便。它是一个 SourceSet，这个我们之前有过介绍，比如有 main SourceSet，对测试来说有 androidTest SourceSet。当我们使用 Android Studio 新建一个项目的时候，会帮我们默认生成main和androidTest SourceSet，路径和 main 相似，是src/androidTest/，当我们运行测试的时候，androidTest SourceSet 会被构建成一个可以安装到设备上的测试 Apk，这个测试 Apk 里有很多我们写好的测试用例，他们会被执行，来测试我们的 App。