司机客户端的离线服务方法、司机客户端及相关系统与流程

本发明涉及一种司机客户端的离线服务方法、司机客户端及相关系统。

背景技术：

随着智能终端和移动互联网APP的发展，为城市的人们的出行提供了便利，如今打车软件已经非常普及，解决了城市生活中，由于出租车司机和乘客之间信息不对称导致的打车难的问题。

智能打车软件改变了传统的打车方式，用户可以通过自己的乘客客户端（例如可以是手机APP）发送自己的出发点和目的地，打车系统将其打车需求向该乘客附近一定范围内的司机客户端（可以是手机APP或者各种车载终端）进行推送，司机通过司机客户端接单后，打车系统会发送司机的联系方式等信息给乘客，直至双方联系完成订单。

但是，司机在开车服务的过程中，手机断网是不可避免的，比如进入了无信号的路段，在离线状态下，服务器端对司机客户端的操作无法进行记录，导致服务订单就没办法正常的完成，这会对司机和乘客带来很大的不便。当司机服务完成后，如果出现手机网络中断，无法与服务器交互获得账单数据的情况，导致该次服务无法成功支付费用。

技术实现要素：

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种司机客户端的离线服务方法、司机客户端及相关系统。

基于上述问题，本发明实施例提供的一种司机客户端的离线服务方法，包括：监测司机客户端与打车系统服务器之间的网络连接情况；

当网络连接中断时，缓存所述司机客户端在此期间的每个业务操作请求，并记录各业务操作请求的触发时间；

当网络连接恢复时，根据所述记录各业务操作请求的触发时间，将所缓存的业务操作请求依次上传到打车系统服务器。

可选地，所述业务操作请求包括账单确认请求，所述方法还包括：

根据车辆的实时地理位置信息，记录车辆的行驶信息；

当打车服务结束时，判断当前司机客户端与打车系统服务器之间的网络连接是否中断，当中断时，按照预设的离线算法及所述车辆的行驶信息，计算账单的费用；根据所述账单的费用，触发生成账单确认请求并缓存；当未中断时，将记录车辆的行驶信息发送给打车系统服务器。

可选地，所述预设的离线算法，通过下述方式获得：

接收所述打车系统服务器发送的订单信息以及与所述订单信息相匹配的离线算法并保存。

可选地，在计算账单的费用之后，触发生成账单确认请求并缓存之前，还包括：

接收司机客户端发送的费用调整请求，根据司机客户端输入的调整数额，调整账单的费用。

可选地，将所缓存的业务操作请求上传到打车系统服务器之后，还包括：

删除所缓存的业务操作请求。

本发明实施例提供的司机客户端，包括：监测模块，用于监测司机客户端与打车系统服务器之间的网络连接情况；

缓存模块，用于当所述检测模块监测到网络连接中断时，缓存所述司机客户端在此期间的每个业务操作请求，并记录各业务操作请求的触发时间；

上传模块，用于当所述检测模块监测到网络连接恢复时，根据所述记录各业务操作请求的触发时间，将所缓存的业务操作请求依次上传到打车系统服务器。

可选地，所述业务操作请求包括账单确认请求，所述司机客户端还包括：记录模块、判断模块和计算模块；

其中：

所述记录模块，用于根据车辆的实时地理位置信息，记录车辆的行驶信息；

所述判断模块，用于当打车服务结束时，判断当前司机客户端与打车系统服务器之间的网络连接是否中断；

所述计算模块，用于判断网络连接中断时，按照预设的离线算法及所述车辆的行驶信息，计算账单的费用；

所述缓存模块，还用于根据所述账单的费用，触发生成账单确认请求并缓存；

所述上传模块，用于判断网络连接未中断时，将记录车辆的行驶信息发送给打车系统服务器。

可选地，还包括：算法接收模块，用于接收所述打车系统服务器发送的订单信息以及与所述订单信息相匹配的离线算法并保存。

可选地，所述司机客户端还包括：

调整模块，用于在计算模块计算账单的费用之后，缓存模块中触发生成账单确认请求并缓存之前，接收司机客户端发送的费用调整请求，根据司机客户端输入的调整数额，调整账单的费用。

可选地，所述司机客户端还包括：删除模块，用于在上传模块将缓存模块所缓存的业务操作请求上传到打车系统服务器之后，删除所缓存的业务操作请求。

本发明实施例提供的一种提供打车服务的系统，包括：至少一个乘客客户端、打车系统服务器和至少一个上述司机客户端。

本发明实施例至少实现了如下技术效果：

本发明实施例提供的司机客户端的离线服务方法、司机客户端及相关系统，实时监测司机客户端与打车系统服务器之间的网络连接情况；当网络连接中断时，缓存所述司机客户端在此期间的每个业务操作请求，并记录各业务操作请求的触发时间；当网络连接恢复时，根据所述记录各业务操作请求的触发时间，将所缓存的业务操作请求依次上传到打车系统服务器。本发明实施例提供的方案可以让司机客户端在网络中断的环境下，正常显示各种状态及订单费用，在不影响司机任何操作的基础上顺利完成订单的服务，提升了司机和乘客的使用体验。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其它优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本发明实施例提供的司机客户端的离线服务方法的流程图；

图2为本发明实施例提供的计算账单的过程的流程图；

图3为本发明实施例提供的司机客户端的结构图；

图4为本发明实施例提供的打车服务的系统的结构图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

本公开实施例提供的一种司机客户端的离线服务方法，参照图1所示，具体包括以下步骤：

S11、监测司机客户端与打车系统服务器之间的网络连接情况；

S12、当网络连接中断时，缓存所述司机客户端在此期间的每个业务操作请求，并记录各业务操作请求的触发时间；

S13、当网络连接恢复时，根据所述记录各业务操作请求的触发时间，将所缓存的业务操作请求依次上传到打车系统服务器。

下面对上述步骤作进一步详细的说明。

在上述步骤S11中，打车系统服务器可以实时监测司机客户端与打车系统服务器之间的网络连接情况。

监测的方式可以有多种具体实施方式，例如，网络中的接收和发送数据可以使用SOCKET（套接字）进行实现，司机客户端通过心跳包搜索来确保与打车系统服务器是否正常连接，比如定时发心跳包给打车系统服务器，然后接收回应包，如果在反应时间内没有收到该回应包则可以认为与打车系统服务器已经断开连接。其中反应的时间可以预设，预设的时间间隔越短，监测的准确性越高，但这需要耗费一定的流量。所谓的心跳包就是客户端定时发送简单的信息给服务器端告诉它我还在而已。代码就是每隔几分钟发送一个固定信息给服务端，服务端收到后回复一个固定信息，如果客户端在预设的时间内没有收到服务端信息则视网络断开。以此来监测网络连接情况，确保连接的有效性。

在上述步骤S12中，当监测到网络连接中断时，司机客户端也可以进行业务操作，但每个业务操作都只是缓存在司机客户端，并且记录每个业务操作触发的时间，例如通过记录业务操作触发的时间来确定其触发的先后顺序；这样确保司机的所有业务操作不会中断和无效。

在上述步骤S13中，当监测到网络连接恢复时，把缓存在司机客户端的各业务操作请求，按照触发的时间先后，依次上传到打车系统服务器，以完成整个订单相关的交互流程。

本公开实施例提供的上述司机客户端的离线服务方法可以让司机在网络中断的环境下，正常显示各种状态及订单费用，在不影响司机任何操作的基础上顺利完成订单的服务。而当网络连接恢复的时候，再根据各业务的操作请求的触发时间，将司机所做的业务操作请求上传到打车系统服务器。实现了即使在断网的情况下，司机的业务操作不会无效和丢失，在再次连网后仍然可以被继续执行且有效，从而进一步保证了司机的各种业务操作不会因为断网受到影响，提升了司机和乘客的使用体验。

在一个实施例中，上述业务操作请求例如可以包括：上车确认请求、费用结算请求等，根据车辆的实时地理位置信息，记录并形成车辆的行驶信息。

当将乘客送达目的地时，司机客户端需要发送账单确认请求给服务器以接续后续支付流程，进而完成整个打车服务过程，为了保证账单确认请求的顺利生成，本发明实施例提供的上述方法，司机乘客端判断当前司机客户端与打车系统服务器之间的网络连接是否中断，当中断时，按照预设的离线算法及车辆的行驶信息，计算账单的费用；根据所述账单的费用，触发生成账单确认请求并缓存；当未中断时，将记录车辆的行驶信息发送给打车系统服务器。

上述车辆的行驶信息，例如可以包括行驶的时间、总里程、过桥费、高速费、停车费、调度费、额外收取的服务费用等。

例如，根据全球定位系统（Global Positioning System，GPS）定位存储车辆的实时地理位置信息，计算并记录车辆行驶的总里程。

司机在使用司机客户端的时候，由于GPS定位不需要网络，所以在无网络下是可以进行时间和里程的计算的。而当打车服务结束时，当没有网络连接，也可以实现账单费用的计算，同时缓存账单费用信息等，以便生成账单确认请求；当有网络连接时，将车辆行驶信息（例如根据GPS计算得到的车辆行驶里程）发送给打车系统服务器，并在打车系统服务器端，计算出账单费用信息，由打车系统服务器将计算后结果返回司机客户端进而生成账单确认请求。

在一个实施例中，上述用到的预设的离线算法，可以通过以下方式获得：在司机客户端接收打车服务订单成功时，下载了打车系统服务器的一套计算公式，该算法与服务订单信息相匹配，不同业务类型的打车服务订单，所用到的账单计算费用使用的公式可以不一样。这样在司机客户端接收打车服务订单时，还接收了与之配套的一套计算公式。该司机客户端接收到的计算公式与打车系统服务端的计算公式一致，这样保证了在网络中断状态下计算费用的结果和在有网络状态下计算费用的结果保持一致。当然，也可以由打车系统服务器预先统一下发一次算法，所有的订单都通用该算法，或者，约定部分类型的订单使用同一个算法，而另外部分类型的订单使用其他算法，本发明实施例对此不做限定。

在一个实施例中，在计算账单的费用之后，触发生成账单确认请求并缓存之前，还包括：接收司机客户端发送的费用调整请求，根据司机客户端输入的调整数额，调整账单的费用。

具体地，在账单确认之前，判断当前是否有网络连接，当在网络中断的情况下，司机可以手动调整公里数，因为显示的公里数是由服务过程中GPS踩点计算得到的，与有网络连接时相比，GPS定位和网络连接定位计算出的公里数准确性较低，所以可以允许司机对公里数进行微调。另外还有一些费用需要司机手动输入，比如高速费、停车费，这些费用是由服务过程中具体的行驶情况产生的，在有无网络连接的情况下，司机可以手动对这些数据进行输入补充。

下面通过一个完整的实施例说明计算账单的过程，参照图2所示：

S201、开始；

S202、服务结束；

S203、判断当前是否有网络；有执行S204；否执行S205；

S204、进行在线计费；如需调整费用执行S206；

S205、进行离线计费；

S206、在页面中调整相关费用数值，重新计算费用；

S207、发送账单确认请求；

在一个实施例中，将所缓存的业务操作请求上传到打车系统服务器之后，还可以执行下述步骤：删除所缓存的业务操作请求。

司机客户端通常安装在手机设备或手持移动设备上，而上述设备的存储空间有限，而司机客户端每天接单可能多达几十起，所以缓存会越来越多，给上述设备也造成一定的负荷，所以，当打车系统服务器确认司机客户端缓存，都已经上传到打车系统服务器之后，有必要删除一部分久远的缓存；上述删除命令是打车系统服务器根据司机客户端的实际情况每间隔一段时间后，自动发送给司机客户端，执行删除缓存的指令；当然司机客户端也可以手动删除缓存，但前提条件都是在上述缓存已经上传到打车系统服务器之后，才可以成功执行删除缓存指令。

基于同一发明构思，本发明实施例还提供了一种司机客户端和提供打车服务的系统，由于该客户端和系统所解决问题的原理与前述实施例一种司机客户端的离线服务方法相似，因此该客户端和系统的实施可以参见前述方法的实施，重复之处不再赘述。

下述为本发明实施例提供的司机客户端，可以用于执行上述司机客户端的离线服务方法实施例。

参照图3所示，一种司机客户端，包括：

监测模块31，用于监测司机客户端与打车系统服务器之间的网络连接情况；

缓存模块32，用于当所述检测模块监测到网络连接中断时，缓存所述司机客户端在此期间的每个业务操作请求，并记录各业务操作请求的触发时间；

上传模块33，用于当所述检测模块监测到网络连接恢复时，根据所述记录各业务操作请求的触发时间，将所缓存的业务操作请求依次上传到打车系统服务器。

在一个实施例中，上述缓存模块32中的业务操作请求包括账单确认请求，参照图3所示，上述司机客户端还包括：记录模块321、判断模块322和计算模块323；其中：

记录模块321，用于根据车辆的实时地理位置信息，记录车辆的行驶信息；

判断模块322，用于当打车服务结束时，判断当前司机客户端与打车系统服务器之间的网络连接是否中断；

计算模块323，用于判断网络连接中断时，按照预设的离线算法及所述车辆的行驶信息，计算账单的费用；

缓存模块32，还用于根据所述账单的费用，触发生成账单确认请求并缓存；

上传模块33，用于判断网络连接未中断时，将记录车辆的行驶信息发送给打车系统服务器。

在一个实施例中，上述司机客户端还包括算法接收模块324，用于接收所述打车系统服务器发送的订单信息以及与所述订单信息相匹配的离线算法并保存。

在一个实施例中，上述司机客户端还包括：调整模块325，用于在计算模块323计算账单的费用之后，缓存模块32中触发生成账单确认请求并缓存之前，接收司机客户端发送的费用调整请求，根据司机客户端输入的调整数额，调整账单的费用。

在一个实施例中，上述司机客户端还包括：删除模块326，用于在上传模块33将缓存模块32所缓存的业务操作请求上传到打车系统服务器之后，删除所缓存的业务操作请求。

本实施例还公开了一种提供打车服务的系统，参照图4所示，至少一个乘客客户端、打车系统服务器和至少一个如上述的司机客户端。

在本发明实施例提供的打车服务的系统中，司机客户端的结构、工作原理的具体实施方式可以参照本发明实施例提供的前述司机客户端的实施方式，相同之处不再赘述。

本发明实施例提供的司机客户端的离线服务方法、司机客户端及相关系统，在司机客户端该方法包括：监测司机客户端与打车系统服务器之间的网络连接情况；当网络连接中断时，缓存所述司机客户端在此期间的每个业务操作请求，并记录各业务操作请求的触发时间；当网络连接恢复时，根据所述记录各业务操作请求的触发时间，将所缓存的业务操作请求依次上传到打车系统服务器。本发明提供的方案可以让司机在网络中断的环境下，正常显示各种状态及订单费用，在不影响司机任何操作的基础上顺利完成订单的服务。而当网络连接恢复的时候，再根据各业务的操作请求的触发时间，将司机所做的业务操作请求上传到打车系统服务器。实现了即使在断网的情况下，司机的业务操作不会无效和丢失，在连网后仍然可以被继续执行且有效，从而进一步保证了司机的各种业务操作不会因为断网受到影响，提升了司机和乘客的使用体验。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器和光学存储器等）上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备（系统）、和计算机程序产品的流程图和／或方框图来描述的。应理解可由计算机程序指令实现流程图和／或方框图中的每一流程和／或方框、以及流程图和／或方框图中的流程和／或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和／或方框图一个方框或多个方框中指定的功能的步骤。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。