一种场景实现方法、装置及设备与流程

本发明涉及场景实现技术领域，具体涉及一种场景实现方法、装置及设备。

背景技术：

现有技术中场景实现过程中多采用继承的方式来实现代码复用以及多态。在场景对象设计层面，没有进行数据和逻辑的分离，无法灵活地通过组合的方式构建多态的场景对象。虽说部分逻辑使用行为模式实现局部的组合能力，但整体还是以继承为主。这种方式会造成基类代码以及对象类个数的膨胀，同时带来多重继承的复杂性。

技术实现要素：

本发明提出了一种场景实现方法、装置及设备，能够解决业务开发过程中的复杂度、复用性、健壮性等问题。本发明具体是以如下技术方案实现的：

一方面，本发明提供了一种场景实现方法，包括：

接收场景创建请求，所述场景创建请求包括第一数量个场景实体的参数；

从预设实体数据库中获取所述第一数量个场景实体的参数对应的实体属性数据和实体逻辑组件；

根据所述实体属性数据和实体逻辑组件生成所述第一数量个场景实体；

基于所述第一数量个场景实体创建目标场景。

另一方面，本发明提供了一种场景实现装置，包括：

创建请求接收模块，用于接收场景创建请求，所述场景创建请求包括第一数量个场景实体的参数；

获取模块，用于从预设实体数据库中获取所述第一数量个场景实体的参数对应的实体属性数据和实体逻辑组件；

生成模块，用于根据所述实体属性数据和实体逻辑组件生成所述第一数量个场景实体；

创建模块，用于基于所述第一数量个场景实体创建目标场景。

进一步的，所述第一数量个场景实体包括一个或多个场景实体，所述生成模块，具体用于根据所述多个场景实体中每一场景实体的实体属性数据和实体逻辑组件生成相应的场景实体。

进一步的，所述装置还包括：

修改请求接收模块，用于接收场景实体修改请求；

修改模块，用于根据所述场景实体修改请求对所述目标场景所对应的场景实体中的实体逻辑组件进行修改，得到更新后的实体逻辑组件；

场景实体更新模块，用于根据所述更新后的实体逻辑组件和相应的实体属性数据生成更新后的场景实体；

目标场景更新模块，用于基于所述更新后的场景实体更新所述目标场景。

进一步的，所述装置还包括：

消息传输中心建立模块，用于建立场景的消息传输中心，以便通过所述消息传输中心进行场景实体之间、场景实体逻辑组件之间以及场景实体和外部系统之间的消息传输。

进一步的，所述装置还包括：

场景运作组件集合获取模块，用于获取场景运作组件集合，所述场景运作组件集合包括多种场景运作规则对应的组件；

第一确定模块，用于根据场景运作类型所对应的场景运作需求从所述场景运作组件集合中确定与所述场景运作需求相匹配的场景运作组件；

映射关系建立模块，用于建立所述相匹配的场景运作组件与所述场景运作类型的映射关系。

进一步的，所述场景创建请求还包括场景运作需求参数；

相应的，所述装置还包括：

场景运作类型确定模块，用于根据所述场景运作需求参数确定相应的场景运作类型；

第二确定模块，用于基于所述映射关系确定与所述相应的场景运作类型所对应的场景运作组件；

场景运作组件获取模块，用于通过标准场景运作入口获取所述所对应的场景运作组件；

目标场景运作融合模块，用于基于所述所对应的场景运作组件对所述目标场景的运作融合，得到所述目标场景的目标运作场景。

另一方面，本发明提供了一种场景实现设备，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如所述第一方面所述的场景实现方法。

本发明提供了一种场景实现方法、装置及设备，将目标场景中的实体的属性数据和逻辑组件分离存放，通过属性数据和逻辑组件的聚合形成多态化的实体，达到复用以及多态目的，又有效地避免了类个数以及基类代码的膨胀。

附图说明

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

图1是本发明实施例提供的一种场景实现方法的流程示意图；

图2是本发明实施例提供的一种传统的场景实现方法的架构示意图；

图3是本发明实施例提供的一种建立实体数据库的方法的流程示意图；

图4是本发明实施例提供的一种以动态方式实现场景的方法的流程示意图；

图5是本发明实施例提供的一种场景运作组件建立方法的流程示意图；

图6是本发明实施例提供的一种对玩法进行抽象分类的示意图；

图7是本发明实施例提供的一种通过标准入口获取场景运作组件的方法的流程示意图；

图8是本发明实施例提供的一种各玩法的进入流程示意图；

图9是本发明实施例提供的一种场景实现方法的架构类的示意图；

图10是本发明实施例提供的一种场景实现方法的架构示意图；

图11是本发明实施例提供的一种通过单机entity实现移动功能的流程示意图；

图12是本发明实施例提供的一种通过多人模式下entity实现移动功能的流程示意图；

图13是本发明实施例提供的一种游戏场景实现时的业务开发流程意图；

图14是本发明实施例提供的一种场景实现装置的结构示意图。

具体实施方式

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

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

以下介绍本发明基于上述系统的场景实现的方法，本说明书提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或服务器产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

图1是本发明实施例提供的一种场景实现方法的流程示意图，如图1所示，所述方法具体包括：

s101：接收场景创建请求，所述场景创建请求包括第一数量个场景实体的参数。

本说明书中的场景可以是一个虚拟的场景，具体可以指游戏中的一个虚拟世界，在这个虚拟世界里可以看到其他玩家以及非玩家角色(npc，不受玩家操控的游戏角色)，并可以和他们进行交互。

本说明书中的实体(entity)可以指游戏世界中一个有独立生命周期的单元。比如说，一个npc，一个怪物等。实体可以是一个抽象的概念，没有行为(behavior)的entity只是一堆数据的集合，本身没有任何逻辑。行为执行代码，用于实现不同的行为逻辑的代码，比如说移动behavior用于实现运动逻辑，同步behavior用于实现网络同步逻辑等。

在场景对象类的设计上，如图2所示，现有技术采用传统的继承actor(actor与entity实体类似，只是另一种说法)体系，虽说部分逻辑使用行为模式实现局部的组合能力，但整体还是以继承为主。这种方式会造成基类代码以及对象类个数的膨胀，同时带来多重继承的复杂性。本说明书的方案将数据和逻辑进行了分离，使用属性(attribute)填写数据，组件封装逻辑，通过逻辑组件的组合，聚合形成多态化的entity实体。

所述第一数量个场景实体包括一个或多个场景实体。

s103：从预设实体数据库中获取所述第一数量个场景实体的参数对应的实体属性数据和实体逻辑组件。

如图3，所述预设实体数据库的建立方式，具体包括：

s301：获取第二数量个场景实体样本。

其中，场景实体样本可以是现有游戏场景中已使用的大量的场景实体样本，也可以是开发人员设计出的未在游戏场景中使用的大量的场景实体样本。

s303：获取所述第二数量个场景实体样本中每个场景实体样本的属性数据和逻辑组件。

一个entity的属性数据是一个entity的变量集合，用于表达当前entity的状态，以及上下文信息等。

一个实体的逻辑组件是将该实体的行为执行代码封装成组件，用于实现不同的行为逻辑的代码。

本说明书中，将每个场景样本实体的属性数据和逻辑组件进行分离存放。

s305：将所述第二数量个场景实体样本的所有属性数据和所有逻辑组件分别存入所述预设实体数据库。

本说明书中，将场景实体样本的所有属性数据和所有逻辑组件分离存入预设实体数据库，便于开发人员随时调用其中的实体属性数据或逻辑组件。

s105：根据所述实体属性数据和实体逻辑组件生成所述第一数量个场景实体。

当所述第一数量个场景实体为多个场景实体时，所述根据所述实体属性数据和实体逻辑组件生成所述第一数量个场景实体，具体包括：

根据所述多个场景实体中每一场景实体的实体属性数据和实体逻辑组件生成相应的场景实体，从而得到第一数量个场景实体。

在场景对象类的设计上将数据和逻辑进行了分离，使用属性填写数据，组件封装逻辑，通过逻辑组件的组合，聚合形成多态化的entity实体。相对传统的继承actor体系，这种eab(entity+attribute+behavior)架构在达到复用以及多态目的的同时有效地避免了类个数以及基类代码的膨胀。

s107：基于所述第一数量个场景实体创建目标场景。

具体的，利用已经生成的一个或多个场景实体创建需要的场景。

需要说明的是，本说明书中的场景实体可以通过组合形式为静态和动态来定义其特性，一个entity可以包含多个不同的behavior。这个描述的过程可以是静态的，即在代码书写时描述，也可以是动态的，即在代码运行时才进行描述。以下步骤401-407描述的是动态的场景实体。

本说明书中的方法，在目标场景创建成功后，若在目标场景中的实体运行后，开发人员对实体运行的表现不满意，还可以对目标场景进行修改，以达到开发人员的设计要求。

如图4，s401：接收场景实体修改请求。

其中，场景实体修改请求具体可以涉及对场景实体的逻辑组件、或逻辑组件对属性数据调用的相关参数的修改。

s403：根据所述场景实体修改请求对所述目标场景所对应的场景实体中的实体逻辑组件进行修改，得到更新后的实体逻辑组件。

由于本说明书中的实体属性数据和实体逻辑组件是分离存储的，因此，可以对实体逻辑组件单独修改，无需改动复杂的代码即可得到更新后的实体逻辑组件。

s405：根据所述更新后的实体逻辑组件和相应的实体属性数据生成更新后的场景实体。

s407：基于所述更新后的场景实体更新所述目标场景。

通过静态和动态两种方式进行组合的形式定义不同entity的特性，可以实现玩法的多样化需求。

现有的多个实体之间没有消息沟通机制，造成对象之间相互引用。各种场景对象引用交织在一起，造成代码耦合。因此，本说明书提出利用消息传输中心解决上述问题。

本说明书的场景实现方法还包括：建立场景的消息传输中心，以便通过所述消息传输中心进行场景实体之间、场景实体逻辑组件之间以及场景实体和外部系统之间的消息传输。

消息沟通：通过消息机制调用其他行为，或者其他entity的逻辑接口。相比于直接通过对象接口调用，它是解除消息传递两端的代码耦合的一种方式。

消息传输中心：多个entity之间相互沟通的一个渠道。entity通过在消息传输中心注册其关心的entity以及消息类型来接收来自于这个entity的消息通知。避免entity之间互相暴露自己的引用，造成entity生命周期存在依赖。

外部系统和entity，以及entity内部组件之间通过消息沟通，两个entity之间通过消息传输中心进行消息的转发，从而达到逻辑内聚和对外隐藏的同时，也可以与外部系统交流沟通的目的。

现有技术中玩法逻辑通过单件实现。玩法虽然划分模块，但没有统一出共性，形成抽象类型，并且玩法进入入口不统一，代码冗余。因此，本说明书中提出通过组件实现场景运作的玩法。

如图5，在所述接收场景创建请求之前，所述方法还包括：

s501：获取场景运作组件集合，所述场景运作组件集合包括多种场景运作规则对应的组件。

其中，所述多种场景运作规则包括单人、多人、有场景、无场景等运作规则。游戏场景运作规则也可以理解成游戏的不同类型的玩法。玩法是游戏中的各种游戏模式的别名，其拥有游戏规则，人数限制，进行流程，输赢判断等等这些元素。比如说军团战玩法，小镇玩法，多人副本玩法等。

s503：根据场景运作类型所对应的场景运作需求从所述场景运作组件集合中确定与所述场景运作需求相匹配的场景运作组件。

基于开发人员的场景运作需求确定相应的场景运作类型，例如，当需要建立单人游戏，则确定相应的场景运作类型为单人运作类型。接着，从步骤501的场景运作组件集合中选择相应的单人运作的场景，并确定适合单人运作场景的场景运作组件。

s505：建立所述相匹配的场景运作组件与所述场景运作类型的映射关系。

建立所述相匹配的场景运作组件与所述场景运作类型的映射关系，是为了便于开发人员创建目标场景时按需调用与目标场景的运作类型相匹配的场景运作组件。

通过实现不同的玩法组件，挂接到不同的抽象玩法上，从而在实现玩法逻辑的多样化的同时不会和原有的框架代码产生耦合。同时部分具有公用性质的玩法组件也可以达到复用的目的，提高了开发效率。

本说明书的方案，总结出玩法共性，形成抽象类型，提高复用性，健壮性，并且降低了玩法的开发难度，是业务开发专注于业务逻辑本身。

具体的，如图6所示，将原来的玩法抽象成四种玩法类型：单人场景、多人场景、无场景单人战斗和无场景多人战斗，这样，游戏场景开发人员只需要专注其中一种游戏本身的业务逻辑进行开发。

如图7所示，所述场景创建请求还包括场景运作需求参数；

相应的，本说明书的场景实现方法还包括：

s701：根据所述场景运作需求参数确定相应的场景运作类型。

所述场景运作需求参数是开发人员根据目标场景的创建需求而确定的参数。

在进入玩法时传入该玩法所属于的抽象类型，玩法组件定义，以及各种参数开关。

s703：基于所述步骤505中的映射关系确定与所述相应的场景运作类型所对应的场景运作组件。

玩法组件：一个独立的完整的逻辑单元。同行为类似，不同点在于玩法组件一般针对于整个玩法的逻辑，而不是一个游戏实体的逻辑。比如手势控制组件，场景事件组件等，以及一些具体玩法逻辑，例如军团竞赛玩法组件，小镇玩法组件等。

s705：通过标准场景运作入口获取所述所对应的场景运作组件。

所述标准场景运作入口是为不同玩法类型设置的统一入口，通过所述入口可以得到与所述玩法类型匹配的场景运作组件，例如单人运作需求的场景可以获取到适用于单人场景的运作组件。

在框架设计上，统一了所有不同玩法类型的入口，业务开发时可以通过不同参数进入不同的类型的玩法(单人、多人、有场景、无场景)；对外隐藏了不同类型玩法的进入流程细节。

s707：基于所述所对应的场景运作组件对所述目标场景的运作融合，得到所述目标场景的目标运作场景。

如图8所示，是本说明书列举出的四种玩法的进入流程。

单人场景：标准场景入口handleenterscenegame→退出上一个玩法系统→初始化场景→创建场景组件→场景加载→加载完毕后，通知玩法组件加载完毕，开始执行场景逻辑。

多人场景：标准场景入口handleenterscenegame→连接服务器以及完成登录注册流程→向服务器发起进入场景请求→收到回包后，退出上一个玩法系统→初始化场景→创建场景组件→场景加载→加载完毕后，通知玩法组件加载完毕，开始执行场景逻辑→通知服务器加载完毕，开始同步场景数据。

多人无场景战斗：标准场景入口handleenterscenegame→连接服务器以及完成登录注册流程→向服务器发起进入场景请求→收到回包后，通知战斗系统开始初始化→战斗系统回调初始化完毕后，退出上一个玩法系统→通知初始化结束。

单人无场景战斗：标准场景入口handleenterscenegame→通知战斗系统开始初始化→战斗系统回调初始化完毕后，退出上一个玩法系统→通知初始化结束。

本说明书中的场景实现方法，由于总结了玩法共性，抽象出了多种类型，使新玩法的业务开发有了一个模板，解决了业务开发过程中的复杂度、复用性、健壮性等问题。统一了所有不同玩法类型的入口，业务开发时可以通过不同参数进入不同的类型的玩法(单人，多人，有场景，无场景)，不需要关心不同类型玩法的进入流程细节，是业务开发专注于本身逻辑的实现。

对应各个玩法的公用特性，以及不同玩法的逻辑，利用玩法组件的方式挂接实现，可以让逻辑代码与框架代码解耦，同时也能够达到复用的目的，提高了开发的效率。

在场景对象设计方面，由于数据和逻辑进行了分离，因此可以更好地通过插件式的组合来实现对象的多样化。相比传统的actor继承体系，eab可以通过静态和动态两种方式定义不同entity的特性,使解决方案更加灵活。消息沟通的机制，可以解除调用引用的可见，从而达到逻辑内聚和对外隐藏的同时，也可以与外部系统交流沟通的目的。

综上，本说明书中的场景实现方法，将框架代码和逻辑业务代码完全分离，框架代码可以直接在以后项目中使用。

如图9，介绍了本说明书中基于eab系统类的框架。该框架内部与外部之间通过sceneattributeservice类进行属性数据的访问。

sceneservice类，场景玩法服务。封装了4种抽象玩法(单人场景，多人场景，单人无场景战斗，多人无场景战斗)的进入流程。进入流程包含c/s协议交互，玩法组件创建，资源加载等基础服务。负责entity的创建以及销毁。

entity类，作为属性(attribute)和行为(behavior)的容器，entity内部的behavior通过消息沟通，并且共享entity的属性集合。

behavior类，通过不同子类实现逻辑行为。entity内部不同behavior通过消息进行沟通。

entitymsgcenter类，用于不同entity之间通过消息沟通。

sceneattributeservice类，用于外部系统访问场景系统内部变量，避免场景系统和外部系统产生耦合。内部变量通过sceneattributeservice注册访问属性，外部系统通过查询属性来获得内部数据。

如图10所示，在eab框架下，数据和代码进行了分离。属性集合(attribute)代表数据，行为(behavior)代表执行代码。一个entity由一个属性集合和任意多个行为组合而成。在entity内部，多个行为之间通过消息进行沟通，并且共享entity的属性集合。

下面举例说明entity内behavior通过消息相互协作：

如图11，是通过单机entity实现移动功能。本地的控制组件将运动消息发送给运动组件，运动组件再将位移消息发送给显示组件，再由显示组件在本地显示对entity行为的控制结果。在此过程中，会根据需要读取属性集合中的数据。

如图12，是通过多人模式下entity实现移动功能。本地的控制组件将运动消息发送给运动组件和移动同步组件，运动组件再将位移消息发送给显示组件，再由显示组件在本地显示对entity行为的控制结果，在移动同步组件收到同步的运动消息时，通过服务器将运动消息发送到远端实体的控制组件，远端的控制组件再将运动消息发送给远端运动组件，再由远端运动组件将位移消息发送给远端显示组件。在此过程中，会根据需要读取相应的属性集合中的数据。

下面介绍具体游戏场景实现时的业务开发流程：

1.选择玩法类型，包括单人场景、多人场景、无场景战斗(单人)和无场景战斗(多人)；

2.挂接玩法组件，开发玩法业务逻辑组件，挂接需要使用的玩法公共组件；

3.开发业务玩法场景对象(entity)，包括，

使用blueprint(蓝图)定义业务场景对象由哪些行为(behavior)构成；

如果需要，开发这个业务需要的新的行为(behavior)；

传入blueprint(蓝图)，由工厂生成场景对象实例。

本说明书提供的场景实现方法，对业务开发隐藏底层和流程上的细节，让开发人员专注于业务逻辑本身的开发。

本发明实施例还提供了一种场景实现装置，如图14所示，所述装置包括：

创建请求接收模块1401，用于接收场景创建请求，所述场景创建请求包括第一数量个场景实体的参数；

获取模块1403，用于从预设实体数据库中获取所述第一数量个场景实体的参数对应的实体属性数据和实体逻辑组件；

生成模块1405，用于根据所述实体属性数据和实体逻辑组件生成所述第一数量个场景实体；

创建模块1407，用于基于所述第一数量个场景实体创建目标场景。

进一步的，所述装置还包括：

样本获取模块1409，用于获取第二数量个场景实体样本；

样本属性数据和逻辑组件获取模块1411，用于获取所述第二数量个场景实体样本中每个场景实体样本的属性数据和逻辑组件；

存储模块1413，用于将所述第二数量个场景实体样本的所有属性数据和所有逻辑组件分别存入所述预设实体数据库。

进一步的，所述第一数量个场景实体包括一个或多个场景实体，所述生成模块，具体用于根据所述多个场景实体中每一场景实体的实体属性数据和实体逻辑组件生成相应的场景实体。

进一步的，所述装置还包括：

修改请求接收模块1415，用于接收场景实体修改请求；

修改模块1417，用于根据所述场景实体修改请求对所述目标场景所对应的场景实体中的实体逻辑组件进行修改，得到更新后的实体逻辑组件；

场景实体更新模块1419，用于根据所述更新后的实体逻辑组件和相应的实体属性数据生成更新后的场景实体；

目标场景更新模块1421，用于基于所述更新后的场景实体更新所述目标场景。

进一步的，所述装置还包括：

消息传输中心建立模块1423，用于建立场景的消息传输中心，以便通过所述消息传输中心进行场景实体之间、场景实体逻辑组件之间以及场景实体和外部系统之间的消息传输。

进一步的，所述装置还包括：

场景运作组件集合获取模块1425，用于获取场景运作组件集合，所述场景运作组件集合包括多种场景运作规则对应的组件；

第一确定模块1427，用于根据场景运作类型所对应的场景运作需求从所述场景运作组件集合中确定与所述场景运作需求相匹配的场景运作组件；

映射关系建立模块1429，用于建立所述相匹配的场景运作组件与所述场景运作类型的映射关系。

进一步的，所述场景创建请求还包括场景运作需求参数；

相应的，所述装置还包括：

场景运作类型确定模块1431，用于根据所述场景运作需求参数确定相应的场景运作类型；

第二确定模块1433，用于基于所述映射关系确定与所述相应的场景运作类型所对应的场景运作组件；

场景运作组件获取模块1435，用于通过标准场景运作入口获取所述所对应的场景运作组件；

目标场景运作融合模块1437，用于基于所述所对应的场景运作组件对所述目标场景的运作融合，得到所述目标场景的目标运作场景。

所述的装置实施例中的装置与方法实施例基于同样的发明构思。

本发明实施例还提供了一种场景聚类设备，所述设备包括处理器和存储器，所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、所述至少一段程序、所述代码集或指令集由所述处理器加载并执行以实现如前述的场景聚类方法。

由上述本发明提供的场景聚类的方法、装置、设备的实施例可见，本发明的方案，接收场景创建请求，所述场景创建请求包括第一数量个场景实体的参数；从预设实体数据库中获取所述第一数量个场景实体的参数对应的实体属性数据和实体逻辑组件；根据所述实体属性数据和实体逻辑组件生成所述第一数量个场景实体；基于所述第一数量个场景实体创建目标场景。将目标场景中的实体的属性数据和逻辑组件分离存放，通过属性数据和逻辑组件的聚合形成多态化的实体，达到复用以及多态目的，又有效地避免了类个数以及基类代码的膨胀。

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

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

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。