出行方式推荐方法及装置与流程

本申请实施例涉及互联网技术领域，特别涉及一种出行方式推荐方法及装置。

背景技术：

随着互联网技术的发展，基于互联网技术的出行应用为人们的生活带来越来越多的便利，例如可以为用户规划出基于公共交通车辆(例如公交车、地铁、出租车等)及网约车辆(包括专车、快车、顺风车、大巴等)的出行方式。对于出行路线中上述出行工具无法覆盖的路线片段，现有技术中，均是推荐用户步行出行。

然而，步行的出行方式通常耗费较长的时间，尤其是当无法覆盖的路线片段的距离较长时，推荐用户步行出行并不是用户期望的推荐结果，即属于无效的推荐结果，由于生成推荐结果的过程中，需要消耗服务器的计算资源，服务器将推荐结果推送给用户时，也需要消耗带宽资源，因此，无效的推荐结果势必导致服务器计算资源和带宽资源的浪费。

技术实现要素：

为了解决上述问题，本申请实施例提供一种出行方式推荐方法及装置。

具体地，本申请实施例是通过如下技术方案实现的：

根据本申请实施例的第一方面，提供一种出行方式推荐方法，所述方法包括：

确定用户的目标出行路线中长距离出行工具无法覆盖的路线片段，其中，所述长距离出行工具包括：公共交通车辆和网约车辆；

判断所述路线片段的起点周围是否存在可用的短距离出行工具；

当所述路线片段的起点周围存在可用的短距离出行工具时，生成出行方式推荐结果，其中，所述出行方式推荐结果用于提示所述用户在到达所述路线片段的起点时使用所述可用的短距离出行工具进行出行；

将所述出行方式推荐结果发送给所述用户的终端设备。

本申请实施例中，所述生成出行方式推荐结果，包括：

获取所述用户的历史出行数据，其中，所述历史出行数据中包含所述用户使用过的短距离出行工具的种类信息；

根据所述历史出行数据，生成出行方式推荐结果。

本申请实施例中，在所述判断所述路线片段的起点周围是否存在可用的短距离出行工具之前，还包括：

判断所述路线片段的路线长度是否达到预设长度阈值；

当所述路径片段的路线长度达到所述预设长度阈值时，判断所述路线片段的起点周围是否存在可用的短距离出行工具。

本申请实施例中，所述方法还包括：

当检测到用户到达所述路线片段的起点时，生成街景地图开启指令；

发送所述街景地图开启指令给所述终端设备，其中，所述街景地图开启指令用于指示所述终端设备开启街景地图。

本申请实施例中，所述出行方式推荐结果中携带有以下信息中的至少一种：

可用的短距离出行工具的种类、可用的短距离出行工具的位置信息、及可用的短距离出行工具的计费方式信息。

根据本申请实施例的第二方面，提供一种出行方式推荐装置，所述装置包括：

确定模块，用于确定用户的目标出行路线中长距离出行工具无法覆盖的路线片段，其中，所述长距离出行工具包括：公共交通车辆和网约车辆；

第一判断模块，用于判断所述确定模块确定出的路线片段的起点周围是否存在可用的短距离出行工具；

第一生成模块，用于在所述第一判断模块的判断结果为是的情况下，生成出行方式推荐结果，其中，所述出行方式推荐结果用于提示所述用户在到达所述路线片段的起点时使用所述可用的短距离出行工具进行出行；

第一发送模块，用于将所述第一生成模块生成的出行方式推荐结果发送给所述用户的终端设备。

本申请实施例中，所述第一生成模块，包括：

数据获取子模块，用于在所述第一判断模块的判断结果为是的情况下，获取用户的历史出行数据，其中，所述历史出行数据中包含所述用户使用过的短距离出行工具的种类信息；

结果生成子模块，用于根据所述数据获取子模块获得的历史出行数据，生成出行方式推荐结果。

本申请实施例中，所述装置还包括：

第二判断模块，用于判断所述路线片段的路线长度是否达到预设长度阈值，并在判断结果为是的情况下，触发所述第一判断模块执行判断所述路线片段的起点周围是否存在可用的短距离出行工具的操作。

本申请实施例中，所述装置还包括：

第二生成模块，用于在检测到用户到达所述路线片段的起点的情况下，生成街景地图开启指令；

第二发送模块，用于发送所述第二生成模块生成的街景地图开启指令给所述终端设备，其中，所述街景地图开启指令用于指示所述终端设备开启街景地图。

本申请实施例中，所述出行方式推荐结果中携带有以下信息中的至少一种：

可用的短距离出行工具的种类、可用的短距离出行工具的位置信息，及可用的短距离出行工具的计费方式信息。

根据本申请实施例的第三方面，提供一种计算机存储介质，所述存储介质中存储有程序指令，所述程序指令包括：

确定用户的目标出行路线中长距离出行工具无法覆盖的路线片段，其中，所述长距离出行工具包括：公共交通车辆和网约车辆；

判断所述路线片段的起点周围是否存在可用的短距离出行工具；

当所述路线片段的起点周围存在可用的短距离出行工具时，生成出行方式推荐结果，其中，所述出行方式推荐结果用于提示所述用户在到达所述路线片段的起点时使用所述可用的短距离出行工具进行出行；

将所述出行方式推荐结果发送给所述用户的终端设备。

本申请实施例中，对于目标出行路线中长距离出行工具无法覆盖的路线片段，可以结合该路线片段的起点位置及该路线片段的起点位置周围的短距离出行工具，为用户推荐合适的短距离出行工具(例如自行车、摆渡车等等)，由于相比于步行的出行方式，推荐用户使用短距离出行工具出行可以缩短出行时长和减少体力成本，更符合用户的期望，因此可以提高服务器计算资源和带宽资源的利用率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本申请实施例。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请实施例，并与说明书一起用于解释本发明的原理。

图1A是本申请实施例根据一示例性实施例示出的一种出行方式推荐方法的流程图；

图1B是本申请实施例根据一示例性实施例示出的出行路线中公交车辆无法覆盖的路线片段的示意图；

图1C是本申请实施例根据一示例性实施例示出的图1A所示方法的应用场景图；

图2是本申请实施例根据一示例性实施例示出的图1A中步骤103的一种实施方式的流程图；

图3是本申请实施例根据一示例性实施例示出的另一种出行方式推荐方法的流程图；

图4是本申请实施例根据一示例性实施例示出的一种出行方式推荐装置的框图；

图5是本申请实施例根据一示例性实施例示出的另一种出行方式推荐装置的框图；

图6是本申请实施例根据一示例性实施例示出的另一种出行方式推荐装置的框图；

图7是本申请实施例根据一示例性实施例示出的另一种出行方式推荐装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请实施例的一些方面相一致的装置和方法的例子。

在本申请实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请实施例。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

目前，对于出行路线中公交车辆(例如公交车、地铁、出租车)及网约车辆等出行工具无法覆盖的路线片段，现有技术中，均是推荐用户步行。然而，出行步行的出行方式通常耗费较长的时间，尤其是当无法覆盖的路线片段的距离较长时，推荐用户步行出行并不是用户期望的推荐结果，即属于无效的推荐结果，由于生成推荐结果的过程中，需要消耗服务器的计算资源，服务器将推荐结果推送给用户时，也需要消耗带宽资源，因此，无效的推荐结果势必导致服务器计算资源和带宽资源的浪费。为了解决上述问题，本申请提供了一种出行方式推荐方法及装置。

下面首先对本申请实施例提供的出行方式推荐方法进行介绍。

如图1A所示，图1A是本申请实施例根据一示例性实施例示出的一种出行方式推荐方法的流程图，该方法可以包括以下步骤：

在步骤101中，确定用户的目标出行路线中长距离出行工具无法覆盖的路线片段，其中，该长距离出行工具包括：公共交通车辆和网约车辆。

本申请实施例中，公共交通车辆包括：公交车、地铁及出租车等，网约车辆指的是网络预约汽车，包括：专车、快车、顺风车及大巴车等等。

对于公交车和地铁这类公共交通车辆来说，通常有固定的停靠站点(即公共交通站点)，用户只能在公共交通站点才可以上车，且这类公共交通车辆运行的路线也是固定的，在此情况下，本申请实施例中的长距离出行工具无法覆盖的路线片段可以指的是从起点到公共交通站点这一段路、或者从公共交通站点到终点的这一段路，或者从一个公共交通站点到另一个公共交通站点这一段路，同时本申请实施例中的长距离出行工具无法覆盖的路线片段也可以指的是从起点到网约车辆固定站点、起点到网约车辆可搭乘地点、网约车辆可搭乘地点到终点、网约车辆固定站点到终点的这一段路。

本申请实施例中，可以获得城市公交线路信息(包括公交车和地铁的发车时间信息和停靠站点信息等等)及城市地图数据，依据城市公交线路信息和城市地图数据，确定用户的目标出行路线中公交车和地铁这类长距离出行工具无法覆盖的路线片段。

对于出租车和网约车辆来说，出租车和网约车辆的停靠点和运行路线通常没有特别严格的规定，一般都是司机按照乘客指定的上车点去接载乘客，按照乘客指定的下车点送达乘客，然而，有时，乘客的行程的起点并不是该乘客指定的上车点，乘客的行程的终点并不是该乘客指定的下车点，在此情况下，本申请实施例中的长距离出行工具无法覆盖的路线片段指的是行程的起点到指定上车点这一段路，或者指定下车点到行程的终点这一段路。

本申请实施例中，可以获得目标行程的起点、终点、用户指定的上车点和下车点，根据上述地点确定用户的目标出行路线中出租车和网约车辆这类长距离出行工具无法覆盖的路线片段。

为了便于理解，以公交车为例，同时结合图1B对本申请实施例中的路线片段进行介绍，如图1B所示，由起点至终点的路线为目标出行路线，其中，起点至公共交通站点A之间的线路、公共交通站点B至公共交通站点C之间的线路、及公共交通站点D至终点之间的线路等这三条线路，公交车无法到达；公共交通站点A至公共交通站点B之间的线路，及公共交通站点C至公共交通站点D之间的线路这两条线路，公交车可以到达。因此，目标出行路线中无法被公交车覆盖的路线片段包括：起点至公共交通站点A之间的线路、公共交通站点B至公共交通站点C之间的线路、及公共交通站点D至终点之间的线路等这三条线路。

在步骤102中，判断路线片段的起点周围是否存在可用的短距离出行工具；若判断结果为是，则执行步骤103。

本申请实施例中，短距离出行工具指的是除长距离出行工具之外的陆上交通工具，包括：自行车、电动车、平衡车、三轮车、摆渡车、接驳车及小巴等等。

本申请实施例中，可以从一个或多个第三方服务商(例如自行车服务平台、摆渡车服务平台)获得对应的短距离出行工具的状态数据，根据获得的短距离出行工具的状态数据，确定路线片段的起点的周围是否有可用的短距离出行工具，其中，该状态数据可以包括：短距离出行工具的位置信息、用于表征短距离出行工具当前是否可用的信息等等。

本申请实施例中，路线片段的起点的周围指的是路线片段的起点方圆M米内的地理范围，在实际应用中，可以根据实际需求，设定M的取值，例如M为100，本申请实施例对此不作限定。

在步骤103中，生成出行方式推荐结果，其中，该出行方式推荐结果用于提示该用户在到达该路线片段的起点时使用可用的短距离出行工具进行出行。

本申请实施例中，出行方式推荐结果中可以携带有以下信息中的至少一种：可用的短距离出行工具的种类、可用的短距离出行工具的位置信息，及可用的短距离出行工具的计费方式信息。

本申请实施例中，在判断出路线片段的起点周围在可用的短距离出行工具后，基于该路线片段的起点周围存在的可用的短距离出行工具，生成携带有该出行工具的信息的出行方式推荐结果。

例如，路线片段的起点A周围存在自行车，那么推荐用户在A位置下车后骑自行车完成后续的行程。

在步骤104中，将出行方式推荐结果发送给该用户的终端设备。

本申请实施例中，终端设备可以包括：智能手机、平板电脑等移动终端。

终端设备在接收到出行方式推荐结果后，将该出行方式推荐结果输出给用户，具体的，可以在显示屏上显示可用的短距离出行工具的可用信息，或者也可以通过该终端设备的声音播放部件播放可用的短距离出行工具的可用信息。

本申请实施例一示例性应用场景中，如图1C所示，该应用场景中包括：出行平台及多个短距离出行工具，分别为自行车、电动车、平衡车，及小巴/摆渡车，其中，在实际应用中，出行平台指的是服务器。出行平台，可以搜索长距离出行工具无法覆盖的路线片段的起点附近的出行工具，向用户推荐合适的短距离出行工具。

由上述实施例可见，该实施例中，对于目标出行路线中长距离出行工具无法覆盖的路线片段，可以结合该路线片段的起点位置及该路线片段的起点位置周围的短距离出行工具，为用户推荐合适的短距离出行工具(例如自行车、摆渡车等等)，由于相比于步行的出行方式，推荐用户使用短距离出行工具出行可以缩短出行时长和减少体力成本，更符合用户的期望，因此可以提高服务器计算资源和带宽资源的利用率。

考虑到用户通常都有喜好的出行方式，例如有的用户喜欢骑自行车出行，有的用户喜欢坐摆渡车出行，且用户的行为习惯可以从一定程度上反应出该用户的喜好，因此根据用户的行为习惯，为用户推荐短距离出行工具，可以从一定程度上提升用户的满意度，此时，如图2所示，图2是本申请实施例根据一示例性实施例示出的图1A中步骤103的一种实施方式的流程图，步骤103可以包括以下步骤：

在步骤201中，获取用户的历史出行数据，其中，该历史出行数据中包含该用户使用过的短距离出行工具的种类信息。

本申请实施例中，短距离出行工具的种类指的是出行工具属于自行车、电动车、平衡车、三轮车、摆渡车、接驳车还是属于小巴等等。

在步骤202中，根据该历史出行数据，生成出行方式推荐结果。

本申请实施例中，可以根据用户的历史出行数据，确定该用户使用过的短距离出行工具的类型及各类型的使用次数，通常情况下，用户使用的次数越多，该用户越倾向于该类型的短距离出行工具，因此，可以优先向用户推荐使用该类型的短距离出行工具，具体的，可以控制终端设备在展示出行方式推荐结果时，将该类型的短距离出行工具排列在其他可用的短距离出行工具前面、或者只展示该类型的短距离出行工具等等。

由上述实施例可见，该实施例可以根据用户的行为习惯，为用户推荐短距离出行工具，此时，出行方式推荐结果通常更符合用户的期望，从而可以在一定程度上提升用户的满意度。

如图3所示，图3是本申请实施例根据一示例性实施例示出的另一种出行方式推荐方法的流程图，考虑到长距离情况下，使用短距离出行工具出行更节省时间和体力成本，而在超短距离(例如几十米或一二百米)情况下，步行更为便捷，基于上述情况，此时该方法可以包括以下步骤：

在步骤301中，确定用户的目标出行路线中长距离出行工具无法覆盖的路线片段，其中，该长距离出行工具包括：公共交通车辆和网约车辆。

本申请实施例中的步骤301，与图1A所示实施例中的步骤101类似，本申请实施例对此不再赘述，详情请见步骤101中的内容。

在步骤302中，判断路线片段的路线长度是否达到预设长度阈值；若判断结果为是，则执行步骤303。

考虑到在长距离情况下，用户使用短距离出行工具出行，通常更为节省时间和体力成本，因此，本申请实施例中，可以通过将路线片段的路线长度与预设长度阈值进行比较，来确定路线片段的路线长度是长距离还是短距离，如果路线片段的路线长度大于或等于预设长度阈值，则认为路线片段的路线长度是长距离，此时推荐用户使用短距离出行工具出行。

又考虑到在超短距离情况下，用户使用短距离出行工具可能会耗费较多的时间，例如在路线片段的起点附近寻找自行车，达到路线片段的终点后还要找地方停放自行车；又例如摆渡车都有一定的发车时间，等待摆渡车发车可能也耗费一定时间，相比之下，步行更为方便，快捷。因此，本申请实施例中，如果路线片段的路线长度小于预设长度阈值，则认为路线片段的路线长度是超短距离，此时推荐用户步行出行。

需要说明的是，本申请实施例中的预设长度阈值可以依据经验，进行设置，也可以根据实际需求，进行设置，本申请实施例对此不作限定。

在步骤303中，判断路线片段的起点周围是否存在可用的短距离出行工具；若判断结果为是，则执行步骤304。

在步骤304中，生成出行方式推荐结果，其中，该出行方式推荐结果用于提示该用户在到达该路线片段的起点时使用可用的短距离出行工具进行出行。

在步骤305中，将出行方式推荐结果发送给该用户的终端设备。

本申请实施例中的步骤303～步骤305，与图1A所示实施例中的步骤102～步骤104类似，本申请实施例对此不再赘述，详情请见步骤102～步骤104中的内容。

由上述实施例可见，该实施例可以根据公交车辆无法覆盖的路线片段的长度，来选择向用户推荐出行方式，如果公交车辆无法覆盖的路线片段的长度较长，则推荐用户使用短距离出行工具出行，如果公交车辆无法覆盖的路线片段的长度较短，则推荐用户步行出行，使得出行方式推荐结果更为合理，从而在一定程度上提高用户的满意度。

本申请实施例提供的另一种实施例中，该实施例可以在上述任一方法实施例的基础上，增加以下步骤：

当检测到用户到达路线片段的起点时，生成街景地图开启指令；

发送该街景地图开启指令给该用户的终端设备，其中，该街景地图开启指令用于指示该终端设备开启街景地图。

本申请实施例中，街景地图是一种实景地图服务，为用户提供城市、街道或其他环境的360度全景图像，用户可以通过该服务获得如临其境的地图浏览体验。

考虑到街景地图更为直观，易于辨认，对于方向感不强的用户，用起来比较方便，因此，当用户到达路线片段的起点时，可以控制终端设备开启街景地图，以便用户可以通过该终端设备上展示的街景地图直观地了解周围的环境，较快的找到可用的短距离出行工具，及按照该街景地图继续进行后续的行程。

本申请实施例中，街景地图上可以展示有以下信息：路线片段的起点位置、用户当前的位置、可用的短距离出行工具当前位置及路线片段的终点位置。

本申请实施例中，可以通过颜色高亮、颜色渐变、鲜艳的颜色等醒目方式将路线片段的起点位置、用户当前的位置、可用的短距离出行工具当前位置及路线片段的终点位置标示在街景地图上，以便用户可以很直观地识别出路线片段的起点位置、用户当前的位置、可用的短距离出行工具当前位置及路线片段的终点位置。

由上述实施例可见，该实施例中，当用户到达路线片段的起点附近时，可以控制终端设备开启街景地图，由于街景地图包含的信息量更全面，直观性和精确性更高，因此便于用户了解周围环境，较快地找到可用的短距离出行工具、或者较快地到达路线片段的起点，从而提高出行效率。

应当注意，尽管在附图中以特定顺序描述了本申请实施例方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。相反，流程图中描绘的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

与前述出行方式推荐方法的实施例对应，本申请实施例还提供了出行方式推荐装置的实施例。

如图4所示，图4是本申请实施例根据一示例性实施例示出的一种出行方式推荐装置的框图，所述装置可以包括：

确定模块410，用于确定用户的目标出行路线中长距离出行工具无法覆盖的路线片段，其中，所述长距离出行工具包括：公共交通车辆和网约车辆；

第一判断模块420，用于判断所述确定模块410确定出的路线片段的起点周围是否存在可用的短距离出行工具；

第一生成模块430，用于在所述第一判断模块420的判断结果为是的情况下，生成出行方式推荐结果，其中，所述出行方式推荐结果用于提示所述用户在到达所述路线片段的起点时使用所述可用的短距离出行工具进行出行；

第一发送模块440，用于将所述第一生成模块430生成的出行方式推荐结果发送给所述用户的终端设备。

由上述实施例可见，该实施例中，对于目标出行路线中长距离出行工具无法覆盖的路线片段，可以结合该路线片段的起点位置及该路线片段的起点位置周围的短距离出行工具，为用户推荐合适的短距离出行工具(例如自行车、摆渡车等等)，由于相比于步行的出行方式，推荐用户使用短距离出行工具出行可以缩短出行时长和减少体力成本，更符合用户的期望，因此可以提高服务器计算资源和带宽资源的利用率。

如图5所示，图5是本申请实施例根据一示例性实施例示出的另一种出行方式推荐装置的框图，该实施例可以在图4所示实施例的基础上，所述第一生成模块430，可以包括：

数据获取子模块431，用于在所述第一判断模块420的判断结果为是的情况下，获取用户的历史出行数据，其中，所述历史出行数据中包含所述用户使用过的短距离出行工具的种类信息；

结果生成子模块432，用于根据所述数据获取子模块431获得的历史出行数据，生成出行方式推荐结果。

如图6所示，图6是本申请实施例根据一示例性实施例示出的另一种出行方式推荐装置的框图，该实施例可以在图4或图5所示实施例的基础上，所述装置还可以包括：

第二判断模块610，用于判断所述路线片段的路线长度是否达到预设长度阈值，并在判断结果为是的情况下，触发所述第一判断模块420执行判断所述路线片段的起点周围是否存在可用的短距离出行工具的操作。

如图7所示，图7是本申请实施例根据一示例性实施例示出的另一种出行方式推荐装置的框图，该实施例可以在图4～图6所示任一实施例的基础上，所述装置还可以包括：

第二生成模块710，用于在检测到用户到达所述路线片段的起点的情况下，生成街景地图开启指令；

第二发送模块720，用于发送所述第二生成模块710生成的街景地图开启指令给所述终端设备，其中，所述街景地图开启指令用于指示所述终端设备开启街景地图。

本申请实施例提供的另一种实施例中，该实施例可以在图4～图7所示任一实施例的基础上，所述出行方式推荐结果中可以携带有以下信息中的至少一种：

可用的短距离出行工具的种类、可用的短距离出行工具的位置信息，及可用的短距离出行工具的计费方式信息。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

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

本申请实施例还提供了一种计算机存储介质，所述存储介质中存储有程序指令，所述程序指令包括：确定用户的目标出行路线中长距离出行工具无法覆盖的路线片段，其中，所述长距离出行工具包括：公共交通车辆和网约车辆；判断所述路线片段的起点周围是否存在可用的短距离出行工具；当所述路线片段的起点周围存在可用的短距离出行工具时，生成出行方式推荐结果，其中，所述出行方式推荐结果用于提示所述用户在到达所述路线片段的起点时使用所述可用的短距离出行工具进行出行；将所述出行方式推荐结果发送给所述用户的终端设备。

本申请实施例可采用在一个或多个其中包含有程序代码的存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。计算机可用存储介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括但不限于：相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

本领域技术人员在考虑说明书及实践这里公开的公开后，将容易想到本申请实施例的其它实施方案。本申请实施例旨在涵盖本申请实施例的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请实施例未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请实施例的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请实施例并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请实施例的范围仅由所附的权利要求来限制。