[发明专利]应用多渠道打包方法、装置、计算机设备及存储介质

说明书

本申请公开了一种应用多渠道打包方法、装置、计算机设备及存储介质。该方法包括：获取apk安装包，通过第一脚本将apk安装包的后缀名调整至指定后缀名，并进行解压得到解压后文件；获取解压后文件中包括的多个子文件并分别进行SHA1运算，得到一一对应的文件摘要；将文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值并存储至子文件的目录中；在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；通过第三脚本将解压文件进行压缩，得到渠道包。该方法实现了渠道包打包自动化，简化了打渠道包的过程，提高了打包效率和成功率。

技术领域

本申请涉及安卓应用开发技术领域，尤其涉及一种应用多渠道打包方法、装置、计算机设备及存储介质。

背景技术

目前，Android应用(即安卓系统中的应用程序)在进行多渠道打包时，一般采用如下方案：

1)在AndroidManifest.xml文件中定义mate-data标签，设置渠道占位符；

2)在工程build.gradle文件下的productFlavors定义渠道号(其中，gradle文件是一个项目自动化构建工具；productFlavors用于定义产品的特性)；

采取上述方式进行多渠道打包时，每次增加一个渠道包时，需要修改build.gradle，还需在productFlavors定义渠道号，也即当需要配置多个渠道包就会执行相同次数的打包签名的操作，导致操作复杂。具体的，当每次开始打包都会修改AndroidManifest.xml文件，将渠道占位符替换为真实地渠道名称，然后在执行编译，开始一次完整的打包流程。所以多个渠道编译打包耗时＝每个渠道包编译的耗时总和＝(或者近似等于)N*一个渠道的编译打包时间，其中N为渠道总数目。而且在打包的过程中不能修改代码，以避免出错。通过这种方式实现多渠道打包非常耗时，生产效率很低。

发明内容

本申请提供了一种应用多渠道打包方法、装置、计算机设备及存储介质，旨在解决现有技术中进行多渠道打包时，每次增加一个渠道包时，需要修改build.gradle，还需在productFlavors定义渠道号，而且打包的过程中不能修改代码，导致打包效率低下，且容易出错的问题。

第一方面，本申请提供了一种应用多渠道打包方法，其包括：

获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；

获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；

将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；

在子文件的目录中通过第二脚本创建渠道标示文件，对应根据待配置的渠道号对渠道标示文件进行命名，得到包括渠道数据的解压文件；

通过第三脚本将解压文件进行压缩，得到渠道包。

第二方面，本申请提供了一种应用多渠道打包装置，其包括：

解压单元，用于获取apk安装包，通过第一脚本将apk安装包的后缀名调整至预先设置的指定后缀名，并进行解压得到解压后文件；

文件摘要获取单元，用于获取解压后文件中包括的多个子文件，将子文件分别进行SHA1运算，得到一一对应的文件摘要；

编码单元，用于将与子文件一一对应的文件摘要分别进行Base64编码，得到与文件摘要一一对应的哈希值，将与文件摘要一一对应的哈希值存储至子文件的目录中；