Gradle多渠道打包的原理、实践与辅助开发

背景

在发布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对应一个渠道,实现多渠道打包。

Gradle多渠道打包的原理、实践与辅助开发_第1张图片
buildTypes与文件目录

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

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

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

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

规则

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

Gradle多渠道打包的原理、实践与辅助开发_第2张图片
drawable资源文件会直接覆盖

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

Gradle多渠道打包的原理、实践与辅助开发_第3张图片
字符串等xml资源,会覆盖元素

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

Gradle多渠道打包的原理、实践与辅助开发_第4张图片
在main中不能有待分版的代码文件

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

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

Gradle多渠道打包的原理、实践与辅助开发_第5张图片
通过常量设置不同版本的代码逻辑

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

Gradle多渠道打包的原理、实践与辅助开发_第6张图片
根据Build Variant使用不同的代码

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

实践

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

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

Gradle多渠道打包的原理、实践与辅助开发_第7张图片
buildTypes与文件目录

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

Gradle多渠道打包的原理、实践与辅助开发_第8张图片
多版本已生效

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

Gradle多渠道打包的原理、实践与辅助开发_第9张图片
更换资源文件

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

Gradle多渠道打包的原理、实践与辅助开发_第10张图片
待替换的元素

制作各版本的java代码文件

Gradle多渠道打包的原理、实践与辅助开发_第11张图片
各版本的java代码文件

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

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

Gradle多渠道打包的原理、实践与辅助开发_第12张图片
根据版本实现不同的业务逻辑

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

Gradle多渠道打包的原理、实践与辅助开发_第13张图片
同时打包

生成多个apk文件

Gradle多渠道打包的原理、实践与辅助开发_第14张图片
生成apk文件

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

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

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

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

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

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

利用多渠道辅助开发

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

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

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

Gradle多渠道打包的原理、实践与辅助开发_第15张图片
在debug时选择不同的版本

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

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

Gradle多渠道打包的原理、实践与辅助开发_第16张图片
mock模拟数据

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

参考文献

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

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

你可能感兴趣的:(Gradle多渠道打包的原理、实践与辅助开发)