CN112416353A - 渠道包打包方法、装置及计算机设备 - Google Patents

Abstract

本申请公开了一种渠道包打包方法、装置及计算机设备，该方法包括：接收目标软件的渠道包打包请求；获取所述目标软件的软件母包以及所述渠道包打包请求中包括的所有的渠道信息；根据每一条所述渠道信息调用对应渠道的渠道配置文件；通过多个协程并行处理方式将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包。本申请还提供一种计算机可读存储介质。本申请通过在线程中建立多个协程对应每一个渠道，从而执行多渠道并行打包，能够有效提高对多个渠道执行渠道包打包的灵活性和效率。

Description

渠道包打包方法、装置及计算机设备

技术领域

本申请涉及互联网技术领域，尤其涉及一种渠道包打包方法、装置及计算机设备。

背景技术

目前，国内Android市场的渠道非常多，一款游戏上线的时候，上多少渠道，就需要接入多少渠道的SDK(Software Development Kit，软件开发工具包)，比如游戏要在华为应用市场上线的话，就需要接入华为渠道的SDK，包括客户端接入和服务端接入，要在腾讯渠道上线的话，需要接入腾讯渠道的SDK，等等。因此，需要将待上线的游戏打包成对应渠道的渠道包，然后才能接入到该渠道的SDK。

现有技术中，每次生成一个游戏的渠道包，都需要单独选择该渠道的资源和代码与游戏安装母包进行合并，如果说，只需要更新一个渠道的游戏包，操作量还可以，但是现在游戏基本上没有单渠道上线的情况，基本都是要在各个渠道同时上线，如果要上几十个渠道的的话，那么就需要更新几十个游戏渠道包，需要替换几十次渠道资源和代码分别与安装母包进行合并，而且是串行的这种方式严重影响生成游戏渠道包的效率。

发明内容

本申请提出一种渠道包打包方法、装置及计算机设备，能够解决现有技术中对多个渠道进行打包时效率低下的问题。

首先，为实现上述目的，本申请提供一种渠道包打包方法，所述方法包括：

接收目标软件的渠道包打包请求；获取所述目标软件的软件母包以及所述渠道包打包请求中包括的所有的渠道信息；根据每一条所述渠道信息调用对应渠道的渠道配置文件；通过多个协程并行处理方式将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包。

在一个例子中，所述根据每一条所述渠道信息调用对应渠道的渠道配置文件包括：根据所述渠道信息在预设的渠道配置信息表中查询出所述渠道信息对应的目标渠道包括的渠道配置信息，其中，所述渠道配置信息表包括每一个渠道的渠道信息和渠道配置信息，所述渠道配置信息包括渠道功能，以及用于渠道包打包的配置参数；从预设的代码库中调用所有所述渠道功能对应的渠道功能代码作为所述目标渠道的渠道配置文件。

在一个例子中，所述方法还包括：接收所述目标渠道的渠道更新请求，获取所述渠道更新请求中的新渠道配置信息和新渠道功能代码；根据所述新渠道配置信息将所述渠道配置信息表中所述目标渠道的对应的渠道配置信息进行更新；以及根据所述新渠道功能代码将所述代码库中所述目标渠道的对应的渠道功能代码进行更新。

在一个例子中，所述将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包包括：将所述软件母包进行反编译，得到软件母包反编译文件；将每一个渠道对应的渠道配置文件进行反编译，得到每一个渠道对应的渠道功能包反编译文件；将所述软件母包反编译文件分别与每一个所述渠道功能包反编译文件进行资源合并，得到每一个渠道的渠道包。

在一个例子中，所述多个协程并行处理方式包括：根据渠道打包请求创建渠道包打包进程，并在所述渠道包打包进程中创建至少一条线程用于执行渠道包打包；在所述线程中建立多个协程，其中，所述多个协程的协程数量与渠道数量相同；将每一个渠道对应的渠道配置文件与所述软件目标进行资源合并的执行进程添加到所述多个协程中的一个协程中执行。

在一个例子中，所述获取所述目标软件的软件母包包括：根据预设的自检方式对接收到的所述软件母包进行自检，输出自检结果；当所述自检结果为不通过时，则进行报错并提示；当所述自检结果为通过时，则将所述软件母包存放到渠道包打包进程以用于后续与每一个所述渠道配置文件进行资源合并。

在一个例子中，所述自检方式包括静态自检和动态自检；其中，所述静态自检包括对所述软件母包的程序代码执行检查，所述动态自检包括编译所述软件母包执行调试检查。

此外，为实现上述目的，本申请还提供一种渠道包打包装置，所述装置包括：

接收模块，用于接收目标软件的渠道包打包请求；获取模块，用于获取所述目标软件的软件母包以及所述渠道包打包请求中包括的所有的渠道信息；调用模块，用于根据每一条所述渠道信息调用对应渠道的渠道配置文件；打包模块，用于通过多个协程并行处理方式将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包。

进一步地，本申请还提出一种计算机设备，所述计算机设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如上述的渠道包打包方法的步骤。

进一步地，为实现上述目的，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序可被至少一个处理器执行，以使所述至少一个处理器执行如上述的渠道包打包方法的步骤。

相较于现有技术，本申请所提出的渠道包打包方法、装置、计算机设备及计算机可读存储介质，能够接收目标软件的渠道包打包请求；获取所述目标软件的软件母包以及所述渠道包打包请求中包括的所有的渠道信息；根据每一条所述渠道信息调用对应渠道的渠道配置文件；通过多个协程并行处理方式将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包。通过在线程中建立多个协程对应每一个渠道，从而执行多渠道并行打包，能够有效提高对多个渠道执行渠道包打包的灵活性和效率。

附图说明

图1是本申请一实施例的应用环境示意图；

图2是本申请渠道包打包方法一具体实施例的流程示意图；

图3是图2中步骤S204的一具体实施例的流程示意图；

图4是基于图3步骤S302中的一具体实施例的流程示意图；

图5是图2中步骤S206中所述将每一个所述渠道配置文件分别与所述软件母包进行资源合并的一具体实施例的流程示意图；

图6是基于图2步骤S202中的一具体实施例的流程示意图；

图7是本申请渠道包打包方法的一示例性例子的多渠道打包的流程效果图；

图8是本申请一示例性例子的多协程并发处理渠道包打包的流程效果图；

图9是本申请一示例性例子在线程中建立协程执行多协程并发处理的效果图；

图10～图15是本申请一示例性例子的渠道包打包方法执行的效果图；

图16是本申请渠道包打包装置一实施例的程序模块示意图；

图17是本申请计算机设备一可选的硬件架构的示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

图1是本申请一实施例的应用环境示意图。参阅图1所示，所述计算机设备1与开发平台以及多个渠道连接。所述开发平台对目标软件进行开发或升级后，则可以将所述目标软件的软件母包发送给所述计算机设备1，所述计算机设备1可以接收所述软件母包，然后还可以通过所述开发平台或者通过所述计算机设备1的交互界面接收用户发送的渠道包打包请求，并根据所述渠道包打包请求执行对应的渠道包打包操作。所述计算机设备1与所述多个渠道连接可以接收由各渠道发送的渠道信息和渠道功能代码，所述渠道功能代码包括接入所述渠道资源SDK，所述渠道对应的个性化功能的程序代码包，比如角标显示功能的程序代码包和对应于所述目标软件的附加功能的程序代码包。在本实施例中，所述计算机设备1可作为手机、平板、便携设备、PC机或者服务器等；也可以作为独立的功能模块，附加在所述开发平台以实现多渠道的渠道包打包功能。

实施例一

图2是本申请渠道包打包方法一实施例的流程示意图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。下面以计算机设备1为执行主体进行示例性描述。

如图2所示，所述渠道包打包方法可以包括步骤S200～S206。

步骤S200，接收目标软件的渠道包打包请求。

步骤S202，获取所述目标软件的软件母包以及所述渠道包打包请求中包括的所有的渠道信息。

具体的，当开发平台完成对某一目标软件的开发或者升级之后，则会将所述目标软件的软件母包发送至所述计算机设备1。所述计算机设备1则会接收所述软件母包，并存储到预设的内存或者代码库中；当用户通过所述开发平台或者通过所述计算机设备1的用户交互界面向所述计算机设备1发送对于所述目标软件的渠道包打包请求之后，那么所述计算机设备1则可以从所述内存或者代码库中获取所述目标软件的软件母包，以备后续再根据所述渠道包打包请求包括的所有的渠道信息，将所述软件母包打包成相应的渠道包。在本实施例中，用户向所述计算机设备1发送渠道包打包请求，必然包括需要进行渠道包打包的目标渠道，因此在渠道包打包请求中包括目标渠道的渠道信息。所述渠道信息包括渠道的渠道名称，或者渠道编号，或者渠道标识码等渠道识别信息。

步骤S204，根据每一条所述渠道信息调用对应渠道的渠道配置文件。

具体的，所述计算机设备1在获取到所述渠道信息之后，则进一步根据获取到的所述渠道信息调用对应渠道的渠道配置文件。

如图3所示，在一示例性的实施例中，所述根据每一条所述渠道信息调用对应渠道的渠道配置文件包括步骤S300～S302。

步骤S300，根据所述渠道信息在预设的渠道配置信息表中查询出所述渠道信息对应的目标渠道包括的渠道配置信息，其中，所述渠道配置信息表包括每一个渠道的渠道信息和渠道配置信息，所述渠道配置信息包括渠道功能，以及用于渠道包打包的配置参数。

步骤S302，从预设的代码库中调用所有所述渠道功能对应的渠道功能代码作为所述目标渠道的渠道配置文件。

在本实施例中，所述计算机设备1预先建立一个渠道配置信息表，所述渠道配置信息表用于存放所有渠道的渠道信息和渠道配置信息。例如，当渠道商与游戏方达成合作关系之后，所述计算机设备1则可以与多个渠道建立连接关系，接着，所述计算机设备1则可以依次从每一个渠道获取到对应的渠道信息、对应于所述目标软件的渠道配置信息以及渠道功能代码；然后，所述计算机设备1将所有渠道的渠道功能代码存放到预设的代码库中，并将每一个渠道的渠道信息和渠道配置信息存储到预先建立的渠道配置信息表。

例如，所述计算机设备1预先将渠道名称为“渠道N”，以及“渠道N”对应的渠道配置信息和渠道功能进行关联后，存储到所述渠道配置信息表中。然后当接收到的渠道包打包请求中包括的渠道信息有“渠道N”，所述计算机设备1则可以通过所述渠道配置信息表查询出“渠道N”对应的渠道配置信息和渠道功能；再根据“渠道N”的所述渠道功能从代码库中调用对应的渠道功能代码。

在本实施例中，所述渠道功能，可以是渠道功能名称或编号等渠道功能的相关信息；对于每个渠道的渠道配置信息，包括用于渠道包打包的配置参数，所述配置参数用于控制将该渠道的渠道功能代码与所述目标软件的软件母包执行渠道包打包的控制指令或必要参数。所述渠道功能代码，包括该渠道对应的用于接入渠道的渠道资源SDK的程序代码，以及渠道定制功能的程序代码，比如渠道个性化显示功能或所述目标软件的定制化附加功能的程序代码。

也就是说，所述计算机设备1在接收到渠道包打包请求之前，可以先获取到每一个渠道的渠道信息，渠道配置信息和渠道功能代码，并根据渠道信息和渠道配置信息预先建立渠道配置信息表。

当接收到渠道包打包请求之后，所述计算机设备1则可以根据所述渠道配置信息表查找出所述渠道包打包请求中的所有的渠道信息对应的目标渠道的渠道配置信息以及渠道功能，然后根据每一个渠道的渠道配置信息中的所有的所述渠道功能从所述代码库中调用对应的渠道功能代码作为所述目标渠道的渠道配置文件。

相比与现有技术，这种渠道配置文件获取方式，实现了在执行渠道包打包的过程中，不需要对每个渠道进行单独配置，所需要的渠道的配置文件都可以根据渠道的特点动态下发，然后生成对应于该渠道的可以用于打包的渠道配置文件。

如图4所示，在一示例性的实施例中，所述计算机设备1在执行上述步骤S302过程中，所述方法还可以包括步骤S400～S402。

步骤S400，接收所述目标渠道的渠道更新请求，获取所述渠道更新请求中的新渠道配置信息和新渠道功能代码。

步骤S402，根据所述新渠道配置信息将所述渠道配置信息表中所述目标渠道的对应的渠道配置信息进行更新；根据所述新渠道功能代码将所述代码库中所述目标渠道的对应的渠道功能代码进行更新。

具体的，所述计算机设备1能够根据各个渠道的实际情况，实时更新各个渠道的渠道配置信息和渠道功能代码，其中包括，当目标渠道自身发生更新时，则会向所述计算机设备1发送渠道更新请求；然后，所述计算机设备1接收所述渠道更新请求并获取其中的新渠道配置信息和新渠道功能代码，然后将所述新渠道配置信息和新渠道功能代码替换所述渠道配置信息表中的对应的渠道配置信息以及所述代码库中对应的渠道功能代码。因此，实现了实时更新各个渠道的渠道配置文件，进而实现实时、动态下发渠道配置文件的目的。

步骤S206，通过多个协程并行处理方式将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包。

具体的，当所述计算机设备1获取到每一个渠道的所述渠道配置文件之后，则会进一步执行将所述渠道配置文件与所述软件目标进行资源合并的渠道包打包。在本实施例中，所述计算机设备1通过多个协程并行处理的方式执行对多个渠道并发执行渠道包打包。其中，所述多个协程并行处理方式包括：根据渠道打包请求创建渠道包打包进程，并在所述渠道包打包进程中创建至少一条线程用于执行渠道包打包；在所述线程中建立多个协程，所述多个协程的协程数量与渠道数量相同；然后将每一个渠道对应的渠道配置文件与所述软件目标进行资源合并的执行进程添加到所述多个协程中的一个协程中执行。

由于协程相比于多线程/多进程更加的轻量和高效，可以有效提高多线程的任务的并发性。在启动协程的时候，协程会在线程中形成一个协程队列，方便线程在所述协程队列中不同的协程之间进行替换，协程队列的数量由所述计算机设备1的CPU(CentralProcessing Unit，中央处理器)的核心数决定，CPU的核心数决定了同一时间并发数量，一个CPU核心对应执行一个协程队列的操作步骤，从而可以保证高效率执行渠道包打包过程。当然，每个协程在执行渠道包打包时，每个协程拥有自己的寄存器上下文和栈用于存放渠道包打包过程中的数据，比如渠道配置文件和软件母包，以及两者执行资源合并过程中产生的数据。由于一个线程中的协程队列中的多个协程共享该线程的CPU资源和存储资源，因此，为实现CPU和磁盘的最大化利用当某个协程进入磁盘I/O(Input/Output，输入/输出)阶段或其他等待阶段的时候，CPU会释放出来到需要的协程上去。因此，多个协程在进行调度切换时候，所述计算机设备1会将等待阶段的协程对应寄存器上上下文和栈保存在其他地方，例如，在其他存储单元上设置一个存储区域，用于存储渠道包打包过程中短暂存储的上下文和栈上的数据，然后当该协程从等待状态切回来的时候，则重新恢复先前保存的寄存器上的上下文和栈到该协程对应的寄存器。

如图5所示，在一示例性的实施例中，步骤S206中所述将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包包括步骤S500～S5042

步骤S500，将所述软件母包进行反编译，得到软件母包反编译文件。

步骤S502，将每一个渠道对应的渠道配置文件进行反编译，得到每一个渠道对应的渠道功能包反编译文件。

步骤S504，将所述软件母包反编译文件分别与每一个所述渠道功能包反编译文件进行资源合并，得到每一个渠道的渠道包。

具体的，所述计算机设备1通过多个协程并行处理的方式执行多个渠道对应的渠道包打包，而对于每一个渠道的渠道包打包过程，主要包括将渠道的所述渠道配置文件与所述软件母包进行资源合并。在本实施例中，所述计算机设备1先将所述软件母包进行反编译，得到软件母包反编译文件，然后将所述软件母包反编译文件发送至每一个协程，在任一个协程中，分别执行对应渠道的所述渠道配置文件的反编译并得到对应的渠道功能包反编译文件；接着，每一个协程执行将所述软件母包反编译文件与自身协程中反编译得到的渠道功能包反编译文件进行合并，从而得到对应渠道的渠道包。

在一示例性例子中，例如，所述计算机设备1通过Android Studio平台实现对接开发平台以及多个渠道，因此，所述计算机设备1执行所述多个渠道对应的渠道包打包过程，主要依赖于Android Studio平台对应的机器资源。由于Android Studio存在内存限制，在启动打包的时候，可以通过设置两个线程来参与打包，能够根据线程数量生成对应数量的协程队列，保证资源充分利用的同时，避免Android Studio因为内存泄漏导致崩溃。而在打包的过程中，所述计算机设备1通过给每个协程设置独立的工作区，每个协程的打包过程会在对立的工作区中进行，保证静态资源不会冲突，同时不会相互影响，避免一个渠道的失败，影响到其他渠道。通过这种方式，以多个协程的方式，根据打包的特点，动态生成独立配置文件，通过生成独立工作区的方式来实现并发，在兼顾Android Studio内存的限制的条件下，实现了整体出包效率提升50％以上。

当然，在另一具体实施例中，所述计算机设备1也可以作为实现渠道包打包的附件功能，例如以插件的形式，深度集成在Android studio中，实现了游戏母包生成到渠道包生成的一体化，同时基于协程的打包技术，极大的缩短了打包时间，提升了打包效率50％以上。

如图6所示，在一示例性的实施例中，在步骤S202中，所述计算机设备1获取所述目标软件的软件母包可以包括步骤S600～S604。

步骤S600，根据预设的自检方式对接收到的所述软件母包进行自检，输出自检结果。

步骤S602，当所述自检结果为不通过时，则进行报错并提示。

步骤S604，当所述自检结果为通过时，则将所述软件母包存放到渠道包打包进程以用于后续与每一个所述渠道配置文件进行资源合并。

具体的，在一具体实施例中，为了保证能够顺利执行渠道包打包，所述计算机设备1在获取到所述目标软件的所述软件母包之后，则会根据预设自检方式对所述软件母包进行检查，以确定所述软件母包可以正常使用。所述自检方式包括静态自检和动态自检；其中，所述静态自检包括对所述软件母包的程序代码执行检查，所述动态自检包括编译所述软件母包执行调试检查。在本实施例中，所述计算机设备1可以通过关键代码扫描方式对所述软件母包对应的程序代码中的特定代码段，比如，功能接口代码段，循环或嵌套代码段进行检查，如果出现非法代码段则输出自检报告进行报错；或者，所述计算机设备1预先设置一个游戏终端，比如手机，然后将所述软件母包发送至所述游戏终端进行运行，并调试检查，比如通过所述游戏终端上预设的自检模块中内置的抓包工具对运行过程数据进行抓包分析；当然，也可以建立一个虚拟运行环境，将所述软件母包发送至所述虚拟运行环境进行模拟运行，并调试检查，当调试检查过程出现问题，比如闪退，或者显示不正常，那么所述计算机设备1同样可以输出自检报告进行报错。

参阅图7，是本申请一示例性例子的多渠道打包的流程效果图。在本实施例中，所述计算机设备1通过提供一个渠道包打包的应用软件或平台以实现多渠道的渠道包打包功能。当用户需要执行多渠道的渠道包打包时，则可以对所述应用软件或平台进行用户登录，然后进入打包功能，并从游戏选择项选择目标游戏；然后所述应用软件或平台则会对所述目标游戏的游戏母包通过自检功能进行自检，包括静态自检和/或动态自检，并导出对应的自检报告；当所述目标游戏通过自检后，所述映入软件或平台则会根据用户对于多渠道的选择从渠道管理模块调用对应渠道的渠道配置文件，其中，渠道管理模块包括每个渠道的渠道配置信息和渠道功能代码，而且，所述渠道管理模块可以根据渠道方的请求对渠道进行更新/下载或渠道卸载，例如，将对应渠道的渠道配置信息和渠道功能代码进行下载或更新或删除；接着，所述应用软件或平台进一步将所述目标游戏的游戏母包和各个渠道的渠道配置文件进行资源合并，从而生成对应的渠道包；最后上传到CDN，以供用户下载使用。

参阅图8，是本申请一示例性例子的多协程并发处理渠道包打包的流程效果图。在本实施例中，所述计算机设备1先将游戏母包进行反编译，生成对应的游戏母包反编译文件；接着，所述计算机设备1将所述游戏母包反编译文件发送至执行渠道包打包的线程对应每一个渠道的协程中，每一个协程执行一个渠道的渠道包打包操作，具体包括：将渠道功能包反编译，然后与游戏母包反编译文件进行资源合并，最后进行打包和签名，从而得到渠道包；多个协程并行处理，最后得到的是对应的多个渠道的渠道包。

参阅图9，是本申请一示例性例子在线程中建立协程执行多协程并发处理的效果图。在本实施例中，根据所述计算机设备1的CPU核心数建立对应数量的渠道包打包线程。例如，如果CPU核心数为2个，那么，则可以同时建立两个内核线程以执行多渠道的渠道包打包，所述计算机设备1则会将与渠道数量相同的协程分布建立到两个内核线程上，也就是分别在两条内核线程上建一个协程队列，而两个协程队列中包括的协程数量则与渠道数量相同，从而使得一个CPU核心对应一个内核线程，保证所述计算机设备1能够高效率执行渠道包打包步骤。

参阅图10～图15所示，是本申请一示例性例子的渠道包打包方法执行的效果图。在本实施例中，所述计算机设备1通过应用软件或平台的方式提供交互功能给用户，然后用户可以在该应用软件或平台上执行多渠道的渠道包打包。具体的，如图10所示，用户先通过登录界面登录到该应用软件或平台。然后，在如图11所示的功能选择交互界面上选择“打包工具”项，进入下一个交互流程；当然，在图11所示的功能选择界面，还包括有“自检工具”项，用于对游戏目标进行自检，以及“市场插件”项，用于对各个渠道的渠道功能或插件进行管理。当用户选择“打包工具”后，则跳转到如图12所示的游戏类型选择界面，所述游戏类型选择界面包括待打包的游戏集合，以及执行打包功能的按钮如“快速打包”。用户在所述游戏类型选择界面选择目标游戏，并执行“快速打包”之后，则会跳转到如图13所示的打包管理界面，所述打包管理界面用于提供用户选择所述目标游戏的游戏母包，以及选择需要打包的渠道；当用户选择好目标游戏的游戏母包以及对应的渠道之后，则可以点击“打包”按钮，执行打包，如图14所示。最后，当打包完成之后，则显示打包结果界面，如图15所示。当然，在打包结果界面，打包失败时还可以通过“错误日志”进行查看；打包成功则可以进一步上传渠道包，或对渠道包进行自检。

综上所述，本实施例所提出的渠道包打包方法能够接收目标软件的渠道包打包请求；获取所述目标软件的软件母包以及所述渠道包打包请求中包括的所有的渠道信息；根据每一条所述渠道信息调用对应渠道的渠道配置文件；通过多个协程并行处理方式将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包。通过在线程中建立多个协程对应每一个渠道，从而执行多渠道并行打包，能够有效提高对多个渠道执行渠道包打包的灵活性和效率。

实施例二

图16示意性示出了根据本申请实施例二的渠道包打包装置的框图，该渠道包打包装置可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例中各程序模块的功能。

如图16所示，该渠道包打包装置400可以包括接收模块410、获取模块420、调用模块430和打包模块440，其中：

接收模块410，用于接收目标软件的渠道包打包请求。

获取模块420，用于获取所述目标软件的软件母包以及所述渠道包打包请求中包括的所有的渠道信息。

调用模块430，用于根据每一条所述渠道信息调用对应渠道的渠道配置文件。

打包模块440，用于通过多个协程并行处理方式将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包。

在示例性的实施例中，获取模块420，还用于：根据预设的自检方式对接收到的所述软件母包进行自检，输出自检结果；当所述自检结果为不通过时，则进行报错并提示；当所述自检结果为通过时，则将所述软件母包存放到渠道包打包进程以用于后续与每一个所述渠道配置文件进行资源合并。其中，所述自检方式包括静态自检和动态自检；其中，所述静态自检包括对所述软件母包的程序代码执行检查，所述动态自检包括编译所述软件母包执行调试检查。

在示例性的实施例中，调用模块430，还用于：根据所述渠道信息在预设的渠道配置信息表中查询出所述渠道信息对应的目标渠道包括的渠道配置信息，其中，所述渠道配置信息表包括每一个渠道的渠道信息和渠道配置信息，所述渠道配置信息包括渠道功能，以及用于渠道包打包的配置参数；从预设的代码库中调用所有所述渠道功能对应的渠道功能代码作为所述目标渠道的渠道配置文件。以及，接收所述目标渠道的渠道更新请求，获取所述渠道更新请求中的新渠道配置信息和新渠道功能代码；根据所述新渠道配置信息将所述渠道配置信息表中所述目标渠道的对应的渠道配置信息进行更新；根据所述新渠道功能代码将所述代码库中所述目标渠道的对应的渠道功能代码进行更新。

在示例性的实施例中，打包模块440，还用于：根据渠道打包请求创建渠道包打包进程，并在所述渠道包打包进程中创建至少一条线程用于执行渠道包打包；在所述线程中建立多个协程，其中，所述多个协程的协程数量与渠道数量相同；将每一个渠道对应的渠道配置文件与所述软件目标进行资源合并的执行进程添加到所述多个协程中的一个协程中执行。以及，将所述软件母包进行反编译，得到软件母包反编译文件；将每一个渠道对应的渠道配置文件进行反编译，得到每一个渠道对应的渠道功能包反编译文件；将所述软件母包反编译文件分别与每一个所述渠道功能包反编译文件进行资源合并，得到每一个渠道的渠道包。

实施例三

图17示意性示出了根据本申请实施例三的适于实现渠道包打包方法的计算机设备1的硬件架构示意图。本实施例中，计算机设备1是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是具有网关功能的机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集群)等。如图17所示，计算机设备1至少包括但不限于：可通过系统总线相互通信链接存储器510、处理器520、网络接口530。其中：

存储器510至少包括一种类型的计算机可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器510可以是计算机设备1的内部存储模块，例如该计算机设备1的硬盘或内存。在另一些实施例中，存储器510也可以是计算机设备1的外部存储设备，例如该计算机设备1上配备的插接式硬盘，智能存储卡(SmartMedia Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，存储器510还可以既包括计算机设备1的内部存储模块也包括其外部存储设备。本实施例中，存储器510通常用于存储安装于计算机设备1的操作系统和各类应用软件，例如渠道包打包方法的程序代码等。此外，存储器510还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器520在一些实施例中可以是中央处理器(Central Processing Unit，简称为CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器520通常用于控制计算机设备1的总体操作，例如执行与计算机设备1进行数据交互或者通信相关的控制和处理等。本实施例中，处理器520用于运行存储器510中存储的程序代码或者处理数据。

网络接口530可包括无线网络接口或有线网络接口，该网络接口530通常用于在计算机设备1与其他计算机设备之间建立通信链接。例如，网络接口530用于通过网络将计算机设备1与外部终端相连，在计算机设备1与外部终端之间的建立数据传输通道和通信链接等。网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(GlobalSystem of Mobile communication，简称为GSM)、宽带码分多址(Wideband Code DivisionMultiple Access，简称为WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。

需要指出的是，图17仅示出了具有部件510-530的计算机设备，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。

在本实施例中，存储于存储器510中的渠道包打包方法的程序代码还可以被分割为一个或者多个程序模块，并由一个或多个处理器(本实施例为处理器520)所执行，以完成本申请实施例。

实施例四

本实施例还提供一种计算机可读存储介质，计算机可读存储介质其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：

接收目标软件的渠道包打包请求；获取所述目标软件的软件母包以及所述渠道包打包请求中包括的所有的渠道信息；根据每一条所述渠道信息调用对应渠道的渠道配置文件；通过多个协程并行处理方式将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包。

本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作系统和各类应用软件，例如实施例中渠道包打包方法的程序代码等。此外，计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请实施例的优选实施例，并非因此限制本申请实施例的专利范围，凡是利用本申请实施例说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请实施例的专利保护范围内。

Claims (10)

1.一种渠道包打包方法，其特征在于，所述方法包括：

接收目标软件的渠道包打包请求；

获取所述目标软件的软件母包以及所述渠道包打包请求中包括的所有的渠道信息；

根据每一条所述渠道信息调用对应渠道的渠道配置文件；

通过多个协程并行处理方式将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包。

2.如权利要求1所述的渠道包打包方法，其特征在于，所述根据每一条所述渠道信息调用对应渠道的渠道配置文件包括：

根据所述渠道信息在预设的渠道配置信息表中查询出所述渠道信息对应的目标渠道包括的渠道配置信息，其中，所述渠道配置信息表包括每一个渠道的渠道信息和渠道配置信息，所述渠道配置信息包括渠道功能，以及用于渠道包打包的配置参数；

从预设的代码库中调用所有所述渠道功能对应的渠道功能代码作为所述目标渠道的渠道配置文件。

3.如权利要求2所述的渠道包打包方法，其特征在于，所述方法还包括：

接收所述目标渠道的渠道更新请求，获取所述渠道更新请求中的新渠道配置信息和新渠道功能代码；

根据所述新渠道配置信息将所述渠道配置信息表中所述目标渠道的对应的渠道配置信息进行更新；以及

根据所述新渠道功能代码将所述代码库中所述目标渠道的对应的渠道功能代码进行更新。

4.如权利要求1所述的渠道包打包方法，其特征在于，所述将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包包括：

将所述软件母包进行反编译，得到软件母包反编译文件；

将每一个渠道对应的渠道配置文件进行反编译，得到每一个渠道对应的渠道功能包反编译文件；

将所述软件母包反编译文件分别与每一个所述渠道功能包反编译文件进行资源合并，得到每一个渠道的渠道包。

5.如权利要求1所述的渠道包打包方法，其特征在于，所述多个协程并行处理方式包括：

根据渠道打包请求创建渠道包打包进程，并在所述渠道包打包进程中创建至少一条线程用于执行渠道包打包；

在所述线程中建立多个协程，其中，所述多个协程的协程数量与渠道数量相同；

将每一个渠道对应的渠道配置文件与所述软件目标进行资源合并的执行进程添加到所述多个协程中的一个协程中执行。

6.如权利要求1所述的渠道包打包方法，其特征在于，所述获取所述目标软件的软件母包包括：

根据预设的自检方式对接收到的所述软件母包进行自检，输出自检结果；

当所述自检结果为不通过时，则进行报错并提示；

当所述自检结果为通过时，则将所述软件母包存放到渠道包打包进程以用于后续与每一个所述渠道配置文件进行资源合并。

7.如权利要求6所述的渠道包打包方法，其特征在于，所述自检方式包括静态自检和动态自检；其中，所述静态自检包括对所述软件母包的程序代码执行检查，所述动态自检包括编译所述软件母包执行调试检查。

8.一种渠道包打包装置，其特征在于，所述装置包括：

接收模块，用于接收目标软件的渠道包打包请求；

获取模块，用于获取所述目标软件的软件母包以及所述渠道包打包请求中包括的所有的渠道信息；

调用模块，用于根据每一条所述渠道信息调用对应渠道的渠道配置文件；

打包模块，用于通过多个协程并行处理方式将每一个所述渠道配置文件分别与所述软件母包进行资源合并，得到所述目标软件对应每一个渠道的渠道包。

9.一种计算机设备，其特征在于，所述计算机设备包括存储器、处理器，所述存储器上存储有可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1-7任一项所述的渠道包打包方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序可被至少一个处理器执行，以使所述至少一个处理器执行如权利要求1-7中任一项所述的渠道包打包方法的步骤。

Images