丙午🐎年

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

8.1 defaultConfig 默认配置

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

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

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

因为我们发布或者推广的渠道不同，就造成了我们的 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。

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

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

6.1 如何应用

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

apply plugin: 'java'

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

对于研发来说，测试永远都是绕不开的，通过测试我们可以减少 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。

Android 的多项目和其他基于 Gradle 构建的多项目是差不多，比如 Java 多项目、Groovy 多项目，他们本身都是 Gradle 的多项目构建，唯一的区别是项目本身属性，比如这个项目是 Java 库、那个是 Android App 项目等等。

这一章我们简单的介绍下 Android 不同类型的项目，他们如何设置，如何引用以及库项目如何单独发布，像因多项目导致的 65535 等问题我们已经在上一章节做了介绍，这里就不再重复了。

10.1 Android 项目区别

Android 的项目一般分为 库项目、应用项目、测试项目，Android Gradle 根据他们分别有 3 种插件
com.android.library、com.android.application、com.android.test。

库项目一般和我们的 Java 库非常相似，它比 Java 多的是一些 Android 特有的资源等配置。一般一些具有公用特性的类、资源等可以抽象成一个库工程，这样他们就可以被其他不用的项目引用；还有一种情况，比如我们的工程非常负责，我们可以根据我们业务，把我们的工程分成一个个的库项目，然后通过一个主的应用项目引用他们，组合起来，就是我们最终的产品->一个复杂的 App 了。