CN107861736A - 补丁生成和更新方法及装置、电子设备、存储介质 - Google Patents

Abstract

本公开提供一种补丁生成方法及装置、补丁更新方法及装置、电子设备、以及计算机可读存储介质，涉及计算机技术领域。该补丁生成方法包括：基于原始资源文件生成一基础补丁文件，所述基础补丁文件中包括多个文件大小小于第一阈值的第一文件；将多个所述第一文件进行合并分组以得到多个第二文件，每个所述第二文件中均包括多个所述第一文件；基于所述基础补丁文件中的剩余文件以及所有所述第二文件生成目标补丁文件。本公开可减少http连接数量，从而提高补丁下载效率。

Description

补丁生成和更新方法及装置、电子设备、存储介质

技术领域

本公开涉及计算机技术领域，尤其涉及一种补丁生成方法及装置、补丁更新方法及装置、电子设备、以及计算机可读存储介质。

背景技术

Patch(补丁)技术是指应用程序客户端在更新应用程序内容时，不需要重新下载安装客户端，只需更新本地机器上需要的程序代码和程序资源的技术。Patch技术广泛的应用于当前主流应用平台的各类应用程序例如网络游戏中，其中的应用平台例如包括iOS、Android等移动平台以及Windows等PC(Personal Conputer，个人计算机)平台。

软件的更新通常是以Patch下载或者安装包的方式实现。历史数据显示，采用Patch更新时的用户留存率远高于采用强更安装包更新时的用户留存率。因此，软件的更新换代经常通过定期或不定期的Patch发放来实现，以免用户每次进行软件更新时都要重新下载和安装客户端，不仅能提高用户留存率，同时还可减少不必要的工作量。在此基础上，更新内容的下载速度也是影响用户体验和用户留存的重要因素，下载速度越快，用户体验就越好。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种补丁生成方法及装置、补丁更新方法及装置、电子设备、以及计算机可读存储介质，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本公开的一个方面，提供一种补丁生成方法，包括：

基于原始资源文件生成一基础补丁文件，所述基础补丁文件中包括多个文件大小小于第一阈值的第一文件；

将多个所述第一文件进行合并分组以得到多个第二文件，每个所述第二文件中均包括多个所述第一文件；

基于所述基础补丁文件中的剩余文件以及所有所述第二文件生成目标补丁文件。

本公开的一种示例性实施例中，所述将多个所述第一文件进行合并分组以得到多个第二文件包括：

获取所述基础补丁文件的基础补丁列表，并根据所述基础补丁列表将多个所述第一文件按照路径顺序进行合并；

判断合并后的文件大小是否大于第二阈值，并在合并后的文件大小大于所述第二阈值时，根据合并后的文件生成所述第二文件。

本公开的一种示例性实施例中，所述基于所述基础补丁文件中的剩余文件以及所有所述第二文件生成目标补丁文件包括：

基于所述基础补丁文件中的剩余文件以及所有所述第二文件生成包括通用于不同终端类型的共用资源文件以及适用于预设终端类型的专用资源文件的目标补丁文件。

根据本公开的一个方面，提供一种补丁更新方法，包括：

获取待更新补丁文件的补丁列表并与本地文件进行对比，以得到需要更新的增量补丁列表；

在目标补丁下载模式下，获取根据上述补丁生成方法而生成的目标补丁文件；

将所述目标补丁文件在本地进行解压，以得到需要更新的增量补丁。

本公开的一种示例性实施例中，所述获取根据上述补丁生成方法而生成的目标补丁文件包括：

获取所述目标补丁文件的目标补丁列表，并根据所述增量补丁列表计算需要下载的目标补丁文件的大小；

在所述需要下载的目标补丁文件的大小与需要下载的增量补丁文件的大小的比值小于第三阈值时，获取根据上述补丁生成方法而生成的目标补丁文件。

本公开的一种示例性实施例中，所述补丁更新方法还包括：

在所述需要下载的目标补丁文件的大小与需要下载的增量补丁文件的大小的比值大于等于所述第三阈值时，进入基础补丁下载模式；

在所述基础补丁下载模式下，获取根据上述补丁生成方法而生成的基础补丁文件。

本公开的一种示例性实施例中，所述目标补丁文件和所述基础补丁文件均采用多线程下载方式进行获取。

本公开的一种示例性实施例中，所述补丁更新方法还包括：

在得到需要更新的增量补丁列表之后，判断所述增量补丁列表中的增量补丁文件的大小是否超过第四阈值，并在所述增量补丁文件的大小超过所述第四阈值时进入所述目标补丁下载模式，而在所述增量补丁文件的大小未超过所述第四阈值时进入基础补丁下载模式。

根据本公开的一个方面，提供一种补丁生成装置，包括：

基础补丁生成模块，被配置为基于原始资源文件生成一基础补丁文件，所述基础补丁文件中包括多个文件大小小于第一阈值的第一文件；

补丁合并模块，被配置为将多个所述第一文件进行合并分组以得到多个第二文件，每个所述第二文件中均包括多个所述第一文件；

目标补丁生成模块，被配置为基于所述基础补丁文件中的剩余文件以及所有所述第二文件生成目标补丁文件。

根据本公开的一个方面，提供一种补丁更新装置，包括：

对比模块，被配置为获取待更新补丁文件的补丁列表并与本地文件进行对比，以得到需要更新的增量补丁列表；

更新模块，被配置为在目标补丁下载模式下，获取根据上述补丁生成方法而生成的目标补丁文件；

解压模块，被配置为将所述目标补丁文件在本地进行解压，以得到需要更新的增量补丁。

根据本公开的一个方面，提供一种电子设备，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行上述的补丁生成方法或者上述的补丁更新方法。

根据本公开的一个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述的补丁生成方法或者上述的补丁更新方法。

本公开示例性实施方式所提供的补丁生成方法及装置、以及补丁更新方法及装置，先基于原始资源文件生成一包括多个小文件的基础补丁文件，再对该基础补丁文件中的小文件进行合并处理，以生成一包括多个大文件的目标补丁文件。这样一来，由于多个小文件合并为一大文件能够明显的降低文件数量，因此应用程序在进行补丁更新时可以有效的减少http连接的数量，从而提高补丁的下载效率。经过验证，在稳定的网络环境下，获取普通补丁文件的平均速度为300～400KB/s，而获取本示例实施方式所提供的目标补丁文件的平均速度可提升至2～3MB/s。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出本公开一对比实施例中补丁更新方法的流程图；

图2示意性示出某游戏引擎项目中文件数量分布的示意图；

图3示意性示出某游戏引擎项目中文件容量分布的示意图；

图4示意性示出本公开示例性实施例中补丁生成方法的步骤流程图；

图5示意性示出本公开示例性实施例中补丁生成过程的示意图；

图6示意性示出本公开示例性实施例中目标补丁的生成原理图；

图7示意性示出本公开示例性实施例中目标补丁的存储结构图；

图8示意性示出本公开示例性实施例中补丁生成装置的示意框图；

图9示意性示出本公开示例性实施例中补丁更新方法的步骤流程图；

图10示意性示出本公开示例性实施例中补丁更新方法的流程图；

图11示意性示出本公开示例性实施例中增量补丁的分布示意图；

图12示意性示出本公开示例性实施例中多线程下载方法的示意图；

图13示意性示出本公开示例性实施例中补丁更新装置的示意框图；

图14示意性示出本公开示例性实施例中电子设备的模块示意图；

图15示意性示出本公开示例性实施例中程序产品的示意图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

图1提供了一种补丁更新方法的工作流程图。参考图1所示，该工作流程可以包括如下步骤：

S101、应用程序客户端首先可以通过URL(Uniform Resource Locator，统一资源定位符)访问获取patch md5文件，即补丁的MD5(Message Digest Algorithm 5，消息摘要算法第五版)文件。该patch md5文件中包括有补丁的最新版本信息、补丁列表(patchlist)文件的md5信息、当前所支持的最低包体版本、以及当前最新包体版本等信息。

S102、应用程序客户端通过读取patch md5文件中的最新版本信息并与本地版本进行对比，以判断是否需要进行补丁更新。如果最新版本与本地版本一致，则无需下载补丁；如果最新版本与本地版本不一致，则需要下载补丁。其中，补丁的下载依赖于补丁列表文件。

S103、应用程序客户端会先访问指定的CDN(Content Delivery Network，内容分发网络)下载补丁列表文件，然后通过比较补丁列表文件和本地文件以得到需要更新的文件列表，最后再在补丁下载系统中逐个下载需要更新的补丁文件。

需要说明的是：补丁是由很多个文件组成的，其中的文件类型包括但不限于脚本文件、场景文件、仓库类资源文件、以及非仓库类资源文件等。基于此，参考图1所示，每个文件的下载过程可以包括如下步骤：

S103-1、读取补丁文件的下载地址并进行解析；

S103-2、通过http(HyperText Transfer Protocol，超文本传输协议)请求建立连接；

S103-3、下载补丁文件。

由此可知，本实施例所提供的补丁更新方法中，如果补丁文件中包含n个文件，则上述步骤就需要重复n次，即需要建立n个http连接后逐个进行下载，直至下载完成。这样一来，如果补丁文件过多，则会导致http请求过多，从而影响下载速度。

图2和图3分别为某游戏引擎项目根据文件大小绘制的文件数量分布图和文件容量分布图。结合图2和图3可知，该游戏引擎项目中的文件主要是以小文件为主。在所有文件中，10KB以下的文件数量占61.6％，但其文件大小总和仅占5.4％。而该游戏引擎项目的全量补丁一般包含有34000多个文件，其中20000多个文件是10KB以下的小文件，这就意味着20000多次的http请求下载到的是10KB以下的文件，有些小文件的内容甚至比http地址头还要小。补丁文件的http请求平均大小约为90字节，但经过分析可知，文件大小在90字节以下的文件数量超过2700个，个数占比高达7.9％，这就意味着http连接所消耗的时间比下载文件需要的时间还要长。

基于此，本示例实施方式提供了一种补丁生成方法，用于为一应用程序生成补丁；如图4所示，所述补丁生成方法可以包括：

S401、基于原始资源文件生成一基础补丁文件，所述基础补丁文件中包括多个文件大小小于第一阈值的第一文件；

S402、将多个第一文件进行合并分组以得到多个第二文件，每个第二文件中均包括多个第一文件；

S403、基于基础补丁文件中的剩余文件以及所有第二文件生成目标补丁文件。

其中，所述第一文件是指小文件，所述第二文件是指由多个小文件合并而得的大文件。本实施例中，所述第一文件即小文件是通过设定第一阈值来进行定义的，该第一阈值例如可以设定为10KB，那么第一文件就是指大小在10KB以下的文件。

本公开示例性实施方式所提供的补丁生成方法，先基于原始资源文件生成一包括多个小文件的基础补丁文件，再对该基础补丁文件中的小文件进行合并处理，以生成一包括多个大文件的目标补丁文件。这样一来，由于多个小文件合并为一大文件能够明显的降低文件数量，因此应用程序在进行补丁更新时可以有效的减少http连接的数量，从而提高补丁的下载效率。经过验证，在稳定的网络环境下，获取普通补丁文件的平均速度为300～400KB/s，而获取本示例实施方式所提供的目标补丁文件的平均速度可提升至2～3MB/s。

下面结合附图对本示例实施方式中的补丁生成方法进行详细的说明。

在步骤S401中，基于原始资源文件生成一基础补丁文件，所述基础补丁文件中包括多个文件大小小于第一阈值的第一文件。

本示例实施方式中，所述原始资源文件是指应用程序开发者提供的资源文件，其具体可以包括脚本文件、美术资源文件、以及引擎配置文件；其中的美术资源文件可以包括模型、贴图、骨骼动作、物理、场景、UI(User Interface，用户界面)、以及声音等。所述基础补丁文件是指基于原始资源文件直接生成的补丁文件，也就是普通的补丁文件，因此该基础补丁文件中通常会包含很多小资源文件。

举例而言，如图5所示，某游戏的脚本文件、引擎配置文件、以及美术资源文件等原始资源文件501将通过该游戏引擎的Chef工具502分别转化成应用于不同平台以及适用于不同配置的资源文件503，例如iOS平台上的高档资源、中档资源、低档资源，Android平台上的高档资源、中档资源、低档资源，以及Windows平台上的游戏资源。此时，基于这些资源文件直接生成的补丁文件为普通补丁文件即基础补丁文件504，其数量很多且包括很多个小文件。在此情况下，参考图2和图3所示的文件分布特性，本实施例可将第一阈值优选设定为10KB，这样便可以针对大量小于10KB的第一文件进行后续处理。需要说明的是：所述第一阈值的设定值并不以此为限，其可以根据补丁文件的具体分布特性进行设定。

在步骤S402中，将多个第一文件进行合并分组以得到多个第二文件，每个第二文件中均包括多个第一文件。

本示例实施方式中，所述第二文件是指由多个小文件合并而得的大文件。其中，多个第一文件合并为第二文件的方式可以按照第一文件的数量进行合并，例如每五个第一文件进行合并以得到一个第二文件；或者也可以按照第二文件的大小进行合并，例如若干个第一文件合并之后的文件大小达到1MB以上即为一个第二文件；当然还可以结合以上两种方式。本实施例对于小文件合并为大文件的具体方式不作限定，但应以能够提高文件的下载速度为准。

在一优选实施方式中，如图6所示，所述将多个第一文件进行合并分组以得到多个第二文件可以包括：

S402-1、获取基础补丁文件的基础补丁列表601，并根据该基础补丁列表将多个第一文件602按照路径顺序进行合并；

S402-2、判断合并后的文件大小是否大于第二阈值，并在合并后的文件大小大于第二阈值时，根据合并后的文件生成所述第二文件603。

其中，所述第二阈值可用于衡量第二文件的大小。即，若干个第一文件按序合并，一旦合并后的文件大小达到该第二阈值便会输出一个第二文件，依次重复直至所有小文件均合并为大文件。

举例而言，参考图2和图3所示的某游戏引擎中的文件分布特性，本实施例中的第二阈值例如可以设定为1MB。这样一来，通过本步骤的合并处理，即可将该游戏引擎项目中的文件数量从34000多个减少至800多个，这就意味着可以省略约33000次的http连接，从而能够有效的加快补丁的更新效率。当然，该第二阈值的设定值可以根据应用程序的实际需求进行调整，以求获得合适的最优解。

在步骤S403中，基于基础补丁文件中的剩余文件以及所有第二文件生成目标补丁文件。

本示例实施方式中，所述基础补丁文件中的剩余文件是指除过第一文件之外的其余文件，也就是未合并为第二文件的其余文件，这些文件的大小均超过第一阈值。所述目标补丁文件是指针对基础补丁文件中的第一文件进行合并处理之后而得到的补丁文件，其包含上述的剩余文件以及合并后的第二文件。

在一优选实施方式中，参考图5所示，所述基于基础补丁文件中的剩余文件以及所有第二文件生成目标补丁文件包括：

基于基础补丁文件504中的剩余文件以及所有第二文件生成包括通用于不同终端类型的共用资源文件以及适用于预设终端类型的专用资源文件的目标补丁文件505。

其中，所述共用资源文件是指各个类型终端均可以适用的资源文件，其例如可以包括脚本文件、引擎配置文件、以及美术资源文件中的场景文件和骨骼动作文件等；所述专用资源文件是指仅针对于特定类型终端的资源文件，其例如可以包括美术资源文件中的模型、物理、UI、声音等。

需要说明的是：所述终端类型可以根据终端运行的操作系统进行分类，例如运行iOS操作系统的终端、运行Android操作系统的终端、以及运行Windows操作系统的终端；当然，所述终端类型还可以根据终端的系统配置进行分类，例如具有iOS操作系统的高级配置的终端、具有iOS操作系统的中级配置的终端、以及具有iOS操作系统的低级配置的终端。本实施例针对终端的分类标准不限于此，凡是可能影响Patch生成与更新的因素，均在本实施例的保护范围之内。

在此基础上，为了提高补丁的生成效率，如图7所示，本实施例可将共用资源文件配置于一共用资源目录下，以避免通用类补丁的重复生成，从而达到减少补丁生成耗时以及节约占用空间的效果，同时还将专用资源文件配置于一专用资源目录下，以适应不同终端类型的需求。

举例而言，参考图5和图7所示，应用程序客户端中的共用资源文件具有如下特性：

第一，适用于所有平台的共用资源，在使用Chef工具进行转换的时候只需转换一次并且复用，将其置于Patch目录中的common目录701下，其具体可以包括脚本文件、引擎配置文件、以及美术资源文件中的场景文件和骨骼动作文件等；

第二，适用于不同平台的专用资源，分别置于Patch目录中的iOS-common702、Android-common703、以及Windows-common704目录下。

针对上述的资源结构，在生成目标补丁文件时也沿用了其存储结构。即：common目录下的文件拼接在big-common目录下；iOS-common目录下的文件拼接在big-iOS-common目录下，Android-common目录下的文件拼接在big-Android-common目录下，Windows-common目录下的文件拼接在big-Windows-common目录下。

本示例实施方式中，所述目标补丁文件的目标补丁列表中可以包括大文件的文件名和文件大小、以及大文件中所包含的小文件信息等，其形式例如可以为：“Big File 1”:[size,[File 1,File 2,…File k]]，其含义为文件名为Big File 1的补丁文件大小为size，其中包含File 1,File 2,…File k等资源文件。需要说明的是：上述小文件是指第一文件，上述大文件是指除第一文件之外的剩余文件以及由第一文件合并而得的第二文件。

相应的，本示例实施方式还提供了一种补丁生成装置80，如图8所示，该补丁生成装置80可以包括：

基础补丁生成模块801，被配置为基于原始资源文件生成一基础补丁文件，所述基础补丁文件中包括多个文件大小小于第一阈值的第一文件；

补丁合并模块802，被配置为将多个第一文件进行合并分组以得到多个第二文件，每个第二文件中均包括多个第一文件；

目标补丁生成模块803，被配置为基于基础补丁文件中的剩余文件以及所有第二文件生成目标补丁文件。

本公开示例性实施方式所提供的补丁生成装置，先基于原始资源文件生成一包括多个小文件的基础补丁文件，再对该基础补丁文件中的小文件进行合并处理，以生成一包括多个大文件的目标补丁文件。这样一来，由于多个小文件合并为一大文件能够明显的降低文件数量，因此应用程序在进行补丁更新时可以有效的减少http连接的数量，从而提高补丁的下载效率。

需要说明的是：所述补丁生成装置80中各模块单元的具体细节已经在对应的补丁生成方法中进行了详细的描述，这里不再赘述。

基于上述的补丁生成方法，本示例实施方式还提供了一种补丁更新方法，用于为一应用程序进行补丁更新。如图9所示，该补丁更新方法可以包括：

S901、获取待更新补丁文件的补丁列表并与本地文件进行对比，以得到需要更新的增量补丁列表；

S902、在目标补丁下载模式下，获取根据上述补丁生成方法而生成的目标补丁文件；

S903、将所述目标补丁文件在本地进行解压，以得到需要更新的增量补丁。

本公开示例性实施方式所提供的补丁更新方法，通过获取由多个大文件构成的目标补丁文件，并在本地进行解压以得到需要更新的增量补丁，这样就可以达到减少http连接数量的目的，从而有助于提升补丁的下载效率。

下面结合图10对本示例实施方式中的补丁更新方法进行详细的说明。

在步骤S901之前，所述补丁更新方法可以包括：

S901-a、应用程序客户端会先通过URL访问获取patch md5文件。该MD5文件中包括有补丁的最新版本信息、补丁列表(patch list)文件的md5信息、当前所支持的最低包体版本、以及当前最新包体版本等信息。然后读取MD5文件中的最新版本信息并与本地版本进行对比，以判断是否需要进行补丁更新。如果最新版本与本地版本一致，则无需下载补丁，直接运行客户端即可；如果最新版本与本地版本不一致，则需要下载补丁以进行系统更新。

在步骤S901中，获取待更新补丁文件的补丁列表并与本地文件进行对比，以得到需要更新的增量补丁列表。

其中，所述待更新补丁文件的补丁列表是应用程序客户端通过访问指定的CDN而获取到的。

本示例实施方式中，所述待更新补丁文件的补丁列表是指基础补丁文件的补丁列表，由此得到的增量补丁列表中对应的是基础补丁文件中的各个文件，也是应用程序更新时直接需要的文件。

在步骤S901之后，所述补丁更新方法还可以包括：

S901-b、判断所述增量补丁列表中的增量补丁文件的大小是否超过第四阈值，以在增量补丁文件的大小超过第四阈值时进入目标补丁下载模式，并在增量补丁文件的大小未超过第四阈值时进入基础补丁下载模式。

其中，所述第四阈值可用于衡量需要下载的增量补丁文件的大小。在需要下载的增量补丁文件大于该第四阈值时，即可进入目标补丁下载模式以在目标补丁文件系统中进行下载，从而减少http连接的数量；但在需要下载的增量补丁文件小于该第四阈值时，考虑到实际下载的文件有限，没有必要采用目标补丁文件系统，因此只需通过普通的基础补丁文件系统进行下载即可。本实施例中，该第四阈值例如可以设定为40MB，但不以此为限，其可以根据实际需求进行调整，以获得最优解。

基于此可知，本实施例中的补丁更新方法可以根据实际情况选择基础补丁下载模式或者目标补丁下载模式以进行补丁的下载更新，从而能够以最快的速度完成补丁的更新。

在步骤S902中，在目标补丁下载模式下，获取根据上述补丁生成方法而生成的目标补丁文件。

本示例实施方式中，在进入目标补丁文件系统之后，通过访问CDN以获取目标补丁列表，再根据目标补丁列表获取包括需要的增量补丁的目标补丁文件即可。其中，每个文件的下载步骤如下：第一，读取补丁文件的下载地址并进行解析；第二，通过http请求建立连接；第三，下载文件。如果目标补丁文件中包括N个文件，则上述步骤重复N次即可完成所有补丁的下载。

但是，考虑到目标补丁文件中的第二文件包括了多个第一文件，而应用程序进行补丁更新时直接需要的是第一文件，因此通过目标补丁文件系统下载到的文件中可能同时包括需要更新的文件和不需要更新的文件，这样就会造成资源的浪费，且一旦不需要更新的文件所占的比例较高时，就有可能影响下载效率。

如图11所示，如果增量补丁列表110显示要下载的文件为File A、File B、File E、File G和File L，且根据目标补丁列表显示，文件File A和File B在Big File 1中，文件File E和File G在Big File 2中，文件File L在Big File3中，则应用程序在更新时就会下载Big File 1、Big File 2和Big File 3。但是，如果下载Big File 1、Big File 2和BigFile 3的话，本地已经存在的文件File C、File D、File F、File H、File I、File J和FileK等就会一并下载，因此便会造成资源的浪费。在此情况下，如果增量补丁的分布比较分散且每个Big File文件中增量补丁的个数较少，那么目标补丁下载模式反而可能会增大下载的压力。

针对于此，本示例实施方式采用如下方法进行解决：

S902-1、获取目标补丁文件的目标补丁列表，并根据增量补丁列表计算需要更新的目标补丁文件的大小；

S902-2、在需要更新的目标补丁文件的大小与需要下载的增量补丁文件的大小的比值(Big Patch比值)小于第三阈值时，获取所述目标补丁文件。

S902-3、在需要更新的目标补丁文件的大小与需要下载的增量补丁文件的大小的比值(Big Patch比值)大于等于第三阈值时，进入基础补丁下载模式，并在基础补丁文件系统中获取基础补丁文件。

这样一来，通过计算需要更新的目标补丁文件的大小与需要下载的增量补丁文件的大小的比值，并将该比值与第三阈值进行比较，即可得到增量补丁在目标补丁文件中的分布情况，以便于选择合适的下载模式。

本实施例中，所述第三阈值例如可以设定为4，即，在需要更新的目标补丁文件的大小大于等于需要下载的增量补丁文件的大小的4倍时，选取基础补丁下载模式，在需要更新的目标补丁文件的大小小于需要下载的增量补丁文件的大小的4倍时，选取目标补丁下载模式。当然，该第三阈值仅为某游戏引擎项目的经验值，其可以根据具体项目需求与网络状态进行修改，以求获得最优解。

在步骤S903中，将所述目标补丁文件在本地进行解压，以得到需要更新的增量补丁。

其中，在本地进行解压的目标补丁文件的解压信息存储子在目标补丁列表中，其至少包含文件名以及文件路径。

基于上述步骤S901-S903，即可完成补丁更新过程。

在本示例实施方式中，所述目标补丁文件和所述基础补丁文件均可以采用多线程下载方式进行获取，即多个http连接可在后台同时进行下载。如图12所示，本实施例可以通过线程池121功能来支持多线程的下载方式，该线程池121中可以包含第一线程1211、第二线程1212和第三线程1213等，每个线程对应下载全局队列122中的不同下载项。

以图2和图3所示的某游戏引擎项目中的文件分布为例，该补丁文件是由34000多个文件组成的。如果采用单线程下载方式，则要排队处理上万条任务。为了解决此问题，本实施例优选采用图12所示的线程池功能来实现多线程任务下载，其具有以下优点：第一，可以重复使用线程池中的线程，避免多次创建、销毁线程导致的性能开销；第二，线程池的最大并发数可控，避免线程之间的相互阻塞现象；第三，可对线程进行优化管理，进行二次优化。

需要说明的是：这里所述的多线程方案不仅适用于补丁的下载更新，同时还适用于本地资源的校验。

相应的，本示例实施方式中还提出了一种补丁更新装置130，如图13所示，该补丁更新装置130可以包括：

对比模块1301，被配置为获取待更新补丁文件的补丁列表并与本地文件进行对比，以得到需要更新的增量补丁列表；

更新模块1302，被配置为在目标补丁下载模式下，获取根据上述补丁生成方法而生成的目标补丁文件；

解压模块1303，被配置为将所述目标补丁文件在本地进行解压，以得到需要更新的增量补丁。

本公开示例性实施方式所提供的补丁更新装置，通过获取由多个大文件构成的目标补丁文件，并在本地进行解压以得到需要更新的增量补丁，这样就可以达到减少http连接数量的目的，从而有助于提升补丁的下载效率。

需要说明的是：所述补丁更新装置中各模块单元的具体细节已经在对应的补丁更新方法中进行了详细的描述，这里不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。

所属技术领域的技术人员能够理解，本发明的各个方面可以实现为系统、方法或程序产品。因此，本发明的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

下面参照图14来描述根据本发明的这种实施方式的电子设备1400。附图中的电子设备1400仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图14所示，电子设备1400以通用计算设备的形式表现。电子设备1400的组件可以包括但不限于：上述至少一个处理单元1410、上述至少一个存储单元1420、连接不同系统组件(包括存储单元1420和处理单元1410)的总线1430。

其中，所述存储单元1420存储有程序代码，所述程序代码可以被所述处理单元1410执行，使得所述处理单元1410执行本说明书上述示例性方法部分中描述的根据本发明各种示例性实施方式的步骤。例如，所述处理单元1410可以执行如图4中所示的步骤S401、基于原始资源文件生成一基础补丁文件，所述基础补丁文件中包括多个文件大小小于第一阈值的第一文件；步骤S402、将多个第一文件进行合并分组以得到多个第二文件，每个第二文件中均包括多个第一文件；步骤S403、基于基础补丁文件中的剩余文件以及所有第二文件生成目标补丁文件。又如，所述处理单元1410还可以执行如图9中所示的步骤S901、获取待更新补丁文件的补丁列表并与本地文件进行对比，以得到需要更新的增量补丁列表；步骤S902、在目标补丁下载模式下，获取根据上述补丁生成方法而生成的目标补丁文件；步骤S903、将所述目标补丁文件在本地进行解压，以得到需要更新的增量补丁。

存储单元1420可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(RAM)14201和/或高速缓存存储单元14202，还可以进一步包括只读存储单元(ROM)14203。

存储单元1420还可以包括具有一组(至少一个)程序模块14205的程序/实用工具14204，这样的程序模块14205包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线1430可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备1400也可以与一个或多个外部设备1000(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备1400交互的设备通信，和/或与使得该电子设备1400能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口1450进行。并且，电子设备1400还可以通过网络适配器14140与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器14140通过总线1430与电子设备1400的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备1400使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施方式中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述示例性方法部分中描述的根据本发明各种示例性实施方式的步骤。

参考图15所示，描述了根据本发明的实施方式的用于实现上述方法的程序产品1500，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限。

Claims (12)

1.一种补丁生成方法，其特征在于，包括：

基于原始资源文件生成一基础补丁文件，所述基础补丁文件中包括多个文件大小小于第一阈值的第一文件；

将多个所述第一文件进行合并分组以得到多个第二文件，每个所述第二文件中均包括多个所述第一文件；

基于所述基础补丁文件中的剩余文件以及所有所述第二文件生成目标补丁文件。

2.根据权利要求1所述的补丁生成方法，其特征在于，所述将多个所述第一文件进行合并分组以得到多个第二文件包括：

获取所述基础补丁文件的基础补丁列表，并根据所述基础补丁列表将多个所述第一文件按照路径顺序进行合并；

判断合并后的文件大小是否大于第二阈值，并在合并后的文件大小大于所述第二阈值时，根据合并后的文件生成所述第二文件。

3.根据权利要求1所述的补丁生成方法，其特征在于，所述基于所述基础补丁文件中的剩余文件以及所有所述第二文件生成目标补丁文件包括：

基于所述基础补丁文件中的剩余文件以及所有所述第二文件生成包括通用于不同终端类型的共用资源文件以及适用于预设终端类型的专用资源文件的目标补丁文件。

4.一种补丁更新方法，其特征在于，包括：

获取待更新补丁文件的补丁列表并与本地文件进行对比，以得到需要更新的增量补丁列表；

在目标补丁下载模式下，获取根据权利要求1-3任一项所述的补丁生成方法而生成的目标补丁文件；

将所述目标补丁文件在本地进行解压，以得到需要更新的增量补丁。

5.根据权利要求4所述的补丁更新方法，其特征在于，所述获取根据权利要求1-3任一项所述的补丁生成方法而生成的目标补丁文件包括：

获取所述目标补丁文件的目标补丁列表，并根据所述增量补丁列表计算需要下载的目标补丁文件的大小；

在所述需要下载的目标补丁文件的大小与需要下载的增量补丁文件的大小的比值小于第三阈值时，获取根据权利要求1-3任一项所述的补丁生成方法而生成的目标补丁文件。

6.根据权利要求5所述的补丁更新方法，其特征在于，所述补丁更新方法还包括：

在所述需要下载的目标补丁文件的大小与需要下载的增量补丁文件的大小的比值大于等于所述第三阈值时，进入基础补丁下载模式；

在所述基础补丁下载模式下，获取根据权利要求1-3任一项所述的补丁生成方法而生成的基础补丁文件。

7.根据权利要求6所述的补丁更新方法，其特征在于，所述目标补丁文件和所述基础补丁文件均采用多线程下载方式进行获取。

8.根据权利要求4-7任一项所述的补丁更新方法，其特征在于，所述补丁更新方法还包括：

在得到需要更新的增量补丁列表之后，判断所述增量补丁列表中的增量补丁文件的大小是否超过第四阈值，并在所述增量补丁文件的大小超过所述第四阈值时进入所述目标补丁下载模式，而在所述增量补丁文件的大小未超过所述第四阈值时进入基础补丁下载模式。

9.一种补丁生成装置，其特征在于，包括：

基础补丁生成模块，被配置为基于原始资源文件生成一基础补丁文件，所述基础补丁文件中包括多个文件大小小于第一阈值的第一文件；

补丁合并模块，被配置为将多个所述第一文件进行合并分组以得到多个第二文件，每个所述第二文件中均包括多个所述第一文件；

目标补丁生成模块，被配置为基于所述基础补丁文件中的剩余文件以及所有所述第二文件生成目标补丁文件。

10.一种补丁更新装置，其特征在于，包括：

对比模块，被配置为获取待更新补丁文件的补丁列表并与本地文件进行对比，以得到需要更新的增量补丁列表；

更新模块，被配置为在目标补丁下载模式下，获取根据权利要求1-3任一项所述的补丁生成方法而生成的目标补丁文件；

解压模块，被配置为将所述目标补丁文件在本地进行解压，以得到需要更新的增量补丁。

11.一种电子设备，其特征在于，包括：

处理器；以及

存储器，用于存储所述处理器的可执行指令；

其中，所述处理器配置为经由执行所述可执行指令来执行权利要求1-3任一项所述的补丁生成方法或者权利要求4-8所述的补丁更新方法。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-3任一项所述的补丁生成方法或者权利要求4-8所述的补丁更新方法。