CN107357557A - 一种信息更新方法及装置 - Google Patents

Abstract

本申请公开了一种信息更新方法及装置，接收客户端发送的查新请求，确定查新请求中包含的待校验全局版本信息，根据保存的标准全局版本信息，校验待校验全局版本信息是否与最新全局版本信息一致，校验不一致时，确定待校验全局版本信息中与标准类别版本信息不一致的类别版本信息，并将相应的标准类别版本信息对应的静态业务信息发送至所述客户端进行更新。使用全局版本信息进行校验，可以避免针对客户端中的每一类别的静态业务信息都与各业务系统的静态业务信息进行一一比对校验，在校验过程中能够有效节省系统处理资源，进而提升了更新的效率。

Description

一种信息更新方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种信息更新方法及装置。

背景技术

随着互联网技术的不断发展，在线系统(如：网站)面向不同用户可提供相应的客户端，客户端作为一种访问在线系统的接入口，用户可以在客户端的界面中浏览或查看到由在线系统所提供的各类业务信息，从而便捷地获取到在线系统所提供的各类业务服务。

客户端所显示的业务信息通常分为两种：一种是在客户端每次运行时，从服务器中获取到的动态业务信息，如：新闻内容、实时天气信息、商品的销售量信息等，动态业务信息会实时发生变化。另一种是静态业务信息，存储在客户端本地，通常不会实时更新，例如：天气业务中的城市名、在线购物应用中商品的类目信息等。对于静态业务信息而言，受到外界因素的影响，仍会发生一定程度的变化，此时，就需要在线系统对静态业务信息进行更新。

现有技术中，由于不同类型的业务所对应的静态业务信息各不相同，而不同类型的业务通常由在线系统后台不同的业务系统进行管理。那么，当某一类型的业务的静态业务信息有更新内容时，在线系统便会根据具有更新内容的静态业务信息更新客户端中相应类型业务所对应的静态业务信息，以使得客户端所展示的静态业务信息，与在线系统内各业务系统所管理的静态业务信息保持一致。

但是，对上述的方式而言，由于在线系统中不同的业务系统只负责管理自身的静态业务信息，那么，当客户端每次与在线系统保持连接时，在线系统都需要分别查询每个业务系统所对应的静态业务信息，并分别与客户端中各类型的业务所对应的静态业务信息进行比对校验，以判断是否需要对静态业务信息进行更新。显然，这样的方式较为繁琐。

发明内容

本申请实施例提供一种信息更新方法及装置，用以解决现有技术中更新客户端中的静态业务信息的问题。

本申请实施例提供的一种信息更新方法，包括：

接收客户端发送的查新请求；

获取所述查新请求中包含的待校验全局版本信息；其中，所述待校验全局版本信息中包含多个业务的静态业务信息分别对应的类别版本信息；

根据保存的标准全局版本信息，校验所述待校验全局版本信息是否与所述标准全局版本信息一致；其中，所述标准全局版本信息中包含多个业务的静态业务信息所对应的标准类别版本信息；

当校验不一致时，在待校验全局版本信息中确定与标准类别版本信息不一致的类别版本信息，并将该类别版本信息对应的静态业务信息发送至所述客户端进行更新。

本申请实施例还提供的一种信息更新方法，包括：

向服务器发送查新请求，以使得所述服务器确定所述查新请求中包含的多个业务的静态业务信息的待校验全局版本信息，根据保存的标准全局版本信息，校验所述待校验全局版本信息是否与所述标准全局版本信息一致，并当校验不一致时，在待校验全局版本信息中确定与标准类别版本信息不一致的类别版本信息，将相应的标准类别版本信息对应的静态业务信息反馈给所述客户端；

接收所述服务器反馈的静态业务信息；

根据接收到的所述静态业务信息，更新相应业务原有的静态业务信息。

本申请实施例还提供的一种信息更新装置，包括：

接收模块，接收客户端发送的查新请求；

获取模块，获取所述查新请求中包含的待校验全局版本信息；其中，所述待校验全局版本信息中包含多个业务的静态业务信息分别对应的类别版本信息；

校验模块，根据保存的标准全局版本信息，校验所述待校验全局版本信息是否与所述标准全局版本信息一致；其中，所述标准全局版本信息中包含多个业务的静态业务信息所对应的标准类别版本信息；

更新模块，当校验不一致时，确定待校验全局版本信息中与标准类别版本信息不一致的类别版本信息，并将相应的标准类别版本信息对应的静态业务信息发送至所述客户端进行更新。

本申请实施例还提供的一种信息更新装置，包括：

发送模块，用于向服务器发送查新请求，以使得所述服务器确定所述查新请求中包含多个业务的静态业务信息的待校验全局版本信息，根据保存的标准全局版本信息，校验所述待校验全局版本信息是否与所述标准全局版本信息一致，并当校验不一致时，确定待校验全局版本信息中与标准类别版本信息不一致的类别版本信息，将相应的标准类别版本信息对应的静态业务信息反馈给所述客户端；

接收模块，接收所述服务器反馈的静态业务信息；

更新模块，根据接收到的所述静态业务信息，更新相应业务原有的静态业务信息。

本申请实施例提供一种信息更新方法及装置，通过本方法，当服务器接收到了客户端发送的查新请求后，会确定出该查新请求所包含的待校验全局版本信息，这里的待校验全局版本信息反映了客户端本次存储的各类别的静态业务信息的版本，相应地，服务器中存储有标准全局版本信息，而标准全局版本信息反映了服务器内各业务系统所对应的静态业务信息的版本，服务器就会根据存储的标准全局版本信息对待校验全局版本信息进行校验，如果校验一致，那么就表明服务器中的静态业务信息并未发生变化；如果校验不一致，那么就表明服务器中的静态业务信息发生了变化，此时服务器就会对客户端本地的静态业务信息进行更新。显然，采用上述方式，服务器会统一地对其内部不同的业务系统各自的静态业务信息进行管理，并且，使用全局版本信息进行校验，可以避免针对客户端中的每一类别的静态业务信息都与各业务系统的静态业务信息进行一一比对校验，在校验过程中能够有效节省系统处理资源，进而提升了更新过程的效率。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1a为本申请实施例提供的基于服务器侧的信息更新过程；

图1b为在线系统中的服务器和各业务系统之间的架构示意图；

图2为本申请实施例提供的基于客户端侧的信息更新过程；

图3为本申请实施例提供的基于服务器侧的信息更新装置结构示意图；

图4为本申请实施例提供的基于客户端侧的信息更新装置结构示意图。

具体实施方式

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

如前所述，在线系统内部的不同业务系统各自管理自身的静态业务信息，当客户端与在线系统通过网络连接之后，在线系统需要分别检测客户端中属于不同业务系统的静态业务信息是否为最新，显然，这样的方式过于繁琐，实际应用中，在线系统面向大量的客户端都进行上述的静态业务信息的更新检测，将耗费过多的系统处理资源，并且，各业务系统各自管理自身静态业务信息的方式较为散乱，缺乏一种统一的管理方式。

基于此，就需要一种针对静态业务信息进行统一进行管理、更新的方式。故在本申请实施例中，提供了一种信息更新方法，如图1a所示。

需要说明的是，如图1a所示的方法将由在线系统后台的服务器进行相应的信息更新操作，可以理解，所述的服务器与在线系统后台的各个业务系统之间保持通讯交互，用以实时监测各业务系统中业务的静态业务信息的版本。具体而言，在线系统中的所述服务器和各业务系统之间的架构示意图如图1b所示。

具体而言，图1a所示的方法具体包括如下步骤：

S101：接收客户端发送的查新请求。

在本申请实施例中，所述的客户端可以运行于终端内，当用户通过终端启动客户端(或将客户端从终端的操作系统的后台激活至前台)时，客户端便会向服务器发出查新请求。

其中，查新请求是客户端所发出的用于查询静态业务信息更新的请求，并且，一旦静态业务信息发生了变更，则会进一步请求服务器进行更新。

在本申请实施例中的一种方式下，客户端会针对其中的多个业务的静态业务信息的版本生成相应的全局版本信息，可以认为，全局版本信息反映了当前时刻客户端中各业务的静态业务信息的版本状态的总体情况。

S102：获取所述查新请求中包含的待校验全局版本信息。

其中，所述待校验全局版本信息中包含多个业务的静态业务信息分别对应的类别版本信息。换言之，本申请实施例中的所述待校验全局版本信息随着各类别版本信息的变化进行变化。

在本申请实施例中，客户端本地存储有多个业务的静态业务信息，不同业务的静态类别信息均具有各自的版本信息，那么，客户端就会针对每一业务的静态业务信息，统计各版本信息，并据此生成相应的全局版本信息。

例如：客户端中包含两类业务A和B的静态业务信息，假设，业务A的静态业务信息的版本为a.1.0，业务B的静态业务信息的版本为b.2.1。全局版本信息为v.1.0。

在本示例中，若业务A或业务B的静态业务信息的版本发生了改变，全局版本信息均会发生改变，如：假设业务A的静态业务信息的版本变为a.1.1(业务B的静态业务信息的版本未改变)，那么，全局版本信息将变更为v.1.1。

从上例可见，只要任一类别的静态业务信息的版本信息发生了改变，那么，全局版本信息就会发生改变。换言之，全局版本信息反映了当前时刻所有类别的静态业务信息的当前版本。

需要说明的是，上述的全局版本信息是客户端中多个业务的静态业务信息的全局版本信息，而服务器中的不同的业务系统中可能存在已进行更新的静态业务信息，所以，客户端会将上述的全局版本信息作为一种待校验的信息携带在匹配请求中，发送给服务器，以便服务器对待校验的全局版本信息进行校验，也即，服务器将执行下述步骤S103。

S103：根据保存的标准全局版本信息，校验所述待校验全局版本信息是否与所述标准全局版本信息一致。

其中，所述标准全局版本信息中包含多个业务的类静态业务信息所对应的标准类别版本信息。换言之，所述标准全局版本信息随着各类别版本信息的变化进行变化。

相类似地，对于服务器而言，会获取不同业务系统的静态业务信息的版本信息，并基于各类别的静态业务信息的版本信息，生成全局版本信息，由于服务器内不同业务系统中的静态业务信息均是最新的，所以，这些静态业务信息的版本信息也是最新的，便可将这些版本信息作为标准版本信息，进而，服务器中的全局版本信息就是标准全局版本信息。

那么，客户端所发送的待校验的全局版本信息若与服务器内的标准全局版本信息一致，则表明服务器中各类别的静态业务信息并未有更新(即，待校验的全局版本信息就是最新的)；如果不一致，就表明待校验的全局版本信息并不是最新的，则需要针对客户端中的静态业务信息进行更新。也即，执行下述步骤S104。

S104：当校验不一致时，在待校验全局版本信息中确定与标准类别版本信息中不一致的类别版本信息，并将相应的标准类别版本信息对应的静态业务信息发送至所述客户端进行更新。

正如前述，若校验不一致，就表明服务器内某些业务的静态业务信息发生了变化，那么，服务器就会将发生了变化的静态业务信息发送给客户端，这样一来，客户端便可以对本地存储的静态业务信息进行更新。

通过上述步骤，当服务器接收到了客户端发送的查新请求后，会确定出该查新请求所包含的待校验全局版本信息，这里的待校验全局版本信息反映了客户端本次存储的各类别的静态业务信息的版本，相应地，服务器中存储有标准全局版本信息，而标准全局版本信息反映了服务器内各业务系统所对应的静态业务信息的版本，服务器就会根据存储的标准全局版本信息对待校验全局版本信息进行校验，如果校验一致，那么就表明服务器中的静态业务信息并未发生变化；如果校验不一致，那么就表明服务器中的静态业务信息发生了变化，此时服务器就会对客户端本地的静态业务信息进行更新。显然，采用上述方式，服务器会统一地对其内部不同的业务系统各自的静态业务信息进行管理，并且，使用全局版本信息进行校验，可以避免针对客户端中的每一类别的静态业务信息都与各业务系统的静态业务信息进行一一比对校验，在校验过程中能够有效节省系统处理资源，进而提升了更新过程的效率。

与现有技术不同的是，在本申请实施例中，服务器将统一管理各业务系统的静态业务信息的更新状态，也即，服务器将实时地监测各业务系统的静态业务信息的标准类别版本信息，并基于此生成标准全局版本信息，具体而言，保存各类静态业务信息所对应的标准全局版本信息，具体包括：实时监测各类静态业务信息所对应的各类别版本信息，针对实时监测到的各类静态业务信息的各类别版本信息，生成全局版本号，将所述全局版本号作为当前时刻的标准全局版本信息，并保存。

具体例如：假设在服务器中，A、B、C三类静态业务信息分别属于不同的三个业务系统，那么，服务器所保存的各类静态业务信息的类别版本信息、以及标准全局版本信息可以如下表1所示。

标准全局版本号	v.1.0
		A类版本号	a.2.1
B类版本号	b.0.1
		C类版本号	c.1.2

表1

从表1中可见，服务器保存了上述三类静态业务信息的标准类别版本信息(即，版本号)，以及所生成的标准全局版本信息(即，标准全局版本号)。可以认为，表1中的内容表征了当前时刻，服务器中各类别静态业务信息的最新状态。

假设业务系统B中的B类静态业务信息发生了变化，那么，业务系统B会更新B类静态业务信息的版本号，假设B类版本号从表1中的b.0.1变为b.0.2。那么，服务器在监测到之后，将更新全局版本号，并保存。具体而言，最新的全局版本号和各类静态业务信息的版本号如下表2所示。

标准全局版本号	v.1.1
		A类版本号	a.2.1
B类版本号	b.0.2
		C类版本号	c.1.2

表2

从表2中可见，B类版本号发生了变化后，标准全局版本号由表1中的v.1.0变更为表2中的v.1.1。

关于标准全局版本号的变更，需要说明的是，在本示例中，如果在业务系统B的静态业务信息发生了变化的同时，服务器监测到了业务系统C的静态业务信息也发生了变化，那么，服务器仍会将标准全局版本号更新为v.1.1。也就是说，服务器监测到一类或同时监测到多类静态业务发生了变化，服务器更新一次全局版本号。基于此，如果服务器已将标准全局版本号更新为v.1.1之后，监测到业务系统C的静态业务信息发生了变化，那么，服务器会再将标准全局版本号更新为v.1.2。

上述示例是为了说明在本申请实施例中服务器保存各类静态业务信息所对应的标准全局版本信息的过程，并不构成对本申请的限定。

基于上述内容，如果服务器校验出待校验全局版本信息与标准全局版本信息不一致，则会对客户端本地所保存的静态业务信息进行更新操作，具体而言，确定待校验全局版本信息中与标准类别版本信息不一致的类别版本信息，并将相应的标准类别版本信息对应的静态业务信息发送至所述客户端进行更新，具体包括：确定所述待校验全局版本信息中包含的各类静态业务信息的各类别版本信息，以及所述标准全局版本信息中包含的各类静态业务信息的各类别版本信息，查找与所述待校验全局版本信息中的类别版本信息不一致的标准类别版本信息，确定查找到的所述标准类别版本信息对应的业务，获取该业务的静态业务信息发送至所述客户端进行更新。

沿用上例：假设由客户端发送的查新请求中，所携带的待校验全局版本信息和各类别静态业务信息的类别版本信息如前述表1所示，而此时，对于服务器而言，由于其中的业务系统B的静态业务信息发生了变化，所以服务器的标准全局版本信息及各类别经静态业务信息的类别版本信息如前述表2所示。

故服务器校验出待校验全局版本信息与标准全局版本信息不一致后，进一步具体确定出B类静态业务信息不一致，所以，服务器将获取业务系统B的静态业务信息，并发送给客户端以进行静态业务信息的更新操作。

上述的更新过程，可以采用增量更新的方式(如：下发增量数据包)，也就是说，服务器只会将类别版本信息不一致的静态业务信息发送给客户端。这样的方式能够有效降低传输过程中的数据量，提升更新效率。当然，这里并不构成对本申请的限定。

这里需要说明的是，对于增量更新的方式，服务器会记录每一业务各次版本的静态业务信息，这样一来，在更新过程中，服务器将会获知客户端所需的静态业务信息，从而已增量数据包的方式将静态业务信息发送给客户端。

此外，作为本申请实施例中的一种方式，在实际应用中，可采用类别标识(如：字符串、key等)来表明类别版本信息所对应的业务系统，例如下表3所示。

标准全局版本号	v.1.0
		keyA	a.2.1
keyB	b.0.1
		keyC	c.1.2

表3

在表3中，字符串“keyA”、“keyB”、“keyC”就是类别标识，分别表示对应于业务系统A、B、C的三种类别的静态业务信息。这里并不构成对本申请的限定。

以上内容是基于服务器侧的描述，在本申请实施例中，基于客户端侧，还提供一种信息更新方法，如图2所示。该方法具体包括以下步骤：

S201：向服务器发送查新请求。

在实际应用中，客户端会在启动时、或者从终端操作系统的后台激活至前台时，向服务器发送查新请求。这里并不构成对本申请的限定。

客户端向服务器发出了查新请求之后，将使得所述服务器确定所述查新请求中包含多个业务的类静态业务信息的待校验全局版本信息，根据保存的标准全局版本信息，校验所述待校验全局版本信息是否与所述标准全局版本信息一致，并当校验不一致时，确定待校验全局版本信息中与标准类别版本信息不一致的类别版本信息，将相应的标准类别版本信息对应的静态业务信息反馈给所述客户端。

S202：接收所述服务器反馈的静态业务信息。

S203：根据接收到的所述静态业务信息，更新相应业务原有的静态业务信息。

从如图2所示的方法中可见，与前述的服务器侧相类似，客户端也会管理器本地存储的各类静态业务信息，根据各类静态业务信息的类别版本信息，生成待校验的全局版本信息。这样的方式能够从总体上体现出各类静态业务信息的版本状态，从而当服务器接收匹配请求后，可以便捷且快速地针对待校验全局版本信息进行校验。能够提升校验的效率并减少校验过程中系统处理资源的消耗。

作为本申请实施例中的一种方式，对静态业务信息进行更新的过程可采用增量更新，具体而言，根据接收到的静态业务信息，更新相应业务原有的静态业务信息，具体包括：确定接收到的静态业务信息所对应的业务，将接收到的静态业务信息，替换该业务原有的静态业务信息。

此外，客户端还会更新本地的全局版本信息，具体而言，接收所述服务器反馈的静态业务信息，还包括：接收所述服务器反馈的标准全局版本信息。

在此基础上，所述方法还包括：根据所述标准全局版本信息，更新已保存的全局版本信息。

基于上述如图1a和图2所示的信息更新方法，在实际应用场景下，可用于金融类客户端中各类文案的更新，其中，文案就是前述的静态业务信息，例金融类客户端所提供的股票业务中，各类股票的名称，就是一种文案；又例如：金融类客户端所提供的金融产品业务中，金融产品的名称及其详细信息，也是一种文案。那么，不同业务的文案需要更新时，就可以根据前述方法进行更新。具体过程不再赘述。

以上为本申请实施例提供的信息更新方法，基于同样的思路，本申请实施例还提供一种信息更新装置，如图3所示，所述装置包括：

接收模块301，接收客户端发送的查新请求。

获取模块302，获取所述查新请求中包含的待校验全局版本信息；其中，所述待校验全局版本信息中包含多个业务的静态业务信息分别对应的类别版本信息。

校验模块303，根据保存的标准全局版本信息，校验所述待校验全局版本信息是否与所述标准全局版本信息一致；其中，所述标准全局版本信息中包含多个业务的静态业务信息所对应的标准类别版本信息。

更新模块304，当校验不一致时，确定待校验全局版本信息中与标准类别版本信息不一致的类别版本信息，并将相应的标准类别版本信息对应的静态业务信息发送至所述客户端进行更新。

校验模块303，实时监测各业务的类静态业务信息所对应的最新的类别版本信息，作为标准类别版本信息，针对实时监测到的各类静态业务信息的各标准类别版本信息，生成全局版本号，将所述全局版本号作为标准全局版本信息，并保存。

更新模块304，确定所述待校验全局版本信息中包含的各类静态业务信息的各类别版本信息，以及所述标准全局版本信息中包含的各类静态业务信息的各类别版本信息，在所述标准全局版本信息中，查找与所述待校验全局版本信息中的类别版本信息不一致的标准类别版本信息，确定查找到的所述标准类别版本信息对应的业务，获取该业务的静态业务信息发送至所述客户端进行更新。

如图4所示，本申请实施例还提供一种信息更新装置，所述装置包括：

发送模块401，用于向服务器发送查新请求，以使得所述服务器确定所述查新请求中包含的多个业务的类静态业务信息的待校验全局版本信息，根据保存的标准全局版本信息，校验所述待校验全局版本信息是否与所述标准全局版本信息一致，并当校验不一致时，确定待校验全局版本信息中与标准类别版本信息不一致的类别版本信息，将相应的标准类别版本信息对应的静态业务信息反馈给所述客户端；

接收模块402，接收所述服务器反馈的静态业务信息；

更新模块403，根据接收到的所述静态业务信息，更新相应业务原有的静态业务信息。

更新模块403，确定接收到的静态业务信息所对应的业务，将接收到的静态业务信息，替换该业务原有的静态业务信息。

所述接收模块402，接收所述服务器反馈的标准全局版本信息。

所述更新模块403，根据所述标准全局版本信息，更新已保存的全局版本信息。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

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

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

Claims (12)

1.一种信息更新方法，其特征在于，所述方法包括：

接收客户端发送的查新请求；

获取所述查新请求中包含的待校验全局版本信息；其中，所述待校验全局版本信息中包含多个业务的静态业务信息分别对应的类别版本信息；

根据保存的标准全局版本信息，校验所述待校验全局版本信息是否与所述标准全局版本信息一致；其中，所述标准全局版本信息中包含多个业务的静态业务信息所对应的标准类别版本信息；

当校验不一致时，确定待校验全局版本信息中与标准类别版本信息不一致的类别版本信息，并将相应的标准类别版本信息对应的静态业务信息发送至所述客户端进行更新。

2.如权利要求1所述的方法，其特征在于，保存标准全局版本信息，具体包括：

实时监测各业务的静态业务信息所对应的最新的类别版本信息，作为标准类别版本信息；

针对实时监测到的各类静态业务信息的各标准类别版本信息，生成全局版本号；

将所述全局版本号作为标准全局版本信息，并保存。

3.如权利要求1所述的方法，其特征在于，确定待校验全局版本信息中与标准类别版本信息不一致的类别版本信息，并将相应的标准类别版本信息对应的静态业务信息发送至所述客户端进行更新，具体包括：

确定所述待校验全局版本信息中包含的、各类静态业务信息的各类别版本信息，以及所述标准全局版本信息中包含的、各类静态业务信息的各标准类别版本信息；

查找与所述待校验全局版本信息中的类别版本信息不一致的标准类别版本信息；

确定查找到的所述标准类别版本信息对应的业务；

获取该业务的静态业务信息发送至所述客户端进行更新。

4.一种信息更新方法，其特征在于，所述方法包括：

向服务器发送查新请求，以使得所述服务器确定所述查新请求中包含的多个业务的静态业务信息的待校验全局版本信息，根据保存的标准全局版本信息，校验所述待校验全局版本信息是否与所述标准全局版本信息一致，并当校验不一致时，确定待校验全局版本信息中与标准类别版本信息不一致的类别版本信息，将相应的标准类别版本信息对应的静态业务信息反馈给所述客户端；

接收所述服务器反馈的静态业务信息；

根据接收到的静态业务信息，更新相应业务原有的静态业务信息。

5.如权利要求4所述的方法，其特征在于，根据接收到的静态业务信息，更新相应业务原有的静态业务信息，具体包括：

确定接收到的静态业务信息所对应的业务；

将接收到的静态业务信息，替换该业务原有的静态业务信息。

6.如权利要求4所述的方法，其特征在于，接收所述服务器反馈的静态业务信息，还包括：

接收所述服务器反馈的标准全局版本信息；

所述方法还包括：

根据所述标准全局版本信息，更新已保存的全局版本信息。

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

接收模块，接收客户端发送的查新请求；

获取模块，获取所述查新请求中包含的待校验全局版本信息；其中，所述待校验全局版本信息中包含多个业务的静态业务信息分别对应的类别版本信息；

校验模块，根据保存的标准全局版本信息，校验所述待校验全局版本信息是否与所述标准全局版本信息一致；其中，所述标准全局版本信息中包含多个业务的静态业务信息所对应的标准类别版本信息；

更新模块，当校验不一致时，确定待校验全局版本信息中与标准类别版本信息不一致的类别版本信息，并将相应的标准类别版本信息对应的静态业务信息发送至所述客户端进行更新。

8.如权利要求7所述的装置，其特征在于，所述校验模块，实时监测各业务的静态业务信息所对应的最新的类别版本信息，作为标准类别版本信息，针对实时监测到的各类静态业务信息的各标准类别版本信息，生成全局版本号，将所述全局版本号作为标准全局版本信息，并保存。

9.如权利要求7所述的装置，其特征在于，所述更新模块，确定所述待校验全局版本信息中包含的各类静态业务信息的各类别版本信息，以及所述标准全局版本信息中包含的各类静态业务信息的各标准类别版本信息，查找与所述待校验全局版本信息中的类别版本信息不一致的标准类别版本信息，确定查找到的所述标准类别版本信息对应的业务，获取该业务的静态业务信息发送至所述客户端进行更新。

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

发送模块，向服务器发送查新请求，以使得所述服务器确定所述查新请求中包含的多个业务的静态业务信息的待校验全局版本信息，根据保存的标准全局版本信息，校验所述待校验全局版本信息是否与所述标准全局版本信息一致，并当校验不一致时，确定待校验全局版本信息中与标准类别版本信息不一致的类别版本信息，将相应的标准类别版本信息对应的静态业务信息反馈给所述客户端；

接收模块，接收所述服务器反馈的静态业务信息；

更新模块，根据接收到的所述静态业务信息，更新相应业务原有的静态业务信息。

11.如权利要求10所述的装置，其特征在于，所述更新模块，确定接收到的静态业务信息所对应的业务，将接收到的静态业务信息，替换该业务原有的静态业务信息。

12.如权利要求10所述的装置，其特征在于，所述接收模块，接收所述服务器反馈的标准全局版本信息；

所述更新模块，根据所述标准全局版本信息，更新已保存的全局版本信息。