[发明专利]混合技术栈构建打包的方法和装置及机器可读存储介质

说明书

本发明实施例提供一种混合技术栈构建打包的方法和装置及机器可读存储介质，属于大型移动应用构建打包领域。该方法包括：将与Flutter技术栈对应的技术栈任务构建成技术栈AAR包；将与其他技术栈对应的技术栈任务构建成技术栈JAR包，其中，所述其他技术栈为所述混合技术栈中除所述Flutter技术栈之外的技术栈；以及将所述技术栈AAR包与所述技术栈JAR包合并，形成插件任务JAR包。藉此，实现了支持最新技术栈Flutter技术混合开发打包。

技术领域

本发明涉及大型移动应用构建打包领域，具体地涉及一种混合技术栈构建打包的方法和装置及机器可读存储介质。

背景技术

“构建打包”，在移动应用开发领域，技术人员编写后的源码，无法直接给用户使用。需要通过特定机制和过程，将源代码编译转换成移动终端能识别的语言，并打包成一个整体文件。用户下载并安装此文件后，方可使用其提供的功能。转换并打包的这个机制和过程，叫做“构建打包”。

最新“Flutter技术”，是Google开源的UI工具包，帮助开发者通过一套代码库高效构建多平台精美应用，支持移动、Web、桌面和嵌入式平台。Flutter开源、免费，拥有宽松的开源协议，适合商业项目。类似于现在已经被熟知的Android技术。

当前传统的构建打包方案是：假设当前项目属于大中型项目，存在5条业务线(新房、二手房、装修、租赁、海外等)，包含多种技术栈(Android、Kotlin、Swift、Objective-C等)，则打包过程如下：按照壳工程(最终的主工程)的定义清单，将所有业务线设定成不同的插件，然后逐个打包每一个业务线的插件。打包插件的过程，还会基于插件所采用的技术栈，做特定的自定义打包逻辑。每个插件或技术栈的打包过程，都会被分配成任务，然后在打包资源闲置的情况下，逐个执行打包任务。传统的构建打包方案存在以下缺点：(1)无法支持最新技术栈Flutter技术混合开发打包；(2)时间成本高，一个项目通常会被拆成7、8个单独的打包任务，串行执行，无资源时还需要等待；(3)资源浪费，无差别全量打包，只改一个业务插件的一行代码，也需要全部打包，浪费资源；(4)失败率极高，不同业务线插件，隶属不同的开发团队，假设任何一个插件构建失败，则所有任务最终结果都是失败。

发明内容

本发明实施例的目的是提供一种混合技术栈构建打包的方法和装置及机器可读存储介质，其可解决或至少部分解决上述技术问题。

为了实现上述目的，本发明实施例的一个方面提供一种用于混合技术栈构建打包的方法，该方法包括：将与Flutter技术栈对应的技术栈任务构建成技术栈AAR包；将与其他技术栈对应的技术栈任务构建成技术栈JAR包，其中，所述其他技术栈为所述混合技术栈中除所述Flutter技术栈之外的技术栈；以及将所述技术栈AAR包与所述技术栈JAR包合并，形成插件任务JAR包。

可选地，不同技术栈任务对应的构建打包之间是并行进行的。

可选地，该方法还包括：在将与所述混合技术栈中的任一技术栈对应的技术栈任务构建打包之前，判断是否需要对该技术栈任务进行构建打包。

可选地，所述判断是否需要对该技术栈任务进行构建打包包括判断是否存在以下中至少一者来进行判断是否需要对该技术栈任务进行构建打包：该技术栈任务的源代码包含新代码、该技术栈任务对应的技术栈存在技术栈冲突、该技术栈任务对应的技术栈的版本号存在变化以及渠道号存在变化。

可选地，每一插件任务包括多个技术栈任务，不同插件任务对应的打包之间是并行进行的。

可选地，所述Flutter技术栈对应的技术栈任务的功能采用反向代理机制进行延迟加载。