用户界面显示方法、信息处理方法和装置与流程

本发明涉及互联网技术领域，尤其涉及一种用户界面显示方法、信息处理方法和装置。

背景技术：

互联网技术的不断发展已经大大改变了人们的生活方式，比如人们的出行方式、购物方式、配送方式等都在发生巨大变化，为满足用户的各种需求，开发出了各种相应的应用(Application，简称APP)。

针对物流类应用来说，不同的物流服务提供方会提供不同的应用(APP)供用户使用，使得用户能够基于其提供的某种固定配送方式进行配送下单处理。

技术实现要素：

目前，当用户想要比较采用哪个配送方式更适宜时，需要在不同的应用(APP)中输入服务需求信息，以查看每种配送方式相关的配送信息，比如价格，进而进行选择决策，在不同APP间切换操作的方式，使得用户操作不便。

有鉴于此，本发明实施例提供一种用户界面显示方法、信息处理方法和装置，用以克服现有技术中用户查看不同服务方式时操作不便的缺陷。

在本发明的一个实施例中，提供了一种用户界面显示方法，实现于客户端，该方法包括：

根据物流信息，获取与所述物流信息对应的多组服务信息；

在同一用户界面区域中显示所述多组服务信息。

可选地，所述方法还包括：

响应于对所述多组服务信息的选择操作，生成与选择的服务信息对应的服务订单。

可选地，所述物流信息包括：第一地址、第二地址、时限。

可选地，每组所述服务信息中包括：服务类型和服务参数信息；所述服务参数信息包括如下信息中的至少一种：距离信息、时间信息、价格信息。

可选地，所述获取与所述物流信息对应的多组服务信息，包括：

选择与所述第一地址和所述第二地址对应的多种服务类型；

从服务器获取与所述多种服务类型分别对应的距离信息和/或时间信息；

根据所述多种服务类型分别对应的所述距离信息和/或所述时间信息，计算分别与所述多种服务类型对应的价格信息。

在本发明的另一实施例中，提供了一种用户界面显示装置，包括：

获取模块，用于根据物流信息，获取与所述物流信息对应的多组服务信息；

显示模块，用于在同一用户界面区域中显示所述多组服务信息。

在上述实施例提供的用户界面显示方法和装置中，针对用户输入的物流信息，触发获取与该物流信息对应的多组服务信息，并在同一用户界面区域中显示获得的多组服务信息。其中，每组服务信息中包括了多种维度的参数信息，比如服务类型、距离、时间、价格等，从而能够使得用户获得全面的服务信息，并且能够直观地基于不同维度进行选择。而且，在同一用户界面区域中显示获得的多组服务信息，即相当于将多组服务信息进行集中的显示，使得用户在这多组服务信息中进行选择时，无需进行用户界面的切换操作，从而可以直观、方便地进行选择。

在本发明的一个实施例中，提供了另一种信息处理方法，实现于服务器，该方法包括：

接收物流信息；

获取与所述物流信息对应的多组服务信息，所述多组服务信息具有相同的显示区域属性；

发送所述多组服务信息至客户端。

可选地，所述物流信息包括：第一地址、第二地址、时限。

可选地，所述服务信息中包括服务类型和服务参数信息；

所述服务参数信息包括如下信息中的至少一种：距离信息、时间信息、价格信息。

可选地，所述获取与所述物流信息对应的多组服务信息，包括：

获取与所述物流信息对应的多种服务类型；

计算与所述多种服务类型分别对应的服务参数信息。

可选地，所述获取与所述物流信息对应的多种服务类型，包括：

确定与所述物流信息对应的候选服务类型集合；

获取与所述物流信息对应的环境影响因素；

根据所述环境影响因素，过滤所述候选服务类型集合，以过滤后的候选服务类型集合中包含的服务类型作为与所述物流信息对应的多种服务类型。

在本发明的一个实施例中，提供了一种信息处理装置，包括：

接收模块，用于接收物流信息；

获取模块，用于获取与所述物流信息对应的多组服务信息，所述多组服务信息具有相同的显示区域属性；

发送模块，用于发送所述多组服务信息至客户端。

在上述实施例提供的信息处理方法和装置中，服务器在接收到来自客户端的物流信息后，获取与该物流信息对应的多组服务信息，发送获取的多组服务信息至客户端，以使得客户端在同一用户界面区域中显示多组服务信息。由于服务器获得的每组服务信息中包括了多种维度的参数信息，比如服务类型、距离、时间、价格等，从而能够使得用户获得全面的服务信息，并且能够直观地基于不同维度进行选择。而且，在同一用户界面区域中显示获得的多组服务信息，即相当于将多组服务信息进行集中的显示，使得用户在这多组服务信息中进行选择时，无需进行用户界面的切换操作，从而可以直观、方便地进行选择。

附图说明

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

图1为本发明实施例提供的用户界面显示方法实施例一的流程图；

图1(a)为图1所示实施例中多组服务信息的一种显示方式的用户界面示意图；

图1(b)为图1所示实施例中多组服务信息的另一种显示方式的用户界面示意图；

图1(c)为图1所示实施例中任一组服务信息对应的服务选项的显示方式示意图；

图1(d)为对显示在同一用户界面区域的多个服务选项的一种滑动选择操作方式的用户界面示意图；

图1(e)为对显示在同一用户界面区域的多个服务选项的另一种滑动选择操作方式的用户界面示意图；

图2为本发明实施例提供的用户界面显示方法实施例二的流程图；

图3为步骤101的一种可选实现方式的流程图；

图3(a)为图3所示实施例中多组服务信息的一种显示方式的用户界面示意图；

图3(b)为图3所示实施例中多组服务信息的另一种显示方式的用户界面示意图；

图4为本发明实施例提供的信息处理方法实施例一的流程图；

图5为步骤402的一种可选实现方式的流程图；

图6为本发明实施例提供的信息处理方法交互流程图；

图7为本发明实施例提供的用户界面显示装置实施例一的结构示意图；

图8为本发明实施例提供的信息处理装置实施例一的结构示意图。

具体实施方式

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

在本发明实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

应当理解，尽管在本发明实施例中可能采用术语第一、第二、第三等来描述XXX，但这些XXX不应限于这些术语。这些术语仅用来将XXX彼此区分开。例如，在不脱离本发明实施例范围的情况下，第一XXX也可以被称为第二XXX，类似地，第二XXX也可以被称为第一XXX。

取决于语境，如在此所使用的词语“如果”、“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

图1为本发明实施例提供的用户界面显示方法实施例一的流程图，本实施例提供的用户界面显示方法由客户端来执行，该客户端可以是提供物流类应用的客户端。如图1所示，该方法包括如下步骤：

步骤101、根据物流信息，获取与物流信息对应的多组服务信息。

步骤102、在同一用户界面区域中显示多组服务信息。

可选地，上述物流类应用的客户端可以是安装在诸如智能手机、平板电脑、数字助手等终端设备中，当该客户端被开启时，显示物流信息输入界面，从而用户可以在该输入界面输入相应的物流信息。

在一种实际应用场景中，某用户A向用户B寄送某物体时，触发对上述客户端的使用。此时，可选地，用户A在输入界面中输入的物流信息可以包括：第一地址、第二地址、时限。其中，第一地址和第二地址分别对应于发货地址、收货地址。

其中，时限，一般来说，是指取货时限，可选地，可以预先设置几种时限选项，使得用户A可以基于实际需要选择一种时限选项，当然，还可以设置自定义时限选项，以供在预设的时限选项中没有符合需要的选项时，自定义时限选项。因此，可选地，时限选项中可以包括确定时限选项、不确定时限选项和自定义时限选项，其中，确定时限选项比如为：60分钟、90分钟具有确定时限要求的选项；不确定时限选项比如为：不限定时间。

可以理解的是，用户输入的物流信息中除了包含上述第一地址、第二地址、时限外，还可以包括诸如联系人、联系人电话、以及其他可设置的物流配送信息，比如物品重量、物品保价金额、是否拼单等，不以此为限。

当客户端接收到用户输入的物流信息后，触发与该物流信息对应的多组服务信息的获取处理。

可选地，客户端可以通过向服务器发送请求，以通过服务器获取与该物流信息对应的多组服务信息，此时，获取该物流信息对应的多组服务信息的处理逻辑在服务器侧完成。另外，可选地，获取该物流信息对应的多组服务信息的处理逻辑还可以基于客户端和服务器的配合完成，此时，部分处理逻辑在客户端进行，部分处理逻辑在服务器进行。

针对第二种可选方式，将在后续实施例中说明，本实施例中仅简要说明第一种可选方式下客户端与服务器的交互流程，旨在说明客户端可以通过服务器获取多组服务信息，而对于服务器如何获取与物流信息对应的多组服务信息的过程将在后续实施例中详细描述。

具体来说，当客户端接收到用户输入的物流信息后，生成包含该物流信息的服务请求，进而将该服务请求发送至服务器，触发服务器进行与该物流信息对应的多组服务信息的获取处理。

可选地，客户端在生成服务请求的过程中，可能涉及到如下的过程：针对用户输入的物流信息进行字符合法性校验，比如校验用户输入的数字是否超过预设上下限，用户是否在应该输入数字的地方输入了非数字字符，用户是否未输入必须输入的内容，等等；当校验通过后，基于客户端与服务器间通信协议的要求，比如采用信息-摘要算法5(Message-Digest Algorithm 5，简称MD5)对物流信息进行加密，从而生成一个特征码，该特征码用于服务器确定物流信息是否被篡改过；进而，将物流信息以及该特征码封装成一个服务请求，比如Http post请求，发送到服务器。

服务器接收到该服务请求后，触发获取与物流信息对应的多组服务信息的处理，将在后续实施例中描述，服务器将获得的多组服务信息携带于响应消息中反馈给客户端。

客户端接收到服务器反馈的响应消息后，从中解析获得多组服务信息。可选地，在解析获得多组服务信息的过程中，客户端还可以对每组服务信息进行格式校验，以验证收到的每组服务信息是否有效。

可选地，每组服务信息中包括：服务类型和服务参数信息，其中，服务参数信息包括如下信息中的至少一种：距离信息、时间信息、价格信息。其中，服务类型比如可以是指物流配送方或者物流配送工具。

值得说明的是，本发明实施例中，通过对物流配送资源进行整合，为用户提供多种不同的配送方案以供用户进行选择。其中，物流配送资源可以是指不同物流配送方的资源，也可以是同一物流配送方的不同配送工具资源。因此，本发明实施例中，通过对物流配送资源进行服务类型的分类，以基于用户输入的物流信息，针对每种服务类型计算对应的服务参数信息，以作为用户进行选择的依据。

因此，基于用户输入的物流信息而获取的每组服务信息中，通过携带有服务类型以及诸如时间、距离、价格等服务参数信息，可以直观而全面地告知用户能够采用的各种配送方式以及每种配送方式时的详情信息，使得用户能够基于每组服务信息直接作出选择。

另外，为了进一步提高用户进行配送方式选择的便利性，当客户端接收到服务器反馈的多组服务信息时，可以在同一用户界面区域中，显示这多组服务信息，即相当于对这多组服务信息进行集中显示。

可选地，在同一用户界面区域中显示多组服务信息，可以是首先生成与多组服务信息分别对应的服务选项，进而在同一用户界面区域中显示生成的多个服务选项。其中，服务选项可以以可被选择的“卡片”的形式显示，但是并不以此为限，可以以包含对应的一组服务信息的、可被选择的任一形式显示。生成服务选项可以简单理解为按照预先设置的每个服务选项“卡片”的布局样式，填充相应的内容。

可选地，在同一用户界面区域中显示生成的多个服务选项，可以参见如图1(a)和图1(b)所示的显示方式。

具体来说，前述提及到物流信息可以是用户在输入界面中输入的，如图1(a)所示，多个服务选项也可以在该输入界面中显示，即在该输入界面中，既显示有物流信息—图1(a)中示意的收货地址、发货地址、时限选项，也显示有多个服务选项——图1(a)中示意的服务选项1、服务选项2和服务选项3。物流信息显示在信息输入区域中，服务选项显示在服务展示交互区域中。其中，如图1(c)所示，每个服务选项中包含服务类型以及诸如距离、时间、价格等服务参数信息。另外，如图1(b)所示，多个服务选项也可以在不同于输入界面的另一个用户界面中显示，如图中所示的，物流信息显示在物流信息输入页面，服务选项显示在服务展示页面。也就是说，本发明实施例中的同一用户界面区域，更强调的是多个服务选项集中显示在某个用户界面的同一区域中，而并非对是否与物流信息的输入界面是否同一。

另外，如图1(a)和图1(b)所示，当服务选项的数量超出显示区域能够容纳的预设数量时，可以隐含部分服务选项的显示，图中以“…”示出。

在某些可选的实施例中，在同一用户界面区域中显示生成的多个服务选项，可以具体实现为：

将多个服务选项部分地显示在用户界面区域中；

响应于在用户界面区域中触发的滑动显示操作，将多个服务选项滑动显示在用户界面区域中。

当服务选项的个数大于显示服务选项的区域能够静态容纳的数量阈值时，实际在用户界面区域中只能显示部分服务选项，此时，当检测到用户的滑动操作时，触发根据用户触发的滑动操作，相应地控制服务选项滑动显示在用户界面区域中。

其中，用户触发的滑动操作可以是左右滑动，也可以上下滑动，分别如图1(d)和图1(e)所示。

通过在同一用户界面区域中集中显示多组服务信息分别对应的服务选项，使得用户能够直观而全面地获知能够响应其物流配送请求的各种物流配送方式及相关的配送信息，方便做出符合自身需求的选择。即便是服务选项的个数较多时，用户通过滑动操作即可方便地查看各个服务选项，相比于切换界面查看的方式，也具有更好的便利性、直观性。

在另一些可选的实施例中，在同一用户界面区域中显示生成的多个服务选项，可以实现为：

对多个服务选项进行排序；

根据排序结果，在同一用户界面区域中显示多个服务选项。

可选地，多个服务选项在用户界面区域中的显示顺序可以是随机地，也可以是按照一定顺序显示的。由于每个服务选项对应的一组服务信息中包含了诸如服务类型、价格、距离、时间等内容，因此，可以根据预先设置的排序规则，对多个服务选项进行排序，进而根据排序结果，在同一用户界面区域中显示多个服务选项。其中，排序规则比如可以是：按照价格从低到高排序；按照时间从短到长的顺序排序；按照预设的服务类型优先级排序；或者按照同一组服务信息中包含的几种信息内容的加权结果进行排序，等等。

实际应用中可选地，可以在显示多个服务选项的用户界面区域中或者在该用户界面区域相邻的其他某个区域中，设置排序规则选项，从而用户可以基于自身的偏好选择一种适宜的排序规则，以触发对多个服务选项的排序显示。

通过对多个服务选项进行排序显示，使得更加方便用户的选择操作，提高用户选择服务选项的便利性。

综上，通过上述任一实施例提供的用户界面显示方法，当用户输入物流信息后，客户端获取与该物流信息对应的多组服务信息，并在同一用户界面区域中显示获得的多组服务信息。由于每组服务信息中描述了一种配送方式的详情信息，比如包含服务类型以及多种服务参数信息，从而能够使得用户获得全面的服务信息以直观地进行不同配送方式的选择。而且，将多组服务信息进行集中的显示，使得用户可以直观、方便地进行选择，提高选择便利性。

在前述任一可选实施例的基础上，可选地，如图2所示，步骤102之后，该方法还可以包括如下步骤103：

步骤103、响应于对多组服务信息的选择操作，生成与选择的服务信息对应的服务订单。

多组服务信息中的每组服务信息可选地被生成为一一对应的服务选项，也就是说，每组服务信息以服务选项的形式显示在用户界面上。从而，用户对多组服务信息的选择操作即为对多个服务选项的选择操作。

本实施例中，由于每组服务信息即每个服务选项中显示出了服务类型、多种服务参数信息，用户可以直观地基于显示的这些内容进行选择，因此，用户对某个服务选项的选择操作，则直接导致相应服务订单的生成，用户无需进行其他的选择操作。生成服务订单后，用户可以通过点击如图1(a)所示的发布订单按钮来提交该服务订单。

可选地，用户对显示在同一用户界面区域中的多个服务选项进行选择操作时可能涉及到滑动、点击两种类型的操作，其中，滑动操作对应于滑动显示多个服务选项，点击操作对应于选中某个具体的服务选项。

具体地，根据触摸屏的检测原理，当检测到用户手指在上述用户界面区域的按下和离开的操作时，根据按下操作时的坐标(X0,Y0)和离开时的坐标(X1,Y1)，可以得到这两个坐标点之间的位移向量S，其中，Sx和Sy分别是S在x轴和y轴的分向量。

如图1(d)所示，当多个服务选项被设置为左右滑动显示时，若Sx大于一定距离阈值，则视为横向滑动操作，此时根据X轴上的分向量Sx移动各服务选项。若在移动的过程中，最后一个服务选项已经被滑动到屏幕内，则不能再向左滑动；反之，若队第一个服务选项已经被滑动到屏幕内，则不能再向右滑动。

如图1(e)所示，当多个服务选项被设置为上下滑动显示时，若Sy大于一定预设距离阈值，则视为纵向滑动操作，此时根据y轴上的分向量Sy移动各服务选项。若在移动的过程中，最后一个服务选项已经被滑动到屏幕内，则不能再向上滑动；反之，若第一个服务选项已经被滑动到屏幕内，则不能再向下滑动。

综上，当用户的操作表示在x轴或y轴上的移动距离超过一定距离阈值时，表示用户的操作是滑动操作。

相反地，若位移向量S小于预设距离阈值，则视为点击操作，即用户选中了某个服务选项。

基于前述实施例中介绍的多组服务信息的显示、选择过程可知，本发明各实施例提供的用户界面显示方法所揭示的物流配送服务的处理逻辑是：用户只需根据实际的配送需求，在物流信息输入界面中输入必要的物流信息，比如地址、联系人、物品相关信息，至于有哪些配送方式可以用来响应用户的物流需求，则是由客户端和服务器或者是由服务器来基于物流信息来实时计算的，即实时获取与物流信息对应的可能的各服务类型以及每种服务类型对应的服务参数信息。这样，用户只需根据自己的需求从多种可选的配送方式中选择一个即可。也就是说，客户端中不会预先设置有关配送方式选择的控件，比如不会包含与多种服务类型对应的选择控件，以避免限制用户的选择，或者说避免用户因为不能横向比较哪种配送方式更适宜而选择了不适宜的配送方式。

下面结合图3，对客户端如何获取与物流信息对应的多组服务信息的一种可选实现方式进行详细说明。

在前述任一可选实施例的基础上，可选地，如图3所示，步骤101中获取与物流信息对应的多组服务信息，可以通过如下方式实现：

步骤1011、选择与第一地址和第二地址对应的多种服务类型。

步骤1012、从服务器获取与多种服务类型分别对应的距离信息和/或时间信息。

步骤1013、根据多种服务类型分别对应的距离信息和/或时间信息，计算分别与多种服务类型对应的价格信息。

本实施例中假设如下的实际物流应用场景：同城物流。也就是说，假设用户输入的第一地址和第二地址是属于同一城市的地址。并且假设服务类型指示的是不同配送工具，比如电动自行车、摩托车、汽车等。

值得说明的是，上述应用场景仅为举例，实际应用中，还可以是跨城的物流场景，服务类型还可以是指示不同的物流提供商等。

针对步骤1011来说，当接收到用户输入的包含第一地址、第二地址等输入内容的物流信息时，首先可以基于第一地址和第二地址确定出与之对应的城市名称A，进而，基于客户端侧预先存储的城市名称与服务类型的对应关系选择确定与城市名称A对应的服务类型，假设对应的服务类型包括服务类型a、服务类型b和服务类型c。

其中，城市名称与服务类型的对应关系可以是客户端预先从服务器中获得的。而且，该城市名称与服务类型的对应关系是根据每个城市实际支持的配送方式确定的，即根据每个城市中实际支持的配送工具类型确定的。比如，某些城市受限于特殊的地形、道路规划特征，不支持电动自行车配送；某些城市受限于拥挤的路况特征等因素，不支持汽车配送。

本实施例中，虽然在客户端侧可以进行简单地处理逻辑，比如上述基于第一地址和第二地址匹配获得相应的多种服务类型，但是考虑到客户端的计算能力不足，对于获取多组服务信息的过程中，对计算能力要求比较高的处理逻辑还需借助服务器来实现。

因此，针对步骤1012来说，当客户端确定出多种服务类型后，可以从服务器侧获取与该多种服务类型分别对应的距离信息和/或时间信息。具体地，客户端与服务器的交互过程为：

客户端向服务器发送携带有第一地址、第二地址和多种服务类型的获取请求；

服务器在接收到该获取请求后，根据第一地址和第二地址获取与多种服务类型分别对应的距离信息和/或时间信息，并将获取的距离信息和/或时间信息携带在获取响应消息中反馈至客户端；

客户端从接收到的获取响应消息中解析获得与该多种服务类型分别对应的距离信息和/或时间信息。

值得说明的是，在一种可选实现方式中，客户端与服务器间可以基于预先设定的通信协议获知每种通信消息的意图。比如，服务器接收到上述获取请求后，基于通信协议约定，便知道该获取请求是用于获取与该多种服务类型分别对应的距离信息和/或时间信息的。

可选地，服务器可以通过与第三方应用的接口，借助第三方应用来实现上述距离信息、时间信息的计算，或者当服务器中集成了能够计算上述距离信息、时间信息的处理能力时，本地实现该计算。其中，第三方应用比如可以是电子地图应用。

假设服务器中集成有电子地图应用，则服务器可以根据第一地址和第二地址，计算每种服务类型下对应的距离、时间信息。举例来说，当多种服务类型包括电动自行车、摩托车、汽车时，也就是说，服务器计算采用电动自行车配送时，从第一地址到第二地址需要行驶多远的距离，需要多长时间，同理，服务器计算采用摩托车、汽车配送时，从第一地址到第二地址分别需要行驶多远的距离，需要多长时间。

针对步骤1013来说，客户端可以根据服务器反馈的与多种服务类型分别对应的距离信息和/或时间信息，基于预先设置的价格计算方式来计算分别与多种服务类型对应的价格信息。

举例来说，对应于某种服务类型，基于距离信息计算价格的方式可以采用如下的公式实现：

f(S)＝(Pb+P1*(S-S0))，其中，Pb为对应于某种服务类型的基础价格，P1为对应于某种服务类型的每公里单价、S为对应于某种服务类型的距离变量，即第一地址与第二地址之间的距离、S0为对应于某种服务类型的免费距离。

通过上述获取过程，客户端最终能够获得包含服务类型、服务类型对应的时间信息、距离信息、价格信息的多组服务信息。

另外可选地，用户输入的物流信息中除了包含有第一地址、第二地址、时限外，可能还会包含比如物品重量、物品保价金额、是否拼单等信息，此时，每种服务类型对应的价格信息除了受上述距离信息、时间信息影响外，还会受到物品重量、物品保价金额、是否拼单等信息的影响。

因此，在一种可选实现方式中，客户端对于任意某种服务类型对应的价格信息的计算还可以通过如下公式计算实现：

f(K,S,M,V)＝K*(Pb+Ps+Pm+Pv)，其中：

K为拼单系数，取值区间为(0,1]：若用户输入的物流信息中指示用户选择了拼单，则K取值为0，若没有选择拼单，则K取值1；

Pb为与上述某种服务类型对应的基础价格；

Ps为与上述某种服务类型对应的距离加价，Ps＝P1*(S-S0)。其中，P1为每公里单价、S为距离变量，即第一地址与第二地址之间的距离、S0为免费距离；

Pm为与上述某种服务类型对应的重量加价，Pm＝P2*(M-M0)。其中，P2为每公斤单价，M为重量变量，即物品重量，M0为免费重量；

Pv为与上述某种服务类型对应的金额加价，Pv＝P3*(V-V0)。其中，P3为基础单价、V为保价金额变量，即物品保价金额，V0为免费保价金额。

值得说明的是，在上述某些实施例中，客户端获得的每组服务信息中包含的服务类型默认情况下，可以视为都是可用的服务类型。但是实际中，受到实时的天气、交通、运力等因素的影响，客户端获得的多组服务信息分别对应的多种服务类型可能会有部分不可用的情况。

因此，在基于第一地址、第二地址获得多种服务类型的基础上，在一种可选的实现方式中，在每种服务类型对应的服务参数信息中还可以包括指示对应的服务类型是否可用的可用状态信息；在另一种可选的实现方式中，在用户界面区域中显示的每组服务信息中的服务类型都是可用的，即仅在用户界面区域中显示服务类型的可用状态指示服务类型可用的各组服务信息。

下面结合图3(a)和图3(b)举例说明上述两种可选的实现方式，假设基于第一地址、第二地址获得多种服务类型包括服务类型a、服务类型b和服务类型c，并且假设服务类型b对应的可用状态指示不可用，其他两种服务类型对应的可用状态指示可用。

如图3(a)所示，在同一用户界面区域中包含三组服务信息，其中，服务类型a对应的服务参数信息包括可用、时间1、价格1，服务类型b对应的服务参数信息包括不可用、时间2、价格2，服务类型c对应的服务参数信息包括可用、时间3、价格3。该种方式使得用户能够直观地获知每种服务类型的可用状态。

如图3(b)所示，在同一用户界面区域中包含两组服务信息，即仅显示服务类型可用状态指示可用的服务类型a和服务类型c对应的两组服务信息。其中，服务类型a对应的服务参数信息包括时间1、价格1，服务类型c对应的服务参数信息包括时间3、价格3。该种方式可以有效使用屏幕的显示区域，避免冗余的不可用服务信息对屏幕的占用，并排除不可用服务信息对用户选择所需服务信息操作的干扰。

另外，在考虑服务类型是否可用的情况下，上述计算价格信息的方式也适应性改变。

具体来说，针对f(S)＝(Pb+P1*(S-S0))来说，适应性改变为：f(A,S)＝A*(Pb+P1*(S-S0))；

针对f(K,S,M,V)＝K*(Pb+Ps+Pm+Pv)来说，适应性改变为：

f(A,K,S,M,V)＝A*K*(Pb+Ps+Pm+Pv)。

其中，A为可用状态系数，表示对应的服务类型是否可用。A取值0或1，若可用则取值1，若不可用则取值0。

在前述可选的实施例中，主要从当多种服务类型中存在不可用的服务类型时，如果在同一用户界面区域显示对应的多组服务信息，以及如何计算每种服务类型对应的价格信息的角度进行了介绍。下面介绍如何确定每种服务类型的可用状态。

可选地，客户端在基于用户输入的第一地址和第二地址确定出对应的多种服务类型之后，还可以从服务器获取该多种服务类型分别对应的可用状态信息。具体地，客户端向服务器发送携带有该多种服务类型、第一地址和第二地址的查询请求，服务器根据该查询请求确定该多种服务类型分别对应的可用状态信息，并反馈至客户端，客户端进而根据服务器反馈的多种服务类型分别对应的可用状态信息，滤除该多种服务类型中不可用的服务类型。

其中，针对客户端发送的多种服务类型中的任一服务类型，服务器确定该服务类型是否可用的考虑因素可以包括：天气、交通、运力中的一种或多种。

以上述三种考虑因素以及服务类型为配送工具的类型为例来说，可选地：

服务器侧可以周期性更新某地的天气情况与服务类型的对应关系，比如对应于第一地址和第二地址的某城市，天气正常时，可以采用的服务类型包括服务类型a、服务类型b、服务类型c、服务类型d，异常天气，比如大风、大雨等天气时，可以采用的服务类型包括服务类型a、服务类型b。

服务器侧还可以实时获取某路段的交通拥堵情况与服务类型的对应关系，比如若第一地址和第二地址之间的交通路况表明交通流量大于一定阈值时，可以采用的服务类型包括服务类型a、服务类型b、服务类型c、服务类型d，交通流量低于一定阈值时，可以采用的服务类型包括服务类型b、服务类型c。

服务器侧还可以实时统计某地的每种服务类型对应的运力情况。

综上，当服务器接收到客户端发送的上述查询请求后，首先可以基于第一地址和第二地址来获取对应的天气情况、交通拥堵情况，以及确定查询请求中每种服务类型对应的运力情况，进而可以从查询请求中包含的多种服务类型中筛选出满足天气情况、交通拥堵情况和运动情况的可用的服务类型，将筛选出的可用服务类型反馈至客户端，从而使得客户端从上述多种服务类型中滤除不可用的服务类型。

基于上述实施例，当基于用户输入的第一地址和第二地址选择出多种服务类型之后，通过对这多种服务类型进行是否可用的过滤，能够进一步滤除当前不可用的服务类型，从而，一方面可以降低服务器后续计算距离、时间信息以及客户端计算价格信息的计算量，提高处理效率，另一方面也可以有效降低冗余的服务信息对屏幕空间的占用，可以提高屏幕空间的利用率。

通过上述各实施例，已经介绍了客户端侧如何基于用户输入的物流信息获取相应的多组服务信息，以及如何显示多组服务信息，以实现为用户直观地显示全面的服务信息，使得用户对多组服务信息的选择简便，易操作的目的。

下面，结合如下的几个方法实施例，从服务器侧的角度，对服务器如何对物流信息进行处理的过程进行说明。

图4为本发明实施例提供的信息处理方法实施例一的流程图，本实施例提供的信息处理方法由服务器来执行，该服务器对应的客户端可以是提供物流类应用的客户端，相应的，该服务器提供了对物流信息的处理能力。如图4所示，该方法包括如下步骤：

步骤401、接收物流信息。

步骤402、获取与物流信息对应的多组服务信息，该多组服务信息具有相同的显示区域属性。

步骤403、发送多组服务信息至客户端。

本实施例中，服务器接收到的物流信息是通过客户端发送的，也就是当客户端接收到用户输入的物流信息后，将该物流信息发送至服务器。但是，由于服务器与客户端之间是通过一定的通信协议进行网络通信的，因此，该物流信息在客户端与服务器间传输时，是被封装在一定的数据包之内的。

另外，本实施例中，物流应用的场景可以是跨越不同城市、地区的物流配送场景，也可以是同城物流配送场景。

结合实际应用，用户输入的物流信息一般可以包括收货人地址、发货人地址、收货时限等等。因此，本实施例中可选地，物流信息包括：第一地址、第二地址、时限，当然，物流信息中还可以包括诸如收货人姓名、发货人姓名以及物品相关信息，比如物品重量、物品保价金额、是否拼单等。

其中，第一地址和第二地址分别对应于收货人地址、发货人地址；时限一般是指取货时限，如前述实施例中介绍的，该时限可以包括确定时限、不确定时限等多种形式，本实施例不赘述。

当客户端接收到用户输入的物流信息后，生成包含该物流信息的服务请求，进而将该服务请求发送至服务器，触发服务器进行与该物流信息对应的多组服务信息的获取处理。

具体地，客户端与服务器的交互流程如下：

客户端接收用户输入的物流信息，针对用户输入的物流信息进行字符合法性校验，比如校验用户输入的数字是否超过预设上下限，用户是否在应该输入数字的地方输入了非数字字符，用户是否未输入必须输入的内容，等等；当校验通过后，基于客户端与服务器间通信协议的要求，比如采用信息-摘要算法5(Message-Digest Algorithm 5，简称MD5)对物流信息进行加密，从而生成一个特征码，该特征码用于服务器确定物流信息是否被篡改过；进而，将物流信息以及该特征码封装成一个服务请求，比如Http post请求，发送到服务器。

服务器接收到该Http post请求后，从中解析获得其中包含的物流信息和特征码，进而对物流信息实施与客户端相同的MD5加密算法，生成一个服务器端的特征码。将服务器端生成的特征码与服务请求中携带的客户端生成的特征码进行比对，若相同则确认物流信息没有被篡改。然后对Http post请求中的物流信息进行格式有效性校验，即与服务器端预设好的数据格式进行比对，若数据格式一致，校验通过，否则，校验不通过，终止处理。

在上述校验通过后，服务器为了响应客户端的服务请求，需要获取与物流信息对应的多组服务信息。可选地，每组服务信息中包括服务类型和服务参数信息，其中，服务类型比如可以是配送工具类型、不同的物流配送方等，服务参数信息包括如下信息中的至少一种：距离信息、时间信息、价格信息。

也就是说，本实施例中，多组服务信息中的每组服务信息分别对应于一种配送方式，并且包含详细的配送详情信息，用以告知用户可以采用什么类型的配送方式进行配送，并且告知用户每种配送方式所需的时间、距离、价格等参数信息，以供用户从多种配送方式中选择一种所需的，方便用户选择。

另外，除了每组服务信息中包含了多个维度的信息以方便用户选择外，本发明实施例中，为了进一步便于用户在客户端上的选择操作，服务器获取的多组服务信息还具有相同的位置区域属性。该相同的位置区域属性，简单来说，就是能够使得该多组服务信息在客户端的同一用户界面区域中集中显示。可选地，服务器在获取多组服务信息后，可以为每组服务信息打一个标签，该标签用于标记该组服务信息在客户端某用户界面上的位置区域。可以理解的是，各组服务信息具有相同的标签，从而，客户端可以基于每组服务信息的标签，将多组服务信息显示在同一用户界面区域中。

可以理解的是，服务器之所以能够针对物流信息获取多组服务信息，是因为服务器端对物流配送资源进行了有效的整合和管理。其中，物流配送资源可以是指不同物流配送方的资源，也可以是同一物流配送方的不同配送工具资源。因此，本发明实施例中，服务器通过对物流配送资源进行分类，确定出各个服务类型。

而且，值得说明的是，在同城配送的应用场景中，可以基于对各个城市实际物流配送资源的调查，确定每个城市实际支持的物流配送资源，比如各个城市中采用的配送工具类型，从而在服务器中预先建立城市与配送资源类型即服务类型间的对应关系。

基于此，服务器针对用户实际触发的物流信息，获取与该物流信息对应的多组服务信息的过程，主要包括：首先，确定与该物流信息对应的多种服务类型；其次，针对确定出的每种服务类型计算对应的服务参数信息。

可选地，如图5所示，上述步骤402中获取与该物流信息对应的多组服务信息，可以通过如下步骤实现：

步骤4021、确定与物流信息对应的候选服务类型集合。

步骤4022、获取与物流信息对应的环境影响因素。

步骤4023、根据环境影响因素，过滤候选服务类型集合，以过滤后的候选服务类型集合中包含的服务类型作为与物流信息对应的多种服务类型。

步骤4024、计算与物流信息对应的多种服务类型分别对应的服务参数信息。

本实施例中，获取候选服务类型集合的步骤可以在服务器本地完成，也可以是服务器通过与第三方应用的接口，将物流信息发送至第三方应用由第三方应用完成。

以在服务器本地完成上述候选服务类型集合，且以同城物流的应用场景为例，服务器中可以预先设置城市名称与服务类型的对应关系，而且，该城市名称与服务类型的对应关系是根据每个城市实际支持的配送方式确定的。当配送方式以配送工具类型定义时，即该对应关系是根据每个城市中实际支持的配送工具类型确定的。比如，某些城市受限于特殊的地形、道路规划特征，不支持电动自行车配送；某些城市受限于拥挤的路况特征等因素，不支持汽车配送。

因此，基于上述城市名称与服务类型的对应关系，当物流信息中包含第一地址和第二地址时，服务器可以基于该第一地址和第二地址确定对应的城市名称，进而查询该城市名称与服务类型的对应关系，匹配获得与确定出的城市名称对应的各个服务类型，由这些服务类型构成候选服务类型集合。

另外可选地，由于物流信息中除了包括第一地址、第二地址外，还可以包括物品重量、物品尺寸等信息，这些物品相关的信息也可以对候选服务类型集合的确定产生影响。比如，实际应用中，如果需要配送的物品是重量较重、尺寸很大的物品，用电动自行车、摩托车配送可能是不适宜的。

因此，可选地，服务器中还可以预先设置物品重量与服务类型的对应关系，或者，物品尺寸与服务类型的对应关系，或者，物品重量和物品尺寸的整体与服务类型的对应关系。

因此，确定与物流信息对应的候选服务类型集合，既可以是基于城市名称与服务类型的对应关系实现的，也可以是基于城市名称与服务类型的对应关系，以及基于物品重量和/或物品尺寸与服务类型的对应关系实现的。

可选地，当基于城市名称与服务类型的对应关系，以及基于物品重量和/或物品尺寸与服务类型的对应关系来确定与物流信息对应的候选服务集合时，可以是：基于城市名称与服务类型的对应关系，确定与物流信息中的第一地址和第二地址对应的第一服务类型集合；基于物品重量和/或物品尺寸与服务类型的对应关系，确定与物流信息中的物品重量和/或物品尺寸对应的第二服务类型集合；第一服务类型集合和第二服务类型集合取交集构成候选服务类型集合。

当获取与物流信息对应的候选服务类型集合后，可选地，可以直接认为该候选服务类型集合中包含的各服务类型即为与物流信息对应的多种服务类型，进而针对每种服务类型计算相应的服务参数信息，比如距离、时间、价格中的任一个或多个参数。

但是，值得说明的是，在上述可选实施例中，直接认为该候选服务类型集合中包含的各服务类型即为与物流信息对应的多种服务类型，是默认了候选服务类型集合中包含的各服务类型都是可用的服务类型。但是实际中，受到实时的天气、交通、运力等因素的影响，候选服务类型集合中的多种服务类型可能会有部分不可用的情况，因此，可选地，在获取上述候选服务类型集合后，还可以基于环境影响因素对候选服务类型集合进行过滤，以滤除其中包含的不可用的服务类型。

具体来说，为了实现上述过滤处理，首先要获取与物流信息对应的环境影响因素，环境影响因素比如可以包括上述举例的天气、交通、运力等因素中的一种或多种。

以上述三种环境影响因素以及服务类型为配送工具类型为例来说，参考图3所示实施例中的介绍，可选地，服务器可以周期性更新各城市的天气情况与服务类型的对应关系；服务器还可以实时获取某路段的交通拥堵情况与服务类型的对应关系；服务器还可以实时统计各城市的每种服务类型对应的运力情况。

从而，基于各城市天气情况与服务类型的对应关系，服务器可以确定与物流信息中的第一地址和第二地址对应的城市，当前所可以采用的各服务类型；基于路段的交通拥堵情况与服务类型的对应关系，服务器可以确定与物流信息中的第一地址和第二地址对应的当前所可以采用的各服务类型；基于各城市的每种服务类型对应的运力情况，服务器可以确定与物流信息中的第一地址和第二地址对应的城市中各种服务类型的运力状态，从而确定当前所可以采用的各服务类型。

从而，根据上述确定出的各服务类型对候选服务类型集合进行过滤，即取交集，即可得到与物流信息对应的多种可用的服务类型。进而，针对每种可用的服务类型计算相应的服务参数信息。

值得说明的是，服务器计算每种服务类型对应的服务参数信息可以参照图3所示实施例中客户端的计算公式实现，只是计算的主体由客户端变为服务器，因此，在此不再赘述详细的计算过程。

通过对候选服务类型集合进行过滤，可以有效减少后续服务参数信息计算的计算量，而且避免向客户端反馈不可用的服务信息，避免客户端显示不可用的服务信息对屏幕空间的低利用率。

当服务器获取由多种服务类型以及每种服务类型对应的服务参数信息组成的多组服务信息后，响应于客户端的服务请求，将多组服务信息携带于响应消息中反馈至客户端。

客户端接收到服务器反馈的响应消息后，从中解析获得多组服务信息，并将多组服务信息显示在同一用户界面区域中。其中，客户端对多组服务信息的显示处理过程可以参见图1所示实施例，在此不再赘述。

另外，可选地，服务器在获得多组服务信息后，还可以根据一定的排序规则对多组服务信息进行排序，从而，客户端对多种服务信息的显示顺序也是根据该排序结果进行的。具体地，由于每组服务信息中包括了服务类型、距离、价格、时间等信息，因此，排序规则可以针对其中任一种信息维度设置，也可以针对多种信息维度的加权结果设置。排序规则比如可以是：按照价格从低到高排序；按照时间从短到长的顺序排序；按照预设的服务类型优先级排序；或者按照同一组服务信息中包含的几种信息内容的加权结果进行排序，等等。

综上，基于上述各实施例提供的信息处理方法，服务器在接收到来自客户端的物流信息后，获取与该物流信息对应的多组服务信息，发送获取的多组服务信息至客户端，以使得客户端在同一用户界面区域中显示多组服务信息。由于服务器获得的每组服务信息中包括了指示配送方式的服务类型信息以及介绍配送方式详情的服务详情信息，从而能够使得用户获得全面的服务信息，并且客户端在同一用户界面区域中显示获得的多组服务信息，能够使得用户直观地基于不同信息维度进行选择，操作方便。

另外，服务器通过对多组服务信息进行是否可用的过滤处理，保证向客户端反馈的服务信息都是可用的，降低了服务信息的冗余度。

另外，服务器通过对物流配送资源按照不同的服务类型进行整合，扩展了供用户选择配送方式的信息维度，使得用户进行配送方式选择的局限性更小。

上述各实施例分别从客户端的角度或者服务器的角度进行了描述，下面结合图6所示实施例，从实际应用角度介绍本发明实施例提供的信息处理方法，以下将客户端表示为APP，本实施例中的用户界面图参考图1(a)所示。如图6所示，包括如下步骤：

步骤601、响应于用户对APP的开启操作，接收用户在APP的发布订单页面的信息输入区域中输入的物流信息，生成携带有物流信息的服务请求。

步骤602、APP将服务请求发送至服务器。

步骤603、服务器解析获得物流信息，并获取与物流信息对应的多组服务信息。

步骤604、服务器向APP发送携带有多组服务信息的服务响应消息。

步骤605、APP解析获得多组服务信息，将多组服务信息显示在发布订单页面的服务展示交互区域中。

步骤606、响应于用户在服务展示交互区域中对多组服务信息的选择操作，APP将用户选中的一组服务信息置于选中状态。

步骤607、响应于用户对发布订单页面中发布订单按钮的点击操作，APP生成服务订单。

以下将详细描述本发明的一个或多个实施例的用户界面显示装置。这些用户界面显示装置可以被实现在移动终端的基础架构中，也可以被实现在服务器和客户端的交互系统中。本领域技术人员可以理解，这些用户界面显示装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图7为本发明实施例提供的用户界面显示装置实施例一的结构示意图，如图7所示，该用户界面显示装置包括：获取模块11、显示模块12。

获取模块11，用于根据物流信息，获取与所述物流信息对应的多组服务信息；

显示模块12，用于在同一用户界面区域中显示所述多组服务信息。

可选地，该用户界面显示装置还包括：第一生成模块13。

第一生成模块13，用于响应于对所述多组服务信息的选择操作，生成与选择的服务信息对应的服务订单。

可选地，该用户界面显示装置还包括：第二生成模块14。

第二生成模块14，用于生成与所述多组服务信息分别对应的服务选项。

相应地，所述显示模块12，具体用于在同一用户界面区域中显示生成的多个服务选项。

可选地，显示模块12具体用于：将所述多个服务选项部分地显示在所述用户界面区域中；响应于在所述用户界面区域中触发的滑动显示操作，将所述多个服务选项滑动显示在所述用户界面区域中。

可选地，该用户界面显示装置还包括：排序模块15。

排序模块15，用于对所述多个服务选项进行排序。

相应地，显示模块12，具体用于根据排序结果，在同一用户界面区域中显示所述多个服务选项。

其中，可选地，所述物流信息包括：第一地址、第二地址、时限。

其中，可选地，，每组所述服务信息中包括：服务类型和服务参数信息；所述服务参数信息包括如下信息中的至少一种：距离信息、时间信息、价格信息。

可选地，所述获取模块11包括：选择子模块111、获取子模块112、计算子模块113。

选择子模块111，用于选择与所述第一地址和所述第二地址对应的多种服务类型。

获取子模块112，用于从服务器获取与所述多种服务类型分别对应的距离信息和/或时间信息。

计算子模块113，用于根据所述多种服务类型分别对应的所述距离信息和/或所述时间信息，计算分别与所述多种服务类型对应的价格信息。

可选地，获取子模块112还用于：从服务器获取所述多种服务类型分别对应的可用状态信息。

相应可选地，该用户界面显示装置还包括：过滤模块16。

过滤模块16，用于根据所述服务器反馈的所述多种服务类型分别对应的可用状态信息，滤除所述多种服务类型中不可用的服务类型。

图7所示装置可以执行图1至图3所示实施例的方法，本实施例未详细描述的部分，可参考对图1至图3所示实施例的相关说明。该技术方案的执行过程和技术效果参见图1至图3所示实施例中的描述，在此不再赘述。

以上描述了用户界面显示装置的内部功能和结构，实际中，该用户界面显示装置可实现为终端设备，包括：输入设备、处理器、显示屏；

所述输入设备，用于接收用户输入的物流信息；

所述处理器，耦合到所述输入设备和所述显示屏，用于获取与物流信息对应的多组服务信息；

所述处理器还用于：控制所述显示屏在同一用户界面区域中显示多组服务信息。

可选地，所述处理器还用于执行上述图1至图3所示方法步骤中的全部或部分。

以下将详细描述本发明的一个或多个实施例的信息处理装置。这些信息处理装置可以被实现在服务器的基础架构中，也可以被实现在服务器和客户端的交互系统中。本领域技术人员可以理解，这些信息处理装置均可使用市售的硬件组件通过本方案所教导的步骤进行配置来构成。

图8为本发明实施例提供的信息处理装置实施例一的结构示意图，如图8所示，该装置包括：接收模块21、获取模块22、发送模块23。

接收模块21，用于接收物流信息；

获取模块22，用于获取与所述物流信息对应的多组服务信息，所述多组服务信息具有相同的位置区域属性；

发送模块23，用于发送所述多组服务信息至客户端。

可选地，物流信息包括：第一地址、第二地址、时限。

可选地，每组服务信息中包括服务类型和服务参数信息；所述服务参数信息包括如下信息中的至少一种：距离信息、时间信息、价格信息。

可选地，所述获取模块22包括：获取子模块221、计算子模块222。

获取子模块221，用于获取与所述物流信息对应的多种服务类型。

计算子模块222，用于计算与所述多种服务类型分别对应的服务参数信息。

其中，所述获取子模块221包括：确定单元2211、获取单元2212、过滤单元2213。

确定单元2211，用于确定与所述物流信息对应的候选服务类型集合。

获取单元2212，用于获取与所述物流信息对应的环境影响因素。

过滤单元2213，用于根据所述环境影响因素，过滤所述候选服务类型集合，以过滤后的候选服务类型集合中包含的服务类型作为与所述物流信息对应的多种服务类型。

图8所示装置可以执行图4和图5所示实施例的方法，本实施例未详细描述的部分，可参考对图4和图5所示实施例中的相关说明。该技术方案的执行过程和技术效果参见图4、图5所示实施例中的描述，在此不再赘述。

以上描述了信息处理装置的内部功能和结构，实际中，该信息处理装置可实现为服务器，包括：通信组件、处理器，所述通信组件与所述处理器耦合；

所述通信组件，用于接收物流信息；

所述处理器，用于获取与所述物流信息对应的多组服务信息，所述多组服务信息具有相同的位置区域属性；

所述通信组件还用于：在所述处理器的控制下，发送所述多组服务信息至客户端。

可选地，所述处理器还用于执行上述方法步骤401-步骤403中的全部或部分。

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

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

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