CN114691175A - 一种应用更新方法、装置和系统 - Google Patents

Abstract

本申请公开了一种应用更新方法、装置和系统，该方法包括：在对应用进行更新的情况下，确定应用中的多个模块的最新版本相较于历史版本的差量数据，差量数据中包括每个模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；接收客户端的更新请求，更新请求中包括待更新模块的模块标识和版本号；根据待更新模块的模块标识和版本号，从差量数据中确定对应的目标差量数据；将目标差量数据发送给客户端，由客户端基于目标差量数据对待更新模块进行更新。在对应用进行更新时，通过下发待更新模块对应的差量数据可以实现基于模块的差量更新，针对客户端而言，由于从服务端获取的更新数据为差量数据，因此可以有效减少客户端的流量消耗。

Description

一种应用更新方法、装置和系统

技术领域

本申请涉及计算机技术领域，尤其涉及一种应用更新方法、装置和系统。

背景技术

通常，终端中可以安装各种不同的应用，在用户使用应用的过程中，服务端可以定时或不定时地对应用进行更新，以便基于更新后的应用为用户提供更好地服务。

目前在对应用进行更新时，通常是服务端将应用最新版本的全量配置文件下发给客户端，然后由客户端基于该全量配置文件进行应用更新。然而，由于每次对应用进行更新时都需要客户端从服务端获取全量配置文件，因此，会增加客户端的流量消耗。

发明内容

本申请实施例提供一种应用更新方法、装置和系统，用于解决目前的应用更新方法会增加客户端的流量消耗的问题。

为解决上述技术问题，本申请实施例是这样实现的：

第一方面，提出一种应用更新方法，包括：

在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

接收客户端的更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；

将所述目标差量数据发送给所述客户端，由所述客户端基于所述目标差量数据对所述待更新模块进行更新。

第二方面，提出一种应用更新装置，包括：

第一确定模块，在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

接收模块，接收客户端的更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

第二确定模块，根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；

发送模块，将所述目标差量数据发送给所述客户端，由所述客户端基于所述目标差量数据对所述待更新模块进行更新。

第三方面，提出一种电子设备，该电子设备包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：

在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

接收客户端的更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；

将所述目标差量数据发送给所述客户端，由所述客户端基于所述目标差量数据对所述待更新模块进行更新。

第四方面，提出一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下方法：

在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

接收客户端的更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；

将所述目标差量数据发送给所述客户端，由所述客户端基于所述目标差量数据对所述待更新模块进行更新。

第五方面，提出一种应用更新系统，包括服务端和客户端，其中：

所述服务端在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

所述客户端向所述服务端发送更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

所述服务端根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；将所述目标差量数据发送给所述客户端；

所述客户端基于所述目标差量数据对所述待更新模块进行更新。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

在对应用进行更新的情况下，服务端可以确定应用中的多个模块的最新版本相较于历史版本的差量数据，该差量数据中包括应用中每个模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据，当客户端有更新需求时，可以将待更新模块的模块标识和版本号携带在更新请求中，服务端在接收到客户端的更新请求时，可以根据更新请求中的模块标识和版本号从预先确定的差量数据中确定对应的目标差量数据，并将目标差量数据下发给客户端，由客户端基于目标差量数据对待更新模块进行更新。这样，在对应用进行更新时，由于可以根据每个模块中发生更新的一项或多项配置确定针对每个模块的差量数据，并在客户端有更新需求时，将待更新模块对应的差量数据下发给客户端，因此，可以实现基于模块的差量更新，针对客户端而言，由于从服务端获取的更新数据为差量数据，因此，可以有效减少客户端的流量消耗，节省客户端的流量。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请的一个实施例应用更新方法的流程示意图；

图2是本申请的一个实施例应用更新方法的流程示意图；

图3是本申请的一个实施例电子设备的结构示意图；

图4是本申请的一个实施例应用更新装置的结构示意图；

图5是本申请的一个实施例应用更新系统的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

目前，在对应用进行更新时，服务端通常会向客户端一次下发全量的配置文件，然后由客户端读取配置文件中的配置项进行应用更新。然而，在实际应用中，在对应用进行更新时，通常是对应用中的某一项或多项配置进行更新，而应用中通常包括几百至几千项配置，如果每次更新都将全量的配置文件下发给客户端，那么就会造成不必要的流量消耗，同时全量的配置文件也不便于客户端进行应用更新。

为了解决上述技术问题，本申请实施例提供一种应用更新方法、装置和系统，在对应用进行更新的情况下，服务端可以确定应用中的多个模块的最新版本相较于历史版本的差量数据，该差量数据中包括应用中每个模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据，当客户端有更新需求时，可以将待更新模块的模块标识和版本号携带在更新请求中，服务端在接收到客户端的更新请求时，可以根据更新请求中的模块标识和版本号从预先确定的差量数据中确定对应的目标差量数据，并将目标差量数据下发给客户端，由客户端基于目标差量数据对待更新模块进行更新。

这样，在对应用进行更新时，由于可以根据每个模块中发生更新的一项或多项配置确定针对每个模块的差量数据，并在客户端有更新需求时，将待更新模块对应的差量数据下发给客户端，因此，可以实现基于模块的差量更新，针对客户端而言，由于从服务端获取的更新数据为差量数据，因此，可以有效减少客户端的流量消耗，节省客户端的流量。

本申请实施例提供的技术方案在对应用进行更新时，核心思想是：预先将应用划分为多个模块，每个模块中包括至少一项配置，在对应用进行更新时，确定每个模块相较于历史各版本发生更新的一项或多项配置的配置数据，得到每个模块相较于历史各版本的待更新的差量数据，当客户端有更新需求时，将待更新模块的模块标识和版本号携带在更新请求中，服务端可以根据待更新模块的模块标识和版本号从预先确定的差量数据中确定对应的目标差量数据并发送给客户端，由客户端进行差量更新。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1是本申请的一个实施例应用更新方法的流程示意图。图1所示实施例的执行主体可以是服务端，该服务端可以是应用对应的服务端，也可以是专用于进行应用更新的服务端，这里不做具体限定。图1所示的应用更新方法如下所述。

S102：在对应用进行更新的情况下，确定应用中的多个模块的最新版本相较于历史版本的差量数据，差量数据中包括每个模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据。

应用中可以包括多个模块，每个模块中可以包括一项或多项配置，在对应用进行更新的情况下，可以确定更新后的应用中每个模块的最新版本相较于历史版本的差量数据，该差量数据中包括每个模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据。

本实施例中，应用中的多个模块可以根据应用中的不同功能划分得到，也可以根据实际的场景需求划分得到，这里不做具体限定。

差量数据为待更新数据，在对应用进行更新的情况下，可以针对应用中的每个模块分别确定对应的差量数据，以便后续可以进行差量更新。其中，对应用的更新操作可以由运营管理平台操作人员执行，差量数据的确定操作可以由运营管理平台操作人员触发，比如，运营管理平台操作人员在确定对应用进行更新并确认本次更新完成后，可以点击发布，当触发发布操作时，可以触发确定差量数据的操作。

可选地，作为一个实施例，在确定应用中的多个模块的最新版本相较于历史版本的差量数据时，可以包括以下S1021至S1023：

S1021：确定应用中更新的至少一项配置以及至少一项配置对应的至少一个目标模块。

在对应用进行更新时，可以对应用中的至少一项配置进行更新。在对应用更新完成的情况下，可以确定应用本次更新的至少一项配置以及该至少一项配置对应的至少一个目标模块。

在确定至少一项配置对应的至少一项目标模块时，具体地，可以预先根据不同模块中包括的一项或多项配置确定不同模块和不同配置之间的对应关系，这样，在确定至少一项配置对应的至少一个目标模块时，针对每项发生更新的配置，可以分别根据预先确定的对应关系确定对应的目标模块，由此可以得到与该至少一项配置对应的至少一个目标模块。其中，一个目标模块可以对应一项或多项发生更新的配置。

在确定至少一个目标模块后，可以将该至少一个目标模块的版本号加一，加一后得到的版本号为目标模块的最新版本号。之后，针对每个目标模块，可以通过以下S1022和S1023确定对应的差量数据。

S1022：获取目标模块的最新版本中每项配置的配置数据以及目标模块的多个历史版本中每项配置的历史配置数据。

本实施例中，服务端可以将应用中不同模块的不同版本(包括最新版本和各历史版本)中每项配置的配置数据存储在服务端的本地数据库中，当需要获取目标模块的不同版本中每项配置的配置数据时，可以从服务端的本地数据库中获取。

最新版本中每项配置的配置数据即为对应用进行更新后该目标模块中的全部配置数据。历史版本中每项配置的历史配置数据即为对应用进行更新前该目标模块中的全部配置数据。其中，考虑到用户在使用应用的过程中会对应用进行不断更新，且不同用户对应用的更新次数不同，更新后的应用的版本号也可能不同，因此，为了便于对不同版本的应用进行更新，在获取历史版本的历史配置数据时，可以获取多个历史版本的历史配置数据。此外，考虑到在更新应用的过程中，使用历史版本的用户越来越少，因为，在获取多个历史版本的历史配置数据时，可以获取最近的预设数量的多个历史版本的历史配置数据，比如，可以获取最近的20个历史版本的历史配置数据，这样，可以减少服务端计算差量数据时的计算量，节省资源。

S1023：针对每个历史版本，将目标模块的最新版本中每项配置的配置数据与历史版本中对应配置的历史配置数据进行比对，确定目标模块的最新版本相较于历史版本的差量数据。

以其中一个历史版本为例，在获取到目标模块的最新版本中每项配置的配置数据以及该历史版本中每项配置的历史配置数据后，可以将目标模块中每项配置的最新版本的配置数据与该项配置的历史配置数据进行比对，从而可以确定目标模块中哪些配置发生了更新，然后将发生更新的配置对应的最新版本的配置数据确定为差量数据，由此可以得到目标模块的最新版本相较于一个历史版本的差量数据。基于相同的方法，可以确定得到目标模块的最新版本相较于每个历史版本的差量数据。

例如，假设应用中包括A、B、C三个功能模块，对应的最新版本分别为A:10、B:1和C:20，运营管理平台在对应用进行更新时更新了模块A和B中的配置，更新后，三个功能模块的版本号分别为A:11、B:2和C:20(保持不变)。这样，针对功能模块A，假设模块A中包括k1、k2和k3三个配置项，版本11中各项配置的配置数据分别为v1、v2和v3，版本10中各项配置的配置数据分别为v11、v2和v3，版本9中各项配置的配置数据分别为v12、v21和v3，那么，在生成差量数据时，版本11相较于版本9的差量数据为k1:v1、k2:v2，版本11相较于版本10的差量数据为k1:v1。

同理，针对功能模块B，假设模块B中包括k4、k5和k6三个配置项，版本2中各项配置的配置数据分别为v4、v5和v6，版本1中各项配置的配置数据分别为v4、v51和v6，版本0中各项配置的配置数据分别为v4、v52和v61，那么，在生成差量数据时，版本2相较于版本0的差量数据为k5:v5、k6:v6，版本2相较于版本1的差量数据为k5:v5。

需要说明的是，以上仅以应用中包括3个模块，每个模块中包括3项配置且差量数据中包括模块的最新版本相较于两个历史版本的差量数据为例进行说明，在实际的场景中，应用中可以包括更多个模块，每个模块可以包括一项或多项配置，且差量数据中包括模块的最新版本相较于更多个历史版本的差量数据。

可选地，作为一个实施例，在确定得到目标模块的最新版本相较于多个历史版本的差量数据后，还可以将差量数据进行存储，以便后续当客户端有更新需求时，可以从已存储的差量数据中查找对应的目标差量数据。

具体地，在存储目标模块的最新版本相较于多个历史版本的差量数据时，针对每个历史版本，可以以key-value的方式存储目标模块的最新版本相较于该历史版本的差量数据。其中，key中包括目标模块的模块标识和历史版本的版本号，value中包括目标模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据。

以上述A、B和C三个功能模块为例。针对模块A而言，已知模块A的最新版本为版本11，版本11相较于版本9的差量数据为k1:v1、k2:v2，版本11相较于版本10的差量数据为k1:v1，那么，在存储差量数据k1:v1、k2:v2时，存储的key可以是模块A、版本9，对应的格式可以是<A>:<9>，value可以是k1:v1、k2:v2，对应的格式可以是json格式，具体表示为"k1":"v1"，"k2":"v2"，在存储差量数据k1:v1时，存储的key可以是模块A、版本9，对应的格式可以是<A>:<10>，value可以是k1:v1，对应的格式可以是json格式，具体表示为"k1":"v1"。也就是说，针对模块A，其差量数据可以存储为：

key：<A>:<9>；value："k1":"v1"，"k2":"v2"；

key：<A>:<10>；value："k1":"v1"。

同理，针对模块B，其差量数据可以存储为：

key：<B>:<0>；value："k5":"v5"，"k6":"v6"；

key：<B>:<1>；value："k5":"v5"。

基于上述S1021至S1023记载的内容，服务端可以确定得到应用中多个模块的最新版本相较于历史版本的差量数据。在得到差量数据后，当客户端有更新需求时，服务端可以基于差量数据向客户端提供更新服务，具体可以包括以下S104至S108。

需要说明的是，服务端在每次对应用进行更新时，都可以基于S102中记载的内容确定应用中的多个模块的最新版本相较于历史版本的差量数据，即服务端在每次对应用进行更新时，都会对差量数据进行更新，从而可以保证向客户端提供最新的更新服务。

S104：接收客户端的更新请求，更新请求中包括待更新模块的模块标识和版本号。

本实施例中，客户端可以预先将应用划分为多个模块，该多个模块的划分方式可以与服务端将应用划分为多个模块的方式相同。当客户端对应用中的一个或多个模块有更新需求时，客户端可以将该一个或多个待更新模块的模块标识和版本号携带在更新请求中，然后将更新请求发送给服务端，此时服务端可以接收到客户端的更新请求。

可选地，作为一个实施例，客户端可以针对不同的模块设置不用的更新策略，该更新策略中可以包括更新时机，具体可以表征客户端在何种时机下发送更新请求，这样，服务端接收到的更新请求可以是客户端在指定时机下发送的更新请求，服务端在接收到更新请求后，可以基于后续S106和S108记载的内容向客户端提供更新服务，以便客户端在合适的时机对应用进行更新。或者，客户端的更新策略中也可以包括更新频率，具体可以表征客户端以何种频率发送更新请求，这样，服务端接收到的更新请求可以是客户端以预设频率发送的更新请求，针对每个更新请求，服务端可以基于后续S106和S108记载的内容向客户端提供更新服务，以便客户端可以以预设频率对应用进行更新。

上述指定时机可以由客户端或服务端预先设置，该指定时机可以是用户点击应用中的某个功能模块时，具体而言，在用点击应用中的某个功能模块时，可以触发客户端向服务端发送更新请求，该更新请求中可以携带用户点击的功能模块的模块标识和版本号。比如，清理应用主界面包含了核心清理功能模块，可以在用户点击进入主界面时触发更新请求，以更新清理策略。

上述预设频率可以根据模块的使用情况或属性确定得到，具体而言，可以根据模块的使用频率和模块的重要程度中的至少一项确定得到。比如，三级菜单中的反馈功能模块，考虑到重要性不是那么大，因此针对该模块可以每周发起更新请求，以更新文案等信息。再比如，天气应用中的温度模块，考虑到用户通常需要了解最新的天气变化，因此可以每五分钟发起更新请求，以更新天气情况。

需要说明的是，以上仅以更新策略中包括更新时机和更新频率为例进行说明，在其他实现方式中，也可以包括其他更新策略，比如，设定固定的更新频率，或者设置手动更新等，这里不再一一举例说明。

通过在客户端设置更新策略，并由客户端基于更新策略向服务端发送针对不同模块的更新请求，可以满足用户对应用的更新需求，从而为用户提供更好的更新服务。

S106：根据待更新模块的模块标识和版本号，从差量数据中确定对应的目标差量数据。

服务端在接收到客户端的更新请求后，可以基于更新请求中携带的模块标识和版本号，从预先确定的差量数据中查找与该模块标识和版本号对应的目标差量数据，该目标差量数据可以用于客户端对待更新模块进行差量更新(也可以称为增量更新)。

可选地，作为一个实施例，考虑到服务端确定的差量数据中包括的是模块的最新版本相较于最近几个历史版本的差量数据，并未将距离最新版本较远的且用户使用量较少的历史版本对应的差量数据考虑在内，因此，在从服务端的差量数据中确定目标差量数据时，可以先判断更新请求中携带的待更新模块的版本号与该待更新模块的最新版本号之间的差异是否小于或等于预设阈值。预设阈值可以根据服务端中预先确定的差量数据所对应的历史版本号进行设置。比如，针对模块A，服务端中包括距离模块A最新版本最近的20个历史版本的差量数据，则该预设阈值可以设置为20。

若待更新模块的版本号与待更新模块的最新版本号之间的差异小于或等于预设阈值，则可以认为待更新模块的版本号是最近的某个历史版本，且服务端中包括对应的差量数据，此时，可以根据待更新模块的模块标识和版本号，从服务端预先确定的差量数据中确定对应的目标差量数据。具体而言，可以将待更新模块的模块标识和版本号作为key，在预先确定的差量数据中查找与该key对应的value，并将查找到的value确定为目标差量数据。在确定目标差量数据后，可以执行S108。

若待更新模块的版本号与待更新模块的最新版本号之间的差异大于预设阈值，则可以认为待更新模块的版本号是距离最新版本较远的某个历史版本，且服务端中可能不包括对应的差量数据，此时，为了将待更新模块从较远的历史版本更新为到最新版本，可以获取待更新模块的最新版本的全量数据，并将该全量数据作为更新数据下发给客户端，由客户端基于该全量数据对待更新模块进行全量更新。由于在待更新模块的版本号过低的情况下，服务端可以将全量数据下发给客户端进行全量更新，无需从预先确定的差量数据中查找对应目标差量数据，因此，一方面可以实现对待更新模块的全量更新，有效地将待更新模块更新到最新版本，另一方面还可以简化服务端对差量数据的查找处理逻辑，提高处理效率。

S108：将目标差量数据发送给客户端，由客户端基于目标差量数据对待更新模块进行更新。

服务端在确定目标差量数据后，可以将目标差量数据下发给客户端。客户端在接收到目标差量数据后，可以基于目标差量数据对待更新模块进行差量更新。由于可以根据每个模块中发生更新的一项或多项配置确定针对每个模块的差量数据，并在客户端有更新需求时，将待更新模块对应的差量数据下发给客户端，因此，可以实现基于模块的差量更新，针对客户端而言，由于从服务端获取的更新数据为差量数据，因此，可以有效减少客户端的流量消耗，节省客户端的流量。

可选地，作为一个实施例，客户端在基于目标差量数据对待更新模块进行更新时，为了避免出错，还可以先判断获取到的目标差异数据是否为最新的配置数据。比如，客户端可以在本地存储上次更新时应用中不同模块的配置数据，在获取到目标差量数据后，可以将目标差量数据与本地存储的待更新模块的配置数据进行比较，判断该目标差量数据是否为最新的配置数据。若目标差量数据为最新的配置数据，则可以基于目标差异数据对待更新模块进行更新，反之，则可以不对待更新模块进行更新，以避免出错。

基于上述S102至S108记载的内容可知，本申请实施例提供的技术方案至少可以实现以下技术效果：

(1)控制灵活，通用性好，既可以通过单个应用的功能模块请求对应模块的配置数据，也可以请求全部模块的全部配置数据；

(2)节约计算能力，服务端提前生成计算每个模块和对每个版本的增量数据，计算量小，抗并发能力强；

(3)维护成本低，脱离配置文件形式，使用数据下发，操作人员只需要调整对应的配置项，不需要维护完整的文件；

(4)只下发与客户端对应的变更部分，有效减少客户端的流量消耗，间接提升了后端资源成本的效率。

(5)客户端每次收到配置数据后不需要维护多个文件及全部，只需要存储或更新变更部分，客户端性能好。

为了便于理解本申请实施例提供的技术方案，可以参见图2。图2是本申请的一个实施例应用更新方法的流程示意图。图2所示实施例的执行主体与图1所示实施例的执行主体相同，图2所示的实施例可以包括以下步骤。

S201：在对应用进行更新的情况下，确定应用中更新的至少一项配置以及至少一项配置对应的至少一个目标模块。

S202：针对每个目标模块，获取目标模块的最新版本中每项配置的配置数据以及目标模块的多个历史版本中每项配置的历史配置数据。

S203：针对每个历史版本，将目标模块的最新版本中每项配置的配置数据与历史版本中对应配置的历史配置数据进行比对，确定目标模块的最新版本相较于历史版本的差量数据。

S204：针对每个目标模块，将目标模块的最新版本相较于各历史版本的差量数据以key-value的方式进行存储。

其中，针对每个目标模块的每个历史版本，存储的key中包括目标模块的模块标识和历史版本的版本号，value中包括目标模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据。

S205：接收客户端的更新请求，更新请求中包括待更新模块的模块标识和版本号。

更新请求由客户端在指定时机下发送，或由客户端以预设频率发送，不同模块的更新请求对应的预设频率不同。

S206：以待更新模块的模块标识和版本号为key，从差量数据中查找与key对应的value。

S207：将查找到的value作为目标差量数据发送给客户端，由客户端基于目标差量数据对待更新模块进行更新。

上述S201至S207的具体实现方式可以参见上述S102至S108中相应步骤的具体实现，这里不再重复说明。

可选地，在执行S205后，在致新S206之前，还可以判断更新模块的版本号与待更新模块的最新版本号之间的差异是否小于或等于预设阈值(图2并未示出)，若是，则可以执行S206，若否，则可以获取待更新模块的最新版本的全量数据，并将全量数据发送给客户端，由客户端基于全量数据对待更新模块进行全量更新，以将过低版本的待更新模块更新至最新版本。

本申请实施例提供的技术方案，在对应用进行更新的情况下，服务端可以确定应用中的多个模块的最新版本相较于历史版本的差量数据，该差量数据中包括应用中每个模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据，当客户端有更新需求时，可以将待更新模块的模块标识和版本号携带在更新请求中，服务端在接收到客户端的更新请求时，可以根据更新请求中的模块标识和版本号从预先确定的差量数据中确定对应的目标差量数据，并将目标差量数据下发给客户端，由客户端基于目标差量数据对待更新模块进行更新。这样，在对应用进行更新时，由于可以根据每个模块中发生更新的一项或多项配置确定针对每个模块的差量数据，并在客户端有更新需求时，将待更新模块对应的差量数据下发给客户端，因此，可以实现基于模块的差量更新，针对客户端而言，由于从服务端获取的更新数据为差量数据，因此，可以有效减少客户端的流量消耗，节省客户端的流量。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

图3是本申请的一个实施例电子设备的结构示意图。请参考图3，在硬件层面，该电子设备包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图3中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成应用更新装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

接收客户端的更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；

将所述目标差量数据发送给所述客户端，由所述客户端基于所述目标差量数据对所述待更新模块进行更新。

上述如本申请图3所示实施例揭示的应用更新装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该电子设备还可执行图1和图2的方法，并实现应用更新装置在图1和图2所示实施例中的功能，本申请实施例在此不再赘述。

当然，除了软件实现方式之外，本申请的电子设备并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的便携式电子设备执行时，能够使该便携式电子设备执行图1和图2所示实施例的方法，并具体用于执行以下操作：

在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

接收客户端的更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；

将所述目标差量数据发送给所述客户端，由所述客户端基于所述目标差量数据对所述待更新模块进行更新。

图4是本申请的一个实施例应用更新装置40的结构示意图。请参考图4，在一种软件实施方式中，所述应用更新装置40可包括：第一确定模块41、接收模块42、第二确定模块43和发送模块44，其中：

第一确定模块41，在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

接收模块42，接收客户端的更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

第二确定模块43，根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；

发送模块44，将所述目标差量数据发送给所述客户端，由所述客户端基于所述目标差量数据对所述待更新模块进行更新。

可选地，作为一个实施例，所述第一确定模块41确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，包括：

确定所述应用中更新的至少一项配置以及所述至少一项配置对应的至少一个目标模块；

针对每个所述目标模块，执行以下操作：

获取所述目标模块的最新版本中每项配置的配置数据以及所述目标模块的多个历史版本中每项配置的历史配置数据；

针对每个历史版本，将所述目标模块的最新版本中每项配置的配置数据与所述历史版本中对应配置的历史配置数据进行比对，确定所述目标模块的最新版本相较于所述历史版本的差量数据。

可选地，作为一个实施例，所述第一确定模块41在确定所述目标模块的最新版本相较于所述历史版本的差量数据后，还包括：

以key-value的方式存储所述目标模块的最新版本相较于所述历史版本的差量数据；

其中，所述key中包括所述目标模块的模块标识和所述历史版本的版本号，所述value中包括所述目标模块的最新版本相较于所述历史版本发生更新的一项或多项配置中的配置数据。

可选地，作为一个实施例，所述更新请求由所述客户端在指定时机下发送；或，所述更新请求由所述客户端以预设频率发送，不同模块的更新请求对应的预设频率不同；

其中，所述预设频率通过以下至少一项确定得到：

模块的使用频率；模块的重要程度。

可选地，作为一个实施例，所述第二确定模块42根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据，包括：

判断所述待更新模块的版本号与所述待更新模块的最新版本号之间的差异是否小于或等于预设阈值；

若是，则根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据。

可选地，作为一个实施例，所述第二确定模块42还包括：

若所述待更新模块的版本号与所述待更新模块的最新版本号之间的差异大于所述预设阈值，则获取所述待更新模块的最新版本的全量数据；

将所述全量数据发送给所述客户端，由所述客户端基于所述全量数据对所述待更新模块进行更新。

本申请实施例提供的应用更新装置40还可执行图1和图2的方法，并实现应用更新装置在图1和图2所示实施例的功能，本申请实施例在此不再赘述。

图5是本申请的一个实施例应用更新系统的结构示意图。请参考图5，图5所示的应用更新系统50可以包括服务端51和客户端52，其中：

所述服务端51在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

所述客户端52向所述服务端51发送更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

所述服务端51根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；将所述目标差量数据发送给所述客户端52；

所述客户端52基于所述目标差量数据对所述待更新模块进行更新。

本实施例中，服务端51可以实现上述图1和图2所示实施例中服务端实现的功能，客户端52可以实现上述图1和图2所示实施例中客户端实现的功能，具体实现方式可以参见上述图1和图2所示实施例中相应步骤的具体实现，这里不再重复描述。

总之，以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

Claims (10)

1.一种应用更新方法，其特征在于，包括：

在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

接收客户端的更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；

将所述目标差量数据发送给所述客户端，由所述客户端基于所述目标差量数据对所述待更新模块进行更新。

2.如权利要求1所述的方法，其特征在于，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，包括：

确定所述应用中更新的至少一项配置以及所述至少一项配置对应的至少一个目标模块；

针对每个所述目标模块，执行以下操作：

获取所述目标模块的最新版本中每项配置的配置数据以及所述目标模块的多个历史版本中每项配置的历史配置数据；

针对每个历史版本，将所述目标模块的最新版本中每项配置的配置数据与所述历史版本中对应配置的历史配置数据进行比对，确定所述目标模块的最新版本相较于所述历史版本的差量数据。

3.如权利要求2所述的方法，其特征在于，在确定所述目标模块的最新版本相较于所述历史版本的差量数据后，所述方法还包括：

以key-value的方式存储所述目标模块的最新版本相较于所述历史版本的差量数据；

其中，所述key中包括所述目标模块的模块标识和所述历史版本的版本号，所述value中包括所述目标模块的最新版本相较于所述历史版本发生更新的一项或多项配置中的配置数据。

4.如权利要求1所述的方法，其特征在于，

所述更新请求由所述客户端在指定时机下发送；或，

所述更新请求由所述客户端以预设频率发送，不同模块的更新请求对应的预设频率不同；

其中，所述预设频率通过以下至少一项确定得到：

模块的使用频率；模块的重要程度。

5.如权利要求1所述的方法，其特征在于，根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据，包括：

判断所述待更新模块的版本号与所述待更新模块的最新版本号之间的差异是否小于或等于预设阈值；

若是，则根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据。

6.如权利要求5所述的方法，其特征在于，所述方法还包括：

若所述待更新模块的版本号与所述待更新模块的最新版本号之间的差异大于所述预设阈值，则获取所述待更新模块的最新版本的全量数据；

将所述全量数据发送给所述客户端，由所述客户端基于所述全量数据对所述待更新模块进行更新。

7.一种应用更新装置，其特征在于，包括：

第一确定模块，在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

接收模块，接收客户端的更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

第二确定模块，根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；

发送模块，将所述目标差量数据发送给所述客户端，由所述客户端基于所述目标差量数据对所述待更新模块进行更新。

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

处理器；以及

被安排成存储计算机可执行指令的存储器，该可执行指令在被执行时使该处理器执行以下操作：

在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

接收客户端的更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；

将所述目标差量数据发送给所述客户端，由所述客户端基于所述目标差量数据对所述待更新模块进行更新。

9.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的电子设备执行时，使得所述电子设备执行以下方法：

在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

接收客户端的更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；

将所述目标差量数据发送给所述客户端，由所述客户端基于所述目标差量数据对所述待更新模块进行更新。

10.一种应用更新系统，其特征在于，所述系统包括服务端和客户端，其中：

所述服务端在对应用进行更新的情况下，确定所述应用中的多个模块的最新版本相较于历史版本的差量数据，所述差量数据中包括每个所述模块的最新版本相较于历史版本发生更新的一项或多项配置中的配置数据；

所述客户端向所述服务端发送更新请求，所述更新请求中包括待更新模块的模块标识和版本号；

所述服务端根据所述待更新模块的模块标识和版本号，从所述差量数据中确定对应的目标差量数据；将所述目标差量数据发送给所述客户端；

所述客户端基于所述目标差量数据对所述待更新模块进行更新。

Images