任务处理方法、装置、电子设备和存储介质与流程

本发明涉及信息处理技术领域，特别涉及一种任务处理方法、装置、电子设备和存储介质。

背景技术：

目前存在众多根据业务方的需求，应用场景如在某个任务完成时发放对应的奖励，在某个任务完成之后，执行下一个任务等。

针对不同的业务，如何确定任务是否完成，是亟待解决的技术问题。

技术实现要素：

有鉴于此，本申请提供一种任务处理方法、装置、电子设备和存储介质，能够识别用户行为，满足多样化事件处理的需求，进而能够针对不同业务确定对应任务是否完成。

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

在一个实施例中，提供了一种任务处理方法，所述方法包括：

获取消息；其中，所述消息携带事件标识和用户行为信息；

若确定所述用户行为信息与所述事件标识对应的预设完成条件匹配，则确定已完成所述事件标识对应的事件，更新所述事件的状态为已完成状态；

获取订阅了所述事件标识的任务；

筛选出有效且未完成的任务；

若确定筛选出的任务对应的事件均为已完成状态，则确定所述任务已完成。

其中，

所述消息为业务端按照与服务端约定的预设消息模板生成。

其中，所述获取消息，包括：

从消息队列中获取消息；所述消息由业务端存入到所述消息队列中；

或，

通过接口调用的方式获取业务端上传的消息。

其中，

一次用户行为是用户在业务端上的一次操作；

一个事件为一组符合条件的用户行为；

一个任务为一个或多个事件的组合；

一个任务对应的事件的完成次数为一次或多次；

一个事件对应一个任务或多个任务。

其中，所述预设完成条件为下述之一或任意组合：

符合事件要求的基本条件、频次要求、时长要求；

其中，所述频次要求包括下述之一或任意组合：

累计总次数、按天累计总次数、按天连续次数；

所述时长要求包括下述之一或任意组合：

累计总时长、按天累计时长、按天连续时长。

其中，所述确定已完成所述事件标识对应的事件时，所述方法进一步包括：更新所述事件完成的次数；

所述若确定筛选出的任务对应的事件均为已完成状态之后，所述确定所述任务已完成之前，所述方法进一步包括：

确定事件完成的次数是否为所述任务设置的对应次数，如果是，确定所述任务已完成；否则，确定所述任务未完成。

其中，所述筛选出有效且未完成的任务，包括：

根据任务的有效期和第一任务状态筛选出有效的任务；其中，所述第一任务状态包括有效状态和无效状态；

在有效的任务中根据所述用户行为信息中的用户标识和任务的第二任务状态筛选出未完成的任务；其中，所述第二任务状态包括完成状态和未完成状态。

在另一个实施例中，提供了一种任务处理装置，所述装置包括：配置单元、第一获取单元、第一确定单元、第二获取单元、筛选单元、第二确定单元；

所述配置单元，用于配置预设完成条件；在所述第一确定单元确定已完成事件时，更新所述事件的状态为已完成状态；

所述第一获取单元，用于获取消息；其中，所述消息携带事件标识和用户行为信息；

所述第一确定单元，用于若确定所述第一获取单元获取的消息中携带的用户行为信息与所述事件标识对应的预设完成条件匹配，则确定已完成所述事件标识对应的事件；

所述第二获取单元，当所述第一确定单元确定已完成所述事件标识对应的事件时，用于获取订阅了所述第一获取单元获取的事件标识的任务；

所述筛选单元，用于筛选出所述第二获取单元获取的任务中的有效的，且未完成的任务；

所述第二确定单元，用于若确定所述筛选单元筛选出的任务对应的事件在所述配置单元中均为已完成状态，则确定所述任务已完成。

其中，所述消息为业务端按照与服务端约定的预设消息模板生成。

其中，所述第一获取单元，具体用于获取消息时从消息队列中获取消息；所述消息由业务端存入到所述消息队列中；或，通过接口调用的方式获取业务端上传的消息。

其中，

一次用户行为是用户在业务端上的一次操作；

一个事件为一组符合条件的用户行为；

一个任务为一个或多个事件的组合；

一个任务对应的事件的完成次数为一次或多次；

一个事件对应一个任务或多个任务。

其中，所述预设完成条件为下述之一或任意组合：

符合事件要求的基本条件、频次要求、时长要求；

其中，所述频次要求包括下述之一或任意组合：

累计总次数、按天累计总次数、按天连续次数；

所述时长要求包括下述之一或任意组合：

累计总时长、按天累计时长、按天连续时长。

其中，

所述配置单元，进一步用于当所述第一确定单元确定已完成所述事件标识对应的事件时，更新所述事件完成的次数；

所述第二确定单元，进一步用于所述若确定筛选出的任务对应的事件均为已完成状态时，确定所述事件完成的次数是否为不小于针对所述任务设置的次数，如果是，确定所述任务已完成；否则，确定所述任务未完成。

其中，

所述筛选单元，具体用于筛选出有效且未完成的任务时，包括：根据任务的有效期和第一任务状态筛选出有效的任务；其中，所述第一任务状态包括有效状态和无效状态；在有效的任务中根据所述用户行为信息中的用户标识和任务的第二任务状态筛选出未完成的任务；其中，所述第二任务状态包括完成状态和未完成状态。

在另一个实施例中，提供了一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如所述任务处理方法的步骤。

在另一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现所述任务处理方法的步骤。

由上面的技术方案可见，上述实施例通过定义任务、事件、用户行为之间的关系，通过用户行为是否满足事件要求确定事件是否完成，通过任务对应的事件是否完成确定任务是否完成。该方案能够识别用户行为，满足多样化事件处理的需求，进而能够针对不同业务确定对应任务是否完成。

在定义任务对应的事件时，还可以定义任务完成的次数，当事件的状态和完成次数均与任务对应的设置相匹配时，才能确定任务的完成。通过对任务与事件关系的灵活设置，将事件作为最小计算单位，能够满足多样化的事件的处理需求，进而准确确定任务的处理进展。

附图说明

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

图1为本申请实施例一中任务处理流程示意图；

图2为本申请实施例二中任务处理流程示意图；

图3为本申请实施例中应用于上述技术的装置结构示意图；

图4为本发明实施例提供的电子设备的实体结构示意图。

具体实施方式

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

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

下面以具体实施例对本发明的技术方案进行详细说明。下面几个具体实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

本申请实施例中提供一种任务处理方法，应用于任务处理系统中，所述任务处理系统包括：业务端和服务端；

所述业务端用于在发生一次用户行为时，向所述服务端发送一个消息；

所述服务端，用于在获取到一个消息时，确定所述消息中的事件标识对应事件是否完成，若完成，确定所述事件对应的任务是否完成。

本申请实施例中针对用户行为、事件和任务进行如下定义：

一次用户行为是用户在业务端，如贝壳找房app，上执行的一次操作；

如浏览一个房源详情页；一次成功登录；在vr看房页面停留超过预设时间等。

一个事件为一组符合条件的用户行为，如浏览一个房源详情页；浏览三个房源详情页；当天相似vr看房页停留超过30秒等。

针对事件，可以配置预设完成条件，所述预设完成条件包括下述之一或任意组合：

符合事件要求的基本条件、频次要求、时长要求。

一个任务即为一个业务方的需求，为一个事件或多个事件的组合；一个任务对应的事件的完成次数为一次或多次。

如一个任务可以为：7天内浏览了3个房源详情页并在vr看房页停留超过30秒。

任务有整体的时效时间段，在该时间段内可以多次完成任务；

任务可以设定完成的次数上限；

一个事件可以被多个任务共用，即一个事件可以对应一个或多个任务；

如果将一个事件看作最小计算单位，一个任务的计算可以看作是事件的累计和/或连续。

如一个任务可以表示为：n1×事件1+n2×事件2+.....+nn×事件n。

n为大于0的整数。

业务端发生一次用户行为时，可以按照该业务端与服务端约定的预设消息模板生成消息，发送给服务端。

本申请实施例中的任务处理系统中的业务端可以为一个，也可以为多个，当为多个时，不同业务端与服务端约定的预设消息模板可以相同也可以不同，本申请实施例中对此不进行限制。

预设消息模板作为业务端与服务端通用的规约，约定了消息中包含信息的格式和字段；

其中，约定格式用于服务端能够解析所述消息中携带的内容；

约定的字段用于确定发生该次用户行为后，确定对应的事件是否完成。

预设消息模板中约定的信息包括事件标识和用户行为信息；因此，所述消息携带所述事件标识和用户行为信息。

其中用户行为信息用于表明该消息对应的用户行为，事件标识表示该用户行为对应的事件；

所述用户行为信息包括用户的操作，还可以包括用户标识；

针对事件，有些要求制定某个用户完成某个用户行为，此时，用户标识用于确定当前用户行为对应的用户是否为满足所述事件的用户执行的。

根据业务端所对应的业务，所述用户行为信息还可以包括：房源标识，用户所在城市、用户所在页面、用户的操作、停留时长等；用于确定所述事件标识对应的事件是否完成，但不限于上述信息。

上述设置的信息可以称为预设消息模板的基础信息，在具体实现时还可以设置业务端对应的业务的类型、操作所在的业务入口等业务属性信息。

本申请实施例具体实现时，业务端上报消息，对应服务端获取业务端上报的消息有两种方式，具体如下：

第一种：

业务端将按照预设消息模板生成的消息，将所述消息放入消息队列；

服务端从所述消息队列中获取消息；即后续事件引擎对消息进行消费处理。

第二种：

通过接口调用的方式获取业务端上传的消息。具体实现为：

业务端按照预设消息模板生成的消息，通过调用服务端提供的事件引擎的接口，将所述消息传给所述服务端；

服务端获取业务端上传的消息。

下面结合附图，详细说明本申请实施例中任务处理过程。

实施例一

参见图1，图1为本申请实施例一中任务处理流程示意图。具体步骤为：

步骤101，服务端获取消息；其中，所述消息携带事件标识和用户行为信息。

其中，所述消息为业务端按照与服务端约定的预设消息模板生成。

服务端获取消息可以从消息队列中获取，也可以通过接口调用方式获取，还可以是其他方式获取，本申请实施例中对消息获取方式不进行限制。

步骤102，若确定所述用户行为信息与所述事件标识对应的预设完成条件匹配，则确定已完成所述事件标识对应的事件，更新所述事件的状态为已完成状态。

本申请实施例中针对一事件设置的预设完成条件包括下述之一或任意组合：

符合事件要求的基本条件、频次要求、时长要求；

其中，符合事件要求的基本条件，如房源标识，用户所在城市、用户所在页面、用户的操作、停留时长等；

具体实现时，使用消息中携带的相关信息与配置的符合事件要求的基本条件进行匹配，满足时，确定该条件匹配成功；否则确定该条件匹配不成功。

其中，频次要求包括下述之一或任意组合：

累计总次数、按天累计总次数、按天连续次数。

累计总次数即有效行为的总次数，总次数达到设置的阈值则说明符合事件要求；

按天累计总次数即有效行为的累计达到的次数，适用的场景如累计超过3天有访问详情页的行为；

按天连续次数即有效行为的连续达到的次数，适用的场景如连续超过3天有访问详情页的行为。

时长要求包括下述之一或任意组合：

累计总时长、按天累计时长、按天连续时长；

其中累计总时长即有效行为的总时长；

按天累计时长即有效行为的累计停留的时长，适用的场景如累计超过3天有在vr带看页面停留超过30秒；

按天连续时长即有效行为的累计停留的时长，适用的场景如连续超过3天有在vr带看页面停留超过30秒。

若消息中携带的内容与配置的预设完成条件中存在不匹配的信息，则确定该事件未完成。

步骤103，获取订阅了所述事件标识的任务。

订阅了所述事件标识的任务，即所述任务由所述事件组成，或由所述事件和其他事件组成。

如任务1对应3次事件1和2次事件3，则任务1订阅了事件1和事件3，在服务器中可以存储为任务1标识：事件1标识、事件3标识。

步骤104，筛选出有效且未完成的任务。

本步骤中筛选出有效且未完成的任务，具体包括：

第一步、根据任务的有效期和第一任务状态筛选出有效的任务；其中，所述第一任务状态包括有效状态和无效状态。

本申请实施例中将未过期的，且第一任务状态为有效状态的任务作为有效的任务。

任务都有自己的有效期限，根据其有效期限确定其是否过期，根据任务是否下线确定任务的第一任务状态为有效状态还是无效状态。

第二步、在有效的任务中根据所述用户行为信息中的用户标识和任务的第二任务状态筛选出未完成的任务；其中，所述第二任务状态包括完成状态和未完成状态。

在具体实现时，有些任务是针对某个用户设置的，有的任务对执行用户不进行限制，根据用户标识过滤任务时，筛选出用户标识匹配的，以及无执行用户限制的任务。

在这些任务中筛选出第二任务状态为完成状态的任务。

步骤105，若确定筛选出的任务对应的事件均为已完成状态，则确定所述任务已完成。

一个任务对应一个事件或多个事件，对应的所有事件均为已完成状态才确定对应任务已完成；否则确定所述任务未完成。

若一个任务对应的事件中存在状态为未完成的状态，确定所述任务未完成。

通过定义任务、事件、用户行为之间的关系，通过用户行为是否满足事件要求确定事件是否完成，通过任务对应的事件是否完成确定任务是否完成。该方案能够识别用户行为，满足多样化事件处理的需求，进而能够针对不同业务确定对应任务是否完成。

实施例二

参见图2，图2为本申请实施例二中任务处理流程示意图。具体步骤为：

步骤201，服务端获取消息；所述消息携带事件标识和用户行为信息。

其中，所述消息为业务端按照预设消息模板生成。

服务端获取消息可以从消息队列中获取，也可以通过接口调用方式获取，还可以是其他方式获取，本申请实施例中对消息获取方式不进行限制。

步骤202，若确定所述用户行为信息与所述事件标识对应的预设完成条件匹配，则确定已完成所述事件标识对应的事件，更新所述事件的状态为已完成状态；并更新所述事件完成的次数。

本申请实施例中针对一事件设置的预设完成条件包括下述之一或任意组合：

符合事件要求的基本条件、频次要求、时长要求；

其中，符合事件要求的基本条件，如房源标识，用户所在城市、用户所在页面、用户的操作、停留时长等；

具体实现时，使用消息中携带的相关信息与配置的符合事件要求的基本条件进行匹配，满足时，确定该条件匹配成功；否则确定该条件匹配不成功。

其中，频次要求包括下述之一或任意组合：

累计总次数、按天累计总次数、按天连续次数。

累计总次数即有效行为的总次数，总次数达到设置的阈值则说明符合事件要求；

按天累计总次数即有效行为的累计达到的次数，适用的场景如累计超过3天有访问详情页的行为；

按天连续次数即有效行为的连续达到的次数，适用的场景如连续超过3天有访问详情页的行为。

时长要求包括下述之一或任意组合：

累计总时长、按天累计时长、按天连续时长；

其中累计总时长即有效行为的总时长；

按天累计时长即有效行为的累计停留的时长，适用的场景如累计超过3天有在vr带看页面停留超过30秒；

按天连续时长即有效行为的累计停留的时长，适用的场景如连续超过3天有在vr带看页面停留超过30秒。

步骤203，获取订阅了所述事件标识的任务。

订阅了所述事件标识的任务，即所述任务由所述事件组成，或由所述事件和其他事件组成。

如任务1对应3次事件1和2次事件3，则任务1订阅了事件1和事件3，在服务器中可以存储为任务1标识：事件1标识、事件3标识。

步骤204，筛选出有效且未完成的任务。

本步骤中筛选出有效且未完成的任务，具体包括：

第一步、根据任务的有效期和第一任务状态筛选出有效的任务；其中，所述第一任务状态包括有效状态和无效状态。

本申请实施例中将未过期的，且第一任务状态为有效状态的任务作为有效的任务。

任务都有自己的有效期限，根据其有效期限确定其是否过期，根据任务是否下线确定任务的第一任务状态为有效状态还是无效状态。

第二步、在有效的任务中根据所述用户行为信息中的用户标识和任务的第二任务状态筛选出未完成的任务；其中，所述第二任务状态包括完成状态和未完成状态。

在具体实现时，有些任务是针对某个用户设置的，有的任务对执行用户不进行限制，根据用户标识过滤任务时，筛选出用户标识匹配的，以及无执行用户限制的任务。

在这些任务中筛选出第二任务状态为完成状态的任务。

步骤205，若确定筛选出的任务对应的事件均已完成，且所述事件完成的次数不小于针对所述任务设置的次数，则确定所述任务已完成。

一个任务对应一个事件或多个事件，且会针对每个事件设置需要完成的次数，则所有事件均完成对应次数时，则确定所述任务未完成；否则确定为未完成。

如任务1对应3次事件1和2次事件3，若当前已完成事件1的次数为3次，完成事件3的次数为2次，则确定该任务已完成，不满足事件完成，以及完成次数时，均认为该任务未完成。

若一个任务对应的事件中存在状态为未完成的状态，或存在完成的事件的次数小于针对所述事件设置的次数，则确定所述任务未完成。

通过定义任务、事件、用户行为之间的关系，通过用户行为是否满足事件要求确定事件是否完成，通过任务对应的事件是否完成确定任务是否完成。该方案能够识别用户行为，满足多样化事件处理的需求，进而能够针对不同业务确定对应任务是否完成。

在定义任务对应的事件时，还可以定义任务完成的次数，当事件的状态和完成次数均与任务对应的设置相匹配时，才能确定任务的完成。通过对任务与事件关系的灵活设置，将事件作为最小计算单位，能够满足多样化的事件的处理需求，进而准确确定任务的处理进展。

实施例三

针对完成的任务，将所述任务的状态置为完成状态。

在任务完成后，可以设置可以有如下两种应用：

第一种：

服务端将完成的任务推送给业务端。

推送给业务端的具体操作可以为存储到消息队列中，待业务端自行读取；也可以直接发送给所述业务端，本申请实施例中对此不进行限制。

业务端获知所述任务完成时，根据本地配置的应用场景执行相应的操作，如发放奖励：虚拟货币、贝壳币、积分等；开通其他应用场景，如进行评价等。

第二种：

服务端根据本地配置的执行规则，执行相应的操作，如发放奖励：虚拟货币、贝壳币、积分等；开通其他应用场景，如进行评价等。

本申请实施例中对任务完成后，根据任务的完成在不同应用场景中的具体应用不进行限制。

基于同样的发明构思，本申请实施例还提供一种任务处理装置。参见图3，图3为本申请实施例中应用于上述技术的装置结构示意图。所述装置包括：配置单元301、第一获取单元302、第一确定单元303、第二获取单元304、筛选单元305、第二确定单元306；

配置单元301，用于配置预设完成条件；在第一确定单元303确定已完成事件时，更新所述事件的状态为已完成状态；

第一获取单元302，用于获取消息；其中，所述消息携带事件标识和用户行为信息；

第一确定单元303，用于若确定第一获取单元302获取的消息中携带的用户行为信息与所述事件标识对应的预设完成条件匹配，则确定已完成所述事件标识对应的事件；

第二获取单元304，用于当第一确定单元303确定已完成所述事件标识对应的事件时，获取订阅了第一获取单元302获取的事件标识的任务；

筛选单元305，用于筛选出第二获取单元304获取的任务中的有效的，且未完成的任务；

第二确定单元306，用于若确定筛选单元305筛选出的任务对应的事件在配置单元301中均为已完成状态，则确定所述任务已完成。

其中，所述消息为业务端按照与服务端约定的预设消息模板生成。

其中，第一获取单元302，具体用于获取消息时从消息队列中获取消息；所述消息由业务端存入到所述消息队列中；或，通过接口调用的方式获取业务端上传的消息。

其中，

一次用户行为是用户在业务端上的一次操作；

一个事件为一组符合条件的用户行为；

一个任务为一个或多个事件的组合；

一个任务对应的事件的完成次数为一次或多次；

一个事件对应一个任务或多个任务。

其中，所述预设完成条件为下述之一或任意组合：

符合事件要求的基本条件、频次要求、时长要求；

其中，所述频次要求包括下述之一或任意组合：

累计总次数、按天累计总次数、按天连续次数；

所述时长要求包括下述之一或任意组合：

累计总时长、按天累计时长、按天连续时长。

其中，

配置单元301，进一步用于当所述第一确定单元确定已完成所述事件标识对应的事件时，更新所述事件完成的次数；

第二确定单元306，进一步用于所述若确定筛选出的任务对应的事件均为已完成状态时，确定所述事件完成的次数是否为不小于针对所述任务设置的次数，如果是，确定所述任务已完成；否则，确定所述任务未完成。

其中，

筛选单元305，具体用于筛选出有效且未完成的任务时，包括：根据任务的有效期和第一任务状态筛选出有效的任务；其中，所述第一任务状态包括有效状态和无效状态；在有效的任务中根据所述用户行为信息中的用户标识和任务的第二任务状态筛选出未完成的任务；其中，所述第二任务状态包括完成状态和未完成状态。

上述实施例的单元可以集成于一体，也可以分离部署；可以合并为一个单元，也可以进一步拆分成多个子单元。

在另一个实施例中，还提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述任务处理方法中的步骤。

在另一个实施例中，还提供一种计算机可读存储介质，其上存储有计算机指令，所述指令被处理器执行时可实现所述任务处理方法中的步骤。

图4为本发明实施例提供的电子设备的实体结构示意图。如图4所示，该电子设备可以包括：处理器(processor)410、通信接口(communicationsinterface)420、存储器(memory)430和通信总线440，其中，处理器410，通信接口420，存储器430通过通信总线440完成相互间的通信。处理器410可以调用存储器430中的逻辑指令，以执行如下方法：

获取消息；其中，所述消息携带事件标识和用户行为信息；

若确定所述用户行为信息与所述事件标识对应的预设完成条件匹配，则确定已完成所述事件标识对应的事件，更新所述事件的状态为已完成状态；

获取订阅了所述事件标识的任务；

筛选出有效且未完成的任务；

若确定筛选出的任务对应的事件均为已完成状态，则确定所述任务已完成。

此外，上述的存储器430中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

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