订单分配方法和装置与流程

本发明涉及订单配送领域，具体而言，涉及订单分配方法和装置。
背景技术：
近些年，随着互联网技术的兴盛，物流行业得到了快速的发展，这也使得近些年的物流订单量变得越来越大。物流订单量增大所直接导致的问题就是配送问题，如果配送问题处理不好还会引发其他的连锁反应，比如用户感受度下降等。进而，如何提高配送效率也就成了各个商家最为关心的问题。相关技术中已经出现了一些以优化配送方式为目的的方案，这些方案一定程度上能够改善配送效率过低的问题，但仍有不足之处。技术实现要素：本发明的目的在于提供订单分配方法和装置。第一方面，本发明实施例提供了订单分配方法，包括：获取目标订单的订单信息，订单信息包括以下的任意一种或多种特征：订单属性特征、骑士属性特征、订单与骑士的相对关系特征和配送环境特征；根据目标订单的订单信息和历史骑士配送情况的关联程度，计算候选骑士接受目标订单的接单概率；历史骑士配送情况反应了候选骑士在不同订单信息的条件下，接受订单的概率；根据候选骑士的接单概率确定目标订单的推送对象。第二方面，本发明实施例还提供了一种订单分配装置，包括：获取模块，用于获取目标订单的订单信息，订单信息包括以下的任意一种或多种特征：订单属性特征、骑士属性特征、订单与骑士的相对关系特征和配送环境特征；计算模块，用于根据目标订单的订单信息和历史骑士配送情况的关联程度，计算候选骑士接受目标订单的接单概率；历史骑士配送情况反应了候选骑士在不同订单信息的条件下，接受订单的概率；确定模块，用于根据候选骑士的接单概率确定目标订单的推送对象。本发明实施例提供的订单分配方法，先获取了目标订单的订单信息，而后根据订单信息和历史骑士配送情况计算了候选骑士接受目标订单的接单概率，并最终根据接单概率确定了推送对象，这种确定推送对象的方式考虑到了候选骑士的历史配送情况，能够将订单更准确的推送给更期望接受目标订单的骑士，一定程度上提高了推送的准确度。为使本发明的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。附图说明为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。图1示出了本发明实施例所提供的订单分配方法的基本流程图；图2示出了本发明实施例所提供的订单分配方法的优化流程图；图3示出了本发明实施例所提供的订单分配装置的基本模块图；图4示出了本发明实施例所提供的计算设备的示意图。具体实施方式下面将结合本发明实施例中附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。本申请发明人经过研究发现，影响物流行业的配送效率(即配送时间，配送时间可以是指用户下订单到用户收到订单产品之间的时间长度)的因素有很多，比如配送系统接收用户所下达订单的效率、配送系统向骑士分派订单的效率(也可以说是骑士接单效率)、骑士取货(取得订单所对应的货物)的效率、骑士在取货后，将货物运送到目的地的效率等等。其中，骑士接单效率是一个重点，也就是缩短骑士接单时间长度能够一定程度上提高物流行业整体配送效率。此处的骑士接单时间长度，指的是配送系统开始向众多骑士广播订单至骑士抢到订单的时间长度。相关技术中，骑士接单过程如下：配送系统将新订单向全部骑士广播，直到某个骑士向配送系统发出抢单请求，而后，配送系统就将该订单分配给该发出抢单请求的骑士，进而完成骑士的接单。实际使用中，如果每个订单都向全部骑士进行广播的话，则会占用骑士过多的精力，因此，实际使用中，通常是采用多轮广播的方式来广播新订单，每一轮只向一部分骑士广播新订单。多轮广播指的是配送系统每隔一定的时间将新订单向不同的骑士群体进行广播，直到有骑士发出抢单请求。比如，第一轮广播是向与下单用户的距离小于1km的骑士广播；第二轮广播是向与下单用户的距离为1km-2km的骑士广播；第三轮广播是向与下单用户的距离为2km-4km的骑士广播。骑士在接收到广播的新订单之后，并不必然会直接发出抢单请求，骑士会综合考虑各种因素来决定是否发出抢单请求，因此，在采用多轮广播的方式时，前几轮广播不必然会有骑士来接单(比如骑士距离订单过远，骑士处于配送状态、订单金额过低等等)，这也就造成了无效广播。由此，如果配送系统能够使用较少次数的广播就让骑士接单，则必然能够提高骑士接单效率。综上，相关技术中，只是根据骑士与订单之间的距离来确定向哪个骑士推送订单，这种推送订单的方式的效率较低。针对上述问题，本申请提供了订单分配方法，如图1所示，该方法包括如下步骤：s101，获取目标订单的订单信息，所述订单信息包括以下的任意一种或多种特征：订单属性特征、骑士属性特征、订单与骑士的相对关系特征和配送环境特征；s102，根据目标订单的订单信息和历史骑士配送情况的关联程度，计算候选骑士接受目标订单的接单概率；历史骑士配送情况反应了候选骑士在不同订单信息的条件下，接受订单的概率；s103，根据候选骑士的接单概率确定目标订单的推送对象。步骤s101的订单信息中，订单属性特征所描述的是只和目标订单有关系的信息，比如订单预计完成时间。骑士属性特征描述的是和骑士有关的信息，比如当前骑士未配送完成的订单量。订单与骑士的相对关系特征描述的是订单和骑士的关系，比如订单(主要指订单所对应的取货地点)与骑士之间的距离。配送环境特征描述的是外部环境信息，比如天气状况、交通状况(拥堵状况)等。类似的，历史骑士配送情况中信息的特征内容应当与订单信息的特征内容是一致的。比如，目标订单的订单信息中有订单属性信息，则历史骑士配送情况中也应当有订单属性信息。也就是历史骑士配送情况包括以下的任意一种或多种特征：订单属性特征、骑士属性特征、订单与骑士的相对关系特征和配送环境特征。一般情况下，订单信息中的一部分是由用户提供的(如订单属性特征，是用户在下单的时候提供的)，一部分是由配送系统(步骤s101-s103的执行主体)主动获取到的(如配送环境特征可以是系统实时搜集的)。目标订单可以是指某一个订单，也可以是指由至少两个订单所形成的订单组。比如可以将配送路线基本相同的两个订单组成订单组。也就是，本申请所提供的方法中，还包括如下步骤：获取多个子订单；将属性相似的至少两个子订单整合成目标订单。其中，子订单通常是用户在某一次下单行为中所上传到系统中的，将两个子订单整合成目标订单可以是将这两个子订单进行打包，进而打包到同一个目标订单中的两个子订单最终会向同一个骑士发送。一般来讲，整合到目标订单中的两个子订单的配送录像应当是相似的，或者是取货地点是相似的，或者是送货地点是相似的，当然，两个子订单相似，还可以有其他的判断方法。步骤s102中，候选骑士可以是指全部骑士(配送系统所能够调动的全部骑士)中一部分或者是全部。候选骑士接受目标订单的接单概率，指的是配送系统向骑士分配(也可以理解为发送、广播)目标订单后，骑士向配送系统发送抢单请求来争取配送目标订单的机会的概率。历史骑士配送情况指的是骑士曾经抢单的情况，或者是根据骑士曾经抢单的情况得到的模型。骑士曾经抢单的情况能够一定程度上反应出骑士对某种订单(不同种类订单的配送信息和订单配送额中的至少一个是不同的)的喜好程度，进而，如果骑士越喜欢某一种类的订单，则骑士接受该种类订单的概率就越高。进而，当步骤s101中已经获取到订单信息后，步骤s102中，就可以根据骑士历史上曾经进行抢单的情况来判断出骑士对目标订单的喜好程度，该喜好程度也就可以被认为是接受目标订单的概率，或者是根据喜好程度可以计算出接受目标订单的概率。比如，可以在配送系统中预先建立如下表格：表1编号订单属性特征骑士属性特征接单概率1aaaawwww15％2bbbbxxxx60％3ccccyyyy24％4ddddzzzz57％由表1可见，如果目标订单的订单属性特征符合aaaa，且骑士属性特征符合wwww时，候选骑士接受目标订单的概率是15％，当目标订单的订单属性特征符合bbbb，且骑士属性特征符合xxxx时，候选骑士接受目标订单的概率是60％。接单概率的计算方式也可以采用统计的方式进行，比如，配送系统曾经共向候选骑士x推送过20次订单属性特征为aaaa，且骑士属性特征符合wwww的订单，候选骑士x向配送系统返回了3次抢单请求，也就是，候选骑士x接受了两次订单，放弃了17次订单，进而，确定出的接单概率是15％。除了使用表格的方式，还可以是在配送系统中预先存储骑士抢单概率模型，该骑士抢单概率模型也可以认为是根据历史骑士配送情况的一种体现，或者说，骑士抢单概率模型就是根据大量的历史骑士配送情况生成的，当配送系统将目标订单的订单信息输入到该模型中之后，就可以得到候选骑士接受目标订单的概率了。通过步骤s102可以确定每个候选骑士接收目标订单的接单概率，进而，在步骤s103中，就可以根据候选骑士的接单概率确定目标订单的推送对象。比如，可以将接单概率不为0的候选骑士作为推送对象，也可以将接单概率超过预设阈值(阈值可以是20％，或者是30％，或者是70％)的候选骑士作为推送对象。整体来看，步骤s103有两种结果，一种是将候选骑士中的一个或多个作为推送对象，另一种情况是候选骑士中没有人可以作为推送对象。如果是候选骑士中没有人可以作为推送对象，则可以采用指派的方式，将目标订单向指定的一个候选骑士指派。具体而言，订单信息中的不同特征的主要作用是将不同的订单分类，如果订单信息足够则必然能够将分类进行的很细致，则接单概率的针对性也足够强，但实际上，并不是所有的订单信息都是有效的，经过发明人的实践和分析，认为订单属性特征可以包括如下的任意一个或多个子特征：目标订单所对应的单个订单的数量、目标订单中，最后一个订单所对应的用户所在区域的历史下单量、预估的配送目标订单所需要的时间、预估平均每个订单完成所需要的时间。其中，目标订单所对应的单个订单的数量指的是当目标订单是由多个子订单整合成的情况下，该目标订单所对应的子订单的数量。让，如果目标订单中只有一个子订单，则目标订单所对应的单个订单的数量就是1。目标订单中，最后一个订单所对应的用户所在区域的历史下单量中，历史下单量反应了该区域订单产生的频率，很明显，订单产生的频率越高，则骑士越容易接到订单，进而一般情况下，骑士喜欢到历史下单量大的区域接单。目标订单中，子后一个订单所对应的用户所在的区域就是目标订单中最后一个进行派送的订单所要送达的区域，骑士在将最后一个订单派送完成之后，就可以马上接该区域所发出的新订单了。预估的配送目标订单所需要的时间和预估平均每个订单完成所需要的时间都是预估值，该预估值需要根据具体的参数来计算(比如道路拥堵情况、取货地点、送货地点等等)。预估的配送目标订单所需要的时间指的是送完目标订单中全部子订单所需要的总时间，预估平均每个订单完成所需要的时间指的是送完目标订单中，每个子订单所需要的平均时间(也可以理解为总时间与子订单数量的比值)。骑士属性特征可以包括如下的任意一个或多个子特征：候选骑士的历史订单接单率、候选骑士当前未配送完成的订单的数量、候选骑士在预定时间(如今日)内已完成的订单的类型、候选骑士在预定时间内已完成的订单的数量、候选骑士在预定时间内已完成的订单的区域分布。其中，历史订单接单率指的是骑士曾经接某一类订单的比率，比如，按照订单的属性特征，可以将订单分为多个不同的种类，比如由a地送往b地的订单中，配送时间要求在30分钟以内的分为一类(a类订单)，配送时间在30-60分钟的分为一类(b类订单)。而后，系统共向骑士x分派了a类订单5次，b类订单5次，骑士x接单a类订单5次，b类订单1次，则很明显能够看出骑士x更喜欢接收a类订单，可见，历史接单率能够很明显的反应出骑士的喜好。候选骑士当前未配送完成的订单的数量说明了骑士工作量的饱和程度，如果骑士当前工作量过于饱和，则其很难再接新订单(容易超出配送时限)。候选骑士在预定时间内已完成的订单的类型、数量和区域分布，则说明了骑士在预定时间的活动规律，比如骑士x在月初时，喜欢在城市a配送订单，月中时，喜欢在城市b配送订单，那么系统在向骑士分配订单时，如果是月中进行分配，则应当将城市b的订单分配给骑士x。订单与骑士的相对关系特征可以包括如下的任意一个或多个子特征：候选骑士与目标订单中首个订单之间的距离，候选骑士朝向目标订单中的首个订单前进的方向与候选骑士当前送餐方向的一致程度、候选骑士在目标订单所对应区域的历史送单量。其中，候选骑士与目标订单中首个订单之间的距离反应了骑士到达目标订单中首个订单的难度，如果距离过远，则骑士不容易及时到达，这就使得骑士难以接受该订单。候选骑士朝向目标订单中的首个订单前进的方向与候选骑士当前送餐方向的一致程度也是类似，如果候选骑士朝向目标订单中的首个订单前进的方向与候选骑士当前送餐方向的是完全一致的，那么骑士可以在配送当前订单时，顺序到目标订单的位置处进行配送，这样可以节约成本。候选骑士在目标订单所对应区域(比如目标订单的取货地点或者是送货地点)的历史送单量则可以反映出骑士对某个地域的喜好，比如，骑士更喜欢在离家较近的区域进行配送。配送环境特征可以包括如下的任意一个或多个子特征：目标订单的配送时间所在的时间段、目标订单的配送时间是否属于工作日、目标订单的配送时的天气、目标订单的配送时的交通状况、目标订单的配送目的地所在区域的当前累计订单量、目标订单的配送目的地所在区域的当前骑士数。其中，目标订单的配送时间所在的时间段，可以反映出配送的困难程度。比如时间段是否处于早高峰、晚高峰，时间段是否属于午间炎热的时段等等。目标订单的配送时间是否属于工作日，一定程度上表明了配送的难度和道路拥堵状况，比如工作日配送的难度较低(人们通常在固定的地点办公，周末则容易出去游玩)；周末的道路拥堵时间与工作日的道路拥堵时间是不同的。类似的，目标订单的配送时的天气和目标订单的配送时的交通状况均能反映出配送的难度。目标订单的配送目的地所在区域的当前累计订单量反应了订单的集中程度，如果累计订单量过大，则说明该区域比较方便进行配送，通常情况下，骑士更喜欢去订单量比较大的地方进行配送，因为配送完成这一个订单之后，很快就能够配送下个订单。目标订单的配送目的地所在区域的当前骑士数，也一定程度上能够反应目标订单配送的难易程度，但不同的是，有些骑士喜欢去骑士数量较少的区域配送订单(竞争交一些，很容易抢到订单)，有些骑士喜欢去骑士数量较多的区域配送订单(订单出现的频率高，上一个订单结束之后很快就能接到下一个订单)。具体使用时，可以选择骑士属性特征中的任意一个特征作为骑士属性特征、或将骑士属性特征中的任意两个特征作为订单信息、或将骑士属性特征中的任意三个特征作为订单信息、或将骑士属性特征中的任意四个特征作为订单信息、或将骑士属性特征中的全部特征作为订单信息。比如，可以将候选骑士的历史订单接单率和候选骑士在预定时间内已完成的订单的数量作为骑士属性特征，也可以将候选骑士在预定时间内已完成的订单的数量和候选骑士在预定时间内已完成的订单的区域分布作为骑士属性特征，还可以将候选骑士当前未配送完成的订单的数量、候选骑士在预定时间内已完成的订单的类型和候选骑士在预定时间内已完成的订单的数量作为订单信息。类似的，订单属性特征、订单与骑士的相对关系特征和配送环境特征均可以按照上述关于选择骑士属性特征的方式理解。也就是订单属性特征、订单与骑士的相对关系特征和配送环境特征均可以是由对应的多个子特征中的至少一个所组成。需要说明的是，前文中所说明的不同特征之间是具有相互促进的作用的，也就是各个特征之间并不是孤立的，比如，目标订单的配送时间所在的时间段和目标订单的配送时的天气是具有关联关系的，比如，当处于晚高峰期，且处于下雨状态下，则订单配送难度是远大于只是处于高峰期或者只是处于下雨状态的订单配送难度。步骤s103的结果，可以将候选骑士中的任意一个或多个作为推送对象，当然也可能无法确定出推送对象(比如，每个候选骑士的接单概率均小于为20％，该种状况下，一般是不能将任一个候选骑士作为推送对象的)。进而，在步骤s103能确定出候选骑士中的至少一个作为推送对象时，则可以将目标订单向推送对象进行推送。在步骤s103无法确定出推送对象时，则可以采用指派的方式，将目标订单向指定的一个指派骑士发送，以使指派骑士接受该目标订单，也就是由该指派骑士配送该目标订单。具体而言，步骤s103可以按照如下方式执行：选择接单概率超过预设概率阈值的候选骑士作为推送对象。也就是，可以将接单概率超过一定程度的候选骑士作为推送对象，比如，接单概率超过80％的候选骑士可以认为对该类型的订单更为偏好，进而，就可以将接单概率超过80％的候选骑士作为推送对象，以在后续步骤中向接单概率超过80％的候选骑士推送目标订单。在步骤s103之后，本申请所提供的方法还可以包括如下步骤：向推送对象推送目标订单；判断是否接收到推送对象针对目标订单的接单请求，若否，则降低概率阈值的数值，并重新执行步骤s103。也就是，如果没有骑士接单，则可以降低概率阈值的数值，并重新确定推送对象，在降低概率阈值的数值后，一般是能够将上一次没有选择为推送对象的部分候选骑士选择为推送对象，这样再进行推送的时候，能够扩大推送对象的范围。类似的，在步骤s103之后，如图2所示，本申请所提供的方法还可以包括如下步骤：s104，向推送对象推送目标订单；s105，判断是否接收到推送对象针对目标订单的接单请求，若否，则重新执行步骤s101。此种情况下，在没有收到推送对象针对目标订单的接单请求时，则重新获取目标订单的订单信息，并执行后续步骤s102-s103。此处需要说明的是，重新执行步骤s101是指重新获取了目标订单的订单信息。如前文中的说明，订单信息中可能有一些时效性很强的信息(比如交通状况、天气状况、候选骑士当前未配送完成的订单的数量)，这些信息每经过一段时间就会更新，因此，重新执行步骤s101并不是简单的重复前一轮的行为，而是重新进行了一次计算。基于类似的目的，步骤s103还可以按照如下方式执行：步骤1031，选择接单概率超过概率阈值的候选骑士作为候选目标；步骤1032，判断候选目标的数量是否达到预定的数量阈值范围；步骤1033，若候选目标的数量达到预定的数量阈值范围内，则确定候选目标为推送对象；步骤1034，若候选目标的数量低于预定的数量阈值范围，则降低概率阈值的数值，并重新执行步骤1031；步骤1035，若候选目标的数量高于预定的数量阈值范围，则提高概率阈值的数值，并重新执行步骤1031。步骤1032中，候选目标指的是部分的候选骑士，如果候选骑士的数量过少，则单次推送的价值不高。比如，如果一次只向一个骑士推送目标订单的话，则本轮推送目标订单的成功率只和该骑士的接单概率有关，但如果同时推送给多人的话，则可以一定程度上提高本轮推送的成功率。也就是每次推送的人数不易过少，否则会增加推送的次数；同时，每次推送的人数不易过多，否则过多的骑士接收到目标订单则会造成大量的抢单现象，这也会给系统带来负担。因此，步骤1034中，如果候选目标的数量未超过预定的数量阈值，则需要重新执行步骤1031，以选择出更多的候选骑士作为推送对象。上述方案中，数量阈值范围可以是根据候选骑士的总量确定出来的，比如可以将候选骑士总量的3％-8％作为数量阈值范围。但，实际使用的时候，如果重复执行步骤s101的次数过多，则会对系统带来过重的负担，此时，则可以考虑采用指派的方式向某个骑士派单。也就是，本申请所提供的方法还包括：判断步骤s101的执行次数是否超过预定的次数阈值；若是，则将目标订单向指派骑士发送，以使指派骑士接受该目标订单，也就是由该指派骑士配送该目标订单(一般情况下，指派骑士是必然接收该订单的)。一般来说，指派骑士是一个兜底的选择，一般不会轻易向指派骑士发送目标订单，但如果系统成本过高(步骤s101或步骤s1031的执行次数超过预定的次数阈值)时，则只能采用此种方式了。与上述方法相对应的，本申请还提供了一种订单分配装置，包括：获取模块301，用于获取目标订单的订单信息，所述订单信息包括以下的任意一种或多种特征：订单属性特征、骑士属性特征、订单与骑士的相对关系特征和配送环境特征；计算模块302，用于根据目标订单的订单信息和历史骑士配送情况的关联程度，计算候选骑士接受目标订单的接单概率；历史骑士配送情况反应了候选骑士在不同订单信息的条件下，接受订单的概率；确定模块303，用于根据候选骑士的接单概率确定目标订单的推送对象。优选的，订单属性特征包括如下的任意一个或多个子特征：目标订单所对应的单个订单的数量、目标订单中，最后一个订单所对应的用户所在区域的历史下单量、预估的配送目标订单所需要的时间、预估平均每个订单完成所需要的时间；骑士属性特征包括如下的任意一个或多个子特征：候选骑士的历史订单接单率、候选骑士当前未配送完成的订单的数量、候选骑士在预定时间内已完成的订单的类型、候选骑士在预定时间内已完成的订单的数量、候选骑士在预定时间内已完成的订单的区域分布；订单与骑士的相对关系特征包括如下的任意一个或多个子特征：候选骑士与目标订单中首个订单之间的距离，候选骑士朝向目标订单中的首个订单前进的方向与候选骑士当前送餐方向的一致程度、候选骑士在目标订单所对应区域的历史送单量；配送环境特征包括如下的任意一个或多个子特征：目标订单的配送时间所在的时间段、目标订单的配送时间是否属于工作日、目标订单的配送时的天气、目标订单的配送时的交通状况、目标订单的配送目的地所在区域的当前累计订单量、目标订单的配送目的地所在区域的当前骑士数。优选的，该装置，还包括：第一推送模块，用于向推送对象推送目标订单；第一判断模块，用于判断是否接收到推送对象针对目标订单的接单请求，若否，则降低概率阈值的数值，并驱动确定模块303工作。优选的，该装置，还包括：第二推送模块，用于向推送对象推送目标订单；第二判断模块，用于判断是否接收到推送对象针对目标订单的接单请求，若否，则驱动获取模块301重新工作。优选的，该装置，还包括：第三判断模块，用于判断获取模块301的工作次数是否超过预定的次数阈值；发送模块，用于在判断模块判断为是时，将目标订单向指派骑士发送，以使指派骑士接受该目标订单。优选的，确定模块303包括：选择单元，用于选择接单概率超过概率阈值的候选骑士作为候选目标；判断单元，用于判断候选目标的数量是否达到预定的数量阈值范围；第一调整单元，用于在候选目标的数量低于预定的数量阈值范围时，降低概率阈值的数值，并驱动选择单元重新工作；第二调整单元，用于在候选目标的数量高于预定的数量阈值范围时，提高概率阈值的数值，并驱动选择单元重新工作。与上述方法相对应的，本申请还提供了一种具有处理器可执行的非易失的程序代码的计算机可读介质，程序代码使所述处理器执行前文中所提供的订单分配方法。如图4所示，为本申请实施例所提供的计算设备示意图，该计算设备40包括：处理器41、存储器42和总线43，存储器42存储有执行指令，当计算设备运行时，处理器41与存储器42之间通过总线43通信，处理器41执行存储器42中存储的如订单分配方法的步骤。所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本
技术领域：
的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。当前第1页12