具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1示出了可以应用本公开实施例的示例性系统架构。

如图1所示，该系统架构可以包括终端设备101和102，网络103和服务器104。网络103用以在终端设备101、102和服务器104之间提供通信链路的介质。网络103可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端设备101和102通过网络103与服务器104交互。终端设备101和102上可以安装网约车应用的客户端或者可以展现网约车信息的客户端，在本申请中特别的是安装有乘客所使用的客户端。其他终端设备上也可以安装有司机所使用的客户端。

终端设备101和102可以是各种移动式电子设备。包括但不限于智能手机、平板电脑、笔记本电脑、可穿戴式设备、车载终端等等。本申请所提供的一种网约车信息处理装置可以设置并运行于上述服务器104中。本申请提供的另一种网约车信息处理装置可以设置并运行于上述终端设备101和102中。其可以实现成多个软件或软件模块(例如用来提供分布式服务)，也可以实现成单个软件或软件模块，在此不做具体限定。

服务器104可以是单一服务器，也可以是多个服务器构成的服务器群组。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

现有的网约车服务中，用户在查询了从起始地到目的地的代价信息，例如价格或线路时长，只能选择现在打车与否。如果因为路况等因素导致代价偏高，用户可能就放弃打车。但可能路况会在短时间内改善，用户就丧失稍后改善打车体验的机会，也抑制了网约车行业的发展。还有些情况下，在一些打车高峰期有很多用户选择现在出发并非是行程的需求，而是担心运力紧张导致打不到车，所以着急排队。这就更会造成打车高峰期的代价加大，更难以打到车。有鉴于此，本公开提供了一种新的思路，能够为用户推荐发单时刻，使得希望降低代价或者不着急现在出发的用户能够依据推荐发单时刻选择稍后再发单。下面结合实施例对本公开进行详细描述。

图2为本公开实施例提供的一种网约车信息处理方法的流程图，该方法可以在服务器端执行。如图2中所示，该方法包括以下步骤：

在201中，获取客户端发送的网约车查询条件，查询条件包括起始地和目的地信息。

在202中，依据查询条件确定查询时间区间。

在203中，针对查询时间区间内的各时刻，分别计算从各时刻出发到达目的地的代价信息。

在204中，依据从各时刻出发到达目的地的代价信息，确定满足查询条件的时刻作为推荐出发时刻。

在205中，利用推荐出发时刻，确定推荐发单时刻。

在206中，向客户端返回查询结果，该查询结果包括推荐发单时刻，或者，查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息。

由以上技术方案可以看出，本公开能够在查询时间区间内依据各时刻触发的代价信息，确定推荐发单时刻，并在查询结果中返回推荐发单时刻或进一步返回推荐发单时刻对应的代价信息。使得用户能够依据推荐发单时刻或进一步结合代价信息，选择代价较小的发单时间。第一方面避免了因用户发现当前时刻出发代价偏高而丧失打车体验。第二方面也避免了用户短时间内频繁尝试查询打车的代价信息，提高了用户效率和体验。第三方面也降低了用户的打车代价，为用户节约了成本。第四方面也能够缓解用户都集中在打车高峰期所带来的运力分配不合理的问题。第五方面用户能够一次性获取代价较小的发单时间，不必多次尝试，节约了网络资源，降低了对系统压力的影响。可谓是一举多得。

下面对上述实施例中的各步骤进行详细描述。首先结合实施例对上述步骤201即“获取客户端发送的网约车查询条件，查询条件包括起始地和目的地信息”进行详细描述。

上述网约车查询条件是来自客户端的，至少包括起始地和目的地信息。其中起始地信息可以是用户输入的信息，也可以是依据客户端当前定位得到的。目的地信息通常是用户输入的信息。在本实施例中涉及的“用户”指的是预使用网约车的乘客。

更进一步地，在本公开中上述查询条件还可以进一步包括查询时间区间信息，或者，进一步包括代价范围。

查询时间区间通常是用户设置的未来的一段时间，例如未来一个小时内，未来半个小时内，未来两个小时内等等，根据用户的发单需求来设置。反映了用户能够接受在多久时间内打车。如果用户对行程不着急可以设置一个较长的时间区间。如果用户对行程着急可以设置一个较短的时间区间。

代价范围可以是用户设置的能够接受的打车代价。可以体现为价格范围，例如60元以内。也可以体现为线路时长即耗时范围，例如40分钟内。等等。

上述查询时间区间信息和代价范围的具体作用将在后续步骤中体现。

下面结合实施例对上述步骤202即“依据查询条件确定查询时间区间”进行详细描述。

若查询条件中包含用户设置的查询时间区间，则在本步骤中直接采用用户设置的查询时间区间，即从查询条件中确定查询时间区间。

若查询条件中不包含用户设置的查询时间区间，则在本步骤中可以采用默认设置的查询时间区间，例如默认设置未来一个小时作为查询时间区间。

下面结合实施例对上述步骤203即“针对查询时间区间内的各时刻，分别计算从各时刻出发到达目的地的代价信息”进行详细描述。

在本公开中可以依据预设的粒度将查询时间区间划分为各个时刻。该粒度可以是设置的固定值，也可以是依据查询时间区间的长度对应的粒度。例如，如果用户设置的查询时间区间是半个小时，那么粒度为1分钟。如果用户设置的查询时间区间是24小时，那么粒度为10分钟。

作为其中一种实现方式，可以针对查询时间区间内的各时刻分别执行以下处理，从而得到各时刻出发到达目的地的代价信息：

对时刻t_i而言，基于对时刻t_i的路况预估结果，对起始地和目的地进行路线规划，得到该时刻t_i出发到达目的地的预估时长信息作为从该时刻t_i出发到达目的地的代价信息。

也就是说，首先从起始地到目的地进行路线规划，路线规划过程中会结合路况预测方法，基于对该时刻t_i的路况进行预测，基于路况预测结果进行路线规划并得到该时刻t_i出发到达目的地的预估时长。其中，路线规划和路况预测方法可以采用任何可实现的方式，本公开对此并不加以限制。

作为另一种实现方式，可以针对查询时间区间内的各时刻分别执行以下处理，从而得到各时刻出发到达目的地的代价信息：

对时刻t_i而言，基于对时刻t_i的路况预估结果，对起始地和目的地进行路线规划，得到该时刻t_i出发到达目的地的路线长度和预估时长，利用网约车计价规则进行价格计算，将计算得到的价格作为从该时刻出发到达目的地的代价信息。

其中，网约车计价规则通常是比较固定的，综合考虑了司机、乘客和企业的各方利益。不同的地区或网约车平台会有一些差异，具体的计价规则可以从网约车平台预先获取并进行记录。

网约车计价规则大多是由三方面组成的：起步价、里程和时长。一般来说，起步价包含了特定的里程和时长，比如3公里和10分钟。而当驾驶里程超过3公里就会按照每公里一定费率进行累加。当驾驶时长超过了10分钟，则会按照每分钟一定费率进行累加。最后加和的结果则是计算得到的价格。其中由于驾驶时长和路况相关，不同时刻的路况各不相同，因此不同时刻出发相同起始点和目的地的价格可能是不一样的。本申请对于网约车计价规则的具体内容并不加以限制，在此仅为了方便理解而举例说明。

下面结合实施例对上述步骤204即“依据从各时刻出发到达目的地的代价信息，确定满足查询条件的时刻作为推荐出发时刻”进行详细描述。

在本步骤中，如果查询条件中包括用户设置的查询时间区间，则可以将该查询时间区间内对应代价最小的N个时刻作为推荐出发时刻。

由于在上述步骤中已经可以确定出查询时间区间中各时刻对应的代价信息，因此可以优选代价小的时刻作为推荐出发时刻。上述N可以是预设的正整数。

如果查询条件中包括用户设置的价格范围，则可以将查询时间区间内对应代价符合用户设置的价格范围的时刻作为推荐出发时刻。例如，用户设置了40元以内的价格范围，那么可以从各时刻对应的价格中筛选40元以下的时刻。

需要说明的是，本步骤中确定出的推荐出发时刻可以是一个，也可以是超过一个的数量。

下面对上述实施例中的各步骤进行详细描述。首先结合实施例对上述步骤205即“利用推荐出发时刻，确定推荐发单时刻”进行详细描述。

由于推荐出发时刻指的是推荐用户实际出发的时刻，即从路线起始点出发的时刻。但对于用户而言，更直观和更需要的是什么时刻发单，因此，需要确定推荐发单时刻。

作为一种可实现的方式，本步骤的具体实现过程可以包括以下步骤：

步骤S1：利用推荐出发时刻对网约车接驾时间进行预估，得到预估接单时刻。

步骤S2：利用预估接单时刻对接单时间进行预估，得到推荐发单时刻。

从用户发单到从路线起始点出发，中间还会存在网约车司机接单和接驾的过程。所谓网约车司机接单指的是用户发单后，网约车平台将用户的订单下发给匹配的网约车司机，再由网约车司机接受订单的过程。所谓接驾指的是网约车司机接受订单后，从司机所在位置到达乘客所在位置的过程。

上述步骤S1中是利用推荐出发时刻倒推需要的接驾时间，从而得到预估接单时刻。具体过程如图3中所示，包括以下步骤：

步骤301：获取预设的初始第一时长。

初始第一时长可以是一个预设的时间单元，例如1分钟。

步骤302：确定推荐出发时刻之前第一时长的时刻作为候选接单时刻。

假设推荐出发时刻表示为T_d，推荐出发时刻之前第一时长的时刻表示为T_d-n，此时候选接单时刻为T_d-n。

步骤303：预估候选接单时刻所需的接驾时长。

在本步骤中对候选接单时刻T_d-n所需的接驾时长(表示为T_pickup)进行预估时，可以使用接驾时长预估模型。具体实现将在后续进行详细描述。

步骤304：判断预估的接驾时长是否小于或等于第一时长，如果是，执行步骤305；否则，执行步骤306。

判断T_pickup是否小于或等于当前的第一时长，也就是说，判断是否T_d-n+T_pickup≤T_d。

步骤305：确定候选接单时刻为预估接单时刻，结束当前预估流程。

这种情况下，当前的T_d-n就是预估接单时刻T_t。

步骤306：延长第一时长，重新转至执行步骤302。

这种情况下，可以延长第一时长，例如延长1分钟，第一时长变为2分钟，转至步骤302，此时的T_d-n就是T_d之前2分钟的时刻。依次类推，执行上述步骤，直至确定出预估接单时刻。

上述步骤S2中利用预估接单时刻倒推接单时间，从而得到推荐发单时刻，具体过程如图4中所示，包括以下步骤：

步骤401：获取预设的初始第二时长。

与初始第一时长类似地，初始第二时长可以是一个预设的时间单元，例如1分钟。

步骤402：确定预估接单时刻之前第二时长的时刻作为候选发单时刻。

由于预估接单时刻为T_t，预估接单时刻之前第二时长的时刻表示为T_t-m，此时候选发单时刻为T_t-m。

步骤403：预估所候选发单时刻所需的接单时长。

在本步骤中对候选发单时刻T_t-m所需的接单时长(表示为T_order)进行预估时，可以使用接单时长预估模型。具体实现将在后续进行详细描述。

步骤404：判断预估的接单时长是否小于或等于第二时长，如果是，执行步骤405；否则执行步骤406。

判断T_order是否小于或等于当前的第二时长，也就是说，判断是否T_t-m+T_order≤T_t。

步骤405：确定候选发单时刻为推荐发单时刻，结束当前预估流程。

这种情况下，当前的T_t-m就是推荐发单时刻T_c。

步骤406：延长第二时长，重新转至步骤402。

这种情况下，可以延长第二时长，例如延长1分钟，第二时长变为2分钟，转至步骤402，此时的T_t-m就是T_t之前2分钟的时刻。依次类推，执行上述步骤，直至确定出推荐发单时刻。

下面结合实施例对上述接驾时长预估模型和接单时长预估模型进行详细描述。

上述接驾时长预估模型可以采用回归模型，该模型能够在候选接单时刻T_d-n输入时，输出对应的接驾时长T_pickup。

作为一种优选的实施方式，接驾时长预估模型的结构可以如图5中所示，主要包括嵌入层和全连接层。嵌入层主要用于对输入接驾时长预估模型的各特征进行嵌入处理，分别得到各特征的向量表示。各特征的向量表示进行诸如拼接等融合处理后输入全连接层，由全连接层映射得到接驾时长。

其中，输入接驾时长预估模型的特征除了候选接单时刻T_d-n之外，还包括用户的位置、目的地、推荐出发时刻的代价信息、路线长度、天气信息和路况信息中的至少一种，在图5中以包括这些所有信息为例。其中的代价信息以包括价格和预估时长为例。

上述接单时长预估模型也可以用回归模型，该模型能够在候选发单时刻T_t-m输入时，输出对应的接单时长T_order。

作为一种优选的实施方式，接单时长预估模型的结构可以如图6中所示，主要包括嵌入层和全连接层。嵌入层主要用于对输入接单时长预估模型的各特征进行嵌入处理，分别得到各特征的向量表示。各特征的向量表示进行诸如拼接等融合处理后输入全连接层，由全连接层映射得到接单时长。

其中，输入接单时长预估模型的特征除了候选发单时刻T_t-m之外，还可以包括用户的位置、目的地、推荐出发时刻的代价信息、路线长度和天气信息中的至少一种，在图6中以包括这些所有信息为例。其中的代价信息以包括价格和预估时长为例。

在上述接驾时长预估模型和接单时长预估模型中，用户的位置和目的地进行嵌入处理时，采用的特征可以是POI信息。POI信息可以包括POI名称、属性、坐标信息等。嵌入处理实际上是对POI信息进行语义化表示。其中POI名称中由于可能带有POI热度、功能的特性，因此可以将POI名称进行切词后再进行向量化表示。POI的属性信息重点采用类别，例如公交枢纽、住宅区等等，可以采用离散化的数值表示。坐标信息描述的是空间热度信息，因此可以将整个区域进行区格划分后进行序列化编号，将坐标所在区格的编号作为特征表示。

关于推荐出发时刻、候选发单时刻这类时间特征，可以采用连续值表示。例如对于特定时刻可以包括小时值x，分钟值12，秒钟值z，可以定义两个特征和来表示，这种表示可以让取值范围局限于[-1,1]。

对于时间特征，还可以采用是否为工作日、星期几等离散信息表示。

价格、预估时长、路线长度都是离散值，可以进行归一化处理后直接输入模型。

天气特征可以采用onehot(独热)离散表示，对晴、阴、雾、雨(小雨、中雨、大雨、暴雨)、雪(小雨、中雨、大雨、暴雨)等天气进行表示和区分。

路况特征是在接驾时长预估模型中引入的，因为其对于接驾时长的影响较高，且附近路况特征在其他特征中的表达不足。用户附近的路况特征主要希望能够刻画出一定物理范围内的车流量密度。因此可以采用诸如CNN(Convolutional Neural Networks，卷积神经网络)、GCN(Graph Convolutional Network，图卷积神经网络)等神经网络进行编码。例如可以以用户的位置为中心区域向外扩展预设的范围，例如2km，得到一个4km*4km的正方形区域，然后将这个区域划分为16个1km*1km的小区域。区域内的车流量特征可以采用道路的拥堵系数加权道路长度的平均值来表示，例如：

其中，I_x表示区域内的车流量特征，l_i表示第i个小区域内的道路长度，j_i表示第i个小区域的拥堵系数。

在预先训练上述接驾时长预估模型时，采用的训练数据可以从网约车平台的日志中获取。网约车平台记录有司机接单到乘客上车的时长即接驾时长，从这部分数据中抽取乘客的位置、目的地、价格、路线长度、天气信息、路况信息和司机的接单时刻作为输入，将实际接驾时长作为目标输出，训练回归模型得到接驾时长预估模型。也就是说，在设计损失函数loss时，最小化接驾时长预估模型的输出与实际接驾时长的差值绝对值。

在预先训练上述接单时长预估模型时，采用的训练数据也可以从网约车平台的日志中获取。网约车平台记录有乘客发单到司机接单的时长，即接单时长。从这部分数据中抽取乘客的位置、目的地、价格、路线长度、天气信息和乘客发单时刻作为输入，将实际接单时长作为目标输出，训练回归模型得到接单时长预估模型。也就是说，在设计loss时，最小化接单时长预估模型的输出与实际接单时长的差值绝对值。

上述的接驾时长预估模型和接单时长预估模型可以分别训练，也可以采用多任务学习的方式训练。

在进行多任务学习的方式训练时，如图7中所示，用户的位置、目的地、预估时价格、路线长度和天气信息作为共享特征，其对应的嵌入处理部分为共享层。路况特征是接驾时长预估模型独有的特征。发单时刻是接单时长预估模型的输入，接单模型输出接单时长后，接单时长与发单时刻相结合得到的就是接单时刻，其作为接驾时长预估模型的输入。在进行多任务训练时，每一轮迭代可以随机选择一个任务，计算该任务的损失函数后，采用梯度下降法更新该任务所对应的模型参数。或者，也可以采用联合训练的方式，即仅采用接驾任务的损失函数，采用梯度下降法更新所有模型参数。持续迭代直到满足预设的训练结束条件，例如损失函数收敛，或者迭代次数达到预设的迭代次数阈值，等等。

图8为本公开实施例提供的另一种网约车信息处理方法的流程图，该方法可以在客户端执行。如图8中所示，该方法包括以下步骤：

在801中，获取用户输入的网约车查询条件，该查询条件可以包括起始地和目的地信息。

在本公开实施例中，客户端可以是网约车应用的客户端，也可以是集成了网约车功能的其他应用的客户端，例如集成了网约车功能的地图类应用的客户端。

客户端可以向用户提供第一界面，供用户输入打车的起始地和目的地信息。

更进一步地，还可以向用户提供设置查询时间区间或者代价范围的组件。例如可以在第一界面上提供输入框供用户输入查询时间区间或代价范围。再例如可以在第一界面上提供诸如下拉框等选项供用户选择输入查询时间区间或代价范围。其中代价范围可以是价格范围，也可以是线路(即打车行程)的时长范围。

在802中，将查询条件发送给服务器端，并获取服务器端返回的查询结果，查询结果包括推荐发单时刻，或者查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息。

客户端将上述查询条件发送给服务器端后，由服务器端执行图2所示实施例中的流程，生成查询结果后返回给客户端。服务器端执行的处理在此不做赘述。

其中，推荐发单时刻对应的代价信息可以包括该时刻出发到达目的地的预估时长信息，或者，该时刻出发到达目的地的价格信息。

在803中，展示查询结果。

客户端可以向用户提供第二界面，在该第二界面上展示查询结果。至少在该第二界面上展示推荐发单时刻，该推荐发单时刻可以是一个，也可以是多个。在展现推荐发单时刻时，可以仅展示推荐发单时刻，也可以展示查询时间区间中的各时刻，但突出显示其中的推荐发单时刻。

在展示推荐发单时刻的同时，可以展示该推荐发单时刻对应的代价信息。可以仅提供一种代价信息，也可以提供多种代价信息供用户选择。

图9是本公开实施例提供的一种展示查询结果界面的实例图，如图9中所示，可以提供两种代价信息供用户选择：按照花费(即价格)最少以及按照时间(即线路的预估时长)最少。用户选择花费最少时，向用户展现花费最少的推荐发单时刻。也可以提供多个网约车平台供用户选择查看。图9中以一个小时内的查询时间区间为例，推荐发单时刻突出显示，即16:00的时刻，并展示其对应的花费为27元。

更进一步地，可以在上述第二界面上展现设置出发时间的组件，例如图9中所示的“设置出发时间”组件。获取到该组件被触发的事件后，记录用户设置的出发时间。在用户设置的出发时间到达或者在所述用户设置的出发时间之前预设时长，向用户展示提醒消息。

更进一步地，可以在上述第二界面上展现预约发单的组件，例如图9中所示的“预约打车”组件。获取到该组件被触发的事件后，记录用户设置的发单时间；在到达用户设置的发单时间时，发送从起始地到目的地的网约车订单。

以上是对本公开所提供方法进行的详细描述，下面结合实施例对本公开提供的装置进行详细描述。

图10为本公开实施例提供的一种网约车信息处理装置结构图，设置于服务器端。该装置可以为位于服务器端的应用，或者还可以为位于服务器端的应用中的插件或软件开发工具包(Software Development Kit，SDK)等功能单元。如图10中所示，该装置1000可以包括：条件接收单元1010、区间确定单元1020、代价计算单元1030、第一推荐单元1040、第二推荐单元1050和结果返回单元1060。其中各组成单元的主要功能如下：

条件接收单元1010，用于获取客户端发送的网约车查询条件，查询条件包括起始地和目的地信息。

区间确定单元1020，用于依据查询条件确定查询时间区间。

代价计算单元1030，用于针对查询时间区间内的各时刻，分别计算从各时刻出发到达目的地的代价信息。

第一推荐单元1040，用于依据从各时刻出发到达目的地的代价信息，确定满足查询条件的时刻作为推荐出发时刻。

第二推荐单元1050，用于利用推荐出发时刻，确定推荐发单时刻。

结果返回单元1060，用于向客户端返回查询结果，查询结果包括推荐发单时刻，或者，查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息。

作为其中一种实现方式，查询条件还包括查询时间区间，第一推荐单元1040具体用于将查询时间区间内对应代价最小的N个时刻作为推荐出发时刻，N为预设的正整数。

作为另一种实现方式，查询条件还包括代价范围，第一推荐单元1040具体用于将查询时间区间内对应代价符合用户设置的代价范围的时刻作为推荐出发时刻。

其中，区间确定单元1020具体用于：若查询条件包含用户设置的查询时间区间，则采用用户设置的查询时间区间；否则，采用默认设置的查询时间区间。

其中，代价计算单元1030具体用于针对各时刻分别执行：

基于对该时刻的路况预估结果，对起始地和目的地进行路线规划，得到该时刻出发到达目的地的预估时长信息作为从该时刻出发到达目的地的代价信息；或者，

基于对该时刻的路况预估结果，对起始地和目的地进行路线规划，得到该时刻出发到达目的地的路线长度和预估时长，利用网约车计价规则进行价格计算，将计算得到的价格作为从该时刻出发到达目的地的代价信息。

具体地，第二推荐单元1050可以包括：第一预估子单元1051和第二预估子单元1052。

第一预估子单元1051，用于利用推荐出发时刻对网约车接驾时间进行预估，得到预估接单时刻；

第二预估子单元1052，用于利用预估接单时刻对接单时间进行预估，得到推荐发单时刻。

其中，第一预估子单元1051具体用于：

按照预设的初始第一时长，确定推荐出发时刻之前第一时长的时刻作为候选接单时刻；

预估候选接单时刻所需的接驾时长；

若预估的接驾时长小于或等于第一时长，则确定候选接单时刻为预估接单时刻，否则，延长第一时长，重新转至确定推荐出发时刻之前第一时长的时刻作为候选接单时刻的操作。

作为一种优选的实施方式，第一预估子单元1051在预估候选接单时刻所需的接驾时长时，具体执行：将用户的位置、目的地、代价信息、路线长度、天气信息和路况信息中的至少一种以及候选接单时刻输入接驾时长预估模型，得到候选接单时刻所需的接驾时长。

其中，第二预估子单元1052具体用于：

按照预设的初始第二时长，确定预估接单时刻之前第二时长的时刻作为候选发单时刻；

预估候选发单时刻所需的接单时长；

若预估的接单时长小于或等于第二时长，则确定候选发单时刻为推荐发单时刻，否则，延长第二时长，重新转至确定预估接单时刻之前第二时长的时刻作为候选发单时刻的操作。

作为一种优选的实施方式，第二预估子单元1052在预估候选发单时刻所需的接单时长时，具体执行：将用户的位置、目的地、代价信息、路线长度和天气信息中的至少一种以及候选发单时刻输入接单时长预估模型，得到候选发单时刻所需的接单时长。

图11为本公开实施例提供的另一种网约车信息处理装置的结构示意图，设置于终端设备。该装置可以为位于终端设备的应用，或者还可以为位于终端设备的应用中的插件或软件开发工具包(Software Development Kit，SDK)等功能单元。如图11中所示，该装置可以包括：条件获取单元1101、服务端交互单元1102和结果展示单元1103，还可以进一步包括第一组件响应单元1104和第二组件响应单元1105。其中各组成单元的主要功能如下：

条件获取单元1101，用于获取用户输入的网约车查询条件，查询条件包括起始地和目的地信息；

服务端交互单元1102，用于将查询条件发送给服务器端，并获取服务器端返回的查询结果，查询结果包括推荐发单时刻，或者查询结果包括推荐发单时刻和推荐发单时刻对应的代价信息；

结果展示单元1103，用于展示查询结果。

其中，推荐发单时刻对应的代价信息可以包括：该时刻出发到达目的地的预估时长信息，或者，该时刻出发到达目的地的价格信息。

更进一步地，结果展示单元1103，还可以用于在界面上展现设置出发时间的组件。

第一组件响应单元1104，用于获取到组件被触发的事件后，记录用户设置的出发时间；在用户设置的出发时间到达或者在用户设置的出发时间之前预设时长，触发所述结果展示单元1103向用户展示提醒消息。

更进一步地，结果展示单元1103，还用于在界面上展现预约发单的组件。

第二组件响应单元1105，用于获取到组件被触发的事件后，记录用户设置的发单时间；在到达用户设置的发单时间时，通过所述服务端交互单元1102发送从起始地到目的地的网约车订单。

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

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

如图12所示，是根据本公开实施例的网约车信息处理方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图12所示，设备1200包括计算单元1201，其可以根据存储在只读存储器(ROM)1202中的计算机程序或者从存储单元1208加载到随机访问存储器(RAM)1203中的计算机程序，来执行各种适当的动作和处理。在RAM 1203中，还可存储设备1200操作所需的各种程序和数据。计算单元1201、ROM 1202以及RAM 1203通过总线1204彼此相连。输入/输出(I/O)接口1205也连接至总线1204。

设备1200中的多个部件连接至I/O接口1205，包括：输入单元1206，例如键盘、鼠标等；输出单元1207，例如各种类型的显示器、扬声器等；存储单元1208，例如磁盘、光盘等；以及通信单元1209，例如网卡、调制解调器、无线通信收发机等。通信单元1209允许设备1200通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1201可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1201的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1201执行上文所描述的各个方法和处理，例如网约车信息处理方法。例如，在一些实施例中，网约车信息处理方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1208。

在一些实施例中，计算机程序的部分或者全部可以经由ROM 802和/或通信单元1209而被载入和/或安装到设备1200上。当计算机程序加载到RAM 1203并由计算单元1201执行时，可以执行上文描述的网约车信息处理方法的一个或多个步骤。备选地，在其他实施例中，计算单元1201可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行网约车信息处理方法。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控30制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决传统物理主机与虚拟专用服务器(VPs，Ⅵirtual Private Server)服务中存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。