CN112994955A - 升级包发送管理方法、增量升级包制备方法及相关装置 - Google Patents

Abstract

本发明实施例提出一种升级包发送管理方法、增量升级包制备方法及相关装置，涉及计算机技术领域。其中，上述升级包发送管理方法包括：根据客户端发送的升级请求指令，判断需向客户端下发全量升级包或者增量升级包；在需向客户端下发全量升级包的情况下，将全量升级包确定为第一待升级数据包传送给所述客户端；在需向客户端下发增量升级包的情况下，将第二待升级数据包传送给客户端；其中，第二待升级数据包为根据目标增量升级包得到的数据包，目标增量升级包为与客户端匹配的增量升级包。在发挥两类升级方式各自的优势的情况下，减少升级包重复下载的问题，节约下载流量，缩短下载时耗，进而也节约升级时耗。

Description

升级包发送管理方法、增量升级包制备方法及相关装置

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种升级包发送管理方法、增量升级包制备方法及相关装置。

背景技术

随着智能化移动设备的发展与普及，给我们的生活带来极大的便利。智能化移动设备的固件数据和软件程序的不断升级，也使得智能化移动设备可向用户提供的应用服务也越来越多。

无论是设备固件还是应用软件的升级，要么通过程序版本的包全量升级，要么程序版本的增量升级实现。相关技术中，通常会先采用增量升级，如果增量升级失败，再采用全量升级。不灵活的升级策略匹配，增加升级所需时耗。

发明内容

有鉴于此，本发明的目的在于提供一种升级包发送管理方法、增量升级包制备方法及相关装置。

为了实现上述目的，本发明实施例采用的技术方案如下：

第一方面，本发明提供一种升级包发送管理方法，应用于服务器，所述服务器与客户端通信连接，所述升级包发送管理方法包括：根据所述客户端发送的升级请求指令，判断需向所述客户端下发全量升级包或者增量升级包；在需向所述客户端下发所述全量升级包的情况下，将所述全量升级包确定为第一待升级数据包传送给所述客户端；在需向所述客户端下发所述增量升级包的情况下，将第二待升级数据包传送给所述客户端；其中，所述第二待升级数据包为根据目标增量升级包得到的数据包，所述目标增量升级包为与所述客户端匹配的增量升级包。

与现有技术相比，上述实施例所提供的升级包发送管理方法根据升级请求指令动态地分析客户端适合采用增量包升级还是适合采用全量包升级。从而，灵活地使用两类升级方式。在发挥两类升级方式各自的优势的情况下，减少升级包重复下载的问题，节约下载流量，缩短下载时耗，进而也节约升级时耗。

在可选的实施方式中，所述根据所述客户端发送的升级请求指令，判断需向所述客户端下发全量升级包或者增量升级包的步骤包括：根据所述升级请求指令中所携带的当前版本信息及设备信息，执行一项或者多项预设检验项目；在所述预设检验项目均通过的情况下，判定需向所述客户端下发增量升级包；在至少一项所述预设检验项目未通过的情况下，判定需向所述客户端下发全量升级包。

与现有技术相比，上述实施例所提供的升级包发送管理方法可以从至少一个维度检验本轮升级请求所适合的升级方式，提高判断的准确性。

在可选的实施方式中，所述预设检验项目包括：第一签名检验项目；执行所述第一签名检验项目的步骤包括：检验所述当前版本信息中是否携带当前版本数字签名；如果携带所述当前版本数字签名，则通过所述预设检验项目；如果未携带所述当前版本数字签名，则未通过所述预设检验项目。

在可选的实施方式中，所述预设检验项目包括：第二签名检验项目；执行所述第二签名检验项目的步骤包括：在所述当前版本信息中携带当前数字签名的情况下，检验所述当前数字签名是否与对应的原版数字签名一致；如果当前数字签名与所述原版数字签名一致，则通过所述预设检验项目；如果当前数字签名与所述原版数字签名不一致，则未通过所述预设检验项目。

在可选的实施方式中，所述预设检验项目包括：设备检验项目；执行所述设备检验项目的步骤包括：检验所述设备信息中的设备标识是否属于预设的全量升级列表；如果属于预设的全量升级列表，则未通过所述预设检验项目；如果不属于预设的全量升级列表，则通过所述预设检验项目。

在可选的实施方式中，所述预设检验项目包括：第一标签检验项目，执行所述第一标签检验项目的步骤包括：根据所述当前版本信息中的当前程序版本，确定相邻版本升级包；其中，所述相邻版本升级包为所述当前程序版本的相邻下一个版全量升级包；检验所述相邻版本升级包是否被赋予全量升级标识；如果具有全量升级标识，则未通过所述预设检验项目；如果不具有全量升级标识，则通过所述预设检验项目。

在可选的实施方式中，所述预设检验项目包括：更新深度检验项目，执行所述更新深度检验项目的步骤包括：根据所述当前版本信息中的当前程序版本，计算更新深度；其中，所述更新深度表征当前程序版本与最新发布版本之间的版本跨度；检验所述更新深度是否超过设定值；如果超过，则未通过所述预设检验项目；如果不超过，则通过所述预设检验项目。

在可选的实施方式中，所述预设检验项目包括：第二标签检验项目，执行所述第二标签检验项目的步骤包括：依次第一全量升级包是否具有全量升级标识；其中，所述第一全量升级包包括间隔版本所对应的全量升级包及最新发布版本所对应的全量升级包；所述间隔版本包括在所述当前程序版本与最新发布版本之间发布的程序版本；如果至少一个所述第一全量升级包具有全量升级标识，则未通过所述预设检验项目；如果都不具有全量升级标识，则通过所述预设检验项目。

在可选的实施方式中，所述预设检验项目包括：时耗分析项目，执行所述时耗分析项目的步骤包括：获取第一合并时长；其中，所述第一合并时长为将所述第二待升级数据包与第二全量升级包进行合并所需的时耗；所述第二全量升级包为升级到所述当前程序版本所需的全量升级包；检验所述第一合并时长是否超过全量传输时长；其中，所述全量传输时长为将第三全量升级包传输至客户端所需的时耗；所述第三全量升级包为升级到最新发布版本所需的全量升级包；如果所述第一合并时长超过全量传输时长，则判定未通过所述预设检验项目；如果所述第一合并时长不超过全量传输时长，则判定通过所述预设检验项目。

在可选的实施方式中，所述预设检验项目包括：传输体积检验项目，执行所述传输体积检验项目的步骤包括：比较所述第二待升级数据包与第三全量升级包的体积差异；如果所述体积差异满足预设条件，则通过所述预设检验项目；如果所述体积差异不满足预设条件，则判定未通过所述预设检验项目。

第二方面，本发明提供一种增量升级包制备方法，所述增量升级包制备方法包括：获取升级到最新发布版本所需的目标全量升级包；根据所述目标全量升级包与相邻全量升级包，生成对应的增量升级包；其中，所述相邻全量升级包为升级到相邻上一个程序版本所需的全量升级包；获取将所述增量升级包与所述相邻全量升级包进行合并所需的第二合并时长；若所述第二合并时长超过全量传输时长，则丢弃所述增量升级包并将所述全量升级标识赋予所述目标全量升级包；其中，所述全量传输时长为将所述目标全量升级包传输给客户端所需时耗。

与现有技术相比，上述实施例所提供的增量升级包制备方法在制作最新发布版本所对应的增量升级包后，预估采用增量升级包进行升级的所需时耗，再与传输对应的全量升级包的时耗进行比较，实现从程序版本自身的角度分析是否适合采用增量升级包进行升级。对于不适合进行增量升级包升级的程序版本，通过赋予全量升级标识的方式，提示向需升级到该版本的客户端发送全量升级包，提高升级效率。

在可选的实施方式中，所述增量升级包制备方法还包括：若所述第二合并时长未超过全量传输时长，则比较所述目标全量升级包与对应的所述增量升级包之间的体积差异；在所述体积差异不满足预设条件的情况下，丢弃所述增量升级包并将所述全量升级标识赋予所述目标全量升级包。

第三方面，本发明提供一种升级包发送管理装置，应用于服务器，所述服务器与客户端通信连接，所述升级包发送管理装置包括：判断模块，用于根据所述客户端发送的升级请求指令，判断需向所述客户端下发全量升级包或者增量升级包；发送模块，用于在需向所述客户端下发所述全量升级包的情况下，将所述全量升级包确定为第一待升级数据包传送给所述客户端；所述发送模块，还用于在需向所述客户端下发所述增量升级包的情况下，将第二待升级数据包传送给所述客户端；其中，所述第二待升级数据包为根据目标增量升级包得到的数据包，所述目标增量升级包为与所述客户端匹配的增量升级包。

在可选的实施方式中，所述判断模块包括：检验子模块，用于根据所述升级请求指令中所携带的当前版本信息及设备信息，执行一项或者多项预设检验项目；判定子模块，用于在所述预设检验项目均通过的情况下，判定需向所述客户端下发增量升级包；判定子模块，用于在至少一项所述预设检验项目未通过的情况下，判定需向所述客户端下发全量升级包。

在可选的实施方式中，所述检验子模块具体用于：检验所述当前版本信息中是否携带当前版本数字签名；如果携带所述当前版本数字签名，则通过所述预设检验项目；如果未携带所述当前版本数字签名，则未通过所述预设检验项目。

在可选的实施方式中，所述检验子模块具体用于：在所述当前版本信息中携带当前数字签名的情况下，检验所述当前数字签名是否与对应的原版数字签名一致；如果当前数字签名与所述原版数字签名一致，则通过所述预设检验项目；如果当前数字签名与所述原版数字签名不一致，则未通过所述预设检验项目。

在可选的实施方式中，所述检验子模块具体用于：检验所述设备信息中的设备标识是否属于预设的全量升级列表；如果属于预设的全量升级列表，则未通过所述预设检验项目；如果不属于预设的全量升级列表，则通过所述预设检验项目。

在可选的实施方式中，所述检验子模块具体用于：根据所述当前版本信息中的当前程序版本，确定相邻版本升级包；其中，所述相邻版本升级包为所述当前程序版本的相邻下一个版全量升级包；检验所述相邻版本升级包是否被赋予全量升级标识；如果具有全量升级标识，则未通过所述预设检验项目；如果不具有全量升级标识，则通过所述预设检验项目。

在可选的实施方式中，所述检验子模块具体用于：根据所述当前版本信息中的当前程序版本，计算更新深度；其中，所述更新深度表征当前程序版本与最新发布版本之间的版本跨度；检验所述更新深度是否超过设定值；如果超过，则未通过所述预设检验项目；如果不超过，则通过所述预设检验项目。

在可选的实施方式中，所述检验子模块具体用于：依次第一全量升级包是否具有全量升级标识；其中，所述第一全量升级包包括间隔版本所对应的全量升级包及最新发布版本所对应的全量升级包；所述间隔版本包括在所述当前程序版本与最新发布版本之间发布的程序版本；如果至少一个所述第一全量升级包具有全量升级标识，则未通过所述预设检验项目；如果都不具有全量升级标识，则通过所述预设检验项目。

在可选的实施方式中，所述检验子模块具体用于：获取第一合并时长；其中，所述第一合并时长为将所述第二待升级数据包与第二全量升级包进行合并所需的时耗；所述第二全量升级包为升级到所述当前程序版本所需的全量升级包；检验所述第一合并时长是否超过全量传输时长；其中，所述全量传输时长为将第三全量升级包传输至客户端所需的时耗；所述第三全量升级包为升级到最新发布版本所需的全量升级包；如果所述第一合并时长超过全量传输时长，则判定未通过所述预设检验项目；如果所述第一合并时长不超过全量传输时长，则判定通过所述预设检验项目。

在可选的实施方式中，所述检验子模块具体用于：比较所述第二待升级数据包与第三全量升级包的体积差异；如果所述体积差异满足预设条件，则通过所述预设检验项目；如果所述体积差异不满足预设条件，则判定未通过所述预设检验项目。

第四方面，本发明提供一种增量升级包制备装置，所述增量升级包制备装置包括：获取模块，用于获取升级到最新发布版本所需的目标全量升级包；生成模块，用于根据所述目标全量升级包与相邻全量升级包，生成对应的增量升级包；其中，所述相邻全量升级包为升级到相邻上一个程序版本所需的全量升级包；计时模块，用于获取将所述增量升级包与所述相邻全量升级包进行合并所需的第二合并时长；处理模块，用于若所述第二合并时长超过全量传输时长，则丢弃所述增量升级包并将所述全量升级标识赋予所述目标全量升级包；其中，所述全量传输时长为将所述目标全量升级包传输给客户端所需时耗。

在可选的实施方式中，所述增量升级包制备装置还包括：比较模块，用于若所述第二合并时长未超过全量传输时长，则比较所述目标全量升级包与对应的所述增量升级包之间的体积差异；所述处理模块，还用于在所述体积差异不满足预设条件的情况下，丢弃所述增量升级包并将所述全量升级标识赋予所述目标全量升级包。

第五方面，本发明提供一种服务器，包括处理器和存储器，所述存储器存储有能够被所述处理器执行的机器可执行指令，所述处理器可执行所述机器可执行指令以实现前述实施方式任一所述的级包发送管理方法；或者所述处理器可执行所述机器可执行指令以实现前述实施方式所述的增量升级包制备方法。

第六方面，本发明提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如前述实施方式任一所述的级包发送管理方法；或者所述计算机程序被处理器执行时实现如前述实施方式所述的增量升级包制备方法。

为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本发明实施例提供的应用场景示意图。

图2概念性地示出了生成增量升级包的示例图。

图3示出了本发明实施例提供的服务器的示意图。

图4示出了本发明实施例提供的升级包发送管理方法的步骤流程图。

图5示出了本发明实施例提供的升级包发送管理方法所对应的信令交互图。

图6示出了图4中的步骤S101的子步骤流程图。

图7示出了本发明实施例提供的升级包发送管理装置的示意图。

图8示出了本发明实施例提供的增量升级包制备方法的步骤流程图。

图9概念性地示出了相关技术中制备增量升级包的示例图。

图10示出了本发明实施例提供的增量升级包制备装置的示意图。

图标：100-服务器；110-存储器；120-处理器；130-通信模块；400-升级包发送管理装置；401-判断模块；402-发送模块；500-增量升级包制备装置；501-获取模块；502-生成模块；503-计时模块；504-处理模块。

具体实施方式

下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，术语“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

智能化移动设备从不够智能到成熟，需经历了无数次的程序版本迭代。即便是已成熟的智能化移动设备依然需要不断地进行程序版本的更新，以便为用户提供更多优质的应用服务。需要说明的是，上述程序版本迭代可以是指应用程序的版本更新，也可以是指固件程序的版本更新，对此不作限定。为了方便描述，在后续实施例中均简称为针对待升级程序进行升级。

智能化移动设备对待升级程序进行升级的过程中需通过数据流量从服务器得到最新发布版本的程序数据，然后进行升级。

然而，得到最新发布版本的程序数据的方式可以包括以下两种方式：

方式一（全量升级的情况下）：下载最新发布版本所对应的完整升级包。上述最新发布版本所对应的完整升级包是能够直接将待升级程序升级到最新发布版本的程序数据包，也即，全量升级包。

显然，方式一适用设备范围广（只需设备满足硬件安装条件即可），升级成功率高。此外，对于服务器而言，无需维护大量的增量升级包。但是，通常全量升级包的数据体积大，下载全量升级包的过程是非常耗费流量和时间的。

方式二（增量升级的情况下）：只下载设备的本地程序数据包与最新发布包（也即，最新发布版本所对应的全量升级包）之间的差异部分（又名，增量升级包或差分包）。可见，能够采用增量升级包进行升级的设备，首先，必须已具有本地程序数据包，其次，该本地程序数据包与最新发布包之间具有相同部分。需要说明的是，上述增量升级包可以是采用Xdelta3、bsdiff/bspatch、HDiffPatch等二进制差分算法制成。

显然，方式二中增量升级包的数据体积相对于全量升级包而言更小，下载过程中所需的数据流量更少，且耗时更短。然而，使用增量升级包进行升级需具备一定条件（比如，已具有本地程序数据包且与最新发布包之间具有相同部分），另外，下载增量升级包后，还需要将增量升级包与本地程序包进行合并计算，消耗移动设备的可用内存与CPU计算资源。同时增量升级成功还需要保证升级后的本地程序数据包与最新发布包保持一致，否则依然会升级失败。此外，对于服务器而言，针对每一次新发布的程序版本均需制作与已发布的一个程序版本之间的增量升级包，同时，还需要管理大量增量升级包。

也即，两种方式都各具优势，也各自存在弊端，单独使用全量升级或增量升级都不能很好的解决升级管理的问题。

故，相关技术中，智能化移动设备会先请求下载增量升级包，之后提取本地程序数据包，对本地程序数据包的数字摘要进行校验，校验合格后进行增量升级。整个增量升级过程中出现任何问题，客户端都会降级下载全量包，进行全量升级。虽然，同时使用了两类升级方法，但是在两类升级方式的使用选择方面并不灵活，很容易出现先后下载增量升级包和全量升级包的情况，不仅增加下载流量数据的浪费，还增加了下载时耗。

此外，在没必要使用增量升级（比如，生成的增量包比较大，跟全量包差不多大小，或者增量升级时客户端使用本地包与增量包合并计算耗时长）的情况下，依然固定的请求增量升级包进行升级，将无端增加升级失败的风险。

为了改善上述问题，本发明实施例提供了一种升级包发送管理方法、增量升级包制备方法及相关装置。旨在从升级包的发送决策和增量升级包的制作两个角度出发，解决程序升级方法选择不够灵活，而导致的升级时耗长的问题。

如图1所示，图1示出了本发明实施例所提供的升级包发送管理方法、增量升级包制备方法及相关装置的应用场景。如图1所示，服务器分别与客户端和程序发布设备通信连接。

上述客户端可以是移动设备，移动设备中安装有用于从服务器获取程序升级服务的服务窗口（比如，程序管理APP）。在一些实施例中，上述客户端可以是智能家居设备、可穿戴设备、手机、虚拟现实设备、或增强现实设备等，也可以是平板计算机、膝上型计算机、或机动车辆中的内置设备等。

上述程序发布设备可以是由程序开发者所使用的电子设备。上述程序发布设备具有向服务器发布程序版本数据的权限。

上述服务器可以是，但不限于是，个人电脑（personal computer，PC）、服务器、分布式部署的计算机等等。可以理解的是，服务器也不限于物理服务器，还可以是物理服务器上的虚拟机、基于云平台上构建的虚拟机等能提供与所述服务器或者虚拟机有相同功能的计算机。

对于任何需由服务器提供升级服务的待升级程序（可以是应用程序，也可以是固件程序）而言，服务器内可以存储有其对应的每一个版本的程序数据。上述每一个版本的程序数据包括各版本所对应的全量升级包，也包括个版本所对应的增量升级包。上述所对应的增量升级包为该版本所对应的全量升级包与相邻上一个版本所对应的全量升级包之间的差分包。比如，图2所示，上述待升级程序已有V1版本、V2版本和V3版本，上述三个版本的发布时间分别是V1早于V2，V2早于V3，那么服务器内将存储有该待升级程序所对应的V1版本的全量升级包、V2版本的全量升级包和V3版本的全量升级包。除此之外，在一些实施例中，服务器内还可以存储有V1版本与V2版本之间的增量升级包V12，以及V3版本与V2版本之间的增量升级包V23。也即，对于该待升级程序而言，所对应的程序数据可以包括V1版本的全量升级包、V2版本的全量升级包、V3版本的全量升级包、增量升级包V12及增量升级包V23。

在此需要说明的是，对于V2版本而言，对应的全量升级包为V2，对应的增量升级包为V12。对于V3版本而言，对应的全量升级包为V3，对应的增量升级包为V23。对于V1版本而言，对应的全量升级包为V1，不具有增量升级包。

请参照图3，是服务器100的方框示意图。所述服务器100包括存储器110、处理器120及通信模块130。所述存储器110、处理器120以及通信模块130各元件相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。

其中，存储器110用于存储程序或者数据。所述存储器110可以是，但不限于，随机存取存储器（Random Access Memory，RAM），只读存储器（Read Only Memory，ROM），可编程只读存储器（Programmable Read-Only Memory，PROM），可擦除只读存储器（ErasableProgrammable Read-Only Memory，EPROM），电可擦除只读存储器（Electric ErasableProgrammable Read-Only Memory，EEPROM）等。

处理器120用于读/写存储器110中存储的数据或程序，并执行相应地功能。

通信模块130用于通过所述网络建立所述服务器100与其它通信终端之间的通信连接，并用于通过所述网络收发数据。

应当理解的是，图3所示的结构仅为服务器100的结构示意图，所述服务器100还可包括比图3中所示更多或者更少的组件，或者具有与图3所示不同的配置。图3中所示的各组件可以采用硬件、软件或其组合实现。

请参考图4，图4示出了本发明实施例提供的一种升级包发送管理方法。上述升级包发送管理方法可应用于服务器100。如图4所示，上述升级包发送管理方法包括步骤：

步骤S101，根据客户端发送的升级请求指令，判断需向客户端下发全量升级包或者增量升级包。

上述升级请求指令为客户端向服务器请求升级服务的指令。通常用于请求将待升级软件升级到最新发布版本。在部分情况下，也可以是用于请求将待升级软件升级到特定程序版本。

当然，在客户端内已安装有待升级程序情况下（也即，客户端内具有对应的本地程序数据包），上述特定程序版本是发布时间晚于本地程序数据包的新程序版本。比如，本地程序数据包的版本是图2示出的版本V1，那么特定程序版本可以是图2示出的版本V2或者版本V3，具体可由用户选择。

在一些实施例中，上述升级请求指令可以携带有客户端所对应的相关信息。

在一些实施例中，上述客户端所对应的相关信息可以包括设备信息和/或当前版本信息。

上述设备信息可以包括表征客户端身份的设备标识，比如设备ID。也可以包括表征客户端的硬件状态的设备状态信息，比如，机型信息、电量、当前网络环境（wifi/4G/3G）等。

上述当前版本信息可以包括当前程序版本和/或当前版本数字签名。上述当前程序版本可以是本地程序数据包所对应的版本号。上述当前版本数字签名可以是本地程序数据包的数字化摘要信息，用于表征内地程序数据包的内容。

在一些实施例中，上述服务器可以根据客户端所发送的升级请求指令，评估客户端本次升级所适宜的升级方式，进而判断需向客户端发送全量升级包或者需向客户端发送增量升级包。可理解的，如果评估客户端本次升级所适宜的升级方式是全量升级，那么判定需向客户端发送全量升级包。同理，如果评估客户端本次升级所适宜的升级方式是增量升级，那么判定需向客户端发送增量升级包。

步骤S102，在需向客户端下发全量升级包的情况下，将第一待升级数据包传送给客户端。

在客户端请求将待升级程序升级到最新发布版本的情况下，上述第一待升级数据包为最新发布版本所对应的全量升级包。比如，图2所示出的最新发布版本为V3版本，那么第一待升级数据包为全量升级包V3。

在客户端请求将待升级程序升级到特定程序版本的情况下，上述第一待升级数据包为特定程序版本所对应的全量升级包。比如，客户端内已安装的本地程序数据包的版本是图2示出的版本V1，用户选择升级到版本V2，那么上述第一待升级数据包为版本V2所对应的全量升级包。

步骤S103，在需向客户端下发增量升级包的情况下，将第二待升级数据包传送给客户端。

上述第二待升级数据包可以是根据目标增量升级包得到的数据包。上述目标增量升级包为与客户端匹配的增量升级包。需要说明的是，上述与客户端匹配的增量升级包可以是能够将客户端内的待升级程序升级到最新发布版本或者用户指定的特定程序版本的增量升级包。

示例性地，本地程序数据包的版本是图2示出的版本V1，需将其升级到最新发布版本（也即，版本V3），那么目标增量升级包可以是增量升级包V12和增量升级包V23。

在一些实施例中，如果服务器内还制备有版本V1和V3所对应的全量升级包之间的差分包（也即，增量升级包V13），那么目标增量升级包可以是增量升级包V13。

显然，上述目标增量升级包可以是一个增量升级包，也可以包括多个增量升级包。

在目标增量升级包包括多个增量升级包的情况下，在一些实施例中，生成第二待升级数据包的方式可以是：直接将多个增量升级包均确定为第二升级数据包，以便于依次将上述第二升级数据包发送给客户端。在另一些实施例中，生成第二待升级数据包的方式还可以是：将多个增量升级包进行合并计算，从而得到第二待升级数据包，需要说明的是，这里所说的“合并”可以理解为将多个增量升级包打包归档到一个文档，与增量升级时本地版本包与增量包的合并不同。

为了方便本领域技术人员理解，下面基于图5示出的信息交互图对上述升级包发送管理方法进行说明：

S1，客户端根据待升级程序的当前版本信息及设备信息，生成升级请求指令。

在一些实施例中，客户端可以在侦听到服务器发送的更新通知的情况下，从更新通知中解析出最新发布版本的版本号。然后，将最新发布版本的版本号与本地程序数据包所对应的版本号进行比较，如果本地程序数据包所对应的版本号与最新发布版本的版本号不同，那么自动创建升级请求指令，用于请求将待升级程序升级到最新发布版本。

在另一些实施例中，客户端可以响应于用户的操作，获取用户设定的特定程序版本，并生成对应的升级请求指令，用于请求将待升级程序升级到该特定程序版本。

无论是升级到特定程序版本还是升级到最新发布版本的原理都相同，为了方便描述，后续实施例中均以升级到最新发布版本为例进行说明。

S2，将升级请求指令发送给服务器。

S3，服务器基于接收到的升级请求指令，分析客户端本次请求升级适合采用全量升级还是适合采用增量升级。可以理解地，如果适合采用全量升级，那么需向客户端下发全量升级包。如果适合采用增量升级，那么需向客户端下发增量升级包。也即，上述步骤S3也可以理解为分析需向客户端下发全量升级包还是需向客户端下发增量升级包。

S4，在确定客户端本次请求升级适合采用全量升级时，将对应的第一待升级数据包反馈给客户端。

S5，在确定客户端本次请求升级适合采用增量升级时，将对应的第二待升级数据包反馈给客户端。

下面对本发明实施例的实施细节进行描述：

上述步骤S101的目地在于分析出利于客户端的升级方式。在一些实施例中，为了提高分析的准确性，可以从多个维度进行分析。示例性地，如图6所示，上述步骤S101可以包括以下子步骤：

子步骤S101-1，根据升级请求指令中所携带的当前版本信息及设备信息，执行一项或者多项预设检验项目。

子步骤S101-2，在上述预设检验项目均通过的情况下，判定需向客户端下发增量升级包。

子步骤S101-3，在至少一项预设检验项目未通过的情况下，判定需向所述客户端下发全量升级包。

在一些实施例中，可以从程序数据维度和/或设备维度对上述升级请求指令进行评估。示例性地，可以在不同的维度下设置多类预设检验项目，用于对接收到的升级请求指令进行检验，从而分析出适宜客户端本次升级所使用的升级方式，进而确定出需向客户端发送全量升级包还是需向客户端增量升级包。

比如，利用上述程序维度所对应的预设检验项目对升级请求指令中所携带的当前版本信息进行检验。利用上述设备维度对升级请求指令中所携带的设备信息进行检验。最后，利用子步骤S101-2和子步骤S101-3分析需向客户端下发增量升级包还是需向客户端下发全量升级包。

在一些实施例中，在不同的维度下设置多类预设检验项目可以包括：签名检验项目、设备检验项目、标签检验项目、更新深度检验项目、时耗分析项目、传输体积检验项目中的一项或多项组成。下面依次对每一类项目进行介绍：

1）签名检验项目，也即针对当前版本数字签名的检验项目。

在一些实施例中，上述签名检验项目可以包括第一签名检验项目和第二签名检验项目。

上述第一签名检验项目用于检验当前版本信息中有没有携带当前版本数字签名。在一些实施例中，执行上述第一签名检验项目的步骤包括：

检验升级请求指令中是否携带当前版本数字签名。也即，检验当前版本信息中有没有携带当前版本数字签名。如果携带了当前版本数字签名，则通过该项预设检验项目。如果未携带所述当前版本数字签名，则未通过该项预设检验项目。

上述第二签名检验项目用于检验当前版本信息中携带的当前版本数字签名是否失效。在一些实施例中，执行上述第二签名检验项目的步骤包括：

在当前版本信息中携带当前数字签名的情况下，检验当前数字签名是否与对应的原版数字签名一致。如果当前数字签名与原版数字签名一致，则通过该项预设检验项目。如果当前数字签名与原版数字签名不一致，则未通过该项预设检验项目。

可理解的，如果本地程序数据包在设备内未被修改过，那么它的内容将与原版程序数据相同。上述原版程序数据可以是存储于服务器且与本地程序数据包对应着相同版本号的全量升级包。比如，本地程序数据包所对应的版本号是V1，那么原版程序数据可以是服务器内存储的版本V1所对应的全量升级包。

当然，如果本地程序数据包在设备内被修改过，那么它的内容将与原版程序数据不相同。可见，本地程序数据包在设备内未被修改过的情况下，本地程序数据包的数字签名（也即，当前版本数字签名）与原版程序数据的数字签名（也即，原版数字签名）应当相同。反之，则二者会不同。

可以理解地，由于服务器内的增量升级包都是基于其内存储的不同版本的全量升级包所创建，如果本地程序数据包已被修改，那么将本地程序数据包与对应的目标增量升级包合并后，不能得到最新发布版本所对应的全量升级包，从而导致升级失败。

比如，本地程序数据包对应的版本号是图2中的版本V2，最新发布版本是版本V3，目标增量升级包为增量升级包V23，上述增量升级包V23是基于服务器内存储的全量升级包V2和全量升级包V3生成。如果本地程序数据包与服务器内的全量升级包V2不同，那么本地程序数据包与增量升级包V23合并后不能得到全量升级包V3，如此，便不能正常升级到最新发布版本V3。

因此，可以预先规定在当前版本数字签名与原版数字签名相同时，代表当前版本数字签名有效。在当前版本数字签名与原版数字签名不同时，代表当前版本数字签名失效。

2）设备检验项目，也即针对设备标识的检验项目。在一些实施例中，执行上述设备检验项目的步骤包括：

通过检验设备信息中的设备标识是否属于预设的全量升级列表。如果属于预设的全量升级列表，则未通过该项预设检验项目。如果不属于预设的全量升级列表，则通过该项预设检验项目。

上述全量升级列表为必须采用全量升级包进行升级的设备名单。设备名单由设备ID组成。如此，通过将升级请求指令中的设备标识一一与全量升级列表中各项进行比对，即可判定设备信息中的设备标识是否属于预设的全量升级列表。

可以理解地，被列入全量升级列表的设备ID可以是多次增量升级失败的设备所对应的ID，也可以是预选被设定为只能通过全量升级的设备所对应的ID，还可以是采用增量升级所需时耗过长的设备所对应的ID。

在一些实施例中，创建全量升级列表可以是由开发人员根据已确定只能通过全量升级的客户端所对应的ID号创建而成。在使用过程中，如果开发人员需要新增只能通过全量升级的客户端，则直接将其对应的ID写入全量升级列表。此外，服务器还会定期收集各个客户端进行升级后所产生的上报日志，根据上报日志分析该客户端是否只能采用全量升级包进行升级，如果是，将该客户端所对应的ID号写入全量升级列表。

示例性地，上述上报日志可以包括客户端机型、设备id、应用id、升级方式（全量升级包/增量升级包）、升级耗时、升级是否成功信息等信息之一或之间的组合。

在一些实施例中，上述根据上报日志分析该客户端是否只能采用全量升级包进行升级的方式可以是：

根据客户端所上传的多个上报日志，进行统计。如果统计结果显示，该客户端多次采用增量升级包对待升级程序进行升级均以失败告终，则判定客户端只能采用全量升级包进行升级。比如，客户端a所对应的上报日志中，目标上报日志的数量超过设定阈值。其中，上述目标上报日志为记录了“升级方式”为增量升级包且“升级是否成功信息”为升级失败的上报日志。如果统计结果显示，该客户端采用增量升级包进行升级所对应的升级时耗均很长，则判定客户端只能采用全量升级包进行升级。比如，升级时耗超过预估全量升级时耗，以及升级完成时耗与预估全量升级时耗之间的差异不超过设定值。需要说明的是，上述预估全量升级时耗为预估采用全量升级包进行升级所需的时长。

3）标签检验项目，也即针对程序版本的检验项目。

在一些实施例中，上述标签检验项目可以包括第一标签检验项目和第二标签检验项目。

上述标签是指全量升级标签，是可赋予服务器内程序版本所对应的全量升级包的标签。当一个程序版本的全量升级包被赋予全量升级标签，则表示要升级到该版本的客户端均需要采用全量升级包进行升级。

在一些实施例中，执行第一标签检验项目的步骤包括：

首先，根据当前版本信息中的当前程序版本，确定相邻版本升级包。上述相邻版本升级包为当前程序版本的相邻下一个版全量升级包。比如，当前程序版本是图2中的版本V1，那么相邻下一个版全量升级包为版本V2所对应的全量升级包。其次，检验相邻版本升级包是否被赋予全量升级标识。如果具有全量升级标识，则未通过该项预设检验项目。如果不具有全量升级标识，则通过该项预设检验项目。

在一些实施例中，执行第二标签检验项目的步骤包括：

依次检验第一全量升级包是否具有全量升级标识。上述第一全量升级包是各个间隔版本所对应的全量升级包及最新发布版本所对应的全量升级包；各个间隔版本包括在当前程序版本与最新发布版本之间发布的程序版本。比如，图2中的版本V3为最新发布版本，版本V1为当前程序版本，那么二者之间的间隔版本为版本V2，那么第一全量升级包包括版本V2所对应的全量升级包和版本V3所对应的全量升级包。如果至少一个第一全量升级包具有全量升级标识，则未通过该项预设检验项目。如果第一全量升级包都不具有全量升级标识，则通过预设检验项目。

可以理解地，上述第二标签检验项目适合存在间隔版本的情况下，如果不存在间隔版本的情况，则选择了第一标签检验项目即可，无需再执行第二标签检验项目。如果存在间隔版本的情况，选择了要执行第二标签检验项目，也可以不执行第一标签检验项目。当然，在一些实施例中，也可以选择第一标签检验项目和第二标签检验项目先后被执行。

4）更新深度检验项目，也是针对程序版本的检验项目。

上述更新深度表征更新版本的跨度。比如，将当前程序版本从V1升级到版本V3，那么对应的更新深度为2。当前程序版本从V2升级到版本V3，那么对应的更新深度为1。

在一些实施例中，执行更新深度检验项目的步骤包括：

首先，根据当前版本信息中的当前程序版本，计算更新深度。在一些实施例中，可以是根据当前程序版本的版本号和最新发布版本的版本号，计算对应的更新深度。其次，检验更新深度是否超过设定值。如果超过，则未通过该项预设检验项目。如果不超过，则通过该项预设检验项目。

5）时耗分析项目，用于针对程序合并的检验项目。

在一些实施例中，上述执行时耗分析项目的步骤包括：

首先，获取第一合并时长。上述第一合并时长为将第二待升级数据包与第二全量升级包进行合并所需的时耗。上述第二全量升级包为升级到当前程序版本所需的全量升级包，换句话说，就是服务器内与当前程序版本具有相同版本号的全量升级包。

在一些实施例中，可以是服务器模拟将第二待升级数据包与第二全量升级包进行合并计算，并记录完成合并所需的第一合并时长。通过第一合并时长预估上述客户端采用增量升级包进行升级的过程中，升级包合并所需时长。

其次，检验第一合并时长是否超过全量传输时长。如果第一合并时长超过全量传输时长，则判定未通过该项预设检验项目。如果所述第一合并时长不超过全量传输时长，则判定通过该项预设检验项目。

上述全量传输时长为将第三全量升级包传输至客户端所需的时耗。上述第三全量升级包为升级到最新发布版本所需的全量升级包，也即，最新发布版本所对应的全量升级包。

可以理解地，采用全量升级包进行升级的情况下，没有数据包合并环节。对于全量升级包而言，缺陷在传输时长较长。因此，当上述第一合并时长超过全量传输时长的情况下，采用全量升级包进行升级更优。

6）传输体积检验项目。

在一些实施例中，执行传输体积检验项目的步骤包括：

比较第二待升级数据包与第三全量升级包的体积差异。如果体积差异满足预设条件，则判定通过所述传输体积检验项目。如果体积差异不满足预设条件，则判定未通过所述传输体积检验项目。

在一些实施例中，上述体积差异可以是第二待升级数据包与第三全量升级包之间数据体积差值。在此情况下，上述预设条件可以是数据体积差值不超过预设体积值。

在一些实施例中，上述体积差异还可以是第二待升级数据包与第三全量升级包之间的比例。在此情况下，上述预设条件可以是体积差异不超过预设比例值，比如，不超过70%。

总而言之，本发明实施例可执行的预设检测项目可以包括，但不限于包括上述第一签名检验项目、第二签名检验项目、设备检验项目、第一标签检验项目、更新深度检验项目、第二标签检验项目、时耗分析项目及传输体积检验项目。

上述子步骤S101-1可以是执行上述第一签名检验项目、第二签名检验项目、设备检验项目、第一标签检验项目、更新深度检验项目、第二标签检验项目、时耗分析项目及传输体积检验项目中的一项或多项。当然，执行各项预设检验项目之间没有必然的先后顺序。

比如，上述子步骤S101-1可以包括：

S101-1-1，检验升级请求指令中是否携带当前版本数字签名。如果是，流程进入S101-1-2，如果不是，流程进入子步骤S101-3。

S101-1-2，将升级请求指令中的设备标识与全量升级列表进行比对。如果该设备标识出现在全量升级列表中，流程进入S101-3。如果该设备标识未出现在全量升级列表中，流程进入S101-1-3。

S101-1-3，检验对应的相邻版本升级包是否具有全量升级标识。如果具有，流程进入子步骤S101-3。如果不具有，流程进入S101-1-4。

S101-1-4，检验当前数字签名是否与对应的原版数字签名一致。如果一致，流程进入S101-1-5。如果不一致，流程进入子步骤S101-3。

S101-1-5，依次检验第一全量升级包是否具有全量升级标识。其中，第一全量升级包包括间隔版本所对应的全量升级包及最新发布版本所对应的全量升级包。上述间隔版本包括在当前程序版本与最新发布版本之间发布的程序版本。如果均不具有全量升级标识，流程进入S101-1-6。如果至少一个第一全量升级包具有全量升级标识，流程进入子步骤S101-3。

S101-1-6，计算第二待升级数据包与第三全量升级包之间的比例值。如果上述比例值超过70%，则流程进入子步骤S101-3。如果上述比例值未超过70%，则流程进入子步骤S101-2。

为了执行上述实施例及各个可能的方式中的相应步骤，下面给出一种升级包发送管理装置400的实现方式，可选地，该升级包发送管理装置400可以采用上述图3所示的服务器的器件结构。进一步地，请参阅图7，图7为本发明实施例提供的一种升级包发送管理装置400的功能模块图。需要说明的是，本实施例所提供的升级包发送管理装置400，其基本原理及产生的技术效果和上述实施例相同，为简要描述，本实施例部分未提及之处，可参考上述的实施例中相应内容。该升级包发送管理装置400包括：判断模块401及发送模块402。

判断模块401，用于根据所述客户端发送的升级请求指令，判断需向所述客户端下发全量升级包或者增量升级包。

发送模块402，用于在需向所述客户端下发所述全量升级包的情况下，将所述全量升级包确定为第一待升级数据包传送给所述客户端。

所述发送模块402，还用于在需向所述客户端下发所述增量升级包的情况下，将第二待升级数据包传送给所述客户端；其中，所述第二待升级数据包为根据目标增量升级包得到的数据包，所述目标增量升级包为与所述客户端匹配的增量升级包。

在一些实施例中，上述判断模块401包括：

检验子模块，用于根据所述升级请求指令中所携带的当前版本信息及设备信息，执行一项或者多项预设检验项目；

判定子模块，用于在所述预设检验项目均通过的情况下，判定需向所述客户端下发增量升级包；

判定子模块，用于在至少一项所述预设检验项目未通过的情况下，判定需向所述客户端下发全量升级包。

在一些实施例中，上述检验子模块具体用于：

检验所述当前版本信息中是否携带当前版本数字签名；

如果携带所述当前版本数字签名，则通过所述预设检验项目；

如果未携带所述当前版本数字签名，则未通过所述预设检验项目。

在一些实施例中，上述检验子模块具体用于：

在所述当前版本信息中携带当前数字签名的情况下，检验所述当前数字签名是否与对应的原版数字签名一致；

如果当前数字签名与所述原版数字签名一致，则通过所述预设检验项目；

如果当前数字签名与所述原版数字签名不一致，则未通过所述预设检验项目。

在一些实施例中，上述检验子模块具体用于：

检验所述设备信息中的设备标识是否属于预设的全量升级列表；

如果属于预设的全量升级列表，则未通过所述预设检验项目；

如果不属于预设的全量升级列表，则通过所述预设检验项目。

在一些实施例中，上述检验子模块具体用于：

根据所述当前版本信息中的当前程序版本，确定相邻版本升级包；其中，所述相邻版本升级包为所述当前程序版本的相邻下一个版全量升级包；

检验所述相邻版本升级包是否被赋予全量升级标识；

如果具有全量升级标识，则未通过所述预设检验项目；

如果不具有全量升级标识，则通过所述预设检验项目。

在一些实施例中，上述检验子模块具体用于：

根据所述当前版本信息中的当前程序版本，计算更新深度；其中，所述更新深度表征当前程序版本与最新发布版本之间的版本跨度；

检验所述更新深度是否超过设定值；

如果超过，则未通过所述预设检验项目；

如果不超过，则通过所述预设检验项目。

在一些实施例中，上述检验子模块具体用于：

依次第一全量升级包是否具有全量升级标识；其中，所述第一全量升级包包括间隔版本所对应的全量升级包及最新发布版本所对应的全量升级包；所述间隔版本包括在所述当前程序版本与最新发布版本之间发布的程序版本；

如果至少一个所述第一全量升级包具有全量升级标识，则未通过所述预设检验项目；

如果都不具有全量升级标识，则通过所述预设检验项目。

在一些实施例中，上述检验子模块具体用于：

获取第一合并时长；其中，所述第一合并时长为将所述第二待升级数据包与第二全量升级包进行合并所需的时耗；所述第二全量升级包为升级到所述当前程序版本所需的全量升级包；

检验所述第一合并时长是否超过全量传输时长；其中，所述全量传输时长为将第三全量升级包传输至客户端所需的时耗；所述第三全量升级包为升级到所述最新发布版本所需的全量升级包；

如果所述第一合并时长超过全量传输时长，则判定未通过所述预设检验项目；

如果所述第一合并时长不超过全量传输时长，则判定通过所述预设检验项目。

在一些实施例中，上述检验子模块具体用于：

比较所述第二待升级数据包与第三全量升级包的体积差异；

如果所述体积差异满足预设条件，则通过所述预设检验项目；

如果所述体积差异不满足预设条件，则判定未通过所述预设检验项目。

请参考图8，图8示出了本发明实施例提供的一种增量升级包制备方法。上述增量升级包制备方法应用于服务器。如图8所示，上述增量升级包制备方法可以包括以下步骤：

步骤S201，获取升级到最新发布版本所需的目标全量升级包。

在一些实施例中，可以是在每一次新发布程序版本后，获取此时最新发布版本所对应的全量升级包，以作为目标全量升级包。

步骤S202，根据目标全量升级包与相邻全量升级包，生成对应的增量升级包。

在一些实施例中，上述相邻全量升级包为升级到相邻上一个程序版本所需的全量升级包。比如，最新发布版本是图2中的版本V3，那么相邻上一个程序版本便是版本V2，相邻全量升级包也即版本V2所对应的全量升级包。

在一些实施例中，可以采用Xdelta3、bsdiff/bspatch、HDiffPatch等二进制差分算法制作目标全量升级包与相邻全量升级包之间的增量升级包。

步骤S203，获取将增量升级包与相邻全量升级包进行合并所需的第二合并时长。

步骤S204，若第二合并时长超过全量传输时长，则丢弃增量升级包并将全量升级标识赋予目标全量升级包。

上述全量传输时长为将目标全量升级包传输给客户端所需时耗。

在相关技术中，如图9所示，针对版本V2需要制作其与版本V1之间的增量升级包V12。针对版本V3需要制作其与版本V1之间的增量升级包V13，还需要制作其与版本V2之间的增量升级包V23。显然，本发明实施例（也即，只制作相邻两个版本之间增量升级包）与相关技术相比而言，需要维护的增量升级包更少，拆分增量升级包的工作量也更少。

此外，对于部分增量升级价值不大的程序版本，还会丢弃对于的增量升级包，并赋予该程序版本全量升级标识。以便需要升级到该程序版本的客户端可以直接下载对应的全量升级包，避免徒增升级失败风险。

判定增量升级价值不高的方式除了上述实施例提高的比较第二合并时长和全量传输时长外，还可以比较目标全量升级包与对应的增量升级包之间的体积差异。

也即，在一些实施例中，上述增量升级包制备方法还包括：若第二合并时长未超过全量传输时长，则比较目标全量升级包与对应的所述增量升级包之间的体积差异。在体积差异不满足预设条件的情况下，丢弃增量升级包并将所述全量升级标识赋予目标全量升级包。

为了执行上述实施例及各个可能的方式中的相应步骤，下面给出一种增量升级包制备装置的实现方式，可选地，该增量升级包制备装置500可以采用上述图3所示的服务器100的器件结构。进一步地，请参阅图10，图10为本发明实施例提供的一种增量升级包制备装置500的功能模块图。需要说明的是，本实施例所提供的增量升级包制备装置500，其基本原理及产生的技术效果和上述实施例相同，为简要描述，本实施例部分未提及之处，可参考上述的实施例中相应内容。该增量升级包制备装置500包括：获取模块501、生成模块502、计时模块503及处理模块504。

获取模块501，用于获取升级到最新发布版本所需的目标全量升级包。

生成模块502，用于根据所述目标全量升级包与相邻全量升级包，生成对应的增量升级包；其中，所述相邻全量升级包为升级到相邻上一个程序版本所需的全量升级包。

计时模块503，用于获取将所述增量升级包与所述相邻全量升级包进行合并所需的第二合并时长。

处理模块504，用于若所述第二合并时长超过全量传输时长，则丢弃所述增量升级包并将所述全量升级标识赋予所述目标全量升级包；其中，所述全量传输时长为将所述目标全量升级包传输给客户端所需时耗。

在一些实施例中，增量升级包制备装置500还包括：比较模块，用于若所述第二合并时长未超过全量传输时长，则比较所述目标全量升级包与对应的所述增量升级包之间的体积差异。所述处理模块，还用于在所述体积差异不满足预设条件的情况下，丢弃所述增量升级包并将所述全量升级标识赋予所述目标全量升级包。

可选地，上述模块可以软件或固件（Firmware）的形式存储于图3所示的存储器中或固化于该服务器的操作系统（Operating System，OS）中，并可由图3中的处理器执行。同时，执行上述模块所需的数据、程序的代码等可以存储在存储器中。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本发明的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本发明各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (26)

1.一种升级包发送管理方法，其特征在于，应用于服务器，所述服务器与客户端通信连接，所述升级包发送管理方法包括：

根据所述客户端发送的升级请求指令，判断需向所述客户端下发全量升级包或者增量升级包；

在需向所述客户端下发所述全量升级包的情况下，将所述全量升级包确定为第一待升级数据包传送给所述客户端；

在需向所述客户端下发所述增量升级包的情况下，将第二待升级数据包传送给所述客户端；其中，所述第二待升级数据包为根据目标增量升级包得到的数据包，所述目标增量升级包为与所述客户端匹配的增量升级包。

2.根据权利要求1所述的升级包发送管理方法，其特征在于，所述根据所述客户端发送的升级请求指令，判断需向所述客户端下发全量升级包或者增量升级包的步骤包括：

根据所述升级请求指令中所携带的当前版本信息及设备信息，执行一项或者多项预设检验项目；

在所述预设检验项目均通过的情况下，判定需向所述客户端下发增量升级包；

在至少一项所述预设检验项目未通过的情况下，判定需向所述客户端下发全量升级包。

3.根据权利要求2所述的升级包发送管理方法，其特征在于，所述预设检验项目包括：第一签名检验项目；执行所述第一签名检验项目的步骤包括：

检验所述当前版本信息中是否携带当前版本数字签名；

如果携带所述当前版本数字签名，则通过所述第一签名检验项目；

如果未携带所述当前版本数字签名，则未通过所述第一签名检验项目。

4.根据权利要求2所述的升级包发送管理方法，其特征在于，所述预设检验项目包括：第二签名检验项目；执行所述第二签名检验项目的步骤包括：

在所述当前版本信息中携带当前数字签名的情况下，检验所述当前数字签名是否与对应的原版数字签名一致；

如果当前数字签名与所述原版数字签名一致，则通过所述第二签名检验项目；

如果当前数字签名与所述原版数字签名不一致，则未通过所述第二签名检验项目。

5.根据权利要求2所述的升级包发送管理方法，其特征在于，所述预设检验项目包括：设备检验项目；执行所述设备检验项目的步骤包括：

检验所述设备信息中的设备标识是否属于预设的全量升级列表；

如果属于预设的全量升级列表，则未通过所述设备检验项目；

如果不属于预设的全量升级列表，则通过所述设备检验项目。

6.根据权利要求2所述的升级包发送管理方法，其特征在于，所述预设检验项目包括：第一标签检验项目，执行所述第一标签检验项目的步骤包括：

根据所述当前版本信息中的当前程序版本，确定相邻版本升级包；其中，所述相邻版本升级包为所述当前程序版本的相邻下一个版全量升级包；

检验所述相邻版本升级包是否被赋予全量升级标识；

如果具有全量升级标识，则未通过所述第一标签检验项目；

如果不具有全量升级标识，则通过所述第一标签检验项目。

7.根据权利要求2所述的升级包发送管理方法，其特征在于，所述预设检验项目包括：更新深度检验项目，执行所述更新深度检验项目的步骤包括：

根据所述当前版本信息中的当前程序版本，计算更新深度；其中，所述更新深度表征当前程序版本与最新发布版本之间的版本跨度；

检验所述更新深度是否超过设定值；

如果超过，则未通过所述更新深度检验项目；

如果不超过，则通过所述更新深度检验项目。

8.根据权利要求2所述的升级包发送管理方法，其特征在于，所述预设检验项目包括：第二标签检验项目，执行所述第二标签检验项目的步骤包括：

依次检验第一全量升级包是否具有全量升级标识；其中，所述第一全量升级包包括间隔版本所对应的全量升级包及最新发布版本所对应的全量升级包；所述间隔版本包括在所述当前程序版本与最新发布版本之间发布的程序版本；

如果至少一个所述第一全量升级包具有全量升级标识，则未通过所述第二标签检验项目；

如果都不具有全量升级标识，则通过所述第二标签检验项目。

9.根据权利要求2所述的升级包发送管理方法，其特征在于，所述预设检验项目包括：时耗分析项目，执行所述时耗分析项目的步骤包括：

获取第一合并时长；其中，所述第一合并时长为将所述第二待升级数据包与第二全量升级包进行合并所需的时耗；所述第二全量升级包为升级到所述当前程序版本所需的全量升级包；

检验所述第一合并时长是否超过全量传输时长；其中，所述全量传输时长为将第三全量升级包传输至客户端所需的时耗；所述第三全量升级包为升级到最新发布版本所需的全量升级包；

如果所述第一合并时长超过全量传输时长，则判定未通过所述时耗分析项目；

如果所述第一合并时长不超过全量传输时长，则判定通过所述时耗分析项目。

10.根据权利要求2所述的升级包发送管理方法，其特征在于，所述预设检验项目包括：传输体积检验项目，执行所述传输体积检验项目的步骤包括：

比较所述第二待升级数据包与第三全量升级包的体积差异；

如果所述体积差异满足预设条件，则判定通过所述传输体积检验项目；

如果所述体积差异不满足预设条件，则判定未通过所述传输体积检验项目。

11.一种增量升级包制备方法，其特征在于，所述增量升级包制备方法包括：

获取升级到最新发布版本所需的目标全量升级包；

根据所述目标全量升级包与相邻全量升级包，生成对应的增量升级包；其中，所述相邻全量升级包为升级到相邻上一个程序版本所需的全量升级包；

获取将所述增量升级包与所述相邻全量升级包进行合并所需的第二合并时长；

若所述第二合并时长超过全量传输时长，则丢弃所述增量升级包并将所述全量升级标识赋予所述目标全量升级包；其中，所述全量传输时长为将所述目标全量升级包传输给客户端所需时耗。

12.根据权利要求11所述的增量升级包制备方法，其特征在于，所述增量升级包制备方法还包括：

若所述第二合并时长未超过全量传输时长，则比较所述目标全量升级包与对应的所述增量升级包之间的体积差异；

在所述体积差异不满足预设条件的情况下，丢弃所述增量升级包并将所述全量升级标识赋予所述目标全量升级包。

13.一种升级包发送管理装置，其特征在于，应用于服务器，所述服务器与客户端通信连接，所述升级包发送管理装置包括：

判断模块，用于根据所述客户端发送的升级请求指令，判断需向所述客户端下发全量升级包或者增量升级包；

发送模块，用于在需向所述客户端下发所述全量升级包的情况下，将所述全量升级包确定为第一待升级数据包传送给所述客户端；

所述发送模块，还用于在需向所述客户端下发所述增量升级包的情况下，将第二待升级数据包传送给所述客户端；其中，所述第二待升级数据包为根据目标增量升级包得到的数据包，所述目标增量升级包为与所述客户端匹配的增量升级包。

14.根据权利要求13所述的升级包发送管理装置，其特征在于，所述判断模块包括：

检验子模块，用于根据所述升级请求指令中所携带的当前版本信息及设备信息，执行一项或者多项预设检验项目；

判定子模块，用于在所述预设检验项目均通过的情况下，判定需向所述客户端下发增量升级包；

判定子模块，用于在至少一项所述预设检验项目未通过的情况下，判定需向所述客户端下发全量升级包。

15.根据权利要求14所述的升级包发送管理装置，其特征在于，所述检验子模块具体用于：

检验所述当前版本信息中是否携带当前版本数字签名；

如果携带所述当前版本数字签名，则通过所述预设检验项目；

如果未携带所述当前版本数字签名，则未通过所述预设检验项目。

16.根据权利要求14所述的升级包发送管理装置，其特征在于，所述检验子模块具体用于：

在所述当前版本信息中携带当前数字签名的情况下，检验所述当前数字签名是否与对应的原版数字签名一致；

如果当前数字签名与所述原版数字签名一致，则通过所述预设检验项目；

如果当前数字签名与所述原版数字签名不一致，则未通过所述预设检验项目。

17.根据权利要求14所述的升级包发送管理装置，其特征在于，所述检验子模块具体用于：

检验所述设备信息中的设备标识是否属于预设的全量升级列表；

如果属于预设的全量升级列表，则未通过所述预设检验项目；

如果不属于预设的全量升级列表，则通过所述预设检验项目。

18.根据权利要求14所述的升级包发送管理装置，其特征在于，所述检验子模块具体用于：

根据所述当前版本信息中的当前程序版本，确定相邻版本升级包；其中，所述相邻版本升级包为所述当前程序版本的相邻下一个版全量升级包；

检验所述相邻版本升级包是否被赋予全量升级标识；

如果具有全量升级标识，则未通过所述预设检验项目；

如果不具有全量升级标识，则通过所述预设检验项目。

19.根据权利要求14所述的升级包发送管理装置，其特征在于，所述检验子模块具体用于：

根据所述当前版本信息中的当前程序版本，计算更新深度；其中，所述更新深度表征当前程序版本与最新发布版本之间的版本跨度；

检验所述更新深度是否超过设定值；

如果超过，则未通过所述预设检验项目；

如果不超过，则通过所述预设检验项目。

20.根据权利要求14所述的升级包发送管理装置，其特征在于，所述检验子模块具体用于：

依次第一全量升级包是否具有全量升级标识；其中，所述第一全量升级包包括间隔版本所对应的全量升级包及最新发布版本所对应的全量升级包；所述间隔版本包括在所述当前程序版本与最新发布版本之间发布的程序版本；

如果至少一个所述第一全量升级包具有全量升级标识，则未通过所述预设检验项目；

如果都不具有全量升级标识，则通过所述预设检验项目。

21.根据权利要求14所述的升级包发送管理装置，其特征在于，所述检验子模块具体用于：

获取第一合并时长；其中，所述第一合并时长为将所述第二待升级数据包与第二全量升级包进行合并所需的时耗；所述第二全量升级包为升级到所述当前程序版本所需的全量升级包；

检验所述第一合并时长是否超过全量传输时长；其中，所述全量传输时长为将第三全量升级包传输至客户端所需的时耗；所述第三全量升级包为升级到最新发布版本所需的全量升级包；

如果所述第一合并时长超过全量传输时长，则判定未通过所述预设检验项目；

如果所述第一合并时长不超过全量传输时长，则判定通过所述预设检验项目。

22.根据权利要求14所述的升级包发送管理装置，其特征在于，所述检验子模块具体用于：

比较所述第二待升级数据包与第三全量升级包的体积差异；

如果所述体积差异满足预设条件，则通过所述预设检验项目；

如果所述体积差异不满足预设条件，则判定未通过所述预设检验项目。

23.一种增量升级包制备装置，其特征在于，所述增量升级包制备装置包括：

获取模块，用于获取升级到最新发布版本所需的目标全量升级包；

生成模块，用于根据所述目标全量升级包与相邻全量升级包，生成对应的增量升级包；其中，所述相邻全量升级包为升级到相邻上一个程序版本所需的全量升级包；

计时模块，用于获取将所述增量升级包与所述相邻全量升级包进行合并所需的第二合并时长；

处理模块，用于若所述第二合并时长超过全量传输时长，则丢弃所述增量升级包并将所述全量升级标识赋予所述目标全量升级包；其中，所述全量传输时长为将所述目标全量升级包传输给客户端所需时耗。

24.根据权利要求23所述的增量升级包制备装置，其特征在于，所述增量升级包制备装置还包括：

比较模块，用于若所述第二合并时长未超过全量传输时长，则比较所述目标全量升级包与对应的所述增量升级包之间的体积差异；

所述处理模块，还用于在所述体积差异不满足预设条件的情况下，丢弃所述增量升级包并将所述全量升级标识赋予所述目标全量升级包。

25.一种服务器，其特征在于，包括处理器和存储器，所述存储器存储有能够被所述处理器执行的机器可执行指令，所述处理器可执行所述机器可执行指令以实现权利要求1-10任一所述的级包发送管理方法；或者所述处理器可执行所述机器可执行指令以实现权利要求11或12所述的增量升级包制备方法。

26.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-10任一所述的级包发送管理方法；或者所述计算机程序被处理器执行时实现如权利要求11或12所述的增量升级包制备方法。

Images