一种在客户端显示数据的处理方法和服务器以及客户端与流程

本发明涉及计算机技术领域，尤其涉及一种在客户端显示数据的处理方法和服务器以及客户端。

背景技术：

在多人在线战术竞技(Multiplayer Online Battle Arena，MOBA)游戏中，玩家在战斗中一般需要购买装备，玩家通常被分为两队，两队在分散的游戏地图中互相竞争，每个玩家都通过一个即时战略(Real-Time Strategy，RTS)游戏风格的界面控制所选的角色，这类游戏通常无需操作RTS游戏中常见的建筑群、资源、训练兵种等组织单位，玩家只控制自己所选的角色即可完成战斗。

在MOBA游戏的设计实现过程中，现有技术中采用的一种方法是帧同步的游戏设计方式，帧同步游戏区别于传统的状态同步游戏，通信方式以玩家的输入操作作为同步维度，帧同步不需要同步状态，可以只同步操作就可以了，每个客户端接受到操作以后，通过运算可以达到一致的状态，这样的情况下就算数据量再多，同步量也不会随之增加。

使用帧同步设计的MOBA游戏中参战客户端能够消耗少量流量进行游戏对战功能，但是使用帧同步设计的MOBA游戏需要等待较长的时间才能开始游戏观战，并且游戏战斗开始越久，需要等待越长的时间才能开始游戏观战。接下来进行详细说明：在帧同步游戏中，服务器将战斗数据简单的按照时间戳顺序缓存，例如，服务器在t₁时刻收到客户端的观战请求，服务器会将从0～t₀产生的数据包下发给客户端，t₀是早于t₁的某个时刻，客户端从收到的第一个数据包开始模拟战斗，直到模拟到t₀时刻才算恢复战场，数据量越大模拟计算所需时间也就越长。

假设客户端加载资源所需时间为△t，恢复战场时模拟战斗的速度是正常渲染速度的n倍，发起观战时间为t_x，为了防止通过观战作弊，会限制战斗开始一定时间之后才能观战，通常t_x会大于60秒，客户端恢复战场就需要把这t_x秒的战斗模拟完毕，响应时间可以表示成t＝△t+t_x/n，t_x>＝60秒，假如客户端以10倍的高速模拟战斗，并且玩家在战斗开始1分钟能观战时就开始观战，那么最少也需要(6+△t)秒钟等待，如果要缩短等待时间，就只能提高恢复战场时模拟战斗的速度，这对于计算性能较弱的客户端是无法完成的。

因此，在现有技术中基于帧同步数据实现的游戏观战方案中，玩家无论在什么时候观战，客户端都会向服务器拉取从战斗开始之后的所有帧同步数据包，存在客户端发起观战后需要等待时间过长的问题。

技术实现要素：

本发明实施例提供了一种在客户端显示数据的处理方法和服务器以及客户端，用于解决客户端需要等待时间过长的问题。

为解决上述技术问题，本发明实施例提供以下技术方案：

第一方面，本发明实施例提供一种在客户端显示数据的处理方法，包括：

数据提供服务器接收交互式应用服务器在交互式场景创建完毕后发送的场景资源数据，以及所述数据提供服务器接收所述交互式应用服务器按照预置的快照周期发送的快照数据，所述快照数据是所述交互式应用服务器根据所述交互式场景中的全量对象的状态生成；

所述数据提供服务器接收数据显示客户端发送的数据加载请求；

所述数据提供服务器根据所述数据加载请求向所述数据显示客户端发送所述场景资源数据，以及所述数据提供服务器向所述数据显示客户端发送所述快照数据；

若所述数据提供服务器缓存有所述交互式应用服务器生成的对象交互数据，所述数据提供服务器向所述数据显示客户端发送所述对象交互数据。

第二方面，本发明实施例还提供一种在客户端显示数据的处理方法，包括：

数据显示客户端向数据提供服务器发送数据加载请求；

所述数据显示客户端接收所述数据提供服务器发送的场景资源数据，并根据所述场景资源数据创建交互式场景，所述场景资源数据由交互式应用服务器在所述交互式场景创建完毕后发送给所述数据提供服务器；

所述数据显示客户端接收所述数据提供服务器发送的快照数据，并在所述交互式场景中加载所述快照数据，所述快照数据是所述交互式应用服务器根据所述交互式场景中的全量对象的状态生成；

所述数据显示客户端接收所述数据提供服务器发送的对象交互数据，并根据所述对象交互数据在所述交互式场景中模拟对象交互过程，所述对象交互数据由所述交互式应用服务器发送给所述数据提供服务器。

第三方面，本发明实施例还提供一种数据提供服务器，包括：

第一接收模块，用于接收交互式应用服务器在交互式场景创建完毕后发送的场景资源数据，以及所述数据提供服务器接收所述交互式应用服务器按照预置的快照周期发送的快照数据，所述快照数据是所述交互式应用服务器根据所述交互式场景中的全量对象的状态生成；

第二接收模块，用于接收数据显示客户端发送的数据加载请求；

第一发送模块，用于根据所述数据加载请求向所述数据显示客户端发送所述场景资源数据，以及所述数据提供服务器向所述数据显示客户端发送所述快照数据；

第二发送模块，用于若所述数据提供服务器缓存有所述交互式应用服务器生成的对象交互数据，向所述数据显示客户端发送所述对象交互数据。

第四方面，本发明实施例还提供一种数据显示客户端，包括：

发送模块，用于向数据提供服务器发送数据加载请求；

场景创建模块，用于接收所述数据提供服务器发送的场景资源数据，并根据所述场景资源数据创建交互式场景，所述场景资源数据由交互式应用服务器在所述交互式场景创建完毕后发送给所述数据提供服务器；

快照加载模块，用于接收所述数据提供服务器发送的快照数据，并在所述交互式场景中加载所述快照数据，所述快照数据是所述交互式应用服务器根据所述交互式场景中的全量对象的状态生成；

显示模块，用于接收所述数据提供服务器发送的对象交互数据，并根据所述对象交互数据在所述交互式场景中模拟对象交互过程，所述对象交互数据由所述交互式应用服务器发送给所述数据提供服务器。

从以上技术方案可以看出，本发明实施例具有以下优点：

在本发明实施例中，本发明实施例中采用服务器和客户端同步的方式，交互式应用服务器将场景资源数据、周期性生成的快照数据发送到数据提供服务器，数据提供服务器向数据显示客户端依次发送场景资源数据、快照数据和对象交互数据，保证用户操作数据显示客户端可以在任意时间发起数据显示，数据显示客户端接收到场景资源数据就可以根据场景资源数据创建交互式场景，接收到场景资源数据就可以根据场景资源数据创建交互式场景，接收到快照数据就可以在交互式场景中加载快照数据，接收到对象交互数据就可以根据对象交互数据在交互式场景中模拟对象交互过程。本发明实施例中交互式应用服务器将交互式场景中的数据划分为三种不同类型的数据，各个类型的数据依次加载，从而数据显示客户端都可以迅速恢复出交互式场景中模拟对象的交互，使用户可以流畅的查看模拟对象在交互式场景中的交互过程，解决现有技术中客户端需要等待时间过长的问题。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域的技术人员来讲，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的一种在客户端显示数据的处理方法的流程方框示意图；

图2为本发明实施例提供的另一种在客户端显示数据的处理方法的流程方框示意图；

图3-a为本发明实施例提供的数据提供服务器与交互式应用服务器之间的交互过程示意图；

图3-b为本发明实施例提供的场景资源数据、两个快照数据、对象交互数据的存储结构示意图；

图3-c为本发明实施例提供的数据提供服务器与两个数据显示客户端之间的交互过程示意图；

图3-d为本发明实施例提供的场景资源数据、n个快照数据、对象交互数据的存储结构示意图；

图4为本发明实施例提供的数据显示客户端实现数据回看的流程示意图；

图5-a为本发明实施例提供的一种数据提供服务器的组成结构示意图；

图5-b为本发明实施例提供的一种第一发送模块的组成结构示意图；

图5-c为本发明实施例提供的另一种第一发送模块的组成结构示意图；

图5-d为本发明实施例提供的一种第二发送模块的组成结构示意图；

图6为本发明实施例提供的一种数据显示客户端的组成结构示意图；

图7为本发明实施例提供的另一种数据提供服务器的组成结构示意图；

图8为本发明实施例提供的另一种数据显示客户端的组成结构示意图。

具体实施方式

本发明实施例提供了一种在客户端显示数据的处理方法和服务器以及客户端，用于解决客户端需要等待时间过长的问题。

为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，下面所描述的实施例仅仅是本发明一部分实施例，而非全部实施例。基于本发明中的实施例，本领域的技术人员所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，以便包含一系列单元的过程、方法、系统、产品或设备不必限于那些单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它单元。

以下分别进行详细说明。

本发明实施例提供的在客户端显示数据的处理方法中，交互式应用服务器向数据提供服务器发送数据，数据显示客户端与数据提供服务器进行交互，数据提供服务器向数据显示客户端提供数据用于在客户端本地显示。例如在交互式场景中，交互式应用服务器产生各种数据，通过数据提供服务器发送给数据显示客户端，数据显示客户端可以在本地显示。举例说明，本发明实施例中交互式场景具体可以指的是游戏场景，也可以指的是应用程序的操作场景，例如办公软件的应用操作场景、角色的应用操作场景等。以游戏场景为例，英雄联盟等MOBA游戏提供了在线观战功能，观战客户端需要等待很长时间才能进入某一时刻的观战状态。本发明实施例中，以交互式场景具体为游戏场景为例，数据显示客户端具体可以为观战客户端，数据提供服务器具体可以为观战服务器，交互式应用服务器具体为游戏服务器，则游戏服务器将游戏场景中的所有数据划分为三个类型：场景资源数据、快照数据和对象交互数据，则游戏服务器和观战服务器保持数据同步，观战服务器从游戏服务器接收到场景资源数据、快照数据和对象交互数据，观战服务器依次向观战客户端发送，从而实现观战客户端在本地快速进行观战状态，向用户显示游戏数据。

接下来分别从数据提供服务器和数据显示客户端的角度来说明本发明实施例提供的在客户端显示数据的处理方法。首先从数据提供服务器一侧来说明，请参阅图1所示，本发明一个实施例提供的在客户端显示数据的处理方法，可以包括如下步骤：

101、数据提供服务器接收交互式应用服务器在交互式场景创建完毕后发送的场景资源数据，以及数据提供服务器接收交互式应用服务器按照预置的快照周期发送的快照数据，快照数据是交互式应用服务器根据交互式场景中的全量对象的状态生成。

在本发明实施例中，数据提供服务器是向数据显示客户端提供数据的服务器，该数据提供服务器缓存的数据来源于交互式应用服务器，本发明实施例中交互式应用服务器向交互式应用客户端提供交互应用功能，例如以交互式场景具体为游戏场景或者应用程序操作场景。交互式应用服务器将交互式场景中的所有数据划分为三种类型：场景资源数据、快照数据和对象交互数据。

其中，场景资源数据是预加载数据(可以简称为Pre)，是创建交互式场景所必须的基础数据，在数据显示客户端发起的一次数据加载请求下，只需要创建一次交互式场景即可，该场景资源数据是交互式场景的底层所必备的数据，例如，以游戏场景为例，场景资源数据是每次观战客户端需要在观战时下发的数据，一场观战只用加载一次，用于观战客户端加载战场资源，例如地图资源、英雄模型资源、怪物模型资源等。

在本发明实施例中，快照数据是交互式应用服务器根据交互式场景中的全量对象的状态生成的，并且交互式应用服务器是按照预置的快照周期生成的快照数据，因此交互式应用服务器向数据提供服务器发送的快照数据也是周期性发送的。快照数据(可以简称为Snap)是交互式应用服务器对交互式场景中的全量对象的状态生成的对象状态数据，其中，全量对象是指在交互式场景中显示的全部对象，这些对象包括模拟对象和非控制对象等，举例说明，以游戏场景为例，全量对象的状态可以包括参战角色、防御塔、小兵、野怪等对象的位置、战斗属性等，以及所有参展角色的装备、金钱、战斗统计数据等，交互式应用服务器按照快照周期定时的对交互式场景中的全量对象进行快照，从而能够得到全量对象的状态数据，快照数据可以用于恢复对交互式场景中的全量对象的状态。举例说明，以游戏场景为例，Snap是某一时刻战场中全量对象的状态数据，用于观战客户端恢复战场状态，Snap由战斗服务器(也称为游戏服务器)定时生成，因为战场全量对象的状态会一直改变，所以不同时刻生成的Snap都是不同的。

在本发明实施例中，交互式应用服务器还根据交互式场景中的对象交互行为生成对象交互数据，该对象交互数据是实时的网络上下行数据，交互式应用服务器与交互式应用客户端进行上下行交互后产生，例如，交互式应用服务器按照帧同步的间隔实时的生成对象交互数据。交互式应用服务器生成的对象交互数据实时的发送给数据提供服务器，例如，对象交互数据(可以简称为Act)，Act是战斗服务器一帧之内的所有上下行网络交互数据，用于观战客户端恢复战场状态后模拟战斗过程，战斗服务器会实时将Act转发到观战服务器。其中，Snap和Act的区别在于，前者是全量数据，是恢复战场状态的基础，后者可以看作是增量数据，是恢复战场状态之后模拟战斗行为的基础。

在本发明实施例中，交互式应用服务器向交互式应用客户端提供交互式服务，交互式应用服务器首先创建交互式场景并生成场景资源数据，向数据提供服务器发送场景资源数据，交互式应用服务器按照预置的快照周期生成快照数据，并向数据提供服务器发送该快照数据。其中，场景资源数据和快照数据都缓存在数据提供服务器中，从而该数据提供服务器可以向数据显示客户端提供数据显示服务。

102、数据提供服务器接收数据显示客户端发送的数据加载请求。

在本发明实施例中，当数据显示客户端需要在本地显示交互式场景时，数据显示客户端可以向数据提供服务器发送数据加载请求，则数据提供服务器接收数据显示客户端发送的数据加载请求，数据提供服务器通过该数据加载请求可以确定用户需要显示交互式场景，然后数据提供服务器执行后续步骤103。

103、数据提供服务器根据数据加载请求向数据显示客户端发送场景资源数据，以及数据提供服务器向数据显示客户端发送快照数据。

在本发明实施例中，数据提供服务器从交互式应用服务器获取到场景资源数据，并且获取到不同快照生成时刻生成的快照数据，当数据显示客户端发送数据加载请求时，数据提供服务器可以立即向数据显示客户端发送场景资源数据，从而使数据显示客户端立即开始根据场景资源数据创建交互式场景，从而缩短用户等待数据加载的时间。本发明实施例中，数据提供服务器还向数据显示客户端发送快照数据，从而使数据显示客户端在交互式场景中加载快照数据，在交互式场景中恢复出全量对象的状态。然后再执行步骤104。

在本发明的一些实施例中，若数据提供服务器在第一时刻接收到数据显示客户端发送的数据加载请求，步骤103中的数据提供服务器根据数据加载请求向数据显示客户端发送场景资源数据，包括：

A1、数据提供服务器在第一时刻接收到数据加载请求后，实时的向数据显示客户端发送场景资源数据。

其中，若步骤102中数据提供服务器在第一时刻接收到数据显示客户端发送的数据加载请求，则数据提供服务器在第一时刻接收到数据加载请求后，实时的向数据显示客户端发送场景资源数据，从而尽量缩短数据的传输时间，使数据显示客户端可以及早开始创建交互式场景，其中，实时的向数据显示客户端发送场景资源数据可以是指数据提供服务器在第一时刻接收到数据加载请求后就开始发送场景资源数据。

进一步的，在本发明的另一些实施例中，步骤103中的数据提供服务器向数据显示客户端发送快照数据，包括：

B1、数据提供服务器判断第一时刻是否是交互式应用服务器发送快照数据的快照发送时刻；

B2、若第一时刻是快照发送时刻，数据提供服务器向数据显示客户端发送交互式应用服务器在第一时刻发送的快照数据；

B3、若第一时刻不是快照发送时刻，数据提供服务器从第一时刻开始等待，直至接收到交互式应用服务器在第一时刻之后的最近一个快照发送时刻发送的快照数据；

B4、数据提供服务器向数据显示客户端发送交互式应用服务器在第一时刻之后的最近一个快照发送时刻发送的快照数据。

其中，交互式应用服务器发送快照数据是按照快照周期定时发送的，将交互式应用服务器发送快照数据的时间点定义为快照发送时刻，则按照预置的快照周期就会存在多个快照发送时刻，若第一时刻是快照发送时刻，数据提供服务器接收到了交互式应用服务器在第一时刻发送的快照数据，数据提供服务器可以向数据显示客户端发送交互式应用服务器在第一时刻发送的快照数据，使得数据显示客户端在交互式场景中尽快的加载快照数据，在交互式场景中恢复出全量对象的状态。若第一时刻不是快照发送时刻，则说明交互式应用服务器在第一时刻没有发送最新的快照数据，则数据提供服务器从第一时刻开始等待，直至接收到交互式应用服务器在第一时刻之后的最近一个快照发送时刻发送的快照数据，若数据提供服务器接收到了最新的快照数据，数据提供服务器向数据显示客户端发送交互式应用服务器在第一时刻之后的最近一个快照发送时刻发送的快照数据。举例说明如下，交互式应用服务器生成快照数据的快照周期是5秒，若数据提供服务器刚好在第2秒接收到了数据加载请求，则数据提供服务器就需要再等待3秒，若数据提供服务器接收到了下一个5秒的快照数据，数据提供服务器向数据显示客户端发送下一个5秒的快照数据，这样数据显示客户端最多需要等待3秒就可以恢复出交互式场景，相比于现有技术中帧同步的方式恢复场景，极大的缩短了用户的等待时间。

在本发明的一些实施例中，若数据提供服务器在第二时刻接收到数据显示客户端发送的包括回看时刻的数据加载请求，回看时刻在时间上早于第二时刻。若步骤102中数据提供服务器在第二时刻接收到数据显示客户端发送的包括回看时刻的数据加载请求，则说明数据显示客户端需要加载的是回看时刻的数据，步骤103中的数据提供服务器向数据显示客户端发送快照数据，包括：

C1、数据提供服务器判断回看时刻是否是交互式应用服务器发送快照数据的快照发送时刻；

C2、若回看时刻是快照发送时刻，数据提供服务器向数据显示客户端发送交互式应用服务器在回看时刻发送的快照数据；

C3、若回看时刻不是快照发送时刻，数据提供服务器从回看时刻开始在时间上回溯，找到与回看时刻最近的快照发送时刻，获取交互式应用服务器在与回看时刻最近的快照发送时刻发送的快照数据；

C4、数据提供服务器向数据显示客户端发送交互式应用服务器在与回看时刻最近的快照发送时刻发送的快照数据。

其中，交互式应用服务器发送快照数据是按照快照周期定时发送的，将交互式应用服务器发送快照数据的时间点定义为快照发送时刻，则按照预置的快照周期就会存在多个快照发送时刻，若回看时刻是快照发送时刻，数据提供服务器缓存有交互式应用服务器在回看时刻发送的快照数据，数据提供服务器可以向数据显示客户端发送交互式应用服务器在回看时刻发送的快照数据，使得数据显示客户端在交互式场景中尽快的加载快照数据，在交互式场景中恢复出全量对象的状态。若回看时刻不是快照发送时刻，则说明交互式应用服务器在回看时刻没有发送快照数据，则数据提供服务器从回看时刻开始往前回溯查找最近的快照发送时刻，获取交互式应用服务器在与回看时刻最近的快照发送时刻发送的快照数据，数据提供服务器向数据显示客户端发送交互式应用服务器在与回看时刻最近的快照发送时刻发送的快照数据。举例说明如下，交互式应用服务器生成快照数据的快照周期是5秒，若数据显示客户端需要回看的是某一时刻的数据，刚好该回看时刻数据提供服务器没有缓存快照数据，数据提供服务器从回看时刻开始在时间上回溯，找到与回看时刻最近的快照发送时刻，获取交互式应用服务器在与回看时刻最近的快照发送时刻发送的快照数据，回看时刻减去与回看时刻最近的快照发送时刻相减得到的时间段就是数据显示客户端需要等待的时间，数据显示客户端可以快速的恢复出交互式场景，相比于现有技术中帧同步的方式恢复场景，极大的缩短了用户的等待时间。

104、若数据提供服务器缓存有交互式应用服务器生成的对象交互数据，数据提供服务器向数据显示客户端发送对象交互数据。

在本发明实施例中，由前述描述可知，数据提供服务器缓存有交互式应用服务器生成的对象交互数据，则数据提供服务器还可以向数据显示客户端发送对象交互数据，从而使数据显示客户端根据对象交互数据在交互式场景中模拟对象交互过程，数据显示客户端中显示交互式场景中的模拟对象交互过程，用户可以观看该模拟对象交互过程。本发明实施例中交互式应用服务器将交互式场景中的数据划分为三种不同类型的数据，各个类型的数据依次加载，从而数据显示客户端都可以迅速恢复出交互式场景并恢复出模拟对象的交互，使用户可以流畅的查看模拟对象在交互式场景中的交互过程，解决现有技术中客户端需要等待时间过长的问题。

进一步的，在本发明的另一些实施例中，在前执行步骤C1至步骤C4的实现场景下，步骤104中的数据提供服务器向数据显示客户端发送对象交互数据，包括：

D1、若回看时刻是快照发送时刻，数据提供服务器向数据显示客户端发送交互式应用服务器从回看时刻开始发送的对象交互数据；

D2、若回看时刻不是快照发送时刻，数据提供服务器向数据显示客户端发送交互式应用服务器从与回看时刻最近的快照发送时刻开始发送的对象交互数据。

其中，交互式应用服务器根据交互式场景中的对象交互行为生成对象交互数据，该对象交互数据是实时的网络上下行数据，交互式应用服务器与交互式应用客户端进行上下行交互后产生，在数据显示客户端发起数据回看时，经过步骤C1中的判断，若回看时刻是快照发送时刻，数据提供服务器向数据显示客户端发送交互式应用服务器从回看时刻开始发送的对象交互数据，若回看时刻不是快照发送时刻，数据提供服务器向数据显示客户端发送交互式应用服务器从与回看时刻最近的快照发送时刻开始发送的对象交互数据，从而数据显示客户端就可以从数据提供服务器收到多个对象交互数据，从而数据显示客户端都可以在交互式场景中模拟对象的交互过程。

通过前述实施例对本发明的举例说明可知，本发明实施例中采用服务器和客户端同步的方式，交互式应用服务器将场景资源数据、周期性生成的快照数据发送到数据提供服务器，数据提供服务器向数据显示客户端依次发送场景资源数据、快照数据和对象交互数据，保证用户操作数据显示客户端可以在任意时间发起数据显示，数据显示客户端接收到场景资源数据就可以根据场景资源数据创建交互式场景，接收到场景资源数据就可以根据场景资源数据创建交互式场景，接收到快照数据就可以在交互式场景中加载快照数据，接收到对象交互数据就可以根据对象交互数据在交互式场景中模拟对象交互过程。本发明实施例中交互式应用服务器将交互式场景中的数据划分为三种不同类型的数据，各个类型的数据依次加载，从而数据显示客户端都可以迅速恢复出交互式场景中模拟对象的交互，使用户可以流畅的查看模拟对象在交互式场景中的交互过程，解决现有技术中客户端需要等待时间过长的问题。

前述实施例从数据提供服务器一侧说明了本发明实施例提供的在客户端显示数据的处理方法。首先从数据显示客户端一侧来说明，请参阅图2所示，本发明一个实施例提供的在客户端显示数据的处理方法，可以包括如下步骤：

201、数据显示客户端向数据提供服务器发送数据加载请求。

在本发明实施例中，当数据显示客户端需要在本地显示交互式场景时，数据显示客户端可以向数据提供服务器发送数据加载请求，则数据提供服务器接收数据显示客户端发送的数据加载请求，数据提供服务器通过该数据加载请求可以确定用户需要显示交互式场景。

202、数据显示客户端接收数据提供服务器发送的场景资源数据，并根据场景资源数据创建交互式场景，场景资源数据由交互式应用服务器在交互式场景创建完毕后发送给数据提供服务器。

在本发明实施例中，数据显示客户端发起数据加载请求之后，数据提供服务器从交互式应用服务器获取到场景资源数据，并且获取到不同快照生成时刻生成的快照数据，当数据显示客户端发送数据加载请求时，数据提供服务器可以立即向数据显示客户端发送场景资源数据，数据显示客户端立即开始根据场景资源数据创建交互式场景，从而缩短用户等待数据加载的时间。

203、数据显示客户端接收数据提供服务器发送的快照数据，并在交互式场景中加载快照数据，快照数据是交互式应用服务器根据交互式场景中的全量对象的状态生成。

本发明实施例中，数据提供服务器还向数据显示客户端发送快照数据，数据显示客户端在交互式场景中加载快照数据，在交互式场景中恢复出全量对象的状态。

在本发明的一些实施例中，若数据提供服务器在第一时刻接收到数据显示客户端发送的数据加载请求，步骤203数据显示客户端接收数据提供服务器发送的快照数据，包括：

E1、若第一时刻是快照发送时刻，数据显示客户端从数据提供服务器接收到交互式应用服务器在第一时刻发送的快照数据；

E2、若第一时刻不是快照发送时刻，数据显示客户端从数据提供服务器接收到交互式应用服务器在第一时刻之后的最近一个快照发送时刻发送的快照数据。

其中，交互式应用服务器发送快照数据是按照快照周期定时发送的，将交互式应用服务器发送快照数据的时间点定义为快照发送时刻，则按照预置的快照周期就会存在多个快照发送时刻，若第一时刻是快照发送时刻，数据提供服务器接收到了交互式应用服务器在第一时刻发送的快照数据，数据提供服务器可以向数据显示客户端发送交互式应用服务器在第一时刻发送的快照数据，使得数据显示客户端在交互式场景中尽快的加载快照数据，在交互式场景中恢复出全量对象的状态。若第一时刻不是快照发送时刻，则说明交互式应用服务器在第一时刻没有发送最新的快照数据，则数据提供服务器从第一时刻开始等待，直至接收到交互式应用服务器在第一时刻之后的最近一个快照发送时刻发送的快照数据，若数据提供服务器接收到了最新的快照数据，数据提供服务器向数据显示客户端发送交互式应用服务器在第一时刻之后的最近一个快照发送时刻发送的快照数据。

在本发明的一些实施例中，步骤202数据显示客户端向数据提供服务器发送数据加载请求，包括：

F1、数据显示客户端向数据提供服务器发送包括回看时刻的数据加载请求。

其中，用户需要回看某个时刻的交互式场景中模拟对象的交互过程，数据显示客户端向数据提供服务器发送包括回看时刻的数据加载请求，数据提供服务器在第二时刻接收到数据显示客户端发送的包括回看时刻的数据加载请求。

在本发明的一些实施例中，若数据提供服务器在第二时刻接收到包括回看时刻的数据加载请求，步骤203数据显示客户端接收数据提供服务器发送的快照数据，包括：

G1、若回看时刻是快照发送时刻，数据显示客户端从数据提供服务器接收到交互式应用服务器在回看时刻发送的快照数据；

G2、若回看时刻不是快照发送时刻，数据显示客户端从数据提供服务器接收到交互式应用服务器在在与回看时刻最近的快照发送时刻发送的快照数据。

其中，交互式应用服务器发送快照数据是按照快照周期定时发送的，将交互式应用服务器发送快照数据的时间点定义为快照发送时刻，则按照预置的快照周期就会存在多个快照发送时刻，若回看时刻是快照发送时刻，数据提供服务器缓存有交互式应用服务器在回看时刻发送的快照数据，数据提供服务器可以向数据显示客户端发送交互式应用服务器在回看时刻发送的快照数据，使得数据显示客户端在交互式场景中尽快的加载快照数据，在交互式场景中恢复出全量对象的状态。若回看时刻不是快照发送时刻，则说明交互式应用服务器在回看时刻没有发送快照数据，则数据提供服务器从回看时刻开始往前回溯查找最近的快照发送时刻，获取交互式应用服务器在与回看时刻最近的快照发送时刻发送的快照数据，数据提供服务器向数据显示客户端发送交互式应用服务器在与回看时刻最近的快照发送时刻发送的快照数据。

204、数据显示客户端接收数据提供服务器发送的对象交互数据，并根据对象交互数据在交互式场景中模拟对象交互过程，对象交互数据由交互式应用服务器发送给数据提供服务器。

在本发明实施例中，数据提供服务器缓存有交互式应用服务器生成的对象交互数据，则数据提供服务器还可以向数据显示客户端发送对象交互数据，数据显示客户端根据对象交互数据在交互式场景中模拟对象交互过程，数据显示客户端中显示交互式场景中的模拟对象交互过程，用户可以观看该模拟对象交互过程。本发明实施例中交互式应用服务器将交互式场景中的数据划分为三种不同类型的数据，各个类型的数据依次加载，从而数据显示客户端都可以迅速恢复出交互式场景并恢复出模拟对象的交互，使用户可以流畅的查看模拟对象在交互式场景中的交互过程，解决现有技术中客户端需要等待时间过长的问题。

在本发明的一些实施例中，在前述执行步骤G1至步骤G2的实现场景下，步骤204数据显示客户端接收数据提供服务器发送的对象交互数据，包括：

H1、若回看时刻是快照发送时刻，数据显示客户端从数据提供服务器接收到交互式应用服务器从回看时刻开始发送的对象交互数据；

H2、若回看时刻不是快照发送时刻，数据显示客户端从数据提供服务器接收到交互式应用服务器从与回看时刻最近的快照发送时刻开始发送的对象交互数据。

其中，交互式应用服务器根据交互式场景中的对象交互行为生成对象交互数据，该对象交互数据是实时的网络上下行数据，交互式应用服务器与交互式应用客户端进行上下行交互后产生，在数据显示客户端发起数据回看时，若回看时刻是快照发送时刻，数据提供服务器向数据显示客户端发送交互式应用服务器从回看时刻开始发送的对象交互数据，若回看时刻不是快照发送时刻，数据提供服务器向数据显示客户端发送交互式应用服务器从与回看时刻最近的快照发送时刻开始发送的对象交互数据，从而数据显示客户端就可以从数据提供服务器收到多个对象交互数据，从而数据显示客户端都可以在交互式场景中模拟对象的交互过程。

通过前述实施例对本发明的举例说明可知，本发明实施例中采用服务器和客户端同步的方式，交互式应用服务器将场景资源数据、周期性生成的快照数据发送到数据提供服务器，数据提供服务器向数据显示客户端依次发送场景资源数据、快照数据和对象交互数据，保证用户操作数据显示客户端可以在任意时间发起数据显示，数据显示客户端接收到场景资源数据就可以根据场景资源数据创建交互式场景，接收到场景资源数据就可以根据场景资源数据创建交互式场景，接收到快照数据就可以在交互式场景中加载快照数据，接收到对象交互数据就可以根据对象交互数据在交互式场景中模拟对象交互过程。本发明实施例中交互式应用服务器将交互式场景中的数据划分为三种不同类型的数据，各个类型的数据依次加载，从而数据显示客户端都可以迅速恢复出交互式场景中模拟对象的交互，使用户可以流畅的查看模拟对象在交互式场景中的交互过程，解决现有技术中客户端需要等待时间过长的问题。

为便于更好的理解和实施本发明实施例的上述方案，下面举例相应的应用场景来进行具体说明。

接下来以交互场景具体为游戏场景为例进行说明，数据显示客户端具体可以为观战客户端(后续举例说明中简称为客户端)，数据提供服务器具体可以为观战服务器，交互式应用服务器具体为游戏服务器，则游戏服务器将游戏场景中的所有数据划分为三个类型：场景资源数据、快照数据和对象交互数据，则游戏服务器和观战服务器保持数据同步，观战服务器从游戏服务器接收到场景资源数据、快照数据和对象交互数据，观战服务器依次向观战客户端发送，从而实现观战客户端在本地快速进行观战状态，向用户显示游戏数据。

现有技术中，由于不论观战还是回看，恢复特定时间点的战斗场景，都需要等待的时间较长。而本发明实施例采用的是客户端服务器(Client Server，CS)同步，战斗服务器拥有战场所有的数据，通过将战斗服务器的战场数据定时生成快照数据发送到观战服务器，观战服务器利用快照延迟转发和快照最小回溯技术，保证玩家在任意时间可以进行观战和回看战斗，客户端都可以以最短的时间获取快照数据来恢复战场，从而流畅观战。快照延迟转发用于正常观战，观战客户端第一次连接到观战服务器时需要恢复战场，观战服务器等到可用的场景资源数据和快照数据到来再转发给客户端。快照最小回溯用于回看战斗，当观战客户端选择回看到某个时刻时，观战服务器回溯到该时刻之前最近一个可用的战场恢复快照并转发给客户端，避免每次回看时都从头开始恢复战场。

本发明实施例中用户可以通过观战客户端随时进入、任意回看都可以快速响应，极大幅度降低恢复战场时间，提高响应速度，解决现有技术的痛点。本发明实施例利用战场场景中的全量对象的状态来定时生成数据快照，例如可以包括参战角色、防御塔、小兵、野怪等对象的位置、战斗属性等，以及所有参展角色的装备、金钱、战斗统计数据等，可以用在所有使用CS网络同步的移动游戏中提供观战功能。而现有技术提供的帧同步移动游戏中，服务器没有战场全量对象的状态，无法生成数据快照，因此每次恢复战场场景客户端都会向服务器拉取从战斗开始的战斗数据，并且只能从头开始模拟战斗，恢复战场阶段存在响应时间过长的问题。

请参阅图3-a、图3-b、图3-c、图3-d、图4所示，本发明实施例中通过快照定时生成可以实现观战所需快照数据基础，通过快照延迟转发可以实现观战快速恢复战场，通过快照最小回溯可以实现回看快速恢复战场。接下来分别对本发明实施例的各个过程进行举例说明。

战斗服务器处理的是和参战客户端的交互逻辑以及处理战场中所有数据，战斗服务器的处理逻辑会比较复杂，单台战斗服务器的所能承载的战斗人数不会太高，本发明实施例中在战斗服务器之外单独设置观战服务器，该观战服务器可以和观战客户端之间的交互就比较简单，单台的观战服务器可以承载的观战人数可以很高。本发明实施例中战场场景的观战功能不是在战斗服务器上实现，因为会降低单台战斗服务器的承载量，也限制了一场战斗能够同时支持的观战玩家的数量。本发明实施例中单独部署观战服务器，战斗场景的观战并不会影响战场的负载和部署结构，而且观战服务器可平行扩展。本发明实施例中一场战斗可以映射到不同的观战服务器供玩家观看，能够支持海量的玩家进行观战。接下来本发明实施例介绍观战服务器如何处理观战场景中的场景资源数据、快照数据和对象交互数据。

首先说明场景资源数据和快照数据的生成过程，如图3-a和图3-b所示，观战服务器从战斗服务器缓存到的数据包括：场景资源数据Pre、快照数据Snap1和Snap2、Snap1生成之后产生的对象交互数据Act1-Actn、Snap2生成之后产生的对象交互数据Actk-Actm。在前述的战场数据类型中，Pre是预加载数据，Pre是无论如何都需要在观战时下发的场景资源数据，一场观战过程只用加载一次，用于客户端加载战场资源，例如地图资源、英雄模型资源、怪物模型资源等。Snap是某一时刻战场中全量对象的状态数据，用于客户端恢复战场状态。Snap包由战斗服务器定时生成，因为战场全量对象的状态会一直改变，所以不同时刻生成的Snap都是不同的。Act是战斗服务器一帧之内的所有上下行网络交互数据，用于客户端恢复战场状态后模拟战斗过程。战斗服务器会实时将Act转发到观战服务器。Snap和Act的区别在于，前者是全量数据，是恢复战场状态的基础；后者可以看作是增量数据，是恢复战场状态之后模拟战斗行为的基础。

如图3-a所示，战斗服务器在战斗开始时向观战服务器发送Pre包，等战场创建完毕后生成第一个Snap包，然后每隔5秒利用战场全量对象的状态生成一次Snap包，两个Snap间隔会陆续转发Act包。观战服务器接收到战斗服务器发送的数据包之后按照时间戳缓存。

接下来说明两个客户端分别向观战服务器请求观战的过程，观战服务器从战斗服务器接收到Snap包进行转发，如图3-c和图3-d所示，观战服务器从战斗服务器缓存到的数据包括：场景资源数据Pre、快照数据Snap1、Snap2…、Snapn、每个Snap之后产生的对象交互数据，例如Snap1生成之后产生的对象交互数据Act1-Actn。客户端通过Snap包快速恢复战场，分别模拟了发起观战时有snap包和没有snap包这两种情形。在正常时序观战情景下，观战服务器收到客户端的观战请求时，立马回复Pre，同时标记客户端为等待Snap状态。客户端收到Pre包就开始加载战场资源。

情形一：在t₁时刻观战时，观战服务器正好收到了战斗服务器生成的Snap1，直接发送Snap1给客户端，后续不需要再恢复战场状态，所以只发送Act而不再发送Snap，客户端只需要等待资源加载完成后解析Snap包将战场中的对象状态还原即可。因为客户端在资源齐备后创建战场时间可以忽略不计，所以该情形下模拟恢复战场的响应时间仅仅为解析Pre包加载战场资源所需时间t＝△t，△t为客户端加载资源所需时间。

情形二：在t_x时刻观战时，观战服务器没有收到战斗服务器生成的Snap，便让客户端保持等待状态，期间客户端会停留在预加载界面上。直到Snap2到来时，观战服务器转发Snap2给客户端。这种情形下客户端最多等待5秒就可获得可用Snap包，恢复战场的响应时间取决于等待Snap和解析Pre包加载战场资源哪个更耗时，可以表示成t＝Max(△t，5)。

现有技术的帧同步方案，恢复t_x时刻战场的响应时间与t_x成正比，本发明实施例相比于现有技术，在任何时间观战，恢复战场的响应时间仅有轻微波动，而且都要比现有帧同步方案的响应快。

接下来对本发明实施例中客户端发起回看请求的场景进行说明，请参阅图，本发明实施例中通过Snap包最小回溯的方式减少用户回看战斗的等待时间，Snap包快速回看的实现过程如下，观战客户端需请求回看x时刻的战斗，观战服务器先回溯到x时刻检查缓存数据。如果正好有Snap包，直接返回客户端，并把紧接着的Act包依次推送下去。如果x时刻没有Snap包，根据前述的快照数据缓存机制可知，x时刻的前5秒内是一定有Snap的，这就意味着观战服务器最多只需要回溯5秒就可以找到该Snap包，然后将时间轴拨回该时刻，并向客户端返回Snap和Act。类似于观战，在一次回看操作里，一旦恢复战场状态之后，就不再需要发送snap给客户端了。

本发明实施例中回看时，观战客户端不需要重新加载资源，所以一旦拿到Snap包就可以立刻恢复战场，响应时间几乎为0。对于x时刻没有Snap包的情形，客户端只需要多模拟几秒钟的战斗就能恢复x时刻的战场。假设同样以n倍速度模拟，那么最大响应时间t≈5/n。相比于现有帧同步回看方案的线性响应时间，本发明实施例中显然用时更少。

现有技术的方案中，对于回看的响应时间也是跟回看时间点成正比，设想一个更极端的情况：玩家可能对某一个战斗过程特别感兴趣，并且在一段时间内来回观战。基于上面的描述可知，回看次数越多所需等待恢复战场的额外时间也就越多，这种情况下回看功能基本上是属于不能使用的，也是很多支持顺序观战的游戏并不提供回看功能的主要原因。

本发明实施例利用战场数据快照的转发和回溯，将Moba游戏中的观战响应时间从帧同步方案的线性增长减少到了一个相当小的稳定时间，从根本上解决了在进行观战和回看时需要长时间等待战场恢复，从而不够灵活流畅的问题。

本发明实施例中，玩家在观战时忍受一定的流量消耗，所以在观战和回看的设计上无需在观战客户端缓存观战数据，减少客户端的性能消耗，以便能够适配足够多的客户端。不过基于本发明的设计原则，采用观战客户端将从观战发服务器收到的快照数据缓存在本地，从而在回看时可以一定程度减少与观战服务器交互的设计，也是本发明实施例中提供的快照回溯方案。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

为便于更好的实施本发明实施例的上述方案，下面还提供用于实施上述方案的相关装置。

请参阅图5-a所示，本发明实施例提供的一种数据提供服务器500，可以包括：第一接收模块501、第二接收模块502、第一发送模块503、第二发送模块504，其中，

第一接收模块501，用于接收交互式应用服务器在交互式场景创建完毕后发送的场景资源数据，以及所述数据提供服务器接收所述交互式应用服务器按照预置的快照周期发送的快照数据，所述快照数据是所述交互式应用服务器根据所述交互式场景中的全量对象的状态生成；

第二接收模块502，用于接收数据显示客户端发送的数据加载请求；

第一发送模块503，用于根据所述数据加载请求向所述数据显示客户端发送所述场景资源数据，以及所述数据提供服务器向所述数据显示客户端发送所述快照数据；

第二发送模块504，用于若所述数据提供服务器缓存有所述交互式应用服务器生成的对象交互数据，向所述数据显示客户端发送所述对象交互数据。

在本发明的一些实施例中，若所述数据提供服务器在第一时刻接收到数据显示客户端发送的数据加载请求，所述第一发送模块503，具体用于在所述第一时刻接收到所述数据加载请求后，实时的向所述数据显示客户端发送所述场景资源数据。

在本发明的一些实施例中，请参阅图5-b所示，所述第一发送模块503，包括：

第一判断模块5031，用于判断所述第一时刻是否是所述交互式应用服务器发送快照数据的快照发送时刻；

第一发送子模块5032，用于若所述第一时刻是所述快照发送时刻，向所述数据显示客户端发送所述交互式应用服务器在所述第一时刻发送的快照数据；

第一接收子模块5033，用于若所述第一时刻不是所述快照发送时刻，从所述第一时刻开始等待，直至接收到所述交互式应用服务器在所述第一时刻之后的最近一个快照发送时刻发送的快照数据；

第二发送子模块5034，用于向所述数据显示客户端发送所述交互式应用服务器在所述第一时刻之后的最近一个快照发送时刻发送的快照数据。

在本发明的一些实施例中，若所述数据提供服务器在第二时刻接收到数据显示客户端发送的包括回看时刻的数据加载请求，所述回看时刻在时间上早于所述第二时刻。请参阅图5-c所示，所述第一发送模块503，包括：

第二判断模块5035，用于判断所述回看时刻是否是所述交互式应用服务器发送快照数据的快照发送时刻；

第三发送子模块5036，用于若所述回看时刻是所述快照发送时刻，向所述数据显示客户端发送所述交互式应用服务器在所述回看时刻发送的快照数据；

第二接收子模块5037，用于若所述回看时刻不是所述快照发送时刻，从所述回看时刻开始在时间上回溯，找到与所述回看时刻最近的快照发送时刻，获取所述交互式应用服务器在所述与所述回看时刻最近的快照发送时刻发送的快照数据；

第四发送子模块5038，用于向所述数据显示客户端发送所述交互式应用服务器在与所述回看时刻最近的快照发送时刻发送的快照数据。

在本发明的一些实施例中，请参阅图5-d所示，所述第二发送模块504，包括：

第五发送子模块5041，用于若所述回看时刻是所述快照发送时刻，向所述数据显示客户端发送所述交互式应用服务器从所述回看时刻开始发送的对象交互数据；

第六发送子模块5042，用于若所述回看时刻不是所述快照发送时刻，向所述数据显示客户端发送所述交互式应用服务器从与所述回看时刻最近的快照发送时刻开始发送的对象交互数据。

通过以上对本发明实施例的描述可知，本发明实施例中采用服务器和客户端同步的方式，交互式应用服务器将场景资源数据、周期性生成的快照数据发送到数据提供服务器，数据提供服务器向数据显示客户端依次发送场景资源数据、快照数据和对象交互数据，保证用户操作数据显示客户端可以在任意时间发起数据显示，数据显示客户端接收到场景资源数据就可以根据场景资源数据创建交互式场景，接收到场景资源数据就可以根据场景资源数据创建交互式场景，接收到快照数据就可以在交互式场景中加载快照数据，接收到对象交互数据就可以根据对象交互数据在交互式场景中模拟对象交互过程。本发明实施例中交互式应用服务器将交互式场景中的数据划分为三种不同类型的数据，各个类型的数据依次加载，从而数据显示客户端都可以迅速恢复出交互式场景中模拟对象的交互，使用户可以流畅的查看模拟对象在交互式场景中的交互过程，解决现有技术中客户端需要等待时间过长的问题。

请参阅图6所示，本发明实施例提供的一种数据显示客户端600，可以包括：发送模块601、场景创建模块602、快照加载模块603、显示模块604，其中，

发送模块601，用于向数据提供服务器发送数据加载请求；

场景创建模块602，用于接收所述数据提供服务器发送的场景资源数据，并根据所述场景资源数据创建交互式场景，所述场景资源数据由交互式应用服务器在所述交互式场景创建完毕后发送给所述数据提供服务器；

快照加载模块603，用于接收所述数据提供服务器发送的快照数据，并在所述交互式场景中加载所述快照数据，所述快照数据是所述交互式应用服务器根据所述交互式场景中的全量对象的状态生成；

显示模块604，用于接收所述数据提供服务器发送的对象交互数据，并根据所述对象交互数据在所述交互式场景中模拟对象交互过程，所述对象交互数据由所述交互式应用服务器发送给所述数据提供服务器。

在本发明的一些实施例中，若所述数据提供服务器在第一时刻接收到数据显示客户端发送的数据加载请求，所述快照加载模块603，具体用于若所述第一时刻是快照发送时刻，从所述数据提供服务器接收到所述交互式应用服务器在所述第一时刻发送的快照数据；若所述第一时刻不是所述快照发送时刻，从所述数据提供服务器接收到所述交互式应用服务器在所述第一时刻之后的最近一个快照发送时刻发送的快照数据。

在本发明的一些实施例中，所述发送模块601，具体用于向数据提供服务器发送包括回看时刻的数据加载请求；

若所述数据提供服务器在第二时刻接收到所述包括回看时刻的数据加载请求，所述快照加载模块603，具体用于若所述回看时刻是所述快照发送时刻，从所述数据提供服务器接收到所述交互式应用服务器在所述回看时刻发送的快照数据；若所述回看时刻不是所述快照发送时刻，从所述数据提供服务器接收到所述交互式应用服务器在在与所述回看时刻最近的快照发送时刻发送的快照数据。

在本发明的一些实施例中，所述显示模块604，具体用于若所述回看时刻是所述快照发送时刻，从所述数据提供服务器接收到所述交互式应用服务器从所述回看时刻开始发送的对象交互数据；若所述回看时刻不是所述快照发送时刻，从所述数据提供服务器接收到所述交互式应用服务器从与所述回看时刻最近的快照发送时刻开始发送的对象交互数据。

通过前述实施例对本发明的举例说明可知，本发明实施例中采用服务器和客户端同步的方式，交互式应用服务器将场景资源数据、周期性生成的快照数据发送到数据提供服务器，数据提供服务器向数据显示客户端依次发送场景资源数据、快照数据和对象交互数据，保证用户操作数据显示客户端可以在任意时间发起数据显示，数据显示客户端接收到场景资源数据就可以根据场景资源数据创建交互式场景，接收到场景资源数据就可以根据场景资源数据创建交互式场景，接收到快照数据就可以在交互式场景中加载快照数据，接收到对象交互数据就可以根据对象交互数据在交互式场景中模拟对象交互过程。本发明实施例中交互式应用服务器将交互式场景中的数据划分为三种不同类型的数据，各个类型的数据依次加载，从而数据显示客户端都可以迅速恢复出交互式场景中模拟对象的交互，使用户可以流畅的查看模拟对象在交互式场景中的交互过程，解决现有技术中客户端需要等待时间过长的问题。

图7是本发明实施例提供的一种服务器结构示意图，该服务器1100具体可以为前述实施例中的数据提供服务器，该服务器1100可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上中央处理器(central processing units，CPU)1122(例如，一个或一个以上处理器)和存储器1132，一个或一个以上存储应用程序1142或数据1144的存储介质1130(例如一个或一个以上海量存储设备)。其中，存储器1132和存储介质1130可以是短暂存储或持久存储。存储在存储介质1130的程序可以包括一个或一个以上模块(图示没标出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器1122可以设置为与存储介质1130通信，在服务器1100上执行存储介质1130中的一系列指令操作。

服务器1100还可以包括一个或一个以上电源1126，一个或一个以上有线或无线网络接口1150，一个或一个以上输入输出接口1158，和/或，一个或一个以上操作系统1141，例如Windows ServerTM，Mac OS XTM，UnixTM,LinuxTM，FreeBSDTM等等。

上述实施例中由服务器所执行的步骤可以基于该图7所示的服务器结构。

本发明实施例还提供了另一种终端，该终端具体为前述实施例中的数据显示客户端，如图8所示，为了便于说明，仅示出了与本发明实施例相关的部分，具体技术细节未揭示的，请参照本发明实施例方法部分。该终端可以为包括手机、平板电脑、PDA(Personal Digital Assistant，个人数字助理)、POS(Point of Sales，销售终端)、车载电脑等任意终端设备，以终端为手机为例：

图8示出的是与本发明实施例提供的终端相关的手机的部分结构的框图。参考图8，手机包括：射频(Radio Frequency，RF)电路1010、存储器1020、输入单元1030、显示单元1040、传感器1050、音频电路1060、无线保真(wireless fidelity，WiFi)模块1070、处理器1080、以及电源1090等部件。本领域技术人员可以理解，图8中示出的手机结构并不构成对手机的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

下面结合图8对手机的各个构成部件进行具体的介绍：

RF电路1010可用于收发信息或通话过程中，信号的接收和发送，特别地，将基站的下行信息接收后，给处理器1080处理；另外，将设计上行的数据发送给基站。通常，RF电路1010包括但不限于天线、至少一个放大器、收发信机、耦合器、低噪声放大器(Low Noise Amplifier，LNA)、双工器等。此外，RF电路1010还可以通过无线通信与网络和其他设备通信。上述无线通信可以使用任一通信标准或协议，包括但不限于全球移动通讯系统(Global System of Mobile communication，GSM)、通用分组无线服务(General Packet Radio Service，GPRS)、码分多址(Code Division Multiple Access，CDMA)、宽带码分多址(Wideband Code Division Multiple Access,WCDMA)、长期演进(Long Term Evolution，LTE)、电子邮件、短消息服务(Short Messaging Service，SMS)等。

存储器1020可用于存储软件程序以及模块，处理器1080通过运行存储在存储器1020的软件程序以及模块，从而执行手机的各种功能应用以及数据处理。存储器1020可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器1020可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。

输入单元1030可用于接收输入的数字或字符信息，以及产生与手机的用户设置以及功能控制有关的键信号输入。具体地，输入单元1030可包括触控面板1031以及其他输入设备1032。触控面板1031，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板1031上或在触控面板1031附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板1031可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器1080，并能接收处理器1080发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板1031。除了触控面板1031，输入单元1030还可以包括其他输入设备1032。具体地，其他输入设备1032可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。

显示单元1040可用于显示由用户输入的信息或提供给用户的信息以及手机的各种菜单。显示单元1040可包括显示面板1041，可选的，可以采用液晶显示器(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板1041。进一步的，触控面板1031可覆盖显示面板1041，当触控面板1031检测到在其上或附近的触摸操作后，传送给处理器1080以确定触摸事件的类型，随后处理器1080根据触摸事件的类型在显示面板1041上提供相应的视觉输出。虽然在图8中，触控面板1031与显示面板1041是作为两个独立的部件来实现手机的输入和输入功能，但是在某些实施例中，可以将触控面板1031与显示面板1041集成而实现手机的输入和输出功能。

手机还可包括至少一种传感器1050，比如光传感器、运动传感器以及其他传感器。具体地，光传感器可包括环境光传感器及接近传感器，其中，环境光传感器可根据环境光线的明暗来调节显示面板1041的亮度，接近传感器可在手机移动到耳边时，关闭显示面板1041和/或背光。作为运动传感器的一种，加速计传感器可检测各个方向上(一般为三轴)加速度的大小，静止时可检测出重力的大小及方向，可用于识别手机姿态的应用(比如横竖屏切换、相关游戏、磁力计姿态校准)、振动识别相关功能(比如计步器、敲击)等；至于手机还可配置的陀螺仪、气压计、湿度计、温度计、红外线传感器等其他传感器，在此不再赘述。

音频电路1060、扬声器1061，传声器1062可提供用户与手机之间的音频接口。音频电路1060可将接收到的音频数据转换后的电信号，传输到扬声器1061，由扬声器1061转换为声音信号输出；另一方面，传声器1062将收集的声音信号转换为电信号，由音频电路1060接收后转换为音频数据，再将音频数据输出处理器1080处理后，经RF电路1010以发送给比如另一手机，或者将音频数据输出至存储器1020以便进一步处理。

WiFi属于短距离无线传输技术，手机通过WiFi模块1070可以帮助用户收发电子邮件、浏览网页和访问流式媒体等，它为用户提供了无线的宽带互联网访问。虽然图8示出了WiFi模块1070，但是可以理解的是，其并不属于手机的必须构成，完全可以根据需要在不改变发明的本质的范围内而省略。

处理器1080是手机的控制中心，利用各种接口和线路连接整个手机的各个部分，通过运行或执行存储在存储器1020内的软件程序和/或模块，以及调用存储在存储器1020内的数据，执行手机的各种功能和处理数据，从而对手机进行整体监控。可选的，处理器1080可包括一个或多个处理单元；优选的，处理器1080可集成应用处理器和调制解调处理器，其中，应用处理器主要处理操作系统、用户界面和应用程序等，调制解调处理器主要处理无线通信。可以理解的是，上述调制解调处理器也可以不集成到处理器1080中。

手机还包括给各个部件供电的电源1090(比如电池)，优选的，电源可以通过电源管理系统与处理器1080逻辑相连，从而通过电源管理系统实现管理充电、放电、以及功耗管理等功能。

尽管未示出，手机还可以包括摄像头、蓝牙模块等，在此不再赘述。

在本发明实施例中，该终端所包括的处理器1080还具有控制执行以上由终端执行的方法流程。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本发明提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本发明可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本发明而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

综上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照上述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对上述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。