乙巳🐍年

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

这一章主要针对项目中可以用到的一些实用功能来介绍 Android Gradle，比如如何隐藏我们的证书文件，降低风险；如何批量修改生成的 apk 文件名，这样我们就可以修改成我们需要的，从文件名中就可以看到渠道，版本号以及生成日期等信息，这多方便啊；还有其他突破 65535 方法的限制等等。

9.1 使用共享库

android 的包，比如 android.app, android.content, android.view, 以及 android.widget等，这些是默认就包含在android sdk库里的，所有的应用都可以直接使用它们，系统会帮我们会自动链接他们，不会出现找不到相关类的情况。还有一些库，比如 com.google.android.maps、android.test.runner 等，这些库是独立的，并不会被系统自动链接，所以我们要使用他们的话，就需要单独进行生成使用，这类库我们称之为共享库。

在 AndroidManifest 文件中，我们可以通过来指定我们要使用的库

这样我们就声明了我们需要使用 maps 这个共享库，声明之后，在安装生成的APK包的时候，系统会根据我们的定义，帮我们检测我们的手机系统是否有我们需要的共享库，因为我们设置的android:required=“true”，是必须，如果手机系统不满足，将不能安装该应用。

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

记录

在 build.gradle.kts 添加 maven 仓库

1
2
3
4
5
6

repositories {
    maven {
        url = uri("https://mirrors.cloud.tencent.com/nexus/repository/maven-public/")
        // 或者 setUrl("http://maven.aliyun.com/nexus/content/groups/public/")
    }
}