背景

在发布apk时，经常遇到需要发布多个版本，每个版本均有细微差异的情况，称为多渠道打包，Android Studio中提供了利用Gradle实现多渠道打包的功能。

原理

我们知道，apk的打包过程分7步：

1、打包资源文件，生成R.java文件

2、处理aidl文件，生成相应java 文件

3、编译工程源代码，生成相应class 文件

4、转换所有class文件，生成classes.dex文件

5、打包生成apk

6、对apk文件进行签名

7、对签名后的apk文件进行对齐处理

多渠道打包，就是对这个过程进行一定程度的干涉，Android Studio的Gradle可以通过设置productFlavors来实现这个功能，通过自定义buildTypes，在打包时把主目录与自定义的buildType目录合并，每个buildType对应一个渠道，实现多渠道打包。

buildTypes与文件目录

在实际操作中，针对不同的待打包文件，还要采取不同的方式：

1、配置文件，增设参数，在打包时读取不同版本的参数；

2、资源文件，各版本准备与主版本不同的资源文件，在打包时合并或置换；

3、代码文件，各版本准备自己需要的代码文件，或在代码中针对不同的版本修改业务逻辑；

规则

1、资源文件的覆盖，图片、音频、 XML 类型的 Drawable 等资源文件，将会进行文件级的覆盖。

drawable资源文件会直接覆盖

2、资源文件的合并，字符串、颜色值、整型等资源以及 AndroidManifest.xml ，将会进行元素级的覆盖（不同版本只要写与主版本不同的元素即可）。

字符串等xml资源，会覆盖元素

3、代码资源的准备，代码文件不会覆盖或合并，同一个类文件， 在不同目录（buildTypes 、 productFlavors 、 main）中只能存在一次，否则会有类重复的错误。

在main中不能有待分版的代码文件

这种做法的问题是，由于main目录下不能有这个代码文件，所以每个版本都需要维护一个本版本的代码文件，在后续开发中会有严重的代码文件冗余问题。

如果代码变动不大，没必要使用多个代码文件，可以在gradle中定义一个与版本有关的常量，在代码中根据这个常量判断版本，输出不同的业务逻辑

通过常量设置不同版本的代码逻辑

需要说明的是，在制作不同版本的java文件时，会发现图标不是熟悉的java代码的蓝色图标，只是普通的文件夹图标，里面也不能右键创建package，这是因为当前的Build Variants不是当前版本，AS并没有使用那部分代码，在Build Variants中更换为当前版本即可。

根据Build Variant使用不同的代码

4、覆盖等级为：buildTypes > productFlavors > main。

实践

一个从零开始做gradle多渠道打包的流程如下：

首先，我们要为每个版本创建BuildTypes及对应的文件目录

buildTypes与文件目录

点开左下角的Build Variant，可以看到多版本的配置已经生效

多版本已生效

根据上文所述，根据各版本需要更换资源文件

更换资源文件

编写xml资源中待替换的元素

待替换的元素

制作各版本的java代码文件

各版本的java代码文件

再次强调，这种方式下，在main中不能有同名代码文件。

或者自定义版本常量，在main的代码中编写各版本的业务逻辑

根据版本实现不同的业务逻辑

打包时，可以选择多个版本一起打包

同时打包

生成多个apk文件

生成apk文件

一个简单的多渠道打包过程就完成了。

速度问题与快速多渠道打包

Gradle多渠道打包最大的问题是速度太慢，像上文那样同时打包3个apk，其实就是依次打3个apk，消耗的时间远远超过打包1个，如果待发布的产品版本过多（几十个），一次打包消耗的时间就很可观了，还依赖gradle就不合适了。

这种情况下，一个好的作法是先用gradle打包，把得到的apk当做压缩包，用自定义工具去直接修改apk文件。

所以快速多渠道打包的基本原理是：先制作1个基础apk，然后自己写一个配置工具，去批量地解压缩基础apk并修改文件，从而取得较快的发布速度。

在Github上有一个很实用的开源项目，快速多渠道打包开源项目AndroidMultiChannelBuildTool，是使用Python实现的，使用也很简单，本文在此不再赘述。

利用多渠道辅助开发

Gradle多渠道打包不限于制作apk，在debug时也会起作用，我们可以利用这一点辅助开发。

例如，我们可以在开发过程中模拟后台数据，这样可以在后台服务接口开发滞后时，先完成Android端的业务开发。

前面说过，在多渠道打包会出现多个Build Variants

在debug时选择不同的版本

在这里选择需要debug的版本，就可以mock模拟数据。

利用这样的原理，我们可以制作一个mock版本，在开发前期使用mock版本模拟返回服务端数据，在连接后台调试和产品发布时，使用prod版本发布，而他们使用的业务逻辑都是main中的同一套代码，所以能很好的加速开发。

mock模拟数据

在服务端尚不能提供数据时，这可以帮助我们先完成Android端的开发，详情可以参考Android Studio Flavors的妙用

参考文献

本文参考了Gradle Plugin User Guide的第5节Build Variants，英文不好的童鞋可以去读Android build.gradle配置进阶，简短清晰。

本文参考了Android Studio Flavors的妙用。