Android多渠道打包相关介绍

1、多渠道打包概述

因为国内存在着有众多的应用市场，在不一样的应用市场可能有不一样的统计需求，为此Android开发人员须要为每一个应用市场发布一个安装包，这里就引出了Android的多渠道打包。在安装包中添加不一样的标识，以此区分各个渠道，方便统计app在市场的各类效果。

所以，每当发新版本时，市场会提供一个渠道列表，Android RD会根据这些渠道相应地生成等量的渠道包。随着渠道愈来愈多，为了提升渠道打包的效率，所以催生了对多渠道打包的方式的研究。

本篇文章主要总结一下多渠道打包的相关知识以及美团的新旧两种多渠道打包方案。

2、渠道包生成

Maven方式: 每打一个包都要执行一遍构建过程，效率过低;

apktool: 虽然不须要从新构建，但对每一个包都要从新签名；

随着渠道包的增多，每次打包动辄几个小时，以上两种方式的效率过低。

关于这两种打包方式详见：美团Android自动化之旅—生成渠道包

META-INF添加空文件

这是美团为了提升打包效率而提出的一种新的多渠道打包方式，不须要从新构建，也不须要从新签名。

介绍

经过解压apk，根目录下会有一个META-INF目录，在该目录下添加空文件，能够不用从新签名应用。所以，经过为不一样渠道的应用添加不一样的空文件，能够惟一标识一个渠道。

具体步骤

• 利用python代码用来给apk添加空的渠道文件

• 在Java代码中读取空渠道文件名，识别渠道

具体代码在上面美团生成多渠道包的连接中有详细给出。

Walle

Walle（瓦力）：Android Signature V2 Scheme签名下的新一代渠道包打包神器

瓦力经过在Apk中的APK Signature Block区块添加自定义的渠道信息来生成渠道包，从而提升了渠道包生成效率，能够做为单机工具来使用，也能够部署在HTTP服务器上来实时处理渠道包Apk的升级网络请求。

原理介绍

Android 7.0（Nougat）引入一项新的应用签名方案APK Signature Scheme v2，它是一个对全文件进行签名的方案，能提供更快的应用安装时间、对未受权APK文件的更改提供更多保护，在默认状况下，Android Gradle 2.2.0插件会使用APK Signature Scheme v2和传统签名方案来签署你的应用。

新应用签名方案的签名信息会被保存在区块（APK Signing Block）中， 而区块（Contents of ZIP entries）、区块（ZIP Central Directory）、区块（ZIP End of Central Directory）是受保护的，在签名后任何对其的修改都逃不过新的应用签名方案的检查。

以前的渠道包生成方案是经过在META-INF目录下添加空文件的打包方式在Signature Scheme v2的签名方式下不可以使用了，由于META-INF已经被列入了保护区了，向META-INF添加空文件的方案会对上面受保护的三个区块都有影响。

经过上面描述发现区块（APK Signing Block）是不受签名校验规则保护的，所以Walle正是经过在该区块作文章，写入渠道信息。

具体步骤

• 对新的应用签名方案生成的APK包中区块（APK Signing Block）写入渠道信息，并保存在APK中

• APK在安装过程当中进行的签名校验，是忽略咱们添加的渠道信息的，这样就能正常安装了

• 在App运行阶段，能够经过ZIP的End of central directory、Central directory等结构中的信息找到咱们本身添加的渠道信息，从而实现获取渠道信息的功能

最终，每打一个渠道包只需复制一个APK，而后在APK中添加一个渠道信息便可，这种打包方式速度很是快。

使用方式

• Gradle插件方式，方便快速集成

• 命令行方式，最大化知足各类自定义需求

关于Walle两种使用方式的详细步骤，参见：Android使用walle多渠道打包

3、渠道包适配

上述多渠道打包方式解决了打包慢的问题，可是随着渠道愈来愈多，不一样渠道对应用的要求也不尽相同。

例如，有的渠道要求app的应用名不一样，有些渠道要求应用不能使用第三方统计工具，有些渠道要求应用不能自动更新。

以前的作法是为每一个须要适配的渠道建立一个Git分支，发版时再切换到相应的分支，并合并主分支的代码。适配的渠道比较少的话这种方式还能够接受，随着适配渠道的增多，这种方式就变得不可取。

幸亏Gradle flavor，能够知足渠道适配的需求，只须要经过配置Gradle便可以实现多渠道的适配工做，省心省力。

Flavor

先来看build.gradle文件中的一段代码：

android {
    ....

    productFlavors {
        flavor1 {
            minSdkVersion 14
        }
    }
}
复制代码

上例定义了一个flavor：flavor1，并指定了应用的minSdkVersion为14（固然还能够配置更多的属性，具体可参考相关文档）。与此同时，Gradle还会为该flavor关联对应的sourceSet，默认位置为src/<flavorName>目录，对应到本例就是src/flavor1。

接下来，要作的就是根据具体的需求在build.gradle文件中配置flavor，并添加必要的代码和资源文件。以flavor1为例，运行gradle assembleFlavor1命令既可生成所需的适配包。经过适配不一样的flavor便可以生成不一样的渠道包，但该方式生成渠道包的方式须要重复编译构建。

具体示例

使用不一样的包名

productFlavors {
    qq {
        applicationId "com.hello.group.qq"
    }
}
复制代码

面的代码添加了一个名为qq的flavor，并指定了应用的包名为com.hello.group.qq，运行gradle assembleqq命令便可生成qq适配包。

使用不一样的应用名

Gradle在构建应用时，会优先使用flavor所属sourceSet中的同名资源。因此，解决思路就是在flavor的sourceSet中添加同名的字符串资源，以覆盖默认的资源。

首先，在build.gradle配置文件中添加以下flavor：

android {
    productFlavors {
        wandoujia { 
        }
    }
}
复制代码

上面的配置会默认src/wandoujia目录为wandoujia flavor的sourceSet。

接下来，在src目录内建立wandoujia目录，并添加以下应用名字符串资源（src/wandoujia/res/values/appname.xml）：

<resources>
    <string name="app_name">wandoujia_app</string>
</resources>
复制代码

默认的应用名字符串资源以下（src/main/res/values/strings.xml）:

<resources>
    <string name="app_name">origin_app</string>
</resources>
复制代码

最后，运行gradle assembleWandoujia命令便可生成应用名为wandoujia_app的应用了。

wandoujia包下不使用strings.xml 名是由于会出现文件重复，默认的main 文件夹里存在的文件在其余适配目录中不容许出现相同文件名的文件。

更多flavor适配示例，参见：美团Android自动化之旅—适配渠道包

以上就是最近了解关于多渠道打包的相关知识的总结。

想要实现更多自定义适配多渠道包的需求，还要更多的了解Gradle相关知识。