CN114217989A

CN114217989A - 设备间的服务调用方法、装置、设备、介质及计算机程序

Info

Publication number: CN114217989A
Application number: CN202111520224.1A
Authority: CN
Inventors: 胡海清
Original assignee: Hangzhou Douku Software Technology Co Ltd
Current assignee: Hangzhou Douku Software Technology Co Ltd
Priority date: 2021-12-13
Filing date: 2021-12-13
Publication date: 2022-03-22

Abstract

本申请实施例公开了一种设备间的服务调用方法、装置、终端及存储介质，属于多设备协同领域。本申请能够在本端的注册中心中发现第一服务，在发现后根据该服务的定义信息获知被调用方支持的第一服务协议，再基于本端支持第一服务协议的情况，相应的处理第一服务协议的服务参数，得到跨端参数，使得自身既能够传输该跨端参数，也能够令被调用方根据跨端参数解析出自身支持的第一服务协议中的服务参数，实现了调用方和被调用方支持的协议的不同的场景下，调用方也能够自由调用相应的服务的效果，突破了设备间因操作系统和支持通信协议的不同而造成的无法调用服务的技术难题，提高了设备之间的协作能力。

Description

设备间的服务调用方法、装置、设备、介质及计算机程序

技术领域

本申请实施例涉及多设备协同领域，特别涉及一种设备间的服务调用方法、装置、终端及存储介质。

背景技术

设备间的服务调用，用于指示不同的设备之间能够通过指定的策略进行联动。

相关技术中，当安装有目标操作系统的第一设备需要调用第二设备中的服务时，需要第二设备中同样安装有目标操作系统。并且，该目标操作系统具有软总线的功能。在此情况下，第一设备能够通过与第二设备之间的网络连接，询问第二设备中是否存在指定的服务。在第二设备中存在指定的服务时，第一设备再调用第二设备中的指定的服务。

发明内容

本申请实施例提供了一种设备间的服务调用方法、装置、终端及存储介质，可以提高设备之间的协作能力。所述技术方案如下：

根据本申请的一方面内容，提供了一种设备间的服务调用方法，应用于调用方中，所述方法包括：

从所述调用方本地的服务注册中心中发现第一服务，所述服务注册中心用于存储所述调用方中已注册的服务和被调用方中已注册的服务，所述第一服务是所述被调用方中的已注册的服务；

解析所述第一服务的定义信息，得到所述被调用方支持的第一服务协议；

响应于所述调用方不支持所述第一服务协议，将所述服务参数按照第二服务协议的规范进行转化，得到跨端参数，所述服务参数用于提供给所述第一服务以获取相应的服务结果，所述跨端参数是所述调用方支持的所述第二服务协议中的参数；

基于所述跨端参数调用所述第一服务。

根据本申请的另一方面内容，提供了一种设备间的服务调用方法，应用于被调用方中，所述方法包括：

从调用方接收跨端参数，所述跨端参数是所述调用方支持的第二服务协议中的参数；

转化所述跨端参数，得到所述被调用方支持的第一服务协议中的服务参数；

基于所述服务参数运行所述第一服务，得到服务结果；

向所述调用方反馈所述服务结果。

根据本申请的另一方面内容，提供了一种设备间的服务调用装置，应用于调用方中，所述装置包括：

服务发现模块，用于从所述调用方本地的服务注册中心中发现第一服务，所述服务注册中心用于存储所述调用方中已注册的服务和被调用方中已注册的服务，所述第一服务是所述被调用方中的已注册的服务；

协议获取模块，用于解析所述第一服务的定义信息，得到所述被调用方支持的第一服务协议；

第一转化模块，用于响应于所述调用方不支持所述第一服务协议，将所述服务参数按照第二服务协议的规范进行转化，得到跨端参数，所述服务参数用于提供给所述第一服务以获取相应的服务结果，所述跨端参数是所述调用方支持的所述第二服务协议中的参数；

服务调用模块，用于基于所述跨端参数调用所述第一服务。

根据本申请的另一方面内容，提供了一种设备间的服务调用装置，应用于被调用方中，所述装置包括：

参数接收模块，用于从调用方接收跨端参数，所述跨端参数是所述调用方支持的第二服务协议中的参数；

第二转化模块，用于转化所述跨端参数，得到所述被调用方支持的第一服务协议中的服务参数；

服务运行模块，用于基于所述服务参数运行所述第一服务，得到服务结果；

结果反馈模块，用于向所述调用方反馈所述服务结果。

根据本申请的另一方面内容，提供了一种调用方设备，所述调用方设备包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如本申请各个方面提供的设备间的服务调用方法。

根据本申请的另一方面内容，提供了一种被调用方设备，所述被调用方设备包括处理器和存储器，所述存储器中存储有至少一条指令，所述指令由所述处理器加载并执行以实现如本申请各个方面提供的设备间的服务调用方法。

根据本申请的另一方面内容，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现如本申请各个方面提供由调用方执行的设备间的服务调用方法。

根据本申请的另一方面内容，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令，所述指令由处理器加载并执行以实现如本申请各个方面提供由被调用方执行的设备间的服务调用方法。

根据本申请的一个方面，提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实现方式中提供的由调用方执行的设备间的服务调用方法。

根据本申请的一个方面，提供了一种计算机程序产品，该计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各种可选实现方式中提供的由被调用方执行的设备间的服务调用方法。

本申请实施例提供的技术方案带来的有益效果可以包括：

由于本申请实施例能够在本端的注册中心中发现第一服务，在发现后根据该服务的定义信息获知被调用方支持的第一服务协议，再基于本端支持第一服务协议的情况，相应的处理第一服务协议的服务参数，得到跨端参数，使得自身既能够传输该跨端参数，也能够令被调用方根据跨端参数解析出自身支持的第一服务协议中的服务参数，实现了调用方和被调用方支持的协议的不同的场景下，调用方也能够自由调用相应的服务的效果，突破了设备间因操作系统和支持通信协议的不同而造成的无法调用服务的技术难题，提高了设备之间的协作能力。

附图说明

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

图1是H系统提供的一种系统架构示意图；

图2是H系统提供的一种分布式软总线的核心子系统的架构图；

图3是H系统提供的分布式任务调度的架构图；

图4是本申请一个示例性实施例提供的一种调用方的结构框图；

图5是本申请一个示例性实施例提供的一种被调用方的结构框图；

图6是本申请一个示例性实施例提供的一种设备间的服务调用方法所应用的实施环境图；

图7是本申请一个示例性实施例提供的另一种设备间的服务调用方法所应用的实施环境图；

图8是本申请实施例提供的一种示例性实施例提供的另一种设备间的服务调用方法所应用的实施环境图；

图9是本申请一个示例性实施例提供的一种设备间的服务调用方法的流程图；

图10是本申请一个示例性实施例提供的一种设备间的服务调用方法的流程图；

图11是本申请另一个示例性实施例提供的一种设备间的服务调用方法流程图；

图12是本申请实施例示出的一种设备间的服务调用的系统架构图；

图13是本请实施例提供的一种服务注册的流程示意图；

图14是本申请实施例示出的一种设备间的服务同步的流程示意图；

图15是本申请实施例提供的一种服务发现的示意图；

图16是本申请实施例提供的一种服务调用的流程示意图；

图17是本申请一个示例性实施例提供的一种设备间的服务调用装置的结构框图；

图18是本申请一个示例性实施例提供的另一种设备间的服务调用装置的结构框图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

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

在本申请的描述中，需要理解的是，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性。在本申请的描述中，需要说明的是，除非另有明确的规定和限定，术语“相连”、“连接”应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或一体地连接；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连。对于本领域的普通技术人员而言，可以具体情况理解上述术语在本申请中的具体含义。此外，在本申请的描述中，除非另有说明，“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

如本文中所使用，根据上下文，术语“如果”任选地被解释为“当......时”、“在……时”、“响应于确定”或“响应于检测”。类似地，根据上下文，短语“如果确定……”或“如果检测到(所陈述的条件或事件)时”或“响应于检测到(所陈述的条件或事件)”。

需要说明的是，使用个人可识别信息应遵循公认为满足或超过维护用户隐私的行业或政府要求的隐私政策和做法。具体地，个人可识别信息在管理和处理的过程中应当向用户明确说明授权使用的性质，以使无意或未经授权的访问或使用的风险最小化。

在一些实施方式中，存在能够提供分布式软总线的核心子系统和分布式任务调度的核心子系统的H系统。H系统能够跨端发现和调度相应的服务。需要说明的是，请参见图1，图1是H系统提供的一种系统架构示意图。

在图1中，H系统包括应用层110、框架层120、系统服务层130和内核层140。其中，应用层110包括桌面应用、控制栏应用、设置应用、电话应用以及其它系统应用，另外应用110还包括扩展应用和三方应用。框架层120包括UI(用户界面，User Interface)框架、用户程序框架和能力(Ability)框架。系统服务层130包括分布式任务调度核心子系统、分布式数据管理核心子系统、分布式软总线核心子系统、方舟多语言运行时子系统和公共基础库子系统。

需要说明的是，H系统还提供多个子系统集，每一个子系统集均同时被框架层和系统服务层支持。H系统中的子系统集包括：系统基本能力子系统集、基础软件服务子系统集、增强软件服务子系统集和硬件服务子系统集。其中，系统基本能力子系统集包括多模输入子系统151、图形子系统152、安全子系统153和AI(Artificial Intelligence，人工智能)子系统154。基础软件服务子系统集包括事件通知子系统161、电话子系统162、多媒体子系统163、DFX(Design For X，面向X的设计)子系统164和MSDP&DP子系统165。增强软件服务子系统集包括智慧屏专有业务子系统171、穿戴专有业务子系统172、IOT专有业务子系统173。硬件服务子系统集包括位置服务子系统181、生物特征识别子系统182、穿戴专有硬件服务子系统183和IOT专有硬件服务子系统184。

内核层140可以包括内核子系统和驱动子系统两个部分。其中，内核子系统可以是Linux Kernel或LiteOS。驱动子系统可以是HDF(硬件驱动框架)。

针对H系统的跨端调度服务的能力，介绍如下。H系统中的分布式软总线实现近场设备间统一的分布式通信管理能力，提供不区分链路的设备间发现连接、组网和传输能力，主要功能如下：(1)发现连接，提供基于WiFi(Wireless Fidelity，无线保真)、蓝牙等通信方式的设备发现连接能力。(2)设备组网：提供统一的设备组网和拓扑管理能力，为数据传输提供已组网设备信息。(3)数据传输：提供数据传输通道，支持消息、字节数据传输等能力。业务方通过使用分布式软总线提供的API(Application Programming Interface，应用程序接口)实现设备间的高速通信，不用关心通信细节，进而实现业务平台的高效部署与运行能力，结构图可以参见图2。

请参见图2，图2是H系统提供的一种分布式软总线的核心子系统的架构图。在图2中，分布式软总线的核心子系统2A包括组网及拓扑管理模块211、发现模块212、连接模块213、传输模块214、RPC模块215和WLAN服务模块216。

与分布式软总线的核心子系统2A相连的，包括场景化能力集2B、应用层2C、软硬协同子系统2D和Kernel层2E。其中，软硬协同子系统2D中包括WLAN模块和蓝牙模块。

请参见图3，图3是H系统提供的分布式任务调度的架构图。在图3所示的架构中，包括应用层310、框架层320、系统服务层330和内核层340。其中，应用层310中包括分布式音乐311、分布式计算机312、分布式相机313和分布式导航314。框架层320包括Application(应用)321、TaskDispatcher(任务分发系统)322、Context(上下文)323和App ManagerService Proxy(应用管理器服务代理)324。系统服务层330包括分布式任务调度3A、系统服务管理3B、应用管理服务3C、分布式数据库3D、包管理服务3E、系统服务3F、安全子系统3G和分布式软总线3H。

在系统服务层330中，分布式任务调度包括分布式框架3A和系统服务管理3B。分布式框架3A包括远程启动3A1、远程解绑3A2、组件迁移3A3、远程绑定与调用3A4、绑定关系管理3A5和分布式权限控制3A6。系统服务管理3B包括服务注册及发现功能3B1、SA启动框架3B2、服务远程调用功能3B3。应用管理服务3C包括应用管理功能。分布式数据库3D包括数据同步功能。包管理服务3E包括FA/PA管理、FA/PA信息同步、FA/PA信息查询。系统服务3F包括多媒体子系统和图形子系统。安全子系统3G包括权限控制、绑定认证和群组校验。分布式软总线3H包括发现功能、连接功能和传输功能。

在内核层340中，包括HAL(统一多形态服务调用接口)和Kernel(支持多形态设备的内核及驱动)。

根据图1至图3所示的技术架构，H系统不支持异构系统的服务发现和调用。具体而言，H系统分布式软总线和分布式任务调度子系统，给上层分布式应用提供了较为方便的跨端的服务发现调用能力。但分布式软总线和分布式任务调度子系统仅能为基于H系统的应用提供服务发现和调用能力，没有提供跨系统或跨协议的服务发现和调用能力，H系统的客户端不能发现和调用用户的其它系统中运行的服务。H系统的客户端不能够发现和调用用户的W系统设备或A系统设备上运行的服务。

另外，H系统不支持局域网外的服务发现和调用。H系统的软总线和分布式任务调度的近场服务注册发现是基于COAP协议的，服务发现时通过局域网发送广播消息的技术来实现。故H系统的分布式软总线和分布式任务调度只能约束在局域网内使用，不支持跨局域网的服务。

另外，H系统也不支持块协议调用服务。具体而言，H系统的分布式能力的应用都是基于H系统的Ability分布式调用SDK，不支持调用其它系统的服务，比如A系统的安卓组件服务。

为了本申请实施例所示方案易于理解，下面对本申请实施例中出现的若干名词进行介绍。

COAP(Constrained Application Protocol，受限引用协议)：一种在物联网世界的类web协议，COAP的详细规范定义在RFC 725文档中。

IOT(Internet Of Things，物联网)：又称泛互联，是互联网基础上的延伸和扩展的网络，将各种信息传感设备与网络结合起来而形成的网络，用于实现任何地点和任何时间的时空维度上的人、机和物的互联互通。

OS(Operate System，操作系统)：安装在终端设备或者云端服务器中的计算机程序，该计算机程序用于管理计算机硬件和软件资源。操作系统需要处理终端设备或者云端服务器中的一些基本事务，例如，管理与配置内存、决定系统资源供需的优先次序、控制输入设备与输出设备、操作网络与管理文件系统等。另外，操作系统可以提供一个用于用户与操作系统交互的操作界面。

RPC(Remote Procedure Call，远程过程调用)：是一种通过网络从远程计算机程序上请求服务，而无需解析底层网络技术的思想。

SDK(Software Development Kit，软件开发工具包)：SDK是一些软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。

RTOS(Real Time Operate System，实时操作系统)：是指当外界事件或数据产生时，能够接受并以足够快的速度予以处理，其处理的结果又能在规定的时间之内来控制生产过程或对处理系统做出快速响应，调度一切可利用的资源完成实时任务，并控制所有实时任务协调一致运行的操作系统。

调用方：用于指示一种设备或者终端，该调用方可以是用户日常随身携带的设备，或者日常生活中与个人强相关的设备。调用方可以调用在被调用方中已注册的第一服务，同时，调用方不需要在本地注册第一服务。由此可以实现，调用方中无需安装第一服务，也可以调用第一服务实现相应功能的效果。

被调用方：用于指示一种设备或者终端，该调用方可以是用户日常随身携带的设备，或者日常生活中与个人强相关的设备。被调用方中可以注册有第一服务。该第一服务能够被调用方通过跨设备的方式调用。

其中，调用方和被调用方既可以通过局域网进行通信，也可以通过互联网进行通信，本申请实施例对此不作限定。为了保证调用方和被调用方各自的方案，调用方和被调用方之间可以通过鉴权的过程进行连接，其中，鉴权的过程可以通过密钥进行加密。

随着社会信息化程度的提升，人均设备的数量日益增长。根据相关调研机构的预测，人均设备的数量将能够增长到8个。如何将同一个人使用的设备融合为“一个设备”，也即运行在各个设备上的服务能够无缝互相访问，是本申请所要着重解决的一个问题。

下面，介绍本申请所应用的硬件环境。

示例性地，本申请实施例所示的设备间的服务调用方法，可以应用在调用方中，该调用方具备设备间的服务调用功能。需要说明的是，调用方既可以是用户随身设备，也可以是场景专用设备。其中，用户随身设备是用户可以随身携带的电子设备，该电子设备能够与其它电子设备经由网络通信。场景专用设备可以是在指定场景中专用的设备，例如，车机是在乘车场景中专用的设备。

在此基础上，当调用方是用户随身设备时，该调用方可以包括手机、平板电脑、膝上型电脑、蓝牙耳机、智能眼镜、智能手表、数码相机、MP4播放终端、MP5播放终端、学习机、点读机、电纸书、电子词典、虚拟现实(Virtual Reality，VR)播放终端或增强现实(Augmented Reality，AR)播放终端等。当调用方是场景专用设备时，调用方可以是台式电脑、电脑一体机、电视、车机、蓝牙音箱、蓝牙鼠标、蓝牙键盘或车机。

需要说明的是，被调用方可能落地的终端或者设备的形态，与调用方类似，本处不再赘述。

请参照图4，图4是本申请一个示例性实施例提供的一种调用方的结构框图，如图4所示，该调用方包括处理器420和存储器440，所述存储器440中存储有至少一条指令，所述指令由所述处理器420加载并执行以实现如本申请各个方法实施例所述的设备间的服务调用方法。

在本申请中，调用方400是具备调用服务功能的电子设备。调用方400从所述调用方本地的服务注册中心中发现第一服务，所述服务注册中心用于存储所述调用方中已注册的服务和被调用方中已注册的服务，所述第一服务是所述被调用方中的已注册的服务；解析所述第一服务的定义信息，得到所述被调用方支持的第一服务协议；响应于所述调用方不支持所述第一服务协议，将所述服务参数按照第二服务协议的规范进行转化，得到跨端参数，所述服务参数用于提供给所述第一服务以获取相应的服务结果，所述跨端参数是所述调用方支持的所述第二服务协议中的参数；基于所述跨端参数调用所述第一服务。

处理器420可以包括一个或者多个处理核心。处理器420利用各种接口和线路连接整个调用方400内的各个部分，通过运行或执行存储在存储器440内的指令、程序、代码集或指令集，以及调用存储在存储器440内的数据，执行调用方400的各种功能和处理数据。可选的，处理器420可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(Programmable LogicArray，PLA)中的至少一种硬件形式来实现。处理器420可集成中央处理器(CentralProcessing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示屏所需要显示的内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器420中，单独通过一块芯片进行实现。

存储器440可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory，ROM)。可选的，该存储器440包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器440可用于存储指令、程序、代码、代码集或指令集。存储器440可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等；存储数据区可存储下面各个方法实施例中涉及到的数据等。

请参照图5，图5是本申请一个示例性实施例提供的一种被调用方的结构框图，如图5所示，该被调用方包括处理器520和存储器540，所述存储器540中存储有至少一条指令，所述指令由所述处理器520加载并执行以实现如本申请各个方法实施例所述的设备间的服务被调用方法。

在本申请中，被调用方500是具备调用服务功能的电子设备。被调用方500从调用方接收跨端参数，所述跨端参数是所述调用方支持的第二服务协议中的参数；转化所述跨端参数，得到所述被调用方支持的第一服务协议中的服务参数；基于所述服务参数运行所述第一服务，得到服务结果；向所述调用方反馈所述服务结果。

处理器520可以包括一个或者多个处理核心。处理器520利用各种接口和线路连接整个被调用方500内的各个部分，通过运行或执行存储在存储器540内的指令、程序、代码集或指令集，以及调用存储在存储器540内的数据，执行被调用方500的各种功能和处理数据。可选的，处理器520可以采用数字信号处理(Digital Signal Processing，DSP)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、可编程逻辑阵列(ProgrammableLogic Array，PLA)中的至少一种硬件形式来实现。处理器520可集成中央处理器(CentralProcessing Unit，CPU)、图像处理器(Graphics Processing Unit，GPU)和调制解调器等中的一种或几种的组合。其中，CPU主要处理操作系统、用户界面和应用程序等；GPU用于负责显示屏所需要显示的内容的渲染和绘制；调制解调器用于处理无线通信。可以理解的是，上述调制解调器也可以不集成到处理器520中，单独通过一块芯片进行实现。

存储器540可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory，ROM)。可选的，该存储器540包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器540可用于存储指令、程序、代码、代码集或指令集。存储器540可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等；存储数据区可存储下面各个方法实施例中涉及到的数据等。

请参图6，图6是本申请一个示例性实施例提供的一种设备间的服务调用方法所应用的实施环境图。在图6中，包括手机610、电视620、厨房大屏设备630和智能盥洗镜640。该场景用于指示用户早晨起床后所处于的一个场景中。手机610、电视620、厨房大屏设备630和智能盥洗镜640可以绑定到一个互相可通信的设备群组中。当上述设备均处于局域网中，设备之间可以通过短距离无线传输的方式进行通信，当上述设备有部分与其它的设备距离较远时，设备之间可以通过互联网进行通信。

在图6中，手机610中可以登录有用户的个人帐号。各个设备均可以登录有相同的用户的个人帐号。各个设备通过登录的相同帐号互相进行鉴权，从而加入相同的设备群组中。

在一种可能的应用场景中，当用户早晨起床后，可以拿着手机610去洗手池前洗漱。当智能盥洗镜640检测到手机610与自身之间的距离处于第一距离之内，并且手机610中的视频播放服务正在运行，智能盥洗镜640则调用手机610中的视频播放服务，使得该视频不再在手机610中播放，而是转到智能盥洗镜640中继续播放。需要说明的是，智能盥洗镜640具有普通镜子的功能，且显示屏集成在镜面中。智能盥洗镜640能够通过短距离无线通信的方式与其它设备进行通信。

当用户洗漱完毕，拿起手机610去厨房做早点的过程中，视频将转移回手机610中继续播放。当用户手持手机610到达厨房时，厨房大屏设备630能够检测到手机610与自身的距离处于第二距离之内，并且手机610中的视频播放服务正在运行，厨房大屏设备630则调用手机610中的视频播放服务，使得该视频不再在手机610中播放，而是转到厨房大屏设备630中继续播放。需要说明的是，若厨房大屏设备630中存在扬声器，则视频的声音从厨房大屏设备630输出；若厨房大屏设备630中不存在扬声器，则视频的声音既可以继续通过手机610的扬声器播放，也可以通过用户佩戴的蓝牙耳机或家庭中的蓝牙影响播放。

当用户准备完成早餐，携带手机610从厨房走到餐厅时，由于用户在餐桌距离电视较远，可能无法出现电视自动接力播放视频的效果。但在该场景中，手机610能够在负一屏或者通知栏中提供的视频播放的卡片。其中，视频播放卡片可以是“当前播放的《ABC视频》可以在电视620中播放，是否换屏播放”。当用户手动选择在电视620中继续播放视频时，视频将在电视620中继续播放，并在手机610中停止播放。

请参照图7，图7是本申请一个示例性实施例提供的另一种设备间的服务调用方法所应用的实施环境图。在图7中，包括手机710、车机720和车载音箱730。该场景用于指示用户乘坐轿车或者驾驶轿车的场景。手机710、车机720和车载音箱730可以绑定到衣蛾互相可通信的设备群组中。需要说明的是，基于该乘车场景的特殊性，上述各个设备之间通过短距离无线传输的方式进行通信，或者，各个设备之间通过USB线缆进行连接。

在图7中，手机710中可以登录有用户的个人帐号。各个设备均可以登录有相同的用户的个人帐号。各个设备通过登录的相同帐号互相进行鉴权，从而加入相同的设备群组中。

在一种可能的应用场景中，当用户进入车辆并启动车辆后，手机710既可以通过蓝牙连接的方式与车机720以及车载音箱730建立通信连接，也可以通过USB线缆与车机720以及车载音箱730建立通信连接。在手机710与上述设备建立连接后，车机720可以自动调用手机710中的第一服务。例如，第一服务是视频播放服务，则车机720可以直接调用手机710中的第一服务，继续播放手机710中的视频播放服务中正在播放的视频。从用户体验上而言，视频可以在用户进入轿车后，自动从手机710换屏至车机720中，在车机720的屏幕中继续播放。同样的，车载音箱可以作为手机710的音频输出，继续提供音频输出服务。其中，音频输出可以包括音乐音频输出、视频中的音频输出以及语音通话的音频输出，本申请实施例对此不作限定。

在另一种可能的场景中，第一服务还可以是交互学习服务，用户能够从使用手机710进行交互学习自动切换至使用车机720进行交互学习。比如，用户采用手机710进行在线会议，手机710提供前置摄像头和麦克风。当用户进入车辆之后，车机720将调用手机710中的在线会议服务，并且提供前置摄像头和麦克风，继续使用在线会议服务以便用户在驾驶或者乘车的过程中，继续参与在线会议。需要说明的是，若车辆中没有配备拍摄用户的摄像头，则在线会议服务不再采集用户的影响但并不影响车机720调用在线会议服务。

请参见图8，图8是本申请实施例提供的一种示例性实施例提供的另一种设备间的服务调用方法所应用的实施环境图。在图8中，包括手机810和个人电脑820。其中，个人电脑820可以配备有鼠标、键盘、摄像头和麦克风等输入输出组件，以便用户操作。

在图8中，手机810中可以登录有用户的个人帐号。各个设备均可以登录有相同的用户的个人帐号。各个设备通过登录的相同帐号互相进行鉴权，从而加入相同的设备群组中。

在一种可能的应用场景中，个人电脑820既可以是台式电脑，也可以是笔记本电脑，本申请实施例对此不作限定。当用户携带手机810与个人电脑820之间的距离小于第三距离时，或者，用户通过个人电脑820搜索到手机810在个人电脑820的附近时，用户可以手动操作个人电脑820调用手机810中的第一服务。其中，当个人电脑820与手机810之间的距离小于第三距离时，视为个人电脑820处于手机810的附近。

比如，手机810中存储有工作文件，第一服务用于处理该工作文件。当个人电脑820调用手机810中的第一服务时，个人电脑820能够同时读取到工作文件，直接按照编辑模式显示该工作文件，提高了用户因切换工作设备而导致的工作效率降低的问题。

再比如，手机810中运行有游戏服务(第一服务)，游戏服务中登录有用户的用户帐号。当个人电脑820调用手机810中的第一服务时，个人电脑820能够读取到游戏帐号的信息，并基于手机810上的游戏应用，将输入重定向到个人电脑820的键盘和鼠标，输出重定向到电脑屏幕，声音重定向到音箱，从而让用户快速在电脑上玩游戏。

在本申请实施例中，基于图6至图8所示的实施环境，本申请能够为用户提供的一整天的跨设备调用服务，相应的场景信息请参见表一所示的信息。

表一

基于本申请提供的设备间的服务调用方法，能够以用户为中心提供泛在服务。本申请涉及的多个设备将能够统一运作。多端或者端云无缝融合为一个整体系统运作。具体而言，本申请涉及运行在多个设备上的服务资源统一调度，根据用户场景，由最合适的场景资源，协同提供良好的服务体验。技术上，可以依赖于以下四个技术栈：

1)连接无缝化：用户无感的高效低功耗全场景网络，自适应、高质量、广连接以及多通道。

2)资源融合化：数据端云一体，服务跨端调用，用户高效管理多端设备，开发者灵活集成多设备能力，并倍速创新业务。

3)生态开放化：最大化互联设备，最深度相互赋能。

4)交互智能化：发挥多设备、多模态感知交互能力，实现自然以及精准服务。

其中，资源融合化是系统的资源需要服务化，单端设备需有能力发现用户多设备中的服务。所有的服务化必须要以统一的格式进行定义，才能有效跨端调用。本申请的目的在于解决该问题。展开来介绍，是在异构环境下，用户的多个设备运行不同的操作系统，比如手机Android系统,电脑是Windows系统，如何跨端的服务注册、发现、调用的方法。

请参考图9，图9是本申请一个示例性实施例提供的一种设备间的服务调用方法的流程图。该设备间的服务调用方法可以应用在上述所示的调用方中。在图9中，设备间的服务调用方法包括：

步骤910，从调用方本地的服务注册中心中发现第一服务，服务注册中心用于存储调用方中已注册的服务和被调用方中已注册的服务，第一服务是被调用方中的已注册的服务。

在本申请实施例中，调用方的本地中存在服务注册中心。在实际实现中，服务注册中心可以是一个数据库。调用方在本地访问数据库的速度较快。示意性的，由于调用方的本地的服务注册中心能够实时同步被调用方，以及，其它与调用方相连的设备中的已注册的服务。因此，调用方通过访问本地的服务注册中心，即可知晓自身可以从其它设备中调用的服务。

步骤920，解析第一服务的定义信息，得到被调用方支持的第一服务协议。

在本申请实施例中，调用方能够在发现了第一服务之后，获取到第一服务的定义信息。一种可能的方式中，该第一服务的定义信息存储在指定的文件中。调用方能够解析该文件，从而得到被调用方支持的第一服务协议。

可选的，在调用方知晓第一服务协议之后，调用方能够同时知晓第一服务协议相关的规范和参数要求。

步骤930，响应于调用方不支持第一服务协议，将服务参数按照第二服务协议的规范进行转化，得到跨端参数，服务参数用于提供给第一服务以获取相应的服务结果，跨端参数是调用方支持的第二服务协议中的参数。

在本申请实施例中，在调用方不支持第一服务协议时，调用方将服务参数按照第二服务协议的规范进行转化，得到跨端参数。由于该跨端参数是能够被调用方支持的。因此，调用方能够顺利发送跨端参数至被调用方。

步骤940，基于跨端参数调用第一服务。

在本申请实施例中，调用方将跨端参数发送至被调用方后，能够得到被调用方反馈的调用结果，从而顺利完成第一服务的调用。

综上所述，本实施例提供的设备间的服务调用方法，由于本申请实施例能够在本端的注册中心中发现第一服务，在发现后根据该服务的定义信息获知被调用方支持的第一服务协议，再基于本端支持第一服务协议的情况，相应的处理第一服务协议的服务参数，得到跨端参数，使得自身既能够传输该跨端参数，也能够令被调用方根据跨端参数解析出自身支持的第一服务协议中的服务参数，实现了调用方和被调用方支持的协议的不同的场景下，调用方也能够自由调用相应的服务的效果，突破了设备间因操作系统和支持通信协议的不同而造成的无法调用服务的技术难题，提高了设备之间的协作能力。

请参考图10，图10是本申请一个示例性实施例提供的一种设备间的服务调用方法的流程图。该设备间的服务调用方法可以应用在上述所示的被调用方中。在图10中，设备间的服务调用方法包括：

步骤1010，从调用方接收跨端参数，跨端参数是调用方支持的第二服务协议中的参数。

在本申请实施例中，被调用方能够从调用方接收跨端参数。其中，该跨端参数是调用方支持的第二服务协议中的参数。

步骤1020，转化跨端参数，得到被调用方支持的第一服务协议中的服务参数。

在本申请实施例中，由于被调用方无法直接使用跨端参数，因此，被调用方需要将跨端参数转化为自身支持的第一服务协议中的服务参数。

步骤1030，基于服务参数运行第一服务，得到服务结果。

在本申请实施例中，由于服务参数能够直接在被调用方中识别使用，从而基于该服务参数运行第一服务，得到服务结果。其中，服务结果将随着服务的不同而有所差别。

步骤1040，向调用方反馈服务结果。

在本申请实施例中，为了实现第一服务的正确调用，被调用方向调用方反馈服务结果。

综上所述，本申请提供的设备间的服务调用方法能够令被调用方接收到调用方发送的跨端参数，再将跨端参数转化成本端支持的服务参数，从而基于该服务参数运行对应的第一服务，并将服务结果反馈给调用方，从而实现了调用方和被调用方支持的协议的不同的场景下，调用方也能够自由调用相应的服务的效果，突破了设备间因操作系统和支持通信协议的不同而造成的无法调用服务的技术难题，提高了设备之间的协作能力。

基于上一个实施例所公开的方案，调用方和被调用方之间能够配合实现设备间的服务调用的方法，请参考如下实施例。

请参见图11，图11是本申请另一个示例性实施例提供的一种设备间的服务调用方法流程图。该设备间的服务调用方法可以应用在上述所示的调用方和被调用方之中。在图11中，该设备间的服务调用方法包括：

步骤1101，响应于第一注册服务请求，调用第一统一服务治理模块。

步骤1102，基于第一统一服务治理模块的注册功能，在调用方本地的服务注册中心中注册第一注册服务请求对应的第二服务。

步骤1103，基于第一统一服务治理模块的同步功能，向被调用方同步第二服务。

步骤1104，调用方从调用方本地的服务注册中心中发现第一服务。

在本申请实施例中，步骤1104的执行过程和步骤910的执行过程相同，此处不再赘述。

作为一种替代的实现方式，步骤1104可由下列步骤a1)和步骤a2)来替换，以实现发现第一服务的功能。

步骤a1)，调用方通过调用方中的服务网关接口，调用第一统一服务治理模块。

步骤a2)，基于第一统一服务治理模块，调用方从调用方本地的服务注册中心中查找第一服务。

步骤1105，调用方解析第一服务的定义信息，得到被调用方支持的第一服务协议。

在本申请实施例中，步骤1105的执行过程和步骤920的执行过程相同，此处不再赘述。

步骤1106，响应于调用方不支持第一服务协议，调用方将服务参数按照第二服务协议的规范进行转化，得到跨端参数。

在本申请实施例中，步骤1106的执行过程和步骤930的执行过程相同，此处不再赘述。

步骤1107，调用方向被调用方发送跨端参数。

作为一种替代的实现方式，步骤1107可由下列步骤b1)和步骤b2)来替换，以实现得到跨端参数的功能。

步骤b1)，通过第一跨端协议序列化跨端参数，得到序列化后的跨端参数。

步骤b2)，向被调用方发送序列化后的跨端参数，序列化后的跨端参数用于在被调用方基于第二跨端协议进行反序列化以得到跨端参数。

示意性的，第一统一服务治理模块包括应用层部分和领域层部分，应用部分包括服务注册功能、服务发现功能、服务调度功能、服务更新功能、服务移除功能和服务同步功能中至少一种；领域层部分包括服务定义管理、服务协议管理和服务授权管理中至少一种。

示意性的，定义信息以目标文件格式的形式存储于第一服务的服务包中，目标文件格式用于跨平台提供文本信息。

其中，目标文件格式可以是xml格式，也可以是其它能够存储文本的格式。

示意性的，定义信息包括服务名、服务类型、服务协议和服务的出入参数中至少一种。

示意性的，服务协议包括协议类型、服务唯一标识和协议属性中至少一种；服务的出入参数包括输入参数和输出参数中至少一种。

示意性的，输入参数包括第一参数名、第一数据类型、第一缺省值和第一必要标记中至少一种，第一必要标记用于指示输入参数是否必要；输出参数包括第二参数名、第二数据类型、第二缺省值和第二必要标记中至少一种，第二必要标记用于指示输出参数是否必要。

相应的，被调用方从调用方接收跨端参数。

在被调用方从调用方接收跨端参数之前，被调用方可以预先注册第一服务，并将该服务同步至调用方。

示意性的，被调用方能够响应于第二注册服务请求，调用第二统一服务治理模块；基于第二统一服务治理模块的注册功能，在被调用方的本端注册第二注册服务请求对应的第一服务；基于第二统一服务治理模块的同步功能，向调用方同步第一服务。

步骤1108，被调用方转化跨端参数，得到被调用方支持的第一服务协议中的服务参数。

步骤1109，被调用方基于服务参数运行第一服务，得到服务结果。

步骤1110，被调用方向调用方反馈服务结果。

需要说明的是，步骤1108至步骤1110的执行过程可以参见步骤1020至步骤1040的执行过程，本处不再赘述。

相应的，调用方接收被调用方反馈的服务结果。

其中，服务结果是被调用方中的第一服务基于跨端参数运行后得到的数据。

综上所述，本实施例能够在本端的注册中心中发现第一服务，在发现后根据该服务的定义信息获知被调用方支持的第一服务协议，再基于本端支持第一服务协议的情况，相应的处理第一服务协议的服务参数，得到跨端参数，使得自身既能够传输该跨端参数，也能够令被调用方根据跨端参数解析出自身支持的第一服务协议中的服务参数，实现了调用方和被调用方支持的协议的不同的场景下，调用方也能够自由调用相应的服务的效果，突破了设备间因操作系统和支持通信协议的不同而造成的无法调用服务的技术难题，提高了设备之间的协作能力。

下面介绍本申请提供的设备间的服务调用方法所涉及的技术底层方案。其中，技术底层方案将按照技术点逐个介绍。

统一服务定义

通过对典型服务类型(HTTP、TCP、RPC、Android组件服务等)分析，抽象出满足了所有服务类型的服务定义。主要在两个方面进行了抽象：

第一是抽象了协议定义，基于每一种跨端的服务协议有不同的服务属性的事实，为每一种协议定义了一个Protocol枚举值，同时把Protocol的具体的属性放置在ProtocolAttrbute中，比如TCP的定义为：

"protocol":"tcp"//关键字是protocol，枚举值是tcp

"protocolAttribute":{"IP":"192.168.0.2"，"port:8080"}//关键字是protocolAttribute，用于表示protocol的属性，IP表示属性名称，“192.168.0.2”是IP属性的数值，port表示另一属性名称，“8080”表示port属性的数值。

....

第二个是对服务的输入输出参数按照标准的方法进行定义，Schema(模式)定义为：

请参照表二所示的统一服务定义格式。表二所示的统一定义需要编写服务定义的人员参考。

表二

下面将介绍几种服务的定义。标准服务定义。

(1)投屏服务定义

(2)视频播放服务定义

请参考图12，图12是本申请实施例示出的一种设备间的服务调用的系统架构图。在图12中，包括终端侧系统1210和云侧系统1220。

在终端侧系统1210中，包括网关层1211、应用层1212和领域层1213。其中，网关层1211包括服务网关；应用层1212包括ICDF协议调用子系统、HTTP协议服务调用子系统和Android服务调用子系统；领域层1213包括服务定义管理、服务协议管理和服务授权管理。其中，应用层1212还包括API接口(Content Provider)、设备通讯、服务注册、服务发现、服务调度、服务更新、服务移除和服务同步。设备通讯包括云端访问模块和近场通讯对接模块。在终端侧系统1210中，跨应用层和领域层集成为统一服务治理。

在云侧系统1220中，包括网关层1221、应用层1222和领域层1223。网关层1221包括API网关；应用层1222包括统一服务治理，统一服务治理中进一步包括服务注册、服务发现、服务调度、服务更新、服务移除和服务同步；领域层1223包括统一服务治理域，统一服务治理域进一步包括服务定义管理、服务协议管理和服务授权管理。

其中，领域层用于提供“统一服务治理”。服务定义提供服务定义的整个生命周期的服务；服务协议提供协议相关协议规则管理；服务授权提供服务授权体系模型的服务。应用层基于领域层的服务进行组合，统一对外提供服务注册、服务发现、服务更新和服务调度等能力。

请参考图13，图13是本请实施例提供的一种服务注册的流程示意图。在图13中，包括云侧1310、第一终端侧1320和第二终端侧1330。

其中，服务注册流程可以分为两个发起者。第一个发起者是第一终端侧1320中的服务提供者，发起第一注册服务请求1341。第一终端侧1320中的服务网关接收该第一注册服务请求1341后，将向“统一服务治理”发起服务注册请求。“统一服务治理”将在第一终端侧1320中完成服务的注册。其中，“统一服务治理”的结构可以参见图12，本申请对此不作限定。

另一方面，服务注册流程的另一个发起者是第一终端侧1320中的子系统。其中，子系统可以是ICDF协议调用子系统、HTTP协议服务调用子系统和Android服务调用子系统。需要说明的是，本申请中还可以包括其它用于调用服务的子系统。每一个调用子系统均可以发起服务注册流程。每一个调用子系统均可以向“统一服务治理”发起服务注册请求。“统一服务治理”将在第一终端侧1320中完成服务的注册。

在“统一服务治理”完成服务的注册后，“统一服务治理”能够将在第一终端侧1320完成注册的服务同步到其它与第一终端侧1320组网的设备中。在图13所示的示例中，“统一服务治理”将把在第一终端侧1320完成注册的服务同步到云侧1310以及第二终端侧1330中。该同步请求将发送至相应侧的网关中，再由网关转发至相应的“统一服务治理”中。由于该同步过程有云侧1310的参与。因此，云侧1310还能够将在第一终端侧1320完成注册的服务，进一步同步到其它连接到云侧1310的终端侧中，以令与第一终端侧1320有连接关系的终端都能够知晓第一终端侧1320中已注册有该服务。

换言之，注册服务是服务提供者调用服务治理SDK服务注册接口。服务提供者所提供的服务定义需要遵循统一服务定义的标准。统一服务指令模块将服务定义存储在设备本地数据库中。

请参考图14，图14是本申请实施例示出的一种设备间的服务同步的流程示意图。在图14中，包括云侧1310、第一终端侧1320和第二终端侧1330。

其中，服务同步可以在多个场景或者触发条件下执行。在本申请中，能够触发负同步的场景包括注册服务的场景、服务定义变更的场景和服务移除的场景。需要说明的是，其它涉及到服务的状态改变的场景，也能够触发本申请所示的服务同步的场景，本申请实施例对此不作限定。

以触发服务同步的条件产生在第一终端侧1320为例进行介绍。响应于第一终端侧1320中的服务出现注册服务的场景、服务定义变更的场景和服务移除的场景中任意一种场景，第一终端侧1320中的服务网关均能够获悉该消息，将向“统一服务治理”发送服务同步请求。“统一服务治理”首先将按照消息将本地中的数据库中的服务状态进行变更，再将变更后的服务的相关消息同步至云侧1310和第二终端侧1330。其中，当第二终端侧1330和第一终端侧1320之间能够直接连接时，第一终端侧1320中的“统一服务治理”能够直接进行服务同步流程。当第二终端侧1330和第一终端侧1320之间无法直接连接时，两者之间可以通过云侧1310进行服务同步。

换言之，统一服务治理模块把服务保存在本地服务注册中心(也即数据库)。同时统一服务治理模块把服务信息通过近场连接或云端服务同步到近场中的该用户的其它设备中。另一方面，服务信息修改和移除的同步流程和服务注册流程一样，可参见图14所示的过程。

请参见图15，图15是本申请实施例提供的一种服务发现的示意图。在图15中，以第一终端侧1320为例进行介绍。当第一终端侧1320需要发现某一指定的服务，例如第一终端侧1320需要发现第一服务时，第一终端侧1320中的服务管理器、指定应用或者指定服务能够发起服务发现的指令，该服务发现的指令发送至服务网关。第一终端侧1320中的服务网关将该服务发现的指令发送至“统一服务治理”中。“统一服务治理”再按照该服务发现的指令从本地的数据库1510中查找第一服务。若“统一服务治理”在本地的数据库1510中查找到了第一服务，则可以返回第一服务的具体信息。若“统一服务治理”在本地的数据库1510中没有查找到第一服务，则可以返回查找失败的结果信息。

换言之，第一终端侧1320中的第一服务注册到本地的数据库(也即服务注册中心)，会通过近场连接或者云端，即时同步相应的服务的信息到该用户的其它设备。所以，该方案的服务发现流程只需要从本地的数据库中查找数据即可，避免了相关技术中需要跨端查找相应的服务，降低了查找服务的时延。

请参见图16，图16是本申请实施例提供的一种服务调用的流程示意图。在图16中，包括调用方16A和被调用方16B。首先，服务是调用方16A和被调用方16B两个设备之间的设备间调用。由两个设备各自执行相应的流程，以完成服务的正常调用。

首先，服务的调用在调用方16A侧启动流程。

步骤(C1)，当调用方16A中的服务消费设备需要调用第一服务时，调用方16A将先在本地的数据库中查找第一服务。

步骤(C2)，当调用方16A在本地的数据库中查找到第一服务时，调用方16A从本地的数据库中获取服务定义。

步骤(C3)，调用方16A解析第一服务的服务定义。

步骤(C4)，调用方16A从第一服务的服务定义解析得到服务调用参数。

步骤(C5)，调用方16A从第一服务的服务定义解析得到跨端协议以及属性。

在本申请中，调用方16A通过执行服务发现流程获取第一服务的服务定义。调用方16A能够按照统一服务定义格式解析服务定义。其中服务定义的内容，请参见表二所示的内容。

经过解析之后，调用方16A至少能够得到服务调用参数和跨端协议以及属性。

步骤(C6)，判断调用方16A是否支持该跨端协议。

步骤(C7)，当调用方16A不支持该跨端协议时，执行协议转化流程。

步骤(C8)，当调用方16A支持该跨端协议时，确定出最终的跨端协议和服务调用参数。

在本申请中的，调用方16A将通过系统接口查询服务消费设备是否直接支持该跨端协议的调用。若调用方16A不支持该跨端协议的调用，则将服务调用参数和跨端协议以及属性进行协议转化，转化为服务消费设备支持的跨端参数。随后，调用方16A将输出最终的跨端协议和服务调用参数。

步骤(C9)，基于最终的跨端协议和服务调用参数，调用方16A生成并应用跨端协议Proxy，传输相应的服务参数。

需要说明的是，在一种可能的方式中，在步骤1619执行的过程中，调用方16A可以与被调用方16B之间进行鉴权的过程。该鉴权过程既可以协助调用方16A鉴别被调用方16B的身份，也可以协助被调用方16B鉴别调用方16A的身份。本申请实施例不对具体的鉴权过程作限定。

需要说明的是，跨端协议Proxy用于序列化相应的服务参数，并通过网络传输到被调用方16B。

步骤(C10)，被调用方16B基于跨端协议Stub接收调用方16A传输来的服务参数。

步骤(C11)，被调用方16B将服务参数传输给被调用方16B中的服务提供者。

步骤(C12)，被调用方16B基于服务参数，执行第一服务并反馈服务结果。

在步骤(C12)中，被调用方16B能够基于服务参数，并执行已在本地注册的第一服务，之后将服务结果反馈至调用方16A。

步骤(C13)，被调用方16B基于跨端协议Stub，反馈服务结果。

步骤(C14)，调用方16A基于跨端协议Proxy，接收服务结果，并将服务结果反馈给服务消费设备。

下面将介绍本申请提供的一种设备间的服务调用方法应用在视频接力场景的相关方案。场景描述：手机正在播放视频。当手机靠近电视后，视频在电视上继续从手机当前播放进度继续播放，手机中的视频退出。前置条件：手机和电视都安装了视频播放服务。需要说明的是，手机中存在类型是视频播放的服务即可认为手机中已安装了视频播放服务，电视中存在类型是视频播放的服务即可认为电视中已安装了视频播放服务。

视频接力相关的服务定义：服务实现在com.oplus.pantanal.example应用中，对应实现的service定义在AndroidManifest.xml中。需要说明的是，前述应用的安装包名和服务定义所放置的xml文件均可以根据需要进行更改。示意性的，视频接力相关的应用设置可以按照如下伪代码设定：

示意性的，该视频接力所涉及的服务的定义信息可以存放在xml格式的文件中，具体信息可参见如下：

在本场景中，介绍服务注册的过程。其中，电视机开机之后，按照图13所示的流程，扫描本地的应用，获得上面服务定义的xml文件。从而从服务定义的xml文件中获取服务的定义信息，存储在本地的服务注册中心(即电视机本地的数据库)，并通过近场WIFI连接，同步到手机的服务注册中心(也即手机本地的数据库)。

在本场景中，介绍服务发现的过程。手机正在播放视频，当手机靠近电视后，系统将会提示用户附近有一个大屏电视，更适合播放该视频。进而，手机中的系统将询问用户是否切换至电视播放。在用户选择切换后，视频播放客户端，调用“统一服务治理”系统“服务发现”接口，传入的服务类型是Video Player，得到以上的服务描述，具体流程参考图DK所示的过程。

在本场景中，介绍服务调用的过程。视频播放客户端按照图ED所示的流程调用服务。因为手机和电视都是Android系统，不需要协议转化步骤。手机能够直接从服务定义拿到跨端协议以及服务参数。

(1)跨端协议：“Android分布式组件服务”，协议参数

"deviceId"＝2,

"PackageName"＝"com.oplus.pantanal.example",

"service"＝".VideoService"

"intent"＝"com.oplus.pantanal.example.call"

(2)服务参数：

把当前播放的进度progress，以及视频源url填入到服务参数中

在本场景中，跨端协议stub从网络接受字节流，反序列化后，拿到跨端协议以上参数，通过Android应用管理器，启动VideoService服务，并传入progress和url参数。经过该过程，电视机就能够从progress的位置继续播放该视频，手机得到服务调用结果后，关闭手机中的视频，完成视频接力。

下面将介绍本申请提供的一种设备间的服务调用方法应用在远程相机场景的相关方案。场景描述：用户在电脑中的办公软件中写作，需要拍摄一张图片作为办公软件中的插图，但不方便使用电脑的摄像头。在此情况下，用户启动手机拍照服务，并将通过手机拍照服务获取的照片自动插入到文档中。前置条件：手机上的拍照服务已经支持"统一服务定义"。

手机拍照服务相关的服务定义：服务实现在com.oplus.pantanal.example应用中，对应的实现service定义在AndroidManifest.xml中。需要说明的是，前述应用的安装包名和服务定义所放置的xml文件均可以根据需要进行更改。示意性的，手机拍照服务相关的应用设置可以按照如下伪代码设定：

示意性的，该远程相机场景所涉及的服务的定义信息可以存放在xml格式的文件中，具体信息可参见如下：

在本场景中，介绍服务注册的过程。其中，手机开机后，按照图13的流程，扫描本地的应用，获得上面服务定义的xml，存储在本地的服务注册中心，并通过近场WIFI连接，同步到电脑的服务注册中心。

在本场景中，介绍服务发现的过程。在用户使用电脑中的办公软件编辑文档时，用户需要拍照作为插图，用户点击远程拍照服务。远程拍照服务调用“统一服务治理”系统“服务发现”接口，传入的服务类型Capture-photo，得到以上的服务描述，具体流程参考图DK所示的过程。

在本场景中，介绍服务调用的过程。远程拍照服务按照图ED的流程调用服务。因为电脑是Windows系统，不支持Andorid服务类型，但支持HTTP协议类型，调用协议转化模块，把Android服务参数转化为HTTP协议，HTTP的协议的跨端协议以及服务参数：

(1)HTTP跨端协议：这是http的post内容，在设备间传送。

"deviceId"＝1,

"PackageName"＝"com.oplus.pantanal.example",

"service"＝".CaptureService"

"intent"＝"com.oplus.pantanal.example.capture"

"OriginalProtocol"＝"Android"

按照如上的服务定义，当前定义的拍照服务没有输入参数。这里有个特别的参数OriginalProtocol表示转换前的协议类型。

在本场景中，跨端协议stub从网络接受字节流，反序列化后，通过http协议解析，拿到跨端协议以上参数，因为"OriginalProtocol"＝"Android"，所以通过Android的应用管理器，并传入"intent"＝"com.oplus.pantanal.example.capture"以及"PackageName"＝"com.oplus.pantanal.example"启动CaptureService。CaputreService启动手机摄像头，在用户的引导下拍摄一张照片。照片的二进制文件服务结果通过网络传送到电脑，并返回到电脑中的办公软件中。二进制文件通过下面的输出参数返回的。

<param_out>

</param_out>

由于本申请能够以用户为中心的泛在服务,要求多设备统一运作。基于多设备必然是异构的情况。例如，有的是Windows系统，有的是Android系统，还有的资源受限设备是RTOS系统，从而运行在多设备上的服务也必然是异构的。此外，网络连接也是多样的，有的设备有直接连接互联网的能力，有的设备只有BLE的连接能力。因此，实现多设备上的服务的深度融合，支持异构务跨端调用，支持端端/端云服务同步的方法是不可或缺的关键技术之一。基于本申请，跨端场景的开发者只需要专注在业务本身开发，跨端异构的服务发现，同步和调用由“统一服务治理”系统完成，开发效率大为提高。在一种可以量化的方式中，开发效率提高了90％以上。

需要说明的是，本申请除了能够调用已注册在被调用方中的服务，还能够调用即时服务。其中，即时服务可以是小程序、快应用或微程序中的至少一种。即时服务是无需注册即可使用的服务。另外，本申请还支持云端范围的调用，有较强的扩展性和普适性。

综上所述，本申请提供的设备间的服务调用方法具备统一服务定义的特点。其中，本申请提供了一种统一服务定义方法，可以满足现有的以及未来的跨端异构服务。一种可能的方式中，该服务定义是xml文本文件，该文本文件不仅可以部署在Windows、Android等系统，也可以部署在RTOS等资源受限的系统中。

可选地，本申请提供的设备间的服务调用方法具备端云一体的特点。其中，目前主流系统今年实现了局域网类的端端同步，其方法不能跨越局域网。本申请突破了此限制，服务不仅仅在局域网近场设备间同步，也可以通过云端进行服务同步。

可选地，本申请提供的设备间的服务调用方法具备无中心化的特点。其中，本申请的服务同步方法，并没有服务注册中心，任何一个设备有故障，不会影响其它设备的工作,提高了系统的鲁棒性。

可选地，本申请提供的设备间的服务调用方法具备跨协议调用的特点。其中，该申请支持异构服务的跨协议调用，比如HTTP可以调用Android服务。Android服务也可以调用HTTP服务，扩展了设备间服务互通的能力。

下述为本申请装置实施例，可以用于执行本申请方法实施例。对于本申请装置实施例中未披露的细节，请参照本申请方法实施例。

请参考图17，图17是本申请一个示例性实施例提供的一种设备间的服务调用装置的结构框图。该设备间的服务调用装置可以通过软件、硬件或者两者的结合实现成为调用方的全部或一部分。该装置包括：

服务发现模块1710，用于从所述调用方本地的服务注册中心中发现第一服务，所述服务注册中心用于存储所述调用方中已注册的服务和被调用方中已注册的服务，所述第一服务是所述被调用方中的已注册的服务。

协议获取模块1720，用于解析所述第一服务的定义信息，得到所述被调用方支持的第一服务协议。

第一转化模块1730，用于响应于所述调用方不支持所述第一服务协议，将所述服务参数按照第二服务协议的规范进行转化，得到跨端参数，所述服务参数用于提供给所述第一服务以获取相应的服务结果，所述跨端参数是所述调用方支持的所述第二服务协议中的参数。

服务调用模块1740，用于基于所述跨端参数调用所述第一服务。

在一个可选的实施例中，所述服务调用模块1740，用于向所述被调用方发送所述跨端参数；接收所述被调用方反馈的服务结果，所述服务结果是所述被调用方中的所述第一服务基于所述跨端参数运行后得到的数据。

在一个可选的实施例中，所述服务调用模块1740，用于通过第一跨端协议序列化所述跨端参数，得到序列化后的所述跨端参数；向所述被调用方发送序列化后的所述跨端参数，所述序列化后的所述跨端参数用于在所述被调用方基于第二跨端协议进行反序列化以得到所述跨端参数。

在一个可选的实施例中，所述服务发现模块1710，用于通过所述调用方中的服务网关接口，调用第一统一服务治理模块；基于所述第一统一服务治理模块，从所述调用方本地的所述服务注册中心中查找所述第一服务。

在一个可选的实施例中，所述装置还包括第一注册模块，用于响应于第一注册服务请求，调用第一统一服务治理模块；基于所述第一统一服务治理模块的注册功能，在所述调用方本地的所述服务注册中心中注册所述第一注册服务请求对应的第二服务；基于所述第一统一服务治理模块的同步功能，向所述被调用方同步所述第二服务。

在一个可选的实施例中，所述装置涉及的所述第一统一服务治理模块包括应用层部分和领域层部分，所述应用部分包括服务注册功能、服务发现功能、服务调度功能、服务更新功能、服务移除功能和服务同步功能中至少一种；所述领域层部分包括服务定义管理、服务协议管理和服务授权管理中至少一种。

在一个可选的实施例中，所述装置涉及的所述定义信息以目标文件格式的形式存储于所述第一服务的服务包中，所述目标文件格式用于跨平台提供文本信息。

在一个可选的实施例中，所述装置涉及的所述定义信息包括服务名、服务类型、服务协议和服务的出入参数中至少一种。

在一个可选的实施例中，所述装置涉及的所述服务协议包括协议类型、服务唯一标识和协议属性中至少一种；所述服务的出入参数包括输入参数和输出参数中至少一种。

在一个可选的实施例中，所述装置涉及的所述输入参数包括第一参数名、第一数据类型、第一缺省值和第一必要标记中至少一种，所述第一必要标记用于指示所述输入参数是否必要；所述输出参数包括第二参数名、第二数据类型、第二缺省值和第二必要标记中至少一种，所述第二必要标记用于指示所述输出参数是否必要。

请参考图18，图18是本申请一个示例性实施例提供的另一种设备间的服务调用装置的结构框图。该设备间的服务调用装置可以通过软件、硬件或者两者的结合实现成为被调用方的全部或一部分。该装置包括：

参数接收模块1810，用于从调用方接收跨端参数，所述跨端参数是所述调用方支持的第二服务协议中的参数.

第二转化模块1820，用于转化所述跨端参数，得到所述被调用方支持的第一服务协议中的服务参数。

服务运行模块1830，用于基于所述服务参数运行所述第一服务，得到服务结果。

结果反馈模块1840，用于向所述调用方反馈所述服务结果。

在一个可选的实施例中，所述装置还包括第二注册模块，第二注册模块用于响应于第二注册服务请求，调用第二统一服务治理模块；基于所述第二统一服务治理模块的注册功能，在所述被调用方的本端注册所述第二注册服务请求对应的所述第一服务；基于所述第二统一服务治理模块的同步功能，向所述调用方同步所述第一服务。

本申请实施例还提供了一种计算机可读介质，该计算机可读介质存储有至少一条指令，所述至少一条指令由所述处理器加载并执行以实现如上各个实施例所述的设备间的服务调用方法。

需要说明的是：上述实施例提供的设备间的服务调用装置在执行设备间的服务调用方法时，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将设备的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。另外，上述实施例提供的设备间的服务调用装置与设备间的服务调用方法实施例属于同一构思，其具体实现过程详见方法实施例，这里不再赘述。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的能够实现的示例性的实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims

1.一种设备间的服务调用方法，其特征在于，应用于调用方中，所述方法包括：

基于所述跨端参数调用所述第一服务。

2.根据权利要求1所述的方法，其特征在于，所述基于所述跨端参数调用所述第一服务，包括：

向所述被调用方发送所述跨端参数；

接收所述被调用方反馈的服务结果，所述服务结果是所述被调用方中的所述第一服务基于所述跨端参数运行后得到的数据。

3.根据权利要求2所述的方法，其特征在于，所述向所述被调用方发送所述跨端参数，包括：

通过第一跨端协议序列化所述跨端参数，得到序列化后的所述跨端参数；

向所述被调用方发送序列化后的所述跨端参数，所述序列化后的所述跨端参数用于在所述被调用方基于第二跨端协议进行反序列化以得到所述跨端参数。

4.根据权利要求1至3任一所述的方法，其特征在于，所述从所述调用方本地的服务注册中心中发现第一服务，包括：

通过所述调用方中的服务网关接口，调用第一统一服务治理模块；

基于所述第一统一服务治理模块，从所述调用方本地的所述服务注册中心中查找所述第一服务。

5.根据权利要求1至3任一所述的方法，其特征在于，在所述从所述调用方本地的服务注册中心中发现第一服务之前，所述方法还包括：

响应于第一注册服务请求，调用第一统一服务治理模块；

基于所述第一统一服务治理模块的注册功能，在所述调用方本地的所述服务注册中心中注册所述第一注册服务请求对应的第二服务；

基于所述第一统一服务治理模块的同步功能，向所述被调用方同步所述第二服务。

6.根据权利要求5所述的方法，其特征在于，所述第一统一服务治理模块包括应用层部分和领域层部分，所述应用部分包括服务注册功能、服务发现功能、服务调度功能、服务更新功能、服务移除功能和服务同步功能中至少一种；所述领域层部分包括服务定义管理、服务协议管理和服务授权管理中至少一种。

7.根据权利要求1所述的方法，其特征在于，所述定义信息以目标文件格式的形式存储于所述第一服务的服务包中，所述目标文件格式用于跨平台提供文本信息。

8.根据权利要求7所述的方法，其特征在于，所述定义信息包括服务名、服务类型、服务协议和服务的出入参数中至少一种。

9.根据权利要求8所述的方法，其特征在于，所述服务协议包括协议类型、服务唯一标识和协议属性中至少一种；所述服务的出入参数包括输入参数和输出参数中至少一种。

10.根据权利要求9所述的方法，其特征在于，所述输入参数包括第一参数名、第一数据类型、第一缺省值和第一必要标记中至少一种，所述第一必要标记用于指示所述输入参数是否必要；所述输出参数包括第二参数名、第二数据类型、第二缺省值和第二必要标记中至少一种，所述第二必要标记用于指示所述输出参数是否必要。

11.一种设备间的服务调用方法，其特征在于，应用于被调用方中，所述方法包括：

基于所述服务参数运行所述第一服务，得到服务结果；

向所述调用方反馈所述服务结果。

12.根据权利要求11所述的方法，其特征在于，所述方法还包括：

响应于第二注册服务请求，调用第二统一服务治理模块；

基于所述第二统一服务治理模块的注册功能，在所述被调用方的本端注册所述第二注册服务请求对应的所述第一服务；

基于所述第二统一服务治理模块的同步功能，向所述调用方同步所述第一服务。

13.一种设备间的服务调用装置，其特征在于，应用于调用方中，所述装置包括：

服务调用模块，用于基于所述跨端参数调用所述第一服务。

14.一种设备间的服务调用装置，其特征在于，应用于被调用方中，所述装置包括：

结果反馈模块，用于向所述调用方反馈所述服务结果。

15.一种调用方设备，其特征在于，所述调用方设备包括处理器、和与所述处理器相连的存储器，以及存储在所述存储器上的程序指令，所述处理器执行所述程序指令时实现如权利要求1至10任一所述的设备间的服务调用方法。

16.一种被调用方设备，其特征在于，所述被调用方设备包括处理器、和与所述处理器相连的存储器，以及存储在所述存储器上的程序指令，所述处理器执行所述程序指令时实现如权利要求11或12所述的设备间的服务调用方法。

17.一种计算机可读存储介质，所述存储介质中存储有程序指令，其特征在于，所述程序指令被处理器执行时实现如权利要求1至10任一所述的设备间的服务调用方法。

18.一种计算机可读存储介质，所述存储介质中存储有程序指令，其特征在于，所述程序指令被处理器执行时实现如权利要求11或12所述的设备间的服务调用方法。

19.一种计算机程序，其特征在于，所述计算机程序包括计算机指令，所述计算机指令存储在计算机可读存储介质中；

计算机设备的处理器从所述计算机可读存储介质读取所述计算机指令，所述处理器执行所述计算机指令，使得所述计算机设备执行如权利要求1至10任一所述的设备间的服务调用方法。

20.一种计算机程序，其特征在于，所述计算机程序包括计算机指令，所述计算机指令存储在计算机可读存储介质中；

计算机设备的处理器从所述计算机可读存储介质读取所述计算机指令，所述处理器执行所述计算机指令，使得所述计算机设备执行如权利要求11或12所述的设备间的服务调用方法。

21.一种设备间的服务调用系统，其特征在于，所述系统包括调用方和被调用方，所述调用方用于执行如权利要求1至10任一所述的设备间的服务调用方法，所述被调用方用于执行如权利要求11或12所述的设备间的服务调用方法。