一种高效的Android应用定制包批量打包方法与流程

一种高效的android应用定制包批量打包方法
技术领域
1.本发明涉及android 应用软件开发技术领域，尤其涉及一种高效的 android 应用定制包批量打包方法。


背景技术：

2.近年来，android 应用已经走进了我们生活的，很多手机、车机、平板电脑、跑步机、手表、pos 机等设备上运行的都是 android 应用软件。很多时候，android 应用开发者需要为多种软件分发渠道提供特定的渠道包，需要为各类用户、各类客户提供定制化的服务定制包。其中，渠道包打包方案已经比较成熟， 渠道包打包只与 android 应用软件签名有关，与 android 应用软件是否经过加固、是否经过混淆无关，渠道包打包工具修改渠道信息无需经过再次签名、加固，打包效率较高，android 应用软件开发行业内有开源的高效的渠道包打包工具。定制包打包，尤其是 b2b 领域，经常会有千人千面、企业专属定制等需求，定制包打包方案从最初的 ant 脚本 + 多目录区分资源，到后来的 gradle 脚本 + 多目录区分资源，再到后来的 gradle 多 flavor 的方式，很多公司内部也会自研高效率的定制包打包工具，目前使用最广泛的是 google 官方提供的多 flavor 的打包方案，行业内暂无开源的高效的定制包打包工具。
3.就多 flavor 打包方案而言，定制包打包牵涉到修改文字、图片甚至是功能，由于定制包必须进行签名，很多时候需要加固，如果每打一个定制包都需要进行一次加固和签名，批量打包需要耗费大量的时间，在研发过程中将会是巨大的时间成本投入，尤其是软件发布的过程中，遇到了一个紧急的 bug 进行了修复，即便是改了一行代码，也需要重新耗费大量的时间重新打包，除此之外，多 flavor 的维护需要研发人员参与，需要持续性投入研发成本。
4.单打包机，多 flavor 批量打包方案耗时：全量编译时间 + （差异化编译时间 +加固时间 + 签名时间） * 打包个数 / 线程数 * cpu 实际利用率。多 flavor 批量打包方案耗时主要在有加固需求的场景，如果 android 应用不需要加固，多 flavor 批量打包方案是很好的打包方案，但是它并不是一个通用性的高效的 android 应用定制包批量打包方案。
5.由于多 flavor 打包方案，依赖编译期中间产物，所以如果要做多台打包机分布式打包需要每台打包机都进行一次全量编译。


技术实现要素：

6.本发明的目的是为了解决现有技术中存在的缺点，而提出的一种高效的 android 应用定制包批量打包方法。
7.为实现上述目的，本发明采用了如下技术方案：一种高效的 android 应用定制包批量打包方法，包括服务端、前端管理平台、前端打包平台、ci持续集成服务模块、打包机、打包工具，文件服务器，所述打包工具包括资源准备模块、资源替换模块和重打包模块；
包括以下步骤：s100:资源管理；s101:制定资源替换规则文件并上传定制包资源至服务端；s102: 运营人员通过前端管理平台上传定制包资源；s103: 服务端根据前端管理平台上传的定制包资源，查询资源替换规则文件，根据规则存储定制包资源；s200:定制包批量打包；s211:前端打包平台触发打包；s212:服务端根据打包参数准备打包信息；s213: ci持续集成服务模块调度打包机，透传打包信息给打包机；s214: 打包机启动打包工具；s215: 打包工具根据打包信息拉取代码、拉取定制包资源；s221: 打包工具触发代码全量编译输出android 应用；s222: 打包工具的资源准备模块使用开源的 apktool工具反编译 android 应用；s223: 资源准备模块准备基础临时包 temp.apk；s224: 资源准备模块准备被替换的反编译后的资源包文件夹 temp_res；s225: 打包工具启动多线程，每个线程负责打一个打包，每个线程为一个打包任务，分发打包任务；s231: 每个打包任务中，资源准备模块拷贝一份基础临时包 temp.apk和资源包文件夹temp_res；s232: 每个打包任务根据打包信息执行资源替换模块，替换定制包资源；s233: 每个任务中，重打包模块把替换完成的资源包文件夹 temp_res 增量压缩到基础临时包 temp.apk 中；s234: 每个任务中，重打包模块把压缩完成的 android 应用软件包apk执行 zipalign工具进行字节对齐；s235: 每个任务中，重打包模块把最后生成的android 应用软件包 apk 进行签名；s236: 每个任务把最后签名完成的android 应用软件包 apk 上传到文件服务器；s241: 所有的打包任务完成后通知ci持续集成服务模块；s242: ci持续集成服务模块等待所有的打包机打包完成后，发送打包完成消息给服务端。
8.进一步的，资源替换规则包含资源类型、资源名称、资源路径；资源类型包括文件、文件夹和文本；如果替换的资源类型是文件或文件夹，资源替换规则需要包含被替换的资源路径，如果替换的资源类型是文本，资源替换规则需要包含可编辑的文件类型、文本位置。
9.进一步的，文件类型包括json格式、xml格式、plist格式，文本文件是由节点构成的，所述文本位置是通过抽象的规则描述文本的文件中文本数据的相对位置，文本的位置
通过节点、节点深度、节点的属性、内容进行描述。
10.进一步的，所述定制包资源包括图片、文件、文本内容。
11.进一步的，对有加固需求的场景的 android 应用，使用加固工具对全量编译输出的android 应用进行加固后，再继续执行s222-s242。
12.与现有技术相比，本发明的有益效果为：第一：将定制包需要的资源文件由云端存储，资源文件可以由运营人员/客户上传，不再全部放到源代码中，减少了研发人员参与，降低了开发维护成本，代码和定制资源解耦，使得该方法可以适用于多平台定制包批量打包（例如 ios）；第二：本发明提供的方法制定了资源文件规则，而不是针对固定的资源，如果资源文件有变更，只需要改动 android 代码、资源替换规则声明，而不需要所有的环节都进行改动；第三：本发明定义了一套文本替换表达式的规则，通过该表达式的规则可以描述具体的要进行替换的文本位置，该表达式是通用的，是针对于文件类型的，不仅限于 android 平台所需要的文件类型；第四：先全量编译出母包，进行加固后再反编译的方式，保留了加固后的产物，后续批量打包定制包只需要替换资源再回编译即可，避免了每次打包都需要加固而带来的打包时间消耗；第五：将反编译后的文件夹下的文件进行拆分，把不变的文件和文件夹保留，易变的文件移动到反编译后的文件夹之外的文件夹，反编译后的文件夹中只保留了不变的文件夹和文件，打包为临时包，易变的文件夹中的文件在经过替换器替换后，增量压缩到临时包中，节省了大量的不变的文件的压缩时间；第六：本发明提供的方法不依赖于编译器中间产物，可以方便的用于多台打包机做分布式打包，只需要增加 ci 分布式调度即可。
附图说明
13.图1为本发明的定制包批量打包方法的资源管理流程图；图2为本发明的定制包批量打包方法的流程图；图3为本发明的定制包批量打包方法的结构示意图。
实施方式
14.为使对本发明的目的、构造、特征、及其功能有进一步的了解，兹配合实施例详细说明如下。
15.一种高效的 android 应用定制包批量打包方法，包括服务端m103、前端管理平台、前端打包平台m101、ci持续集成服务模块m102、打包机m104、打包工具m105，文件服务器等，所述打包工具包括资源准备模块m251、资源替换模块m252和重打包模块m253。
16.包括以下步骤：s100:资源管理；s101:制定资源替换规则文件并上传定制包资源至服务端。
17.资源规则用于抽象描述资源，必须要包含资源类型、资源名称、资源路径，其中资
源类型包括文件、文件夹和文本，如果替换的资源类型是文件或文件夹，资源规则需要包含被替换的资源路径，如果替换的资源类型是文本，资源规则需要包含可编辑的文件类型、文本位置，文本位置是和文件类型相关的，不同的文件类型有不同的描述文本位置的方法；文本的文件类型包括json、xml、plist等格式；文本位置是通过抽象的规则描述文本的文件中文本数据的相对位置；所述文本数据包括字段或者字段的值等；例如一个文本文件中的文本具有1000行其中第400行中有一个文本数据要将其替换掉，不同格式的文本文件或者不同的人开发的文件，这个文本数据的位置可能不是固定的，我们需要用计算机可识别的语言去描述这个文本数据的相对于整个文本的位置。
18.json格式是一种轻量级的数据交换格式，基于 ecmascript（european computer manufacturers association, 欧洲计算机协会制定的js规范）的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据；xml全称是extensible markup language，中文译为可扩展的标记语言，它是sgml（标准通用标记语言）的一个子集，与html文件不同的是，xml的作用只是数据保存和数据交换。
19.plist格式是一个特殊的文本文件，其中包含属性列表格式的数据。
20.json、xml、plist格式中是没有行的概念，文本的位置是通过节点、节点深度、节点的属性、内容等计算机可识别的语言进行描述；节点通过节点名作为节点的身份标识，在计算机语言中，文本文件是由节点构成的，文本文件的第一个节点为“根节点”。一个文本文件必须有且只能有一个根节点，其他节点都必须是它的子节点，节点的深度就是指由当前节点追溯至根节点的过程中节点的个数，根节点的节点深度为1。
21.节点的属性还包括key 、 value等属性值；内容指的是文本的值text；定义文本替换表达式的规则为：操作符：# 表示节点深度，深度每增加一个需要使用 # 连接；* 表示需要遍历该节点下所有子节点；^ 表示下一个节点；~ 表示上一个节点；@ 表示按索引查找节点；? 表示属性模糊匹配；! 表示属性严格匹配= 用来分割属性的 key 和 value；: 表示内容；空字符表示被替换位，可以是属性、节点名、文本的值text。
22.以上表达式可以支持 json、xml、plist。
23.根据业务需求，确认源代码中需要做替换的资源，根据以上规则表述这些定制包资源并上传到服务端。
24.s102: 运营人员通过前端管理平台上传定制包资源；
定制包资源包括图片、文件、文本内容等；s103: 服务端根据前端管理平台上传的定制包资源，查询资源替换规则文件，根据规则存储定制包资源。
25.s200:定制包批量打包；s211:前端打包平台m101触发打包。
26.用户通过操作前端打包平台进行打包，生成打包参数。打包参数由用户选择生成。打包参数用户是需要进行打包的代码的索引信息，可根据打包参数得知用户需要打包的数目、类型等。
27.s212:服务端m102根据打包参数准备好打包信息。打包信息根据打包参数及服务端配置生成。
28.s213: ci持续集成服务模块m103调度打包机m104，透传打包信息给打包机。
29.打包机为专用来拉取代码进行编译打包并上传到测试包下载服务器的电脑设备。
30.透传是利用特定的网络技术和协议，将服务器上的数据直接发送给用户。
31.s214: 打包机m104启动打包工具m105。
32.s215: 打包工具m105根据打包信息拉取代码、拉取定制包资源。
33.s221: 打包工具触发代码全量编译输出android 应用。
34.全量编译是对用户源程序局部修改后进行的重新编译的工作涉及全部源代码，并不局限于局部修改及相关部分；即无论是否有修改，全量编译都将进行依次全新的完整的编译，并不基于上一次的编译基础。
35.s222: 打包工具的资源准备模块m251使用开源的 apktool工具反编译 android 应用。反编译是把编译后的程序重新变回源代码，反编译就是通过使用编译工具将应用文件中的源文件和资源反编译出来，得到的源文件和资源文件可以进行处理后再进行编译。
36.s223: 资源准备模块m251准备基础临时包 temp.apk。
37.s224: 资源准备模块m251准备被替换的反编译后的资源包文件夹 temp_res。
38.s225: 打包工具启动多线程，每个线程负责打一个打包，每个线程为一个打包任务，分发打包任务。
39.s231: 每个打包任务中，资源准备模块m251都会拷贝一份基础临时包 temp.apk和资源包文件夹temp_res。
40.s232: 每个打包任务根据打包信息执行资源替换模块m252，替换定制包资源，替换文件、文件夹和文本。
41.s233: 每个任务中，重打包模块m253把替换完成的资源包文件夹 temp_res 增量压缩到基础临时包 temp.apk 中。
42.s234: 每个任务中，重打包模块m253把压缩完成的 android 应用软件包apk执行 zipalign工具进行字节对齐。
43.s235: 每个任务中，重打包模块m253把最后生成的android 应用软件包 apk 进行签名。
44.s236: 每个任务把最后签名完成的android 应用软件包 apk 上传到指定的文件服务器。
45.s241: 所有的打包任务完成后通知 ci持续集成服务模块m103。
46.s242: ci持续集成服务模块m103等待所有的打包机m104打包完成后，发送打包完成消息给服务端m102。
47.进一步的，对有加固需求的场景的 android 应用，使用加固工具对全量编译输出的android 应用进行加固后，再继续执行s222-s242；所述加固工具包括360、百度或应用宝等。先全量编译出母包，进行加固后再反编译的方式，保留了加固后的产物，后续批量打包定制包只需要替换资源再回编译即可，避免了每次打包都需要加固而带来的打包时间消耗。
48.单打包机八线程，本发明提供的方法耗时：全量编译时间 + 反编译时间 + 临时包和临时资源准备时间 + （拷贝临时文件时间 + 资源替换时间 + 增量压缩时间 + 字节对齐时间 + 签名时间） * 打包个数 / 线程数 * cpu 实际利用率。
49.例如：如果有一台打包机，一个 android 应用软件在该打包机中打包需要 5 分钟，android 应用包体为 100 mb，反编译需要20秒，回编译需要 8 秒，加固需要 2 分钟，签名需要 10 秒，需要替换 5 张 20 kb 的图片，一个内部有 10 个文件的文件夹，1 个 100 kb 的配置文件，10 处文本显示内容，需要打 200 个定制包，多 flavor 批量打包方案和本发明提供的方法在单打包机八线程（按照实际跑满四线程来算）的耗时对比如下：多 flavor 批量打包方案：约 7300 秒；本发明提供的方案：约 1630 秒。
50.打包效率的提升，可以降低打包机/打包服务器投入成本，提升 android 应用软件发布效率，有效的避免因紧急问题修复而带来的发布延期，节约研发成本，提升研发效率。
51.本发明已由上述相关实施例加以描述，然而上述实施例仅为实施本发明的范例。必需指出的是，已揭露的实施例并未限制本发明的范围。相反地，在不脱离本发明的精神和范围内所作的更动与润饰，均属本发明的专利保护范围。

技术特征：
1.一种高效的 android 应用定制包批量打包方法，其特征在于：包括服务端、前端管理平台、前端打包平台、ci持续集成服务模块、打包机、打包工具，文件服务器，所述打包工具包括资源准备模块、资源替换模块和重打包模块；包括以下步骤：s100:资源管理；s101:制定资源替换规则文件并上传定制包资源至服务端；s102: 运营人员通过前端管理平台上传定制包资源；s103: 服务端根据前端管理平台上传的定制包资源，查询资源替换规则文件，根据规则存储定制包资源；s200:定制包批量打包；s211:前端打包平台触发打包；s212:服务端根据打包参数准备打包信息；s213: ci持续集成服务模块调度打包机，透传打包信息给打包机；s214: 打包机启动打包工具；s215: 打包工具根据打包信息拉取代码、拉取定制包资源；s221: 打包工具触发代码全量编译输出android 应用；s222: 打包工具的资源准备模块使用开源的 apktool工具反编译 android 应用；s223: 资源准备模块准备基础临时包 temp.apk；s224: 资源准备模块准备被替换的反编译后的资源包文件夹 temp_res；s225: 打包工具启动多线程，每个线程负责打一个打包，每个线程为一个打包任务，分发打包任务；s231: 每个打包任务中，资源准备模块拷贝一份基础临时包 temp.apk和资源包文件夹temp_res；s232: 每个打包任务根据打包信息执行资源替换模块，替换定制包资源；s233: 每个任务中，重打包模块把替换完成的资源包文件夹 temp_res 增量压缩到基础临时包 temp.apk 中；s234: 每个任务中，重打包模块把压缩完成的 android 应用软件包apk执行 zipalign工具进行字节对齐；s235: 每个任务中，重打包模块把最后生成的android 应用软件包 apk 进行签名；s236: 每个任务把最后签名完成的android 应用软件包 apk 上传到文件服务器；s241: 所有的打包任务完成后通知ci持续集成服务模块；s242: ci持续集成服务模块等待所有的打包机打包完成后，发送打包完成消息给服务端。2.如权利要求1所述的高效的 android 应用定制包批量打包方法，其特征在于：资源替换规则包含资源类型、资源名称、资源路径；资源类型包括文件、文件夹和文本；如果替换的资源类型是文件或文件夹，资源替换规则需要包含被替换的资源路径，如果替换的资源类型是文本，资源替换规则需要包含可编辑的文件类型、文本位置。3.如权利要求2所述的高效的 android 应用定制包批量打包方法，其特征在于：文件
类型包括json格式、xml格式、plist格式，文本文件是由节点构成的，所述文本位置是通过抽象的规则描述文本的文件中文本数据的相对位置，文本位置通过节点、节点深度、节点的属性、内容进行描述。4.如权利要求1所述的高效的 android 应用定制包批量打包方法，其特征在于：所述定制包资源包括图片、文件、文本内容。5.如权利要求1所述的高效的 android 应用定制包批量打包方法，其特征在于：对有加固需求的场景的 android 应用，使用加固工具对全量编译输出的android 应用进行加固后，再继续执行s222-s242。

技术总结
本发明提供一种高效的Android应用定制包批量打包方法，包括服务端、前端管理平台、前端打包平台、CI持续集成服务模块、打包机、打包工具，文件服务器，包括以下步骤：资源管理；制定资源替换规则文件并上传定制包资源至服务端；运营人员通过前端管理平台上传定制包资源；服务端根据前端管理平台上传的定制包资源，查询资源替换规则文件，根据规则存储定制包资源；定制包批量打包；本发明提升打包效率，降低打包机/打包服务器投入成本，提升Android应用软件发布效率，有效的避免因紧急问题修复而带来的发布延期，节约研发成本，提升研发效率。提升研发效率。


技术研发人员：郝振钧
受保护的技术使用者：鱼快创领智能科技（南京）有限公司
技术研发日：2023.07.27
技术公布日：2023/10/5