CN115150378A - 出行服务方法及装置、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请公开一种出行服务方法、出行服务装置、电子设备及非易失性计算机可读存储介质。出行服务方法包括：确定当前所处的应用场景，确定与应用场景对应的服务集合；根据出行信息、当前时间和当前位置确定触发事件；在应用场景下检测到触发事件的情况下，确定服务集合中对应于触发事件的目标服务；确定目标服务的初始调用信息，根据初始调用信息确定目标调用信息，目标调用信息与运行目标服务的电子设备匹配；根据目标调用信息运行目标服务。本申请实施方式的出行服务方法、出行服务装置、电子设备及非易失性计算机可读存储介质方便用户快速实现意图，用户体验较好，且目标服务能够实现跨平台运行，扩展了电子设备的使用场景。

Description

出行服务方法及装置、电子设备及计算机可读存储介质

技术领域

本申请涉及电子技术领域，更具体而言，涉及一种出行服务方法、出行服务装置、电子设备及 非易失性计算机可读存储介质。

背景技术

目前，在用户出行时，需自主启动电子设备中多个应用程序实现整个旅途，如用户要使用电子 设备实现某个功能，一般需要主动进行交互(如操作触控屏或者语音等)，用户操作较为繁琐，用 户体验差。

发明内容

本申请实施方式提供一种出行服务方法、出行服务装置、电子设备及非易失性计算机可读存储 介质。

本申请实施方式的出行服务方法包括确定当前所处的应用场景，确定与应用场景对应的服务集 合；根据出行信息、当前时间和当前位置确定触发事件；在应用场景下检测到触发事件的情况下， 确定服务集合中对应于触发事件的目标服务；确定目标服务的初始调用信息，根据初始调用信息确 定目标调用信息，目标调用信息与运行目标服务的电子设备匹配；根据目标调用信息运行目标服务。

本申请实施方式的出行服务装置包括场景感知模块、服务治理模块和服务运行模块。所述场景 感知模块用于确定当前所处的应用场景，确定与所述应用场景对应的服务集合。所述服务治理模块 用于根据出行信息、当前时间和当前位置确定触发事件；在所述应用场景下检测到触发事件的情况 下，确定所述服务集合中对应于所述触发事件的目标服务；确定所述目标服务的初始调用信息，根 据所述初始调用信息确定目标调用信息，所述目标调用信息与运行所述目标服务的电子设备匹配； 及所述服务运行模块用于根据所述目标调用信息运行所述目标服务。

本申请实施方式的电子设备包括处理器。所述处理器用于确定当前所处的应用场景，确定与所 述应用场景对应的服务集合；根据出行信息、当前时间和当前位置确定触发事件；在所述应用场景 下检测到所述触发事件的情况下，确定所述服务集合中对应于所述触发事件的目标服务；确定所述 目标服务的初始调用信息，根据所述初始调用信息确定目标调用信息，所述目标调用信息与运行所 述目标服务的电子设备匹配；根据所述目标调用信息运行所述目标服务。

本申请实施方式的非易失性计算机可读存储介质包含计算机程序，当所述计算机程序被一个或 多个处理器执行时，使得所述处理器执行如下出行服务方法：确定当前所处的应用场景，确定与所 述应用场景对应的服务集合；根据出行信息、当前时间和当前位置确定触发事件；在所述应用场景 下检测到所述触发事件的情况下，确定所述服务集合中对应于所述触发事件的目标服务；确定所述 目标服务的初始调用信息，根据所述初始调用信息确定目标调用信息，所述目标调用信息与运行所 述目标服务的电子设备匹配；根据所述目标调用信息运行所述目标服务。

本申请实施方式的出行服务方法、出行服务装置、电子设备及非易失性计算机可读存储介质通 过出行信息、当前时间和当前位置来确定触发事件，以获取符合用户意图的服务，并启动、运行与 触发事件匹配的服务，从而可无需用户进行交互操作，通过预测用户意图，方便用户快速实现意图， 用户体验较好。此外，通过确定当前所处的应用场景，从而确定与应用场景对应的服务集合，在应 用场景下检测到触发事件的情况下，在服务集合中确定响应触发事件的目标服务，从而通过确定应 用场景并检测触发事件，快速确定对应的目标服务并运行，减少了用户查找目标服务的时间成本， 有利于提高用户体验。且可以理解，不同平台(如安卓平台、服务器平台等)的服务的类型是不同 的，如在安卓平台的服务在服务器平台无法正常运行，因此，本申请实施方式将目标服务的初始调 用信息转换为与目标服务匹配目标调用信息后，即可使得目标服务能够在电子设备稳定地运行。如 此，目标服务能够实现跨平台运行，扩展了电子设备的使用场景。

本申请的实施方式的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得 明显，或通过本申请的实施方式的实践了解到。

附图说明

本申请的上述和/或附加的方面和优点从结合下面附图对实施方式的描述中将变得明显和容易 理解，其中：

图1是本申请某些实施方式的出行服务方法的流程示意图；

图2是本申请某些实施方式的出行服务装置的示意图；

图3是本申请某些实施方式的电子设备的平面示意图；

图4是本申请某些实施方式的应用和服务的关系示意图；

图5是本申请某些实施方式的电子设备和的手表的连接示意图；

图6和图7是本申请某些实施方式的出行服务方法的流程示意图；

图8是本申请某些实施方式的出行服务方法的场景示意图；

图9是本申请某些实施方式的出行服务方法的流程示意图；

图10是本申请某些实施方式的出行服务方法的场景示意图；

图11至图16是本申请某些实施方式的出行服务方法的流程示意图；

图17至图19是本申请某些实施方式的出行服务方法的场景示意图；

图20和图21是本申请某些实施方式的出行服务方法的流程示意图；

图22和图23是本申请某些实施方式的服务调度方法的场景示意图；

图24是本申请某些实施方式的出行服务方法的流程示意图；

图25是本申请某些实施方式的应用脚本的结构示意图；

图26是本申请某些实施方式的服务调度方法的原理示意图；

图27是本申请某些实施方式的服务调度方法的场景示意图；

图28是本申请某些实施方式的服务调度方法的流程示意图；

图29和图30是本申请某些实施方式的服务调度方法的原理示意图；

图31至图34是本申请某些实施方式的服务调度方法的流程示意图；

图35是本申请某些实施方式的服务调度方法的场景示意图；

图36是本申请某些实施方式的服务调度方法的流程示意图；

图37是本申请某些实施方式的服务调度方法的原理示意图；

图38和图39是本申请某些实施方式的服务调度方法的流程示意图；

图40是本申请某些实施方式的服务调度方法的场景示意图；

图41是本申请某些实施方式的服务调度系统的结构示意图；

图42是本申请某些实施方式的服务调度方法的原理示意图；

图43是本申请某些实施方式的非易失性计算机可读存储介质和处理器的连接状态示意图。

具体实施方式

下面详细描述本申请的实施方式，实施方式的示例在附图中示出，其中，相同或类似的标号自 始至终表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施方式是 示例性的，仅用于解释本申请的实施方式，而不能理解为对本申请的实施方式的限制。

请参阅图1，本申请实施方式提供一种出行服务方法。该出行服务方法包括步骤：

01：确定当前所处的应用场景，确定与应用场景对应的服务集合；

02：根据出行信息、当前时间和当前位置确定触发事件；

03：在应用场景下检测到触发事件的情况下，确定服务集合中对应于触发事件的目标服务；

04：确定目标服务的初始调用信息，根据初始调用信息确定目标调用信息，目标调用信息与运 行目标服务的电子设备匹配；及

05：根据目标调用信息运行目标服务。

请参阅图2，本申请实施方式提供一种出行服务装置10。出行服务装置10包括场景感知模块 11、服务治理模块12和服务运行模块13。本申请实施方式的出行服务方法可应用于出行服务装置 10。其中，场景感知模块11用于执行步骤01，服务治理模块12用于执行步骤02、步骤03和步骤04，服务运行模块13用于执行步骤05。

请参阅图3，本申请实施方式还提供一种电子设备100。电子设备100包括处理器20。本申请 实施方式的出行服务方法可应用于电子设备100。处理器20用于执行步骤01、步骤02、步骤03、 步骤04和步骤05。

其中，电子设备100包括有壳体30。电子设备100可以是手机、平板电脑、显示设备、笔记本 电脑、柜员机、闸机、智能手表500、头显设备、游戏机等。如图3所示，本申请实施方式以电子 设备100是手机为例进行说明，可以理解，电子设备100的具体形式并不限于手机。壳体30还可 用于安装电子设备100的显示装置、成像装置、供电装置、通信装置等功能模块，以使壳体30为 功能模块提供防尘、防摔、防水等保护。

具体地，出行服务装置10可设置在电子设备100中，或者，出行服务装置10可设置在云端的 服务器200中，或者，出行服务装置10可同时设置在电子设备100和服务器200中。

例如，处理器20包括在电子设备100的第一处理器21和服务器200的第二处理器22。第一处 理器21或第二处理器21可执行步骤01至步骤05。或者，第一处理器21用于执行步骤01和步骤 02，第二处理器22用于执行步骤03和步骤05，第一处理器21用于执行步骤05等。

场景感知模块11可确定当前所处的应用场景。

应用场景可以是电子设备100当前所处的使用场景，可获取交互信息，然后根据交互信息确定 使用场景。例如，使用场景可根据电子设备100的交互信息确定。根据当前电子设备1000或与当 前电子设备100通信连接的其他电子设备100(如手机为当前电子设备100，车辆为其他电子设备 100)的摄像头40识别到的图像(或根据全球定位系统(GlobalPositioning System，GPS)检测的位置 信息)确定的使用场景为商场，则确定应用场景为商场场景；若确定的使用场景为地铁，则确定应 用场景为地铁场景。或者，如根据电子设备100接收到用户的输入，以确定使用场景，如用户的手 势输入、触控输入、语音输入等满足预设条件时，确定对应的使用场景，如手势为双指叩击手势， 确定使用场景为跨端截屏场景。

例如，场景感知模块11可根据电子设备100的位置信息(如手机的GPS信息或车辆的GPS信 息)，来确定当前所处的应用场景，如位置信息表示电子设备100处于地下车库时，即可确定应用 场景为车库。可以理解，不同的应用场景对应不同的服务集合，例如车库场景，一般存在“车位导 航”、“车辆管理”等服务，对于地铁场景，一般存在“乘车码”、“到站提示”等服务，从而根据应 用场景来确定服务集合。

服务，是一个技术上的概念。当某个功能实体，对外提供一个可被调用的接口，支持传入参数、 执行功能及返回结果。则这个可被调用的接口，就是一个服务。

提供上述接口的实体称之为服务提供者。一个服务提供者可以对外暴露多个服务。服务提供者 的实体类型不限。

服务可以是安卓UI服务、感知服务、云端服务(如云端的软件即服务(Software asa Service， SaaS))、语音服务、系统化服务(如安卓应用)、第三方服务(如谷歌浏览器插件)等。

例如，WPS OFFICE中的插件通过服务网关暴露给电子设备100，电子设备100通过WPS的服 务网关调用WPS中的插件，从而实现对应的服务，如插入图片服务、插入文字服务等。

服务作为应用运行过程中的最小单元，用于实现特定任务。比如，车位导航服务实现导航功能、 车辆管理服务用于实现车辆锁定/解锁、乘车码服务用于实现弹出乘车码功能、到站提示服务用于实 现提示用户到站的功能、截屏服务用于实现设备截屏功能、投屏服务用于实现设备间的显示画面投 屏等等。例如，地图应用则包括了导航服务和到站提醒服务等。

应用运行过程中调用的服务可以为当前设备上的服务，也可以是其他设备上的服务。比如，应 用运行过程中，可以通过调用其他设备上的截屏服务，获取其他设备的设备截屏，并通过调用图片 显示服务，对其他设备的设备截屏进行显示。

请参阅图4，应用可以看作是由服务构成的集合(如图4中的应用1至应用3)，用于通过服 务之间的调用实现特定的业务逻辑。不同于传统应用只能运行在特定操作系统上，本申请的应用(如 图4中的应用3)的服务可以是不同操作系统上的服务，即应用支持异构操作系统，可以实现跨平 台运行。

不同于传统应用安装过程中，需要将运行过程中使用到的所有服务预先安装在本地，本申请的 应用中的服务支持动态部署，即在运行过程基于当前设备所执行的业务逻辑，将业务逻辑对应的服 务动态部署至当前设备。相应的，当通过多个设备实现同一应用的功能时，由于不同设备的业务逻 辑可能不同，因此不同设备部署的服务也可能存在差异，即应用中的服务具有差分部署的特性。

可以理解，应用场景对应的服务集合可以是预设的，也可以是基于用户日常在不同应用场景下 所使用的服务的使用次数及使用时长来确定。例如，在每次进出地铁场景时，用户都使用了乘车码 服务，则可将乘车码服务作为地铁场景对应的服务集合中的一个。

在确定所处的应用场景后，可在当前应用场景下检测触发事件，从而确定服务集合中，对应于 触发事件的目标服务。

处理器20可根据电子设备100中的应用程序(Application，APP)的订票信息，以获取出行信 息。其中，出行信息可包括出行时间、到站时间、目的地、出行抵达时间、出发地位置、到站位置 等信息。需要说明的是，目的地并不代表订票信息中的到站位置，同样的，出行抵达时间并不代表 订票信息中的到站时间。处理器20可根据订票信息以得到到站时间，并根据目的地和到站位置之 间的距离，以预估出行抵达时间。目的地可根据为用户预先选定好的位置，即位于到站位置对应的 城市中用户预先选定的位置。

此外，在处理器20获取出行信息时，可以是处理器20根据订票信息确定出行信息，又可以是 处理器20根据行程信息确定出行信息，还可以是处理器20根据订票信息和行程信息确定出行信息。

例如，处理器20可根据订票信息，可获取车票上的出发地、到站位置、出发时间、到站时间 等信息，由此则可确定出行信息。又例如，用户可在电子设备100的行程计划中提前预定行程，即 填写目的地，出发地、出行日期等信息，由此，处理器20则可为用户进行订票服务，以预定与行 程信息对应的车票，由此，处理器20则可确定出行信息。

还例如，处理器20可根据用户在电子设备100的形成计划，以提前确定用户前往的目的地的 出发类型，如回家、出差、旅游等，并根据订票信息，以确定出发地、出发地、到站位置、出发时 间、到站时间、抵达时间等信息，以快速确定用户的出行信息，由此，则可快速确定用户意图及需 实现用户意图对应服务。

在某些实施方式中，请结合图5，在处理器20获取出行信息时，可以是用户通过电子设备100 或与电子设备100通信连接的手表500进行输出操作，以获取输入信息。由此，处理器20则可根 据输入信息确定出行信息。

由此，处理器20则可根据出行信息，以确定用户的意图，从而快速实现用户的意图，以为用 户提供便利，提高用户的体验。

在获取到出行信息后，处理器20则可根据出行信息、当前时间和当前位置，以确定用户的意 图，即确定触发事件。并启动与触发事件匹配的服务，并根据触发事件运行服务。

例如，出行时间为早上10点，当前时间为早上8点，当前位置与出发地位置距离较远时，如 10公里、20公里等，处理器20可确定触发事件去出发地，处理器20可根据触发事件为去出发地 以启动打车服务，并运行打车应用程序，以预约车辆，以免用户错过出发时间。

再例如，出行时间为早上10点，当前时间为早上9点，当前位置与出发地位置距离较近，如 100米、200米等，处理器20可确定触发事件为候车，处理器20可根据触发事件为候车以启动听 书服务，并运行听书应用程序，以帮助用户打发候车时间。可选地，处理器20还可根据触发事件 为候车再启动闹钟服务，并运行闹钟程序，以设定闹钟，如设定9点45分的闹钟，以提醒用户检 票上车，以免用户错过行程。

又例如，出行抵达时间为下午5点，到站时间为下午4点，当前时间为下午4点05分，到站 位置与目的地距离较远时，如10公里、20公里等，处理器20则可判断用户正在出站，从而确定触 发事件为打车服务，并运行打车应用程序，以预约车辆，以使用户按能够在出行抵达时间按时到达 目的地。

可选的，处理器20还可根据目的地位置，以判断用户是否需要订酒店服务。例如，处理器20 可判断目的地是否为用户的家乡，若不是用户的家乡，则可启动并运行订酒店服务，以在目的地附 近为用户预定酒店，并在用户确认后完成预定酒店服务。更进一步地，处理器20还可在预定完酒 店后，再根据出行抵达时间，以判断用户是否需要订餐服务。例如，处理器20判断出行抵达时间 为饭点时，则可启动并运行订餐服务，并根据用户历史订餐信息，以选择偏向用户爱好的食物，并 在用户确认后完成订餐服务。

更具体地，触发事件可以为用户交互产生的事件，如用户点击显示屏、用户语音或按键输入、 传感器采集的数据满足预设条件等。其中，传感器采集的数据满足预设条件可以是环境光传感器采 集的环境光亮度达到预设亮度、或GPS检测到当前位置位于预设位置等。

例如，在根据GPS检测得到的位置信息确定用户已进入地铁场景后，即可确定用户想要坐地铁， 从而确定检测到“乘车码”服务的触发事件，此时则从地铁场景的服务集合中，确定“乘车码”服 务为目标服务。而在根据电子设备100的位置信息、麦克风的语音信息等确定用户已进入地铁内， 则可确定用户可能需要到站提醒，因此可确定检测到“到站提示”服务的触发事件，此时则从地铁场 景的服务集合中，确定“到站提示”服务为目标服务。

在确定目标服务后，若目标服务已在电子设备100中安装好，则可直接运行目标服务。而在目 标服务还未安装时，或者为了节省电子设备100的内存，服务可以存储在云端的服务器200，在电 子设备100需要时，从云端的服务器200获取目标服务。

不同系统或平台的服务，其具有不同的进程上层抽象方式以及进程间不同的调用方式，每个服 务在注册时均需要预设好初始调用信息，初始调用信息可以是服务注册时写入的信息。在目标服务 运行的系统或平台与当前电子设备100不同时，电子设备100根据初始调用信息无法直接运行目标 服务，而是需要将目标服务的初始调用信息转换为与目标服务匹配的目标调用信息，从而使得目标 服务能够在当前电子设备100下稳定地运行。

在一个例子中，当前设备为安卓系统，而目标服务为windows服务，当前设备无法直接使用 windows服务。在确定目标服务的初始调用信息后，需要对初始调用信息进行转换。如初始调用信 息可包括安卓参数A、安卓参数B和安卓参数C，目标服务无法直接处理安卓参数A、安卓参数B 和安卓参数C。

因此，当前设备(或服务器200)可将初始调用信息转换为目标调用信息，如将安卓参数A、 安卓参数B和安卓参数C分别转换为windows参数A、windows参数B和windows参数C，然后 将windows参数A、windows参数B和windows参数C输入到目标服务中，即可实现目标服务的调 用。

可以理解，安卓参数和windows参数可能仅是格式不同而实际包含的内容是相同的，如目标服 务为导航服务，在输入目的地进行导航时，安卓参数和windows参数均包括实际的“目的地”，从而 保证服务器200将初始调用信息转换为目标调用信息后，能够正确调用目标服务，避免出现转换后 运行目标服务也可能得到错误的调用结果的情况。

本申请实施方式的出行服务方法、出行服务装置10和电子设备100通过出行信息、当前时间 和当前位置来确定触发事件，以获取符合用户意图的服务，并启动、运行与触发事件匹配的服务， 从而可无需用户进行交互操作，通过预测用户意图，方便用户快速实现意图，用户体验较好。此外， 通过确定当前所处的应用场景，从而确定与应用场景对应的服务集合，在应用场景下检测到触发事 件的情况下，在服务集合中确定响应触发事件的目标服务，从而通过确定应用场景并检测触发事件， 快速确定对应的目标服务并运行，减少了用户查找目标服务的时间成本，有利于提高用户体验。且 可以理解，不同平台(如安卓平台、服务器200平台等)的服务的类型是不同的，如在安卓平台的 服务在服务器200平台无法正常运行，因此，本申请实施方式将目标服务的初始调用信息转换为与 目标服务匹配目标调用信息后，即可使得目标服务能够在电子设备100稳定地运行。如此，目标服 务能够实现跨平台运行，扩展了电子设备100的使用场景。

请参阅图2、图3和图6，在某些实施方式中，步骤02，可包括步骤：

021：根据出行时间和目的地确定出行类型；及

022：根据出行类型、出行时间、目的地、当前时间和当前位置，确定触发事件。

在某些实施方式中，服务治理模块12用于执行步骤021和步骤022。

在某些实施方式中，处理器20用于执行步骤021和步骤022。

具体地，根据上述可知，出行信息包括有出行时间和目的地。由此，在处理器20获取到出行 信息后，处理器20还可根据出行时间和目的地确定出行类型。

例如，出行时间为工作日，即周一至周五时，若目的地不是用户的家乡，则处理器20可确定 出行类型为出差。而若目的地为用户的家乡时，处理器20还可先询问用户是否回家，并在用户确 定是回家时，以确定出行类型为回家。

再例如，出行时间为节假日，若目的地为用户的家乡时，处理器20可确定出行类型为回家。 而若目的地不是用户的家乡时，处理器20可确定出行类型为旅游。

接下来，处理器20则可根据出行类型、出行时间、目的地、当前时间和当前位置等信息以确 定触发事件。

具体地，根据上述可知，出行类型共有出差、回家和旅游这三种类型。那么当出行类型为出差 时，处理器20可如上述举例的情况，确定触发事件可包括打车、订酒店、订餐等。当出行类型为 回家时，此时则无需进行订酒店和订餐服务，处理器20可确定触发事件为打车。当出行类型为旅 游时，处理器20可确定触发事件可包括打车、订酒店、订餐等。此外，在出行类型为旅游时，处 理器20还可确定触发事件可包括查旅游攻略，以为用户提供查旅游攻略的服务。

由此，处理器20可保证针对不同的出行类型，以确定不同的触发事件，从而高效并准确地对 不同的出行类型对应的触发事件进行匹配的服务。

请参阅图2、图3和图7，在某些实施方式中，步骤022，可包括步骤：

0221：在出行类型为回家且当前时间和抵达时间的时间差小于第一预设时间差时、或在出行类 型为回家且当前位置和目的地对应的车站的距离小于预设距离时，确定触发事件为出站和打车；

0222：在出行类型为出差且当前时间和抵达时间的时间差小于第一预设时间差时、或在出行类 型为出差且当前位置和目的地对应的车站的距离小于预设距离时，确定触发事件为出站、打车和订 酒店；及

0223：在出行类型为旅游且当前时间和抵达时间的时间差小于第一预设时间差时、或在出行类 型为旅游且当前位置和目的地对应的车站的距离小于预设距离时，确定触发事件为出站和查旅游攻 略。

在某些实施方式中，服务治理模块12还用于执行步骤0221、步骤0222和步骤0223。

在某些实施方式中，处理器20用于执行步骤0221、步骤0222和步骤0223。

具体地，在处理器20确定出行类型后，针对不同的出行类型则可确定出不同的触发事件。其 中，根据上述可知出行时间包括抵达时间，出行类型包括回家、旅游和出差，触发事件包括出站、 打车、订酒店和查旅游攻略中的至少一种。

具体地，在处理器20确定出行类型为回家时，处理器20可通过计算当前时间和抵达时间的时 间差，并比较该时间差与第一预设时间差的大小，并在该时间差小于第一预设时间差时，以确定触 发事件。例如，当前时间为下午4点，抵达时间为下午4点30分，第一预设时间差为1小时时， 当前时间和抵达时间的时间差小于第一预设时间差，此时，则可确定用户以快抵达目的地，处理器 20则可确定触发事件为出站和打车，由此，处理器20则可根据到站时间，为用户进行预约打车服 务。

此外，如图8所示，在处理器20确定出行类型为回家时，处理器20还可通过计算当前位置， 即所乘车辆H1和目的地对应的车站H2(即到站位置)的距离L1，并比较该距离L1与第一预设时 间差的大小，以在该距离L1小于预设距离时，以确定触发事件。例如，当前位置和到站位置之间 的距离L1为50米，预设距离为100米时，当前位置H1和到站位置H2之间的距离L1小于预设距 离，处理器20确定用户已快到达车站，从而确定触发事件为出站和打车。由此，处理器20则可根 据启动并运行打车服务，以为用户进行预约打车服务。

同样地，在处理器20确定出行类型为出差时，处理器20同样可根据判断当前时间和抵达时间 的时间差是否小于第一预设时间差，或者，如图6所示，根据判断当前位置H1和目的地对应的车 站H2的距离L1是否小于预设距离，从而确定触发事件。其中，由于出行类型为出差，那么触发事 件在出站、打车的基础上，还需提供订酒店服务，即在处理器20启动并运行打车服务，以为用户 进行预约打车服务后，处理器20还需启动并运行订酒店服务，以为用户选定目的地附近的酒店， 以方便用户抵达目的地后，可直接办理入住手续。

此外，处理器20还可根据判断当前时间是否为饭点，如中午12点、下午5点、下午6点等， 以在饭点时，在触发事件上添加订餐服务，处理器20则可启动并运行订餐服务，以为用户进行订 餐。需要说明的是，订餐服务可在通过用户选定时间，如用户可选定在出站后进行用餐，那么处理 器20可在用户出站前，在目的地对应的车站附近进行订餐，还可在用户抵达目的地后进行用餐， 那么处理器20可在启动并运行订酒店服务，以完成预定酒店后，再进行订餐服务。

同样地，在处理器20确定出行类型旅游时，处理器20同样可根据判断当前时间和抵达时间的 时间差是否小于第一预设时间差，或者如图6所示，根据判断当前位置H1和目的地对应的车站H2 的距离L1是否小于预设距离，从而确定触发事件。其中，由于出行类型为旅游，那么触发事件为 出站和查旅游攻略。即，在处理器20确定触发事件为出站和查旅游攻略后，处理器20则可针对出 站对用户进行出站提醒，并在用户出站后，启动并运行查旅游攻略服务，以为用户推荐旅游攻略。

此外，在用户确定旅游攻略后，处理器20则可根据旅游攻略，以为用户提供打车和订酒店服 务，以为用户的旅游提供便利。同样地，处理器20还可根据判断当前时间是否为饭点，并在饭点 时，添加订餐服务，以为用户订餐。

由此，处理器20可针对不同的出行类型，以确定不同的触发事件，从而提供不同的服务，并 无需用户进行交互操作，以方便用户快速实现意图，提高用户的体验。

请参阅图2、图3和图9，在某些实施方式中，步骤03，可包括步骤：

031：在触发事件为出站和打车时，获取与出站匹配的提醒服务和与打车匹配的打车服务；及

步骤05，可包括步骤：

051：根据抵达时间控制提醒服务发出提示信息，并启动打车服务打车到目的地。

在某些实施方式中，服务治理模块12用于执行步骤031，服务运行模块13用于执行步骤051。

在某些实施方式中，处理器20用于执行步骤031和步骤051。

具体地，在处理器20确定触发事件为出站和打车后，处理器20可获取与出站匹配的提醒服务 和与打车匹配的打车服务，并根据抵达时间控制提醒服务发出提示信息，并启动打车服务打车到目 的地。

如图5所示，电子设备100还包括有屏幕50，电子设备100还可以与手表500通信连接，手表 500包括有显示屏501，那么在处理器20获取得到与出站匹配的提醒服务后，如图10所示，若抵 达时间为下午5点，当前时间为下午4点58分，处理器20可控制电子设备100在屏幕50上显示 “前方2分钟后到站，请注意下车”的提示信息，或者处理器20可控制与电子设备100通信连接 的手表500在显示屏501上显示“前方2分钟后到站，请注意下车”的提示信息。此外，处理器20 还可控制电子设备100或与电子设备100通信连接的手表500在发出提示信息的同时，还可控制电 子设备100或手表500自身发出震动，以更好的提示用户。

接下来，在处理器20控制电子设备100或手表500发出提示信息后，如图10所示，电子设备 100的屏幕50或手表500的显示屏501上还可显示“确认”选项O，以获取用户是否接收到提示信 息，即当用户点击“确认”选项O后，处理器20可确定用户接收到提示信息。此时，处理器20可 启动打车服务，以为用户预约车辆，以保证用户在出站后即可乘车前往目的地。此外，在用户乘车 时，处理器20还可控制电子设备100或手表500为用户提供导航服务，以便于用户查看当前位置 与目的地之间的距离，及到达时间。

其中，导航服务可以在电子设备100与手表500之间进行任意切换。例如，当用户乘车过程中 使用电子设备100时，处理器20则可控制手表500显示导航信息，或当用户乘车过程中使用手表 500时，处理器20则可控制电子设备100显示导航信息。

请参阅图2、图3、图5和图11，在某些实施方式中，步骤03，可包括步骤：

032：在触发事件为出站、打车和订酒店时，获取与出站匹配的提醒服务、与打车匹配的打车 服务、和与订酒店匹配的住宿服务；

步骤05，可包括步骤：

052：根据抵达时间控制提醒服务发出提示信息，并启动打车服务打车到目的地；

053：根据抵达时间控制提醒服务发出提示信息，并启动打车服务打车到目的地。

在某些实施方式中，服务治理模块12用于执行步骤032，服务运行模块13用于执行步骤052 和步骤053。

在某些实施方式中，处理器20用于执行步骤032、步骤052和步骤053。

具体地，在处理器20确定触发事件为出站、打车和订酒店时，那么处理器20可确定该触发事 件分别与提醒服务、打车服务和住宿服务匹配。

首先，处理器20可根据抵达时间以控制提醒服务发出提示信息，具体地，处理器20可控制电 子设备100或与电子设备100通信连接的手表500发出提示信息，如图10所示，若抵达时间为下 午5点，当前时间为下午4点58分，处理器20可控制电子设备100在屏幕50上显示“前方2分 钟后到站，请注意下车”的提示信息，或者处理器20可控制与电子设备100通信连接的手表500 在显示屏501上显示“前方2分钟后到站，请注意下车”的提示信息。

此外，电子设备100的屏幕50或手表500的显示屏501上还可显示“确认”选项O，以获取 用户是否接收到提示信息，即当用户点击“确认”选项O后，处理器20可确定用户接收到提示信 息。

接下来，处理器20可启动打车服务，以为用户预约车辆，以使用户在出站后即可乘车前往目 的地。此外，在用户乘车时，处理器20还可控制电子设备100或手表500为用户提供导航服务， 以便于用户查看当前位置与目的地之间的距离，及到达时间。其中，导航服务可以在电子设备100 与手表500之间进行任意切换。例如，当用户乘车过程中使用电子设备100时，处理器20则可控 制手表500显示导航信息，或当用户乘车过程中使用手表500时，处理器20则可控制电子设备100 显示导航信息。

在处理器20完成打车服务后，处理器20可启动住宿服务，并提供以目的地为中心的预定范围 内的酒店的信息，以完成订酒店服务。例如，预定范围可以是2公里，处理器20可选取以目的地 为中心，半径为2公里范围内的酒店信息，从而完成订酒店服务。其中，酒店的确定可以是用户根 据处理器20提供的酒店信息进行选取，还可以是处理器20先对以目的地为中心，半径为2公里范 围内的酒店进行筛选后，以选出评价较高、环境较好的酒店后，在向用户进行推荐，以省去用户筛 选酒店的时间。

更进一步地，在处理器20完成订酒店服务后，处理器20还会判断当前时间是否为饭点，如中 午12点，下午5点等，以为用户提供订餐服务。订餐服务可以由用户选定时间，如订餐服务可以 在打车服务之前进行，那么处理器20可判断用户需在打车前进行就餐，又如，订餐服务可以在打 车服务之后进行，那么处理器20可判断用户需在抵达酒店后进行就餐。

请参阅图2、图3和图12，在某些实施方式中，步骤03：确定服务集合中响应于触发事件的目 标服务，还包括步骤：

033：在触发事件为出站、打车和订酒店时，获取与出站匹配的提醒服务、与打车匹配的打车 服务、和与订酒店匹配的住宿服务；及

步骤05：根据所述目标调用信息运行所述目标服务，包括步骤：

054：根据抵达时间控制提醒服务发出提示信息，并启动攻略服务并提供目的地的攻略信息。

在某些实施方式中，服务治理模块12用于执行步骤033，服务运行模块13还用于执行步骤054。

某些实施方式中，处理器20用于执行步骤033和步骤054。

具体地，在处理器20确定触发事件为出站和查旅游攻略时，处理器20可确定该触发事件与攻 略服务匹配。

首先，处理器20可根据抵达时间以控制提醒服务发出提示信息，具体地，处理器20可控制电 子设备100或与电子设备100通信连接的手表500发出提示信息，如图10所示，若抵达时间为下 午5点，当前时间为下午4点58分，处理器20可控制电子设备100在屏幕50上显示“前方2分 钟后到站，请注意下车”的提示信息，或者处理器20可控制与电子设备100通信连接的手表500 在显示屏501上显示“前方2分钟后到站，请注意下车”的提示信息。此外，电子设备100的屏幕 50或手表500的显示屏501上还可显示“确认”选项O，以获取用户是否接收到提示信息，即当用 户点击“确认”选项O后，处理器20可确定用户接收到提示信息。

接下来，处理器20可启动攻略服务，以为用户提供与目的地相关的攻略信息。例如，处理器 20可根据目的地，以为用户提供在该目的地旅游时的观景顺序。

此外，在用户确定攻略信息后，处理器20还可根据该攻略信息，以启动住宿服务，以预定和 攻略信息中的观景顺序匹配的房间。例如，第一天用户去景点A，处理器20可预定景点A附近的 酒店，第二天用户去景点B，处理器20可预定景点B附近的酒店。又例如，用户分别去景点A、 景点B和景点C，处理器20可选取景点A、景点B和景点C三个景点中间位置的酒店，以便于用 户的旅程。

更进一步地，在处理器20为用户提供攻略信息后，处理器20可启动并运行打车服务，以为用 户预定车辆，以使用户能够快速乘坐车辆前往预定酒店位置。其中，处理器20还会判断当前时间 是否为饭点，如中午12点，下午5点等，以为用户提供订餐服务。订餐服务可以由用户选定时间， 如订餐服务可以在打车服务之前进行，那么处理器20可判断用户需在打车前进行就餐，又如，订 餐服务可以在打车服务之后进行，那么处理器20可判断用户需在抵达酒店后进行就餐。

综上，可以看出，在本申请实施方式的出行服务方法中，在处理器运行提醒服务时，均可控制 电子设备100或与电子设备100通信连接的手表500发出提示信息。

请参阅图2、图3和图13，在某些实施方式中，步骤02，可包括步骤：

023：在当前时间和出发时间的时间差小于第二预设时间差时，确定触发事件为出发；

024：在当前位置与出发地对应的车站的距离小于第二预设距离、且当前时间和出发时间的时 间差大于第三预设时间差时，确定触发事件为候车，第三预设时间差小于第二预设时间差。

在某些实施方式中，服务治理模块12还用于执行步骤023和步骤024。

在某些实施方式中，处理器20用于执行步骤023和步骤024。

具体地，例如，当前时间为早上8点30分，出发时间为早上10点时，第二预设时间差为2小 时，那么处理器20可判断出当前时间和出发时间的时间差小于第二预设时间差，从而确定触发事 件为出发。其中，第二预设时间差可通过用户当前位置与出发地对应的车站位置确定，如用户当前 位置距出发地对应的车站位置需2小时路程时，那么第二预设时间差便为2小时。

又例如，处理器20判断当前位置(用户所处位置)与出发地对应的车站的距离为50米，第二 预设距离为100米，即当前位置与出发地对应的车站的距离小于第二预设距离时，处理器20则会 判断当前时间和出发时间的时间差是否大于第三预设时间差，若当前时间为早上9点，出发时间为 早上10点时，第三预设时间差为30分钟，此时，处理器20可判断当前时间与出发时间的时间差 大于第三预设时间差，那么处理器20可判断用户已抵达车站，处理器20确定触发事件为候车。其 中，第三预设时间差可以是预先设定好的时长，出发时间减去该时长可以是用户最佳到达出发地对 应的车站的时间。

需要说明地是，第三预设时间差是小于第二预设时间差的，两个预设时间差分别代表不同的时 间节点。而第二预设距离小于上述的预设距离，第二预设距离是用于判断用户是否已抵达出发地对 应的车站，而预设距离是用于判断用户是否快要达到目的地对应的车站，即用户在抵达目的地对应 的车站前几分钟内需要进行判断，而车辆速度较快，因此，预设距离是大于第二预设距离的。

请参阅图2、图3、图14至图16，在某些实施方式中，步骤03，可包括步骤：

034：在触发事件为出发时，获取与出发匹配的提醒服务；

步骤05，可包括步骤：

055：根据出发时间控制提醒服务发出提示信息。

步骤03，还可包括步骤：

035：在触发事件为候车时，获取与候车匹配的候车服务，候车服务包括多种；

步骤05，还可包括步骤：

056：启动与候车时长匹配的候车服务，候车时长根据当前时间和出发时间的时间差确定；

其中，步骤056，可包括步骤：

0561：在候车时长大于第一预定候车时长时，启动第一候车服务；

0562：在候车时长大于第二预定候车时长且小于所述第一预定候车时长时，启动第二候车服务， 第二预定候车时长小于第一预定候车时长。

在某些实施方式中，服务治理模块可用于执行步骤034和步骤035，服务运行模块13用于执行 步骤055、步骤056、步骤0561和步骤0562。

在某些实施方式中，处理器20用于执行步骤034、步骤035、步骤055、步骤056、步骤0561 和步骤0562。

具体地，在处理器20确定触发事件为出发时，处理器20可获取与出发匹配的提醒服务，以提 示用户需要出发前往出发地对应的车站。其中，处理器20可根据出发时间控制提醒服务发出提示 信息。

例如，出发时间为上午10点，那么处理器20根据上述第二预设时间差，以确定需要控制提醒 服务发出提示信息的时间，若第二预设时间差为2小时，那么如图17所示，处理器20可在上午8 点时启动并运行提醒服务，以在电子设备100的屏幕50或手表500的显示屏501上显示“现在需 出发前往车站”的提示信息。

而在处理器20确定触发事件为候车时，处理器20可获取与候车匹配的候车服务。其中，候车 服务包括有多种，如，影音服务、游戏服务、看书服务、闹钟服务、听书服务、咖啡服务等。由此， 处理器20可启动并运行与候车时长匹配的候车服务。其中，候车时长可根据当前时间和出发时间 的时间差确定。例如，出发时间为10点，当前时间为9点，则候车时长为1小时。

此外，不同的候车服务可对应不同的候车时长，由此，候车服务可分为第一候车服务和第二候 车服务。第一候车服务包括影音服务、游戏服务和看书服务中的至少一种，第二候车服务包括咖啡 服务、听书服务和闹钟服务中的至少一种。

更进一步地，在处理器20启动并运行候车服务前，处理器20可先判断候车时长的大小，以针 对不同的候车时长启动不同的候车服务。

具体地，处理器20可先判断候车时长是否大于第一预定候车时长，并在候车时长大于第一预 定候车时长时，确定候车服务为第一候车服务，则处理器20可根据用户的选择启动影音服务、游 戏服务和看书服务中的至少一种。

例如，候车时长为2小时，第一预定候车时长为1小时，即候车时长大于第一预定候车时长时， 如图18所示，电子设备100的屏幕50显示影音服务选项M、游戏服务G和看书服务R，此时，用 户可选择M、G和R这三个选项中的其中一种，以使处理器20控制电子设备100启动与用户选定 选项对应的第一候车服务。如，用户选择选项M，处理器20启动并运行影音服务，用户选择选项 G，处理器20启动并运行游戏服务。

又例如，候车时长为50分钟，第一预定候车时长为1小时，第二预定候车时长为30分钟，即 候车时长大于第二预定候车时长且小于第一预定候车时长时，如图19所示，电子设备100的屏幕 50显示咖啡服务D、听书服务L和闹钟服务T，此时，用户可选择D、L和T这三个选项中的其中 一种，以使处理器20控制电子设备100启动与用户选定选项对应的第二候车服务。如用户选择选 项D，处理器20启动并运行咖啡服务，以为用户预定咖啡。用户选择选项L，处理器20启动并运 行听书服务，以为用户播放小说、相声等。用户选择选项T，处理器20启动并运行闹钟服务，以根 据出发时间为用户设定合适时间(如出发时间前15分钟)的闹钟。

请参阅图2、图3和图20，在某些实施方式中，步骤01包括：

011：获取交互信息，根据交互信息确定当前所处的应用场景。

在某些实施方式中，场景感知模块11还用于执行步骤011。

在某些实施方式中，处理器20用于执行步骤011。

具体地，交互信息用于表示电子设备100的任意交互过程所生成的信息，可以是电子设备100 能够获取的信息，例如交互信息包括电子设备100的输入信息、传感器信息、状态信息、位置信息、 及电子设备100的应用的运行信息中至少一种。

其中，输入信息可以包括：语音交互信息、文本交互信息、触控交互信息等，在此不做限定。 传感器信息可以是电子设备100的摄像头40采集的图像、或者姿态传感器采集的姿态信息、或者 环境光传感器采集的环境光亮度信息、麦克风采集的声音信息等。状态信息可以是电子设备100当 前的状态，如电子设备100正与其他设备通信、电子设备100的时间、电量等。位置信息则表示电 子设备100的位置，如家、公司、商城、或者室内的具体位置等。应用的运行信息则包括当前应用 是否完成一个任务(如导航应用的任务可以是导航任务是否完成)、购物应用则可以是当前购物车 是否进行结算等。

在本实施例中，应用场景可包括基础应用场景和高级应用场景，可通过电子设备100的交互信 息，来感知基础应用场景，如环境、时间、活动、交通、位置、附近设备等，还可根据基础应用场 景确定高级应用场景，例如，通过基础应用场景时间/位置推理获得高级应用场景订餐；通过基础应 用场景活动推理获得高级应用场景逛街购物；通过基础应用场景交通工具推理获得高级应用场景上 班；通过基础应用场景位置推理获得高级应用场景游览景点；通过基础应用场景附近设备推理获得 高级应用场景投屏等，在此不做限定。

在一些实施方式中，通过位置感知、交通工具感知、活动状态感知、设备状态感知、设备姿态 感知、附近设备感知、环境状态感知、时间感知中至少一种，来确定应用场景，在此不做限定。

作为一种可实施的方式，根据感知到的电子设备100的位置来确定应用场景。位置感知可以通 过全球定位系统(globalpositioning system，GPS)技术定位电子设备100的位置，可以通过北斗定位 系统技术定位电子设备100的位置等，在此不做限定。例如，在位置信息显示当前处于地铁站时， 确定应用场景为地铁场景；在位置信息显示当前处于车库时，确定应用场景为车库场景。

作为一种可实施的方式，根据感知到的交通工具类型来确定应用场景。交通工具感知可以通过 电子设备100的加速度传感器计算电子设备100在水平方向和垂直方向的变化速度，结合机器学习 等技术，确定电子设备100是否处于驾驶状态，在确定电子设备100处于驾驶状态时，再通过声音 识别区分交通工具类型，例如，小汽车、公交车、火车、飞机等，其中，不同的交通工具对应的环 境噪声不同。

作为一种可实施的方式，根据感知到的活动状态来确定应用场景。活动状态感知可以通过电子 设备100的加速度传感器计算电子设备100在水平方向和垂直方向的变化速度，结合机器学习等技 术，确定电子设备100对应的用户是否处于静止状态、是否处于走路状态、是否处于跑步状态等， 在此不做限定。例如，在用户处于静止状态时，可确定应用场景为睡眠场景；在用户处于跑步状态 时，可确定应用场景为跑步场景。

作为一种可实施的方式，根据感知到的设备状态来确定应用场景。设备状态感知可以通过电子 设备100的操作系统获取电子设备100所处的状态。例如，电子设备100是否连接有音频播放设备， 电子设备100的无线模块是否连接，电子设备100的屏幕是否点亮等，在此不做限定。例如，在电 子设备100连接有音频播放设备时，确定应用场景为音频播放场景。

作为一种可实施的方式，根据感知到的设备姿态确定应用场景。设备姿态感知可以通过电子设 备100的加速度传感器、陀螺仪、磁力计等传感器，结合机器学习等技术，评估电子设备100正面 朝上还是朝下，静置在桌面还是放置在口袋、背包中等，在此不做限定。例如，在电子设备100正 面朝下时，确定应用场景为静音场景。

作为一种可实施的方式，根据感知到的附近设备来确定应用场景。附近设备感知可以通过附近 设备发出的蓝牙、WiFi等广播识别附近设备。其中，附近设备例如可以包括智能手机、智能电视、 智能手表、智能耳机、智能汽车等，在此不做限定。例如，附近设备为智能电视时，确定应用场景 为投屏场景。

作为一种可实施的方式，根据感知到的环境状态来确定应用场景。环境状态感知可以通过电子 设备100的气压计、温度计、环境光等传感器，识别电子设备100当前所处的环境状态。例如，在 环境状态为夜间时，确定应用场景为夜景拍摄场景。

作为一种可实施的方式，根据感知到的时间来确定应用场景。时间感知可以通过获取电子设备 100当前的系统时间，计算日期、星期等信息，确定是工作日还是周末，是早晨、下午、夜晚还是 深夜等。再通过所属国家或者地区，确定是否为节假日等。例如，在时间为工作日且为上班时间时， 确定应用场景为上班场景。

请参阅图2、图3和图21，在某些实施方式中，步骤01，还包括步骤：

012：确定应用场景对应的应用脚本，其中，应用脚本中包括至少一个服务标识；

013：将应用脚本中所有服务标识对应的服务所构成的集合，作为服务集合。

在某些实施方式中，场景感知模块11还用于执行步骤012和步骤013。

在某些实施方式中，处理器20用于执行步骤012和步骤013。

具体地，应用脚本可以包括至少一个服务标识，应用脚本中的每个服务，可以通过服务标识在 服务器200的应用市场中找到此服务，每个服务标识可存在对应的服务；应用脚本还可包括用于控 制应用场景对应的服务集合中服务之间的控制逻辑，如采用脚本语言描述了一段通用的业务逻辑。 其中，该脚本语言可以为xml、javascript。服务之间的调用、管理关系通过应用脚本来实现，且应 用脚本描述了一段通用的业务逻辑。

在确定应用场景对应的应用脚本时，可首先确定应用场景对应的服务清单，服务清单包括与服 务对应的至少一个服务标识，根据服务清单中包括的至少一个服务标识，即可生成应用场景对应的 应用脚本。

在根据服务清单生成应用脚本时，首先根据服务清单中的服务标识生成与应用场景对应的初始 应用脚本，然后可根据对初始应用脚本的编辑数据，来对初始应用脚本进行调整，从而得到编辑后 的应用脚本，编辑后的应用脚本即为与应用场景对应的应用脚本。

当前的编辑数据可根据用户的输入信息、应用场景下采集的交互信息、用户画像、用户对应用 脚本的历史编辑数据等确定。也即是说，随着用户不断对电子设备的使用，每个应用场景对应的服 务集合可根据编辑数据不停更新，从而针对不同应用场景，使得每个用户实现个性化的服务集合， 以提升用户体验。

在一个实施方式中，编辑数据还可根据用户对服务的订阅操作确定。

订阅发起方设备可以通过访问应用商店服务器，获取所有服务的服务列表，然后接收对服务列 表中服务的订阅操作，根据用户订阅的服务对应的服务标识，即可生成应用对应的应用脚本。可以 理解，一个服务可以单独作为应用商店中的一个应用，多个由用户订阅的服务也能够作为应用商店 中的一个应用。

示意性的，如图22所示，用户可访问应用商店，在应用商店界面71中通过搜索框72搜索特 定应用场景(如场景A)对应的所有服务，形成服务清单，每个服务对应一个订阅按钮73。在服务 接收到用户对订阅按钮73的点击操作后，订阅按钮73变为取消订阅按钮74，此时表示该服务已被 订阅，点击取消订阅按钮74即可取消对应应用的订阅。根据已被订阅的一个或多个服务对应的服 务标识，即可生成应用场景对应的应用脚本。

请参阅图23，设备检测到用户的应用订阅发生变化时，将用户新订阅的应用的应用脚本从应用 商店中下载到设备上。

如云端(如服务器200)检测到设备A和设备B的应用订阅发生变更后，会将设备A和设备B 新订阅的应用的服务标识通过变更通知分别发送到设备A和设备B，然后设备A和设备B根据对 应的服务标识从应用商店下载对应的应用脚本，以便完成应用的部署。

在确定应用脚本后，即可根据应用脚本中包括的至少一个服务标识对应的服务构成的集合，以 作为服务集合。例如，可将触发器的控制逻辑对应的多个服务标识作为一个服务集合，或者，应用 脚本中所有触发器的控制逻辑对应的多个服务标识作为一个服务集合。

请参阅图2、图3和图24，在某些实施方式中，步骤03，可包括步骤：

036：在应用场景下检测到触发事件的情况下，触发触发事件在应用脚本中对应的目标触发器；

037：通过目标触发器调用应用脚本中对应的目标控制逻辑，根据目标控制逻辑确定服务集合 中对应于触发事件的目标服务。

在某些实施方式中，服务治理模块12用于执行步骤036和步骤037。

某些实施方式中，处理器20用于执行步骤036和步骤037。

具体地，请参阅图25，应用脚本可由若干触发器(如图25中的触发器A、触发器B、触发器C 和触发器D)构成，而每个触发器又是由触发事件、控制逻辑以及控制逻辑所控制的若干服务构成。 其中，应用脚本中的服务并不是服务本身，而是服务的服务标识(如图25中的服务1、服务2和服 务3)。

其中，触发事件包括交互产生的事件(如到达特定位置、时间、用户交互输入等)，控制逻辑 为触发器对应的业务逻辑，通常由多个服务按照指定的逻辑组合而成。在某个触发事件发生时，触 发特定的触发器，从而执行相应的控制逻辑，根据控制逻辑调用对应的服务。

请参阅图26，应用脚本中的多个触发器在业务上存在关联性，它们共同配合完成一个场景应用。 这个场景应用，需要响应多个不同的事件(即触发事件)，每个事件对应一种行为(如图26中的 动作)。通过创建不同的触发器，并组合在一起，从而形成完整的应用。

比如，满足“音乐随身”的用户需求的场景应用。触发事件为用户在客厅时，动作为声音流转 到客厅音响中播放，触发事件为用户走到卧室时，动作为声音流转到卧室的音响中播放，触发事件 为用户离开房间时，动作为声音流转到手机和蓝牙耳机中播放。

在应用场景下，检测到触发事件的情况下，即可触发触发事件在应用脚本中对应的目标触发器； 通过目标触发器来调用目标触发器对应的目标控制逻辑，从而通过目标控制逻辑来确定服务集合中 对应于触发事件的目标服务。

例如，如图25所示的触发事件被触发后，即可确定触发事件在应用脚本中对应的目标触发器 (即触发器A)，然后通过触发器A来调用触发器A对应的目标控制逻辑(即图25中的控制逻辑)， 从而通过目标控制逻辑来确定服务集合中对应于触发事件的目标服务(如服务1、服务2等)。

可以理解，目标控制逻辑所控制的服务可以是多个，多个服务按照目标控制逻辑执行，例如， 目标控制逻辑所控制的多个服务具有排序，可按先后顺序依次执行。如此，根据目标控制逻辑即可 确定当前要执行的目标服务。

可选地，触发事件还可以是用户触发的事件，比如敲击事件、摇一摇事件等等，也可以是调用 服务后输出的事件，比如，上一触发器对应的服务调用完成后返回的事件，本实施方式对此不作限 定。

本申请的应用中的服务是由控制逻辑串联起来的，在运行时才能决定它所部署的设备，因此在 当前设备下载应用脚本后，通过控制逻辑调用的服务集合，将在此时进行部署。在应用运行后，按 照控制务逻辑的需求，不同的服务可被部署到同一设备，或被差分部署到不同的设备上，在不同的 设备上执行不同的任务，部署的过程是动态。如果在多个设备上存在设备部署服务失败，将提示用 户当前服务不可用。

例如，请参阅图27，对于跨端截屏应用，实现跨端截屏所调用的服务包括双指叩击服务、图片 显示服务以及截屏服务。当用户帐号订阅了跨端截屏应用后，该用户帐号下的手机、平板、车机以 及电视均会下载对应的应用脚本，且在下载应用脚本后均会预先基于初始触发器部署双指叩击服务。

当用户双指叩击手机的屏幕时，确定触发事件为“跨端截图”，手机基于应用脚本中的目标触发 器及目标控制逻辑，确定执行的业务逻辑为请求调用其他设备(如平板、车机、电视等)侧的截屏 服务。

其他设备接收到该请求后，确定触发事件为“进行截图”，其他设备基于应用脚本中的目标触发 器及目标控制逻辑，确定执行的业务逻辑为部署截屏服务，并运行截图服务对当前界面进行截图， 并将截图发送给手机。

手机接收到截图后，即确定触发事件为“显示图像”，手机基于应用脚本中的目标触发器及目标 控制逻辑，确定执行的业务逻辑为部署图片显示服务，并运行图片显示服务显示截图。如此，可通 过服务的动态部署，实现跨端截屏。

请参阅图2、图3和图28，在某些实施方式中，步骤04，可包括步骤：

041：发起对目标服务的目标调用请求，其中，目标调用请求中包含目标服务的初始调用信息；

042：根据目标调用请求中的初始调用信息调用对应的服务代理，通过服务代理确定初始调用 信息对应的目标调用信息。

在某些实施方式中，服务治理模块12还用于执行步骤041和步骤042。

在某些实施方式中，处理器20用于执行步骤041和步骤042。

具体地，请参阅图29，在服务注册后，电子设备100可直接调用该服务；或者由用户对已注册 的服务进行服务编排形成一个整体应用后，调用该应用，例如通过图7所示的订阅的方式，生成一 个或多个对应不同应用场景的应用脚本。然后，电子设备100根据应用场景以及触发事件快速确定 目标服务。

在确定了目标服务后，处理器20可先发起对目标服务的目标调用请求，其中，目标调用请求 中包含目标服务的初始调用信息，初始调用信息可包括服务的基本属性，如服务名、服务ID、服务 描述等；服务的调用方式，如调用协议类型、该协议的一些私有参数等；服务的参数定义：如服务 的入参列表(如参数ID、参数名、参数类型等)、出参列表(如参数ID、参数名、参数类型等)、 服务类型参数之间的转换规则(如转换脚本、描述、服务ID等)等。

其中，为了实现类型相同的服务之间的兼容，在服务注册时，定义了当前服务的参数和标准参 数之间的转换规则(即服务类型参数之间的转换规则)。例如，导航服务包括导航服务A和导航服 务B，导航服务A中的目的地参数为“目的地”，导航服务B中的目的地参数为“最终地点”，通 过建立导航服务A的参数和标准参数之间、及导航服务B的参数和标准参数之间的服务类型参数之 间的转换规则，从而实现服务之间的参数兼容，通过标准参数即可实现导航服务A和导航服务B 的调用。如通过标准参数“到达点”即可调用导航服务A和导航服务B进行目的地导航。

例如，服务的参数定义如下表：

初始调用信息可存储在电子设备100中，或者初始调用信息可存储在服务器200中，处理器20 还可接收服务器200发送的对应于目标服务的初始调用信息。

然后，处理器20根据目标调用请求中的初始调用信息，调用与初始调用信息对应的服务代理， 从而通过服务代理将初始调用信息转换为目标调用信息。

可以理解，服务代理可在本地部署，如在电子设备100部署服务代理；或者，服务代理可设置 在云端的服务器200，处理器20将目标调用请求发送到服务器200，服务器200根据目标调用请求 调用对应的服务代理，将初始调用信息转换为目标调用信息。

请继续参阅图29，可以理解，为了使应用支持异构操作系统，从而实现跨平台运行，在进行服 务调用时需要采用统一格式的目标调用请求，服务网关可通过本地(如电子设备100)或服务器200 部署的服务代理，将同一格式的目标调用请求转换为真实的服务调用，即符合当前平台服务规范的 服务调用。

经过服务代理转换后，可将初始调用信息直接转换为可供当前电子设备100直接运行目标服务 的目标调用信息，从而使得目标服务能够符合当前电子设备100的平台服务规范。

如调用图29所示的Messenger服务、deeplink服务等，则根据服务网关的服务代理进行接口适 配，使得目标调用请求符合Messenger服务、deeplink服务等的真实服务调用，正确调用Messenger 服务、deeplink服务等。

在一些实施例中，初始调用信息中包括服务类型和注册调用信息；服务类型可包括安卓系统服 务、windows系统服务等，注册调用信息则包括上述提到的服务的基本属性、服务的调用方式和服 务的参数定义。

基于所需提供服务的服务类型，电子设备100可以按需部署有不同的服务代理，其中，不同的 服务代理对应不同的编程开发语言(比如java、js、php、C、C++等等)，或，不同的服务代理对 应不同的部署形态(比如小程序、浏览器插件、应用程序等等)，或，不同的服务代理对应不同的 运行环境(比如虚拟机、浏览器、操作系统、容器等等)。

且由于不同的操作系统，有自身不同的进程的上层抽象方式，以及进程间的不同的调用方式， 相同的调用请求将在服务网关内部转换为不同的具体的真实调用。每种服务类型的转换可由指定的 服务代理来完成，服务代理可以根据实际的部署情况进行增加和减少，例如，windows的服务网关 只需部署windows相关的服务代理，Android的服务网关只需部署Android相关的服务代理。

示意性的，如图30所示，服务网关可包括Android Service代理、云端restful代理、Android动 态服务代理以及Web动态服务代理中至少一个。例如，对于Android Service而言，则可通过Android Service将初始调用信息转换为目标调用信息，从而适配不同系统或平台的电子设备100。再例如， 对于云端restful服务而言，则可通过云端restful代理将初始调用信息转换为目标调用信息，从而适 配不同系统或平台的电子设备100。在此不再一一列举。

在某些实施方式中，可通过服务暴露的接口来调用服务。

例如，将云端的RestFul服务对外暴露的接口定义为如下格式：

将对于安卓端的Deeplink服务对外暴露的接口定义为如下格式：

其中，类型信息代表了该服务真实的接口类型，不同的类型，需要配置的属性是不同的。提供 者类型信息指哪个应用可以支持这个服务，比如导航类的服务可由高德或百度提供。链接信息指的 是访问云端的地址。链接标准信息指的是链接的调用方法。

在调用目标服务暴露的接口时，服务网关会根据初始调用信息中的服务类型(对应接口定义中 的类型信息)选择对应的服务代理，然后由服务代理将将注册调用信息转换为适配真实的服务提供 者的接口类型的目标调用信息。

因此，服务提供者是无需做接口适配修改的，他只需要在注册服务时指明这些信息即可快速确 定准确的服务代理，从而实现注册调用信息到目标调用信息的转换，最后根据目标调用信息运行目 标服务，如调用目标服务暴露的接口并输入目标调用信息(如输入参数)到接口，目标服务根据输 入参数输出输出参数，从而实现目标服务的调用。

如此，目标服务能够被任何系统或平台的电子设备100正常运行，实现目标服务的跨平台运行。

请参阅图2、图3和图31，在某些实施方式中，合法性验证包括以下：

06：通过目标服务网关对目标调用请求进行合法性验证；

07：在目标服务网关对目标调用请求验证通过的情况下，执行根据目标调用请求中的初始调用 信息调用对应的服务代理，通过服务代理确定初始调用信息对应的目标调用信息。

在某些实施方式中，服务治理模块12还用于执行步骤06和步骤07。

在某些实施方式中，处理器20用于执行步骤06和步骤07。

具体地，在进行初始调用信息到目标调用信息的转换之前，目标服务网关可先对目标调用请求 进行合法性验证，在合法性验证通过的情况下，再继续通过初始调用信息对应的服务代理进行初始 调用信息到目标调用信息的转换。其中，合法性验证可以是认证电子设备100的用户是否为合法， 通过合法性验证的电子设备100才能够访问服务网关。

进行合法性验证还可以是：

在目标服务网关为当前设备的服务网关的情况下，通过目标服务网关对目标调用请求进行合法 性验证。例如，当前设备的服务网关即为调用目标服务的服务网关。

在目标服务网关为外部设备的服务网关的情况下，将目标调用请求发送至外部设备，并接收外 部设备返回的处理结果，处理结果是外部设备在通过目标服务网关对目标调用请求的合法性验证通 过的情况下，响应目标调用请求得到的。

也即是说，服务调用和网关的合法性验证分别在不同的服务网关，在外部设备的服务网关进行 合法性验证的情况下，可将目标调用请求发送到外部设备，从而根据处理结果来确定是否合法性验 证通过，在合法性验证通过时，再响应该处理结果，从而进行后续的初始调用信息到目标调用信息 的转换。

请参阅图2、图3和图32，在某些实施方式中，步骤05，可包括步骤：

057：在目标服务为第一服务类型的情况下，根据目标调用信息运行目标服务；

058：在目标服务为第二服务类型的情况下，确定目标服务对应的宿主服务，在宿主服务处于 运行状态的情况下，根据目标调用信息运行目标服务。

在某些实施方式中，服务运行模块13还用于执行步骤057和步骤058。

在某些实施方式中，处理器20用于执行步骤057和步骤058。

具体地，服务包括不同的服务类型，如服务包括第一服务类型和第二服务类型，第一服务类型 可以是动态服务，第二服务类型可以是静态服务。

静态服务作为一种预安装服务，其调用依赖于宿主应用，且需要安装有宿主应用，且宿主应用 中的宿主服务运行的情况下，该静态服务才能够被调用。

动态服务则是指支持动态部署的服务，可以在应用运行过程中动态部署在设备中。动态服务作 为一种支持动态部署的服务，其调用并不依赖预先安装的应用，且可供调用的动态服务统一存储在 云端的服务器200中。在目标服务为第一服务类型的情况下，则可直接从服务器200获取目标服务 并进行动态部署，从而根据目标调用信息直接运行目标服务。

在一种可能的实施方式中，目标服务为静态服务，即预安装服务，预安装服务定义了宿主应用 以及访问路径。服务治理模块12用于管理本地设备中由宿主应用提供的静态服务，获取到目标调 用信息后，服务治理模块12查询本地设备中的目标服务，然后确定目标服务对应的宿主服务，在 运行目标服务前，需要先运行宿主服务，从而保证根据目标调用信息能够正常运行目标服务。

可选地，若目标服务启动成功，电子设备100则根据目标服务的初始调用信息(初始调用信息 中的服务类型)，即可确定该目标服务对应的目标服务代理，并通过该目标服务代理进行参数转换， 从而基于目标服务对应的宿主应用及访问路径(目标服务暴露的接口)，获取当前电子设备100中 存储的与目标服务对应的目标服务代码集合，从而通过运行目标服务代码集合调用该目标服务。

可选地，若目标服务启动失败，或目标服务不满足预安装条件(比如宿主应用未安装、宿主服 务未运行等导致目标服务不可使用)，电子设备100则进行失败提示。

在一个示意性的例子中，静态服务的调用过程如图33所示。

步骤3301，向服务网关发起对目标服务的目标调用请求。

步骤3302，服务网关验证请求是否合法；若合法，则执行步骤3303，若不合法，则执行步骤 3309。

步骤3303，检测宿主服务是否启动；则启动目标服务，并执行步骤3304；若未启动，则提示 目标服务启动失败。

步骤3304，检测是否存在目标服务对应的目标服务代理；若存在，则执行步骤3305；若不存 在，则执行步骤3309。

步骤3305，通过目标服务代理转换目标调用请求中的初始调用信息为目标调用信息。

步骤3306，基于转换后的目标调用信息调用目标服务，以得到输出参数。

步骤3307，通过目标服务代理进行输出参数转换，以生成调用结果。

步骤3308，返回调用结果。

步骤3309，返回调用失败。

在另一种可能的实施方式中，目标服务为动态服务，服务治理模块12在服务器200获取到服 务器200发送的对应于目标服务的目标服务代码集合，从而根据目标调用信息运行目标服务代码集 合，从而实现目标服务的调用。

可选地，电子设备100需要根据目标服务的初始调用信息，确定该目标服务对应的目标服务代 理，并通过该目标服务代理进行参数转换，从而输出转换后的目标调用信息，以便基于目标调用信 息调用目标服务。

在一个示意性的例子中，动态服务的调用过程如图34所示。

步骤3401，向服务网关发起目标调用请求。

步骤3402，服务网关验证请求是否合法；若合法，则执行步骤3403，若不合法，则执行步骤 3410。

步骤3403，检测是否存在目标服务对应的目标服务代理；若存在，则执行步骤3404；若不存 在，则执行步骤3410。

步骤3404，通过目标服务代理转换目标调用请求中的初始调用信息为目标调用信息。

步骤3405，检测是否部署有目标服务；若已部署，则执行步骤3406；若未部署，则执行步骤 3407。

步骤3406，基于转换后的目标调用信息调用目标服务，以得到输出参数。

步骤3407，从应用仓库下载并部署目标服务，并基于转换后的目标调用信息调用目标服务，以 得到输出参数。

步骤3408，通过目标服务代理进行输出参数转换，以生成调用结果。

步骤3409，返回调用结果。

步骤3410，返回调用失败。

针对不同的服务调用类型，电子设备100完成服务调用后的后续步骤也存在差异。在一种可能 的实施方式中，在目标服务为同步调用服务的情况下，电子设备100获取目标服务的调用结果，从 而基于调用结果调用下一服务(直至完成该触发器下所有服务的调用)；在目标服务为异步调用服 务的情况下，电子设备100获取目标服务的服务输出事件，从而通过服务输出事件触发目标应用脚 本中的触发器。

其中，服务返回值可以是数据、文件、指令等等，比如截屏服务的返回值可以为截取到的图片； 服务输出事件所触发的触发器可以为目标触发器以外的触发器，也可以为目标触发器，本实施例对 此不作限定。

请参阅图35和图36，在某些实施方式中，服务运行主要的流程如下：

步骤3601，触发事件触发了设备A中特定的触发器。

步骤3602，设备A执行该触发器的控制逻辑。

步骤3603，设备A根据控制逻辑执行业务逻辑，改变状态信息并同步。一个或多个设备上的 状态信息是对等的，可保持应用运行所需的所有状态信息，并在一个设备上的状态信息发生变化时， 通过数据同步将所有设备的状态信息同步到最新状态。

在一个例子中，如图37所示，同一用户帐号下的不同设备在运行同一应用时，设备A部署了 服务1和服务2，设备B部署了服务1和服务3，而设备C部署了服务4和服务5。当设备B中服 务3被调用后，服务3的输出事件改变了状态信息，设备B即通过数据同步方式将状态信息同步至 设备A和设备C，以便设备A和设备C更新自身的状态信息。当设备C中服务5被调用后，服务5 的输出事件改变了状态信息，设备C即通过数据同步方式将状态信息同步至设备A和设备B，以便 设备A和设备B更新自身的状态信息。

通过上述同步机制，用户帐号下的各个设备对等，单个设备的掉线，并不会影响应用的运行。 比如，当通过双指叩击截取其他设备的屏幕图像并发送到当前设备时，用户叩击任意一台设备都能 完成此操作，并且任意设备掉线，并不会不影响其他设备的正常截屏。

步骤3604，服务治理模块12根据控制逻辑调用目标服务，目标服务可以通过服务网关进行调 用。如服务治理模块12通过服务网关调用设备C的服务2。目标服务可以是一个或多个，以列表 展示。如果服务列表只有一个服务，则直接调用该服务，如果有多个服务，则按照策略选择合适的 服务。

目前提供两种策略，策略1是弹出服务列表让用户自行选择；策略2则是根据用户信息、设备 信息、用户行为、服务信息等数据来协助用户自动确定目标服务，如根据用户运行该目标服务时的 历史使用信息来确定目标服务。

步骤3605，对于同步调用而言，应用运行时直接得到服务的返回值，并将这个返回值作为输入 参数以作为后续服务的输入值，如果有后续业务逻辑，则回到步骤3603，否则执行结束。

步骤3606，对于异步调用而言，被调用的服务在完成服务后，向设备A发送触发事件，设备A 响应触发事件，并触发特定的触发器，再次回到步骤3601。

请参阅图2、图3和图38，在某些实施方式中，初始调用信息包括注册调用信息和/或动态调用 信息；步骤04包括：

043：获取当前设备存储的目标服务的注册调用信息，和/或，获取其他服务生成的动态调用信 息；其中，注册调用信息用于表示目标服务相关的属性，动态调用信息用于表示运行目标服务所需 的输入变量；

044：根据注册调用信息和动态调用信息，确定目标调用信息。

在某些实施方式中，服务治理模块12还用于执行步骤043和步骤044。

在某些实施方式中，处理器20用于执行步骤043和步骤044。

具体地，初始调用信息包括注册调用信息和/或动态调用信息；其中，注册调用信息用于表示目 标服务相关的属性，其具体内容请参阅前述描述，在此不再赘述。动态调用信息则包括其他服务或 者电子设备100生成的输入变量，例如，目标服务的输入变量为目标服务集合中除目标服务之外的 其他服务生成的相关参数。

在根据目标调用信息运行目标服务时，将输入变量输入到目标服务，即可得到输出变量，从而 实现目标服务的运行。

具体调用过程可以是：目标服务暴露的接口为：POST http://xxx.x.x.x:8888/service/call，接口需 要获取如下信息：

{A:String,//类型信息

B:String,//调用服务的设备，如果调用目标服务的设备为当前设备，设置为“local”或者设置 为空，如果确定为其它设备调用目标服务，则需要指明其他设备的ID，如与手机连接的手表调用目 标服务时，输入手表的id即可通过手机直接控制手表调用目标服务。

C:[],//服务调用的入参列表(即输入变量)}

可以看到，在通过接口调用目标服务时，需要指定服务类型、服务所在设备(可以指定调用目 标服务的某个设备或者过滤掉某个设备)、和入参列表，其中，入参列表可包括输入变量。

目标服务根据上述信息即可输出输出参数，如当前设备调用云端的地图服务进行导航，则输入 参数中，类型信息为云端restful，调用服务的设备为“local”，输入变量包括目的地地址，目标服务 则输出导航路线及周边地图作为输出参数，从而实现导航。

在一个例子中，对于地铁场景，在用户搭乘地铁后，确定了目标服务为到站提醒服务，在用户 到达每一个站点时，均进行到站提醒，也即是说，调用到站提醒服务时，到站提醒服务会根据电子 设备100输入的位置信息(即作为输入变量)来输出站点信息，在输出的站点信息为目的站点时， 会根据目的站点(即作为输入变量)调用乘车码服务，从而输出乘车码信息。

在另一个例子中，对于跨端截屏场景，若检测到跨端截屏的触发事件(如当前电子设备100接 收到截屏手势)时，运行截屏手势服务，并将截屏手势作为输入变量请求调用其他电子设备100(如 与当前电子设备100登录同一账号的设备)的截屏服务，截屏服务根据截屏手势截屏后会发送截图 到当前电子设备100。

为方便理解，请参阅图39，下面以通过本申请的服务调度方法的整体运行流程进行说明。

如图中步骤S1和S2，本申请的服务由服务开发者开发并上传到服务器200。狭义是指开发者 根据预设的服务框架来开发的；广义是指一般服务开发商开发的服务，即不是按照预设的服务框架 来开发开的服务。

步骤S3，场景感知模块11感知应用场景。

步骤S4，电子设备100会根据交互信息检测触发事件。

步骤S5，在检测到触发事件后，服务治理模块12即可确定触发事件对应的触发器，从而确定 触发器中的控制逻辑对应的一个或多个目标服务。

步骤S6，若电子设备100本地没有目标服务，则从服务器200中下载目标服务并部署到电子设 备100。

步骤S7，若存在多个目标服务，则根据用户选择确定目标服务，或者自动根据用户信息、设备 信息、用户行为、服务信息等数据来协助用户自动确定目标服务。

步骤S8，将目标服务部署到电子设备100中并调用，目标服务可以在当前设备部署，或者在不 同系统或平台的其他设备部署，实现跨平台运行。

步骤S9，在调用目标服务时，服务治理模块12可发送目标调用请求到服务网关。

步骤S10，服务网关确定与目标调用请求中的服务类型对应服务代理，服务代理将注册调用信 息转换为目标调用信息，并发送目标调用信息到服务运行模块13。

步骤S11：服务运行模块13根据目标调用信息运行目标服务。

请结合图39和图40，在一个例子中，电子设备100的场景感知模块11根据位置信息确定应用 场景为购物场景，在用户到达停车场入口时，服务治理模块12检测到触发事件为“车位导航”， 服务治理模块12确定“车位导航”对应的触发器，并确定触发器中的控制逻辑对应的一个或多个 目标服务(如导航服务)，若电子设备100本地未部署导航服务，则从服务器200中下载导航服务 并部署。

在导航服务部署完成后，服务治理模块12调用导航服务，服务治理模块12发送目标调用请求 到服务网关，服务网关确定目标调用请求中的服务类型对应服务代理，服务代理将注册调用信息转 换为目标调用信息，并发送目标调用信息到服务运行模块13，服务运行模块13运行导航服务，以 指导用户停车到空车位。

在停车完成后，服务治理模块12检测到触发事件为“购物”，服务治理模块12确定“购物” 对应的触发器，并确定触发器中的控制逻辑对应的一个或多个目标服务(如购物服务)，若电子设 备100本地未部署购物服务，则从服务器200中下载购物服务并部署。

最后，服务治理模块12调用购物服务，服务治理模块12发送目标调用请求到服务网关，服务 网关确定目标调用请求中的服务类型对应服务代理，服务代理将注册调用信息转换为目标调用信息， 并发送目标调用信息到服务运行模块13，服务运行模块13运行购物服务，以指导用户进行购物， 例如对用户进行导航，快速指引用户找到所需的商品位置；或者，推荐商品；或者通过碰一碰商品 标签，将商品加入到购物车；或者，显示取货码等。

在某些实施方式中，本申请通过将应用服务化，提供了新的开发模型，一种分层开发模型。

具体地，系统提供通用的机制，屏蔽应用相关的复杂细节。服务开发者只需提供功能单一的服 务，这些服务可以被多个应用所使用。服务开发者可以是普通开发者。应用开发者关注业务的逻辑， 系统提供代码/低代码的开发方式。应用开发者可以是普通开发者或是普通用户，降低了开发门槛， 扩大了开发者的基础。

应用的开发分三种角色，对外部开发者而言，主要分为服务开发者，以及应用开发者。

服务作为应用的组成要素，主要的流程为：

1.开发服务。

本申请的应用商店理论上可以接入任意操作系统、平台的服务，因此，开发者可以保持原有的 开发方式，Windows、Android、Cloud等不同平台的开发者可以使用他们熟悉的技术来开发相关服 务。

2.动态服务提交至服务器200。

系统提供了一些动态服务的机制，如果开发者开发的是系统提供的动态服务，则开发者完成服 务的开发后，需要将服务打包后提交至服务器200。

3.应用商店接入服务。

服务开发的主要子流程如下：

1.第三方服务提供商在应用商店中发布服务，指定服务的名称以及服务的说明等相关信息。

2.第三方服务调用的方式，包括调用路径，以及输入参数、输出参数、输入参数和输出参数之 间的转换规则等。

3.第三方服务安装的信息，有两种，一种是预安装的服务，如播放一个视频的服务随着爱奇艺 这个应用的安装而获得，需指定宿主应用的信息以及支持的版本；一种是动态服务，动态服务的代 码在服务器200，可以动态部署到指定设备上，需指定动态服务的类型，以及动态服务在应用商店 的地址。

4.提交服务后，由应用商店进行服务审核，若通过，则可以在应用开发工具中看到此服务。

应用开发者的开发流程：

将提供从代码、低代码、无代码等不同层级的应用开发工具，让专业开发者和普通用户都可以 开发应用。

在某些实施方式中，用户可分享应用。

应用基于用户运行，在不同的用户间，系统提供了统一的框架，支持不同的用户间分享共享应 用。应用开发者只需在打包应用时，指定相关的分享共享交互(如碰一碰、二维码、短信、微信等)， 不需要额外的代码开发，即可实现应用在不同用户间的分享共享，并提供一套机制来授权、撤回分 享共享，保证行为的安全。

这种机制将极大的提升应用的体验：如应用共享剪贴板，让用户名下的设备可以共享复杂粘贴， 如果和好友的手机碰一碰，则可以在你的手机上复制内容，在好友的手机上可以直接粘贴。多机位 相机应用能让你照相时能选择你名下所有设备的摄像头，如果和朋友的手机碰一碰，则可以选择他 的手机的摄像头；如手机上的批量图片处理应用，和好友的手机一碰，处理的速度提升一倍，和电 脑碰一碰，处理速度提升3倍。

或者，如协同画板，用户的多个设备可以协同涂鸦，可以运行在任意设备和系统之上，并可以 在用户的设备流转；如果和其他用户的手机碰一碰，或者发送链接给其他用户，则可以一起来涂鸦。 如超级游戏将运行游戏的宿主设备上的音频、视频、控制能力分布到不同的目标设备上的方式，实 现一个游戏进程在多个目标设备之间的共享的能力；如果和其他用户的手机碰一碰，就可以把当前 游戏的画面、声音、控制等能力转移到其他用户的手机上。

基于上述实施方式，本申请的应用有如下特征：

1.相比于传统应用跟着设备走，本申请的应用跟着人走，用户通过订阅服务来获取与自身绑定 的应用，应用只和用户绑定，而不与具体的设备绑定。

2.本申请的应用天然是分布式的，应用的不同的服务可被部署到同一设备，或被差分部署到不 同的设备上，在不同的设备上执行不同的任务，可支持多设备运行。

3.本申请的应用支持异构操作系统，通过服务网关实现初始调用信息到目标调用信息的转换， 使得应用(如图4中的应用3)的服务可以是不同操作系统上的服务，从而可以跨多种平台运行。

4.本申请的应用中的服务可以支持动态部署，即用户需要使用该服务时才从应用商店下载，从 而支持即点即用的用户使用体验。

5.本申请的应用的定义在不同的设备上是一致的，保证了用户使用体验的一致；且通过多个设 备实现同一应用的功能时，由于不同设备的业务逻辑可能不同，因此不同设备部署的服务也可能存 在差异，应用的服务集合在不同设备上不一样的，具有差分部署的特性，从而可以利用不同设备的 特性。

6.本申请的应用是一种服务组装的应用，服务可以被多个应用所使用，应用由多个服务组合而 成，服务具有高度复用性，降低了开发难度。

7.本申请的可视化开发工具降低了开发门槛，让普通用户也能开发微应用，特别是设备特性相 关微应用，提升设备的使用体验。

8.本申请提供了第三方应用开发者接入的入口，第三方服务只需指定服务名称和说明、及服务 的调用方式等信息，即可让第三方应用在不修改原有应用的前提下，很方便的接入系统。

9.本申请的用户订阅系统让个性化设备体验成为可能，由于应用与用户绑定，因此相同的设备 在切换不同的用户后，用户对应的应用也是不同的，使得用户通过订阅不同的应用能让相同的设备 在不同的用户手中具有不同的特性。

10.本申请的特有的分享共享系统，如应用共享剪贴板，可以让微应用在不同的用户间也可以 产生效果，增加了互动体验。

请参阅图41，示出了本申请一个示例性实施例提供的服务调度系统1000的架构图。该系统中 包括至少一个电子设备100以及服务器200。

在一种可能的实施方式中，电子设备100中设置有服务治理模块12，服务治理模块12作为控 制应用运行的核心，包括脚本管理模块1211、事件总线模块1212、应用调度模块1213、运行时模 块1214以及服务调度模块1215。

脚本管理模块1211用于管理电子设备100中存储的各个应用的应用脚本，并负责对应用脚本 进行解析，以此确定该应用脚本中的触发器以及触发器下的服务。可选地，脚本管理模块1211还 用于在接收到对应用的订阅操作时，下载相应的应用脚本，在接收到对应用的订阅取消操作时，删 除应用对应的应用脚本。

事件总线模块1212用于与应用调度模块1213进行配合，基于触发事件实现应用调度。

在一些实施例中，事件总线模块1212下挂载有多个应用对应的触发器，由于同一触发事件可 能会触发多个订阅的应用，因此事件总线模块1212接收到触发事件后，交由应用调度模块1213从 若干个应用中确定出需要运行的应用。其中，应用调度模块1213可以基于调度策略自动确定应用， 也可以交由用户手动选择应用。

运行时模块1214用于执行应用脚本中的控制逻辑，从而基于该控制逻辑与服务调度模块1215 进行交互，由服务调度模块1215进行服务调用。

此外除了设置有服务治理模块12外，电子设备100中还设置有数据同步模块14以及服务网关 15。

其中，数据同步模块14用于在服务治理模块12的状态发生变更时(比如服务产生的事件导致 状态变更)，向其他设备进行状态同步，确保不同设备的状态信息一致性。

服务网关15用于基于服务调度模块1215的目标调用请求进行服务调用，具体包括代理管理模 块151以及生命周期管理模块152。代理管理模块151中设置有不同的服务代理，服务代理用于将 统一格式的目标调用请求的初始调用信息进行转换，得到符合电子设备100的目标调用信息。

生命周期管理模块152用于管理服务的生命周期。

应用运行过程中，电子设备100除了可以通过自身的服务网关15进行服务调用外，还可以通 过其他设备或服务器200的服务网关15进行服务调用(由应用的业务逻辑决定)，即可以实现跨 设备的服务调用。

针对不同部署方式的服务，如图41所示，电子设备100中还设置有静态服务模块16和动态服 务模块17。静态服务模块16用于管理预安装的静态服务，动态服务模块17则用于管理动态部署的 动态服务。

在一些实施例中，动态服务模块17中包含的服务可以对应不同运行环境、不同部署形态或不 同编程开发语言。图41中以动态服务模块17包含安卓动态服务1251、Web动态服务1252以及容 器动态服务1253为例进行示意性说明，但并不对此构成限定。

服务器200是一台服务器、若干台服务器构成的服务集群或云计算中心。根据服务器集群中各 服务器所实现功能进行划分，如图41所示，服务器集群中包括用户资源管理服务器212、应用商店 服务器222、服务市场服务器223以及云端服务库224。

用户资源管理服务器212用于对使用应用的用户帐号进行管理、对不同用户帐号下订阅的应用 进行管理、对调用的服务进行管理、对用户帐号与设备之间的绑定关系进行管理、在交互过程中进 行安全性验证。

应用商店服务器222用于提供应用订阅服务。用户需要使用应用时，可以通过应用商店服务器 222提供的应用搜索引擎进行应用搜索，进而从搜索结果中选择订阅应用。

在一些实施例中，应用商店服务器222接收到对应用的订阅操作后，将用户帐号与所订阅应用 的服务标识发送至用户资源管理服务器212，由用户资源管理服务器212更新用户帐号与应用的订 阅关系。进一步的，用户资源管理服务器212还用于确定该用户帐号下的其他设备，并向其他设备 推送订阅通知，以便其他设备从应用商店服务器222处下载应用的应用脚本。示意性的，如用户“张 三”通过智能手机订阅应用后，登陆“张三”这一用户帐号的车机和平板电脑接收到用户资源管理 服务器221推送的订阅通知，从而基于通知中的服务标识下载应用的应用脚本。

服务市场服务器223是面向开发者的，用于提供服务查询服务的服务器。开发者可以通过服务 市场服务器223提供的服务搜索引擎进行服务搜索，并将搜索到的服务应用于开发的应用中，进而 将开发完成的应用上传至应用商店服务器222，供其他用户下载使用。

除此之外，开发者也可以进行动态服务开发，并将开发的动态服务上传至应用商店服务器222。

后续电子设备100即可从应用商店服务器222处下载并部署动态服务。

需要说明的是，上述实施例仅对系统的基础架构进行了说明，系统中还可以包括其他计算机设 备(比如开发者设备)或实现其他功能的服务器，本实施例并不对此构成限定。下面基于上述服务 调度系统1000结合具体例子进行解释说明。具体以用户实现跨端截屏应用为例进行说明：

具体地，请结合图41和图42，用户通过应用市场订阅跨端截屏应用。用户资源管理服务器221 推送包含跨端截屏应用的服务标识的订阅通知到用户账户下的所有设备，以方便后续进行服务部署。

其中，跨端截屏应用包括双指叩击服务、图片显示服务以及截屏服务。其中，用户账户下的所 有设备的脚本管理模块1211对应用脚本进行解析，根据解析内容确定需要先部署双指叩击服务。

用户可以在任一设备(如图43所示的手机101)上进行双指敲击动作，从而触发截屏事件，事 件总线模块1212和应用调度模块1213根据截屏事件确定需要运行的服务，然后由服务调度模块 1215调度双指叩击服务，运行双指叩击服务后，该获取其他设备的截屏图像的目标调用请求发送到 其他设备(如图43所示的电脑102)，电脑102的服务网关15中的代理管理模块151确定该目标 调用请求的服务代理，然后对目标调用请求中的初始调用信息进行转换，以生成目标调用信息，电 脑102中的事件总线模块1212和应用调度模块1213配合确定需要部署并运行的服务(如截屏服务)， 服务调度模块1215根据目标调用信息调度截屏服务，以获取截屏图像，并将包含截屏图像的调用 请求再次发送给手机101。

手机的服务网关15中的代理管理模块151确定电脑发送的目标调用请求对应的服务代理，然 后对目标调用请求中的初始调用信息进行转换，以生成目标调用信息，事件总线模块1212和应用 调度模块1213配合确定需要部署和运行的服务(如图片显示服务)，服务调度模块1215根据目标 调用信息调度图片显示服务，图片显示服务根据目标调用信息包含的截屏图像显示电脑102的截屏 图像并可进行保存，从而实现跨端截屏。

然后根据应用脚本中的控制逻辑，调用除被敲击的设备之外的其他设备的截屏服务，确定执行 的业务逻辑应该是截屏并发送，从而下载并动态部署截屏服务，并调用截屏服务对当前设备画面进 行截屏，并反馈至手机。手机接收到其他设备反馈的截屏图片后，调用图片显示服务实现截屏展示。

请参阅图43，本申请实施方式还提供一种包含计算机程序301的非易失性计算机可读存储介质 300。当计算机程序301被一个或多个处理器20执行时，使得一个或多个处理器20执行上述任一 实施方式的出行服务方法。

请结合图1，例如，计算机程序301被一个或多个处理器20执行时，使得处理器20执行以下 出行服务方法：

01：确定当前所处的应用场景，确定与应用场景对应的服务集合；

02：根据出行信息、当前时间和当前位置确定触发事件；

03：在应用场景下检测到触发事件的情况下，确定服务集合中对应于触发事件的目标服务；

04：确定目标服务的初始调用信息，根据初始调用信息确定目标调用信息，目标调用信息与运 行目标服务的电子设备匹配；及

05：根据目标调用信息运行目标服务。

请结合图6，再例如，计算机程序301被一个或多个处理器20执行时，使得处理器20执行以 下出行服务方法：

021：根据出行时间和目的地确定出行类型；及

022：根据出行类型、出行时间、目的地、当前时间和当前位置，确定触发事件。

在本说明书的描述中，参考术语“某些实施方式”、“一个例子中”、“示例地”等的描述意指结合 实施方式或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施方式或示例中。 在本说明书中，对上述术语的示意性表述不一定指的是相同的实施方式或示例。而且，描述的具体 特征、结构、材料或者特点可以在任何的一个或多个实施方式或示例中以合适的方式结合。此外， 在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实 施例或示例的特征进行结合和组合。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个 用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选 实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基 本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理 解。

尽管上面已经示出和描述了本申请的实施方式，可以理解的是，上述实施方式是示例性的，不 能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施方式进行变化、 修改、替换和变型。

Claims (22)

1.一种出行服务方法，其特征在于，包括：

确定当前所处的应用场景，确定与所述应用场景对应的服务集合；

根据出行信息、当前时间和当前位置确定触发事件；

在所述应用场景下检测到所述触发事件的情况下，确定所述服务集合中对应于所述触发事件的目标服务；

确定所述目标服务的初始调用信息，根据所述初始调用信息确定目标调用信息，所述目标调用信息与运行所述目标服务的电子设备匹配；

根据所述目标调用信息运行所述目标服务。

2.根据权利要求1所述的出行服务方法，其特征在于，所述出行信息包括出行时间和目的地，所述根据出行信息、当前时间和当前位置确定触发事件，包括：

根据所述出行时间和所述目的地确定出行类型；及

根据所述出行类型、所述出行时间、所述目的地、所述当前时间和所述当前位置，确定所述触发事件。

3.根据权利要求2所述的出行服务方法，其特征在于，所述出行时间包括抵达时间，所述出行类型包括回家、旅游和出差，所述触发事件包括出站、打车、订酒店和查旅游攻略中至少一种，所述根据所述出行类型、所述出行时间、所述目的地、所述当前时间和所述当前位置，确定所述触发事件，包括：

在所述出行类型为回家且所述当前时间和所述抵达时间的时间差小于第一预设时间差时、或在所述出行类型为回家且所述当前位置和所述目的地对应的车站的距离小于预设距离时，确定所述触发事件为出站和打车；

在所述出行类型为出差且所述当前时间和所述抵达时间的时间差小于所述第一预设时间差时、或在所述出行类型为出差且所述当前位置和所述目的地对应的车站的距离小于所述预设距离时，确定所述触发事件为出站、打车和订酒店；

在所述出行类型为旅游且所述当前时间和所述抵达时间的时间差小于所述第一预设时间差时、或在所述出行类型为旅游且所述当前位置和所述目的地对应的车站的距离小于所述预设距离时，确定所述触发事件为出站和查旅游攻略。

4.根据权利要求3所述的出行服务方法，其特征在于，所述确定所述服务集合中对应于所述触发事件的目标服务，包括：

在所述触发事件为出站和打车时，获取与出站匹配的提醒服务和与打车匹配的打车服务；

所述根据所述目标调用信息运行所述目标服务，包括：

根据所述抵达时间控制所述提醒服务发出提示信息，并启动打车服务打车到所述目的地；

所述确定所述服务集合中响应于所述触发事件的目标服务，包括：

在所述触发事件为出站、打车和订酒店时，获取与出站匹配的提醒服务、与打车匹配的打车服务、和与订酒店匹配的住宿服务；

所述根据所述目标调用信息运行所述目标服务，包括：

根据所述抵达时间控制所述提醒服务发出提示信息，并启动打车服务打车到所述目的地；

在打车服务完成后，启动住宿服务并提供以所述目的地为中心的预定范围内酒店的信息，以完成订酒店服务；

所述确定所述服务集合中响应于所述触发事件的目标服务，包括：

在所述触发事件为出站和查旅游攻略时，获取与出站匹配的提醒服务、和与查旅游攻略匹配的攻略服务；

所述根据所述目标调用信息运行所述目标服务，包括：

根据所述抵达时间控制所述提醒服务发出提示信息，并启动攻略服务并提供所述目的地的攻略信息。

5.根据权利要求4所述的出行服务方法，其特征在于，所述根据所述抵达时间控制所述提醒服务发出提示信息，包括：

控制电子设备或与所述电子设备通信连接的手表发出所述提示信息。

6.根据权利要求1所述的出行服务方法，其特征在于，所述出行信息还包括出发地和出发时间，所述根据出行信息、当前时间和当前位置确定触发事件，还包括：

在所述当前时间和所述出发时间的时间差小于所述第二预设时间差时，确定所述触发事件为出发；

在所述当前位置与所述出发地对应的车站的距离小于第二预设距离、且所述当前时间和所述出发时间的时间差大于所述第三预设时间差时，确定所述触发事件为候车，所述第三预设时间差小于所述第二预设时间差。

7.根据权利要求6所述的出行服务方法，其特征在于，所述确定所述服务集合中对应于所述触发事件的目标服务，包括：

在所述触发事件为出发时，获取与出发匹配的提醒服务；

所述根据所述目标调用信息运行所述目标服务，包括：

根据所述出发时间控制所述提醒服务发出提示信息；

所述确定所述服务集合中响应于所述触发事件的目标服务，包括：

在所述触发事件为候车时，获取与候车匹配的候车服务，所述候车服务包括多种；

所述根据所述目标调用信息运行所述目标服务，包括：

启动与候车时长匹配的候车服务，所述候车时长根据所述当前时间和所述出发时间的时间差确定。

8.根据权利要求7所述的出行服务方法，其特征在于，所述候车服务包括第一候车服务和第二候车服务，所述第一候车服务包括影音服务、游戏服务和看书服务中至少一种，所述第二候车服务包括咖啡服务、听书服务和闹钟服务中至少一种，所述启动与候车时长匹配的候车服务，包括：

在所述候车时长大于第一预定候车时长时，启动所述第一候车服务；

在所述候车时长大于第二预定候车时长且小于所述第一预定候车时长时，启动所述第二候车服务，所述第二预定候车时长小于所述第一预定候车时长。

9.根据权利要求1所述的出行服务方法，其特征在于，还包括：

接收输入操作，以获取输入信息；

根据所述输入信息确定所述出行信息；或者，

根据订票信息和/或行程信息确定所述出行信息。

10.根据权利要求1所述的服务调度方法，其特征在于，所述确定当前所处的应用场景，包括：

获取交互信息，根据所述交互信息确定当前所处的应用场景。

11.根据权利要求1所述的服务调度方法，其特征在于，所述确定与所述应用场景对应的服务集合，包括：

确定所述应用场景对应的应用脚本，其中，所述应用脚本中包括至少一个服务标识；

将所述应用脚本中所有所述服务标识对应的服务所构成的集合，作为所述服务集合。

12.根据权利要求11所述的服务调度方法，其特征在于，所述确定所述应用场景对应的应用脚本，包括：

确定所述应用场景对应的服务清单；

根据所述服务清单中包含的至少一个服务标识，生成所述应用场景对应的应用脚本。

13.根据权利要求12所述的服务调度方法，其特征在于，所述根据所述服务清单中包含的至少一个服务标识，生成所述应用场景对应的应用脚本，包括：

根据所述服务清单中包含的至少一个服务标识，生成所述应用场景对应的初始应用脚本；

获取对所述初始应用脚本的编辑数据，基于所述编辑数据对所述初始应用脚本进行调整，得到所述应用场景对应的应用脚本。

14.根据权利要求11所述的服务调度方法，其特征在于，所述在所述应用场景下检测到触发事件的情况下，确定所述服务集合中对应于所述触发事件的目标服务，包括：

在所述应用场景下检测到触发事件的情况下，触发所述触发事件在所述应用脚本中对应的目标触发器；

通过所述目标触发器调用对应的目标控制逻辑，根据所述目标控制逻辑确定所述服务集合中响应于所述触发事件的目标服务。

15.根据权利要求1所述的服务调度方法，其特征在于，所述确定所述目标服务的初始调用信息，根据所述初始调用信息确定目标调用信息，包括：

发起对所述目标服务的目标调用请求，其中，所述目标调用请求中包含所述目标服务的初始调用信息；

根据所述目标调用请求中的初始调用信息调用对应的服务代理，通过所述服务代理确定所述初始调用信息对应的目标调用信息。

16.根据权利要求15所述的服务调度方法，其特征在于，所述初始调用信息中包括服务类型和注册调用信息；所述根据所述目标调用请求中的初始调用信息调用对应的服务代理，通过所述服务代理确定所述初始调用信息对应的目标调用信息，包括：

调用所述服务类型对应的服务代理，按照预定格式将所述注册调用信息转换为对应的目标调用信息。

17.根据权利要求1和权利要求10至16中任一项所述的服务调度方法，其特征在于，所述根据所述目标调用信息运行所述目标服务，包括：

在所述目标服务为第一服务类型的情况下，根据所述目标调用信息运行所述目标服务；

在所述目标服务为第二服务类型的情况下，确定所述目标服务对应的宿主服务，在所述宿主服务处于运行状态的情况下，根据所述目标调用信息运行所述目标服务。

18.根据权利要求1和权利要求10至16中任一项所述的服务调度方法，其特征在于，所述初始调用信息包括注册调用信息和/或动态调用信息；所述确定所述目标服务的初始调用信息，根据所述初始调用信息确定目标调用信息，包括：

获取当前设备存储的所述目标服务的注册调用信息，和/或，获取其他服务生成的动态调用信息；其中，所述注册调用信息用于表示所述目标服务相关的属性，所述动态调用信息用于表示运行所述目标服务所需的输入变量；

根据所述注册调用信息和所述动态调用信息，确定目标调用信息。

19.根据权利要求1和权利要求10至16中任一项所述的服务调度方法，其特征在于，所述确定所述目标服务的初始调用信息，包括：

接收服务器发送的对应于所述目标服务的初始调用信息；

所述根据所述目标调用信息运行所述目标服务，包括：

在所述目标服务为当前设备的本地化服务的情况下，获取所述当前设备存储的目标服务代码集合，根据所述目标调用信息运行所述目标服务代码集合；

在所述目标服务为当前设备的非本地化服务的情况下，获取所述服务器发送的对应于所述目标服务的目标服务代码集合，根据所述目标调用信息运行所述目标服务代码集合。

20.一种出行服务装置，其特征在于，包括：

场景感知模块，用于确定当前所处的应用场景，确定与所述应用场景对应的服务集合；

服务治理模块，用于根据出行信息、当前时间和当前位置确定触发事件；在所述应用场景下检测到触发事件的情况下，确定所述服务集合中对应于所述触发事件的目标服务；确定所述目标服务的初始调用信息，根据所述初始调用信息确定目标调用信息，所述目标调用信息与运行所述目标服务的电子设备匹配；及

服务运行模块，用于根据所述目标调用信息运行所述目标服务。

21.一种电子设备，其特征在于，所述电子设备包括处理器，所述处理器用于确定当前所处的应用场景，确定与所述应用场景对应的服务集合；根据出行信息、当前时间和当前位置确定触发事件；在所述应用场景下检测到所述触发事件的情况下，确定所述服务集合中对应于所述触发事件的目标服务；确定所述目标服务的初始调用信息，根据所述初始调用信息确定目标调用信息，所述目标调用信息与运行所述目标服务的电子设备匹配；根据所述目标调用信息运行所述目标服务。

22.一种包括计算机程序的非易失性计算机可读存储介质，所述计算机程序被处理器执行时，使得所述处理器执行权利要求1-19任意一项所述的出行服务方法。

Images