CN104142856B - 服务程序调用方法、系统及其智能设备 - Google Patents

Abstract

本申请公开了一种服务程序调用方法、系统及智能设备，该服务程序调用方法包括：接收应用程序调用对应的服务程序的调用请求；判断所述服务程序是否已定义为远程调用；若已定义为远程调用，则从远端调用所述服务程序；若未定义为远程调用，则从本地调用所述服务程序。本申请有效地解决了现有技术的智能设备由于运行服务程序中大量复杂的运算而导致能耗过多的技术问题，降低了智能设备的能耗。

Description

服务程序调用方法、系统及其智能设备

技术领域

本申请涉及服务调用技术领域，具体是涉及一种服务程序调用方法，还涉及一种服务程序调用系统及其智能设备。

背景技术

随着用户终端（如手机和掌上电脑）以及云终端等智能设备技术的高速发展，智能设备也越来越普及。然而在实现智能化的同时，另一方面伴随而来的是越来越复杂的应用程序及其大量复杂的运算，这些大量复杂的运算需要频繁大量地在智能设备本地调用运行一个或多个服务程序进行服务，进而必然导致智能设备自身的能耗越来越大。因此，目前本领域技术人员急于解决智能设备的能耗问题。

为了降低智能设备的能耗，现有技术采用了一种应用级解耦的方式。

举例而言，对于手机来说，用户希望充电次数和时间越少越好，即希望降低其能耗。现有技术将本应运行在手机端的整个应用程序都部署在云终端进行运行，而应用程序运行时即可在云终端调用运行相关的服务程序进行运算，手机仅负责输入和显示结果。在工作时，手机端将用户通过GUI（Graphic User Interface，图形用户接口）操作利用网络发送给云终端，云终端在应用程序每次更新屏幕时候将图像信息传送回给手机进行显示。

这种应用级解耦的方式虽然在一定程度上可实现云终端与手机的无缝整合，从用户的角度看，应用程序仿佛运行在手机上。但是这种解耦方式需要采用VNC（VirtualNetwork Computing，虚拟网络计算）技术在手机与云终端之间进行交互，因此虽然在一定程度上降低了智能设备的能耗，但容易造成手机端用户的GUI操作延迟增加，界面切换不顺畅。

发明内容

有鉴于此，本申请提供了一种服务程序调用方法、系统及智能设备，以解决现有技术的智能设备由于运行服务程序的大量复杂运算而导致能耗过多的技术问题。

为解决上述问题，本申请第一方面提供一种服务程序调用方法，所述服务程序调用方法包括：接收应用程序调用对应的服务程序的调用请求；判断所述服务程序是否已定义为远程调用；若已定义为远程调用，则从远端智能设备调用所述服务程序；若未定义为远程调用，则从本地调用所述服务程序。

结合第一方面，在第一种可能的实现方式中，所述从远端智能设备调用所述服务程序的步骤包括：根据所述调用请求产生第一binder引用并将所述第一binder引用返回给所述应用程序；将所述服务程序的识别信息发送至远端智能设备，以使远端智能设备产生与所述服务程序对应的第二binder引用，并存储所述第二binder引用与所述服务程序的对应关系；在所述应用程序根据所述第一binder引用调用所述服务程序时，将所述应用程序的调用信息发送至所述远端智能设备，以使所述远端智能设备根据所述调用信息查找所述第二binder引用，根据所述第二binder引用调用所述服务程序，并返回所述服务程序运行获得的数据结果；利用所述第一binder引用将所述数据结果返回给所述应用程序。

结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，所述从本地调用所述服务程序的步骤包括：根据所述调用请求从本地查找与所述服务程序对应的第三binder引用并将所述第三binder引用返回给所述应用程序；在所述应用程序根据所述第三binder引用调用所述服务程序时，利用所述第三binder引用将所述服务程序运行获得的数据结果返回给所述应用程序。

结合第一方面、第一方面的第一种可能或第二种可能的实现方式，在第三种可能的实现方式中，所述接收应用程序调用对应的服务程序的调用请求的步骤之前还包括：对需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦，以定义为远程调用。

结合第一方面的第三种可能的实现方式，在第四种可能的实现方式中，所述对需远程调用服务的应用程序及对应的服务程序进行注册及解耦的步骤包括：获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应的服务程序的服务名称；存储所述程序名称和所述服务名称。所述判断所述服务程序是否已定义为远程调用的步骤包括：判断是否已存储有所述服务程序的服务名称，若已存储有对应的服务名称则判断为已定义远程调用，若未存储有对应的服务名称则判断为未定义远程调用。

结合第一方面的第三种可能的实现方式，在第五种可能的实现方式中，所述接收应用程序调用对应的服务程序的调用请求的步骤之前还包括：获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程序名称及对应的服务程序的服务名称；查找并删除所述程序名称和所述服务名称，以动态注消所述至少一个已注册及解耦的应用程序的注册及解耦。

结合第一方面、第一方面的第一种可能或第二种可能的实现方式，在第六种可能的实现方式中，所述服务程序为应用进程服务或系统进程服务。

为解决上述问题，本申请第二方面提供一种智能设备，所述智能设备包括：代理服务模块，用于从远端智能设备调用服务程序；管理模块，用于接收应用程序调用对应的服务程序的调用请求并判断所述服务程序是否已定义为远程调用；处理模块，用于在所述管理模块判断到所述服务程序已定义为远程调用时，通过所述代理服务模块从远端智能设备调用所述服务程序，在所述管理模块判断到所述服务程序未定义为远程调用时，则从本地调用所述服务程序。

结合第二方面，在第一种可能的实现方式中，所述管理模块具体用于根据所述调用请求产生与所述代理服务模块相对应的第一binder引用并将所述第一binder引用返回给所述应用程序。所述代理服务模块具体用于将所述服务程序的识别信息发送至远端智能设备，以使远端智能设备产生与所述服务程序对应的第二binder引用，并存储所述第二binder引用与所述服务程序的对应关系。所述代理服务模块具体还用于在所述应用程序根据所述第一binder引用调用所述服务程序时，将所述应用程序的调用信息发送至所述远端智能设备，以使所述远端智能设备根据所述调用信息查找所述第二binder引用，根据所述第二binder引用调用所述服务程序，并返回所述服务程序运行获得的数据结果。所述处理模块具体用于利用所述第一binder引用将所述代理服务模块从所述远端智能设备接收的所述数据结果返回给所述应用程序。

结合第二方面的第一种可能的实现方式，在第二种可能的实现方式中，所述管理模块具体用于在所述管理模块判断到所述服务程序未定义为远程调用时，根据所述调用请求从本地查找与所述服务程序对应的第三binder引用并将所述第三binder引用返回给所述应用程序。所述处理模块具体还用于在所述应用程序根据所述第三binder引用调用所述服务程序时，利用所述第三binder引用将所述服务程序运行获得的数据结果返回给所述应用程序。

结合第二方面、第二方面的第一种可能或第二种可能的实现方式，在第三种可能的实现方式中，所述智能设备还包括：注册模块，用于对需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦，以定义为远程调用。

结合第二方面的第三种可能的实现方式，在第四种可能的实现方式中，所述注册模块具体包括：第一获取单元，用于获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应的服务程序的服务名称；第一管理单元，用于存储所述第一获取单元获取到的所述程序名称和所述服务名称。其中，所述管理模块具体用于判断所述第一管理单元中是否已存储有所述服务程序的服务名称，若所述第一管理单元中已存储有对应的服务名称则判断为已定义远程调用，若所述第一管理单元中未存储有对应的服务名称则判断为未定义远程调用。

结合第二方面的第四种可能的实现方式，在第五种可能的实现方式中，所述智能设备还包括注销模块，所述注销模块包括：第二获取单元，用于获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程序名称及对应的服务程序的服务名称；第二管理单元，用于查找并删除所述第二获取单元获取到的所述程序名称和所述服务名称，以动态注消所述至少一个已注册及解耦的应用程序的注册及解耦。

结合第二方面的第一种或第二种可能的实现方式，在第六种可能的实现方式中，所述智能设备为用户终端或云终端，所述服务程序为应用进程服务或系统进程服务，所述管理模块为AMS模块或SM模块，所述处理模块为基于binder机制的binder驱动模块。

为解决上述问题，本申请第三方面提供一种服务程序调用方法，所述服务程序调用方法包括：接收远端智能设备发送的需远程调用的服务程序的识别信息，并根据所述服务程序的识别信息在本地确定对应的所述服务程序，其中，所述服务程序在远端智能设备已定义为远程调用，所述远端智能设备根据所述应用程序调用对应的服务程序所发出的调用请求产生所述服务程序的识别信息；在接收到远端智能设备发送的针对所述服务程序的调用信息时，根据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的数据结果返回给所述远端智能设备的应用程序。

结合第三方面，在第一种可能的实现方式中，所述根据所述服务程序的识别信息在本地确定对应的所述服务程序的步骤具体包括：根据所述服务程序的识别信息产生与所述服务程序对应的第一binder引用，并存储所述第一binder引用与所述服务程序的对应关系。所述根据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的数据结果返回给所述远端智能设备的应用程序的步骤具体包括：根据所述调用信息查找所述第一binder引用，并根据所述第一binder引用调用所述服务程序；将利用所述第一binder引用返回的所述服务程序运行获得的数据结果发送给所述远端智能设备，以使所述远端智能设备利用第二binder引用将所述数据结果返回给所述应用程序。其中，所述远端智能设备根据所述调用请求产生所述第二binder引用。

结合第三方面或第三方面的第一种可能的实现方式，在第二种可能的实现方式中，所述服务程序为应用进程服务或系统进程服务。

为解决上述问题，本申请第四方面提供一种智能设备，所述智能设备包括：代理服务模块，用于接收远端智能设备发送的需远程调用的服务程序的识别信息，其中，所述服务程序在远端智能设备已定义为远程调用，所述远端智能设备根据所述应用程序调用对应的服务程序所发出的调用请求产生所述服务程序的识别信息；管理模块，用于根据所述代理服务模块接收到的所述服务程序的识别信息在本地确定对应的所述服务程序；处理模块，用于在所述代理服务模块接收到远端智能设备发送的针对所述服务程序的调用信息时，根据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的数据结果返回给所述远端智能设备的应用程序。

结合第四方面，在第一种可能的实现方式中，所述管理模块具体用于根据所述服务程序的识别信息产生与所述服务程序对应的第一binder引用，并存储所述第一binder引用与所述服务程序的对应关系。所述处理模块具体用于在所述代理服务模块接收到远端智能设备发送的针对所述服务程序的调用信息时，根据所述调用信息查找所述第一binder引用，并根据所述第一binder引用调用所述服务程序。所述代理服务模块具体用于将所述处理模块利用所述第一binder引用返回的所述服务程序运行获得的数据结果发送给所述远端智能设备，以使所述远端智能设备利用第二binder引用将所述数据结果返回给所述应用程序，其中，所述远端智能设备根据所述调用请求产生所述第二binder引用。

结合第四方面或第四方面的第一种可能的实现方式，在第二种可能的实现方式中，所述智能设备为用户终端或云终端，所述服务程序为应用进程服务或系统进程服务，所述管理模块为AMS模块或SM模块，所述处理模块为基于binder机制的binder驱动模块。

为解决上述问题，本申请第五方面提供一种服务程序调用系统，所述服务程序调用系统包括第一智能设备和第二智能设备。所述第一智能设备包括：第一代理服务模块，用于从所述第二智能设备调用服务程序；第一管理模块，用于接收应用程序调用对应的服务程序的调用请求并判断所述服务程序是否已定义为远程调用；第一处理模块，用于在所述第一管理模块判断到所述服务程序已定义为远程调用时，根据所述调用请求产生所述服务程序的识别信息并通过所述第一代理服务模块发送给所述第二智能设备，以通过所述第一代理服务模块从第二智能设备调用所述服务程序，在所述第一管理模块判断到所述服务程序未定义为远程调用时，则从本地调用所述服务程序。所述第二智能设备包括：第二代理服务模块，用于接收所述第一代理服务模块发送所述服务程序的识别信息；第二管理模块，用于根据所述第二代理服务模块接收到的所述服务程序的识别信息在本地确定对应的所述服务程序；第二处理模块，用于在所述第二代理服务模块接收到所述第一代理服务模块发送的针对所述服务程序的调用信息时，根据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的数据结果通过所述第二代理服务模块发送给所述第一代理服务模块以返回给所述应用程序。

结合第五方面，在第一种可能的实现方式中，所述第一管理模块具体用于根据所述调用请求产生与所述第一代理服务模块相对应的第一binder引用并将所述第一binder引用返回给所述应用程序。所述第一代理服务模块具体用于将所述服务程序的识别信息发送至所述第二代理服务模块，所述第二管理模块具体用于根据所述识别信息产生与所述服务程序对应的第二binder引用，并存储所述第二binder引用与所述服务程序的对应关系。所述第一代理服务模块具体还用于在所述应用程序根据所述第一binder引用调用所述服务程序时，将针对所述应用程序的调用信息发送至所述第二代理服务模块，所述第二处理模块具体用于根据所述服务程序的调用信息查找所述第二binder引用，并根据所述第二binder引用调用所述服务程序。所述第二代理服务模块具体用于将所述第二处理模块利用所述第二binder引用返回的所述服务程序运行获得的数据结果发送给所述第一处理模块，所述第一处理模块具体用于利用所述第一binder引用将所述第一代理服务模块接收的所述数据结果返回给所述应用程序。

结合第五方面的第一种可能的实现方式，在第二种可能的实现方式中，所述第一管理模块具体还用于在所述第一管理模块判断到所述服务程序未定义为远程调用时，根据所述调用请求从本地查找与所述服务程序对应的第三binder引用并将所述第三binder引用返回给所述应用程序。所述第一处理模块具体还用于在所述应用程序根据所述第三binder引用调用所述服务程序时，利用所述第三binder引用将所述服务程序运行获得的数据结果返回给所述应用程序。

结合第五方面、第五方面的第一种或第二种可能的实现方式，在第三种可能的实现方式中，所述第一智能设备还包括：注册模块，用于获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应的服务程序的服务名称，并存储所述程序名称和所述服务名称；注销模块，用于获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程序名称及对应的服务程序的服务名称，查找并删除所述程序名称和所述服务名称，以动态注消所述至少一个已注册及解耦的应用程序的注册及解耦。其中，所述第一管理模块具体用于判断所述注册模块中是否已存储有所述服务程序的服务名称，若所述注册模块中已存储有对应的服务名称则判断为已定义远程调用，若所述注册模块中未存储有对应的服务名称则判断为未定义远程调用。

结合第五方面的第一种或第二种可能的实现方式，在第四种可能的实现方式中，所述第一智能设备和所述第二智能设备的其中之一为用户终端、另一为云终端，所述第一处理模块和所述第二处理模块为基于binder机制的binder驱动模块。

结合第五方面的第一种或第二种可能的实现方式，在第五种可能的实现方式中，所述第一管理模块和所述第二管理模块均为AMS模块、或均为SM模块，所述服务程序相应地为应用进程服务或系统进程服务。

本申请在智能设备上设置代理服务模块并对自身的应用程序需要远程调用的服务程序预先进行定义，使得应用程序在运行并需要调用服务程序时通过代理服务模块从远端智能设备进行调用。本申请可以将需要进行大量复杂运算等特定的服务程序定义到远端智能设备运行，因此有效地解决了自身运行服务程序所需要的能耗问题。同时，本申请由于应用程序在智能设备自身进行运行而服务程序在远端智能设备上运行，无需采用现有的VNC技术进行智能设备之间的信息交互，因此有效地避免了操作延迟等问题，使得操作、显示性能更加顺畅。

附图说明

图1A是实现本申请服务程序调用方法的服务程序调用系统的其中一实施例结构示意图；

图1B是本申请服务程序调用方法第一实施例的流程示意图；

图2是本申请服务程序调用方法第二实施例的流程示意图；

图3是本申请智能设备第一实施例的结构示意图；

图4是本申请智能设备第二实施例的结构示意图；

图5是本申请服务程序调用方法第三实施例的流程示意图；

图6是本申请服务程序调用方法第四实施例的流程示意图；

图7是本申请智能设备第三实施例的结构示意图；

图8是本申请智能设备第四实施例的结构示意图；

图9是本申请服务程序调用系统第一实施例的结构示意图；

图10是本申请服务程序调用系统第二实施例的结构示意图；以及

图11是本申请智能设备一实施例的具体结构示意图。

具体实施方式

以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、接口、技术之类的具体细节，以便透切理解本申请。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施方式中也可以实现本申请。在其它情况中，省略对众所周知的装置、电路以及方法的详细说明，以免不必要的细节妨碍本申请的描述。

下面结合附图和具体的实施方式进行说明。

请参阅图1A和图1B，图1A是实现本申请服务程序调用方法的服务程序调用系统的其中一实施例结构示意图，图1B是本申请服务程序调用方法第一实施例的流程示意图。需要说明的是，图1A中显示了智能设备以及远端智能设备的部分结构，但不应构成对本实施例服务程序调用方法的限定，在本技术领域人员理解的范围内，还可以通过其他结构的服务程序调用系统实现本实施例，在此不作细述。

在本实施例中，如图1B所示，本实施例的服务程序调用方法包括但不限于以下步骤。

步骤S100，接收应用程序调用对应的服务程序的调用请求。与图1A对应的是，步骤S100可以由第一管理模块执行，其中，第一管理模块从应用程序进程模块接收应用程序调用对应的服务程序的调用请求。

步骤S101，判断服务程序是否已定义为远程调用，若判断到为已定义为远程调用时，执行步骤S102′，若判断到未定义为远程调用时，执行步骤S102″。与图1A对应的是，步骤S101可以由第一管理模块执行，也可以由第一处理模块执行，在此不作限定。

在步骤S101中，系统可以根据哈希表等表结构或者其他标记的方式判断该应用程序的调用请求中所描述的服务程序是否已定义为远程调用，譬如具体根据该应用程序的名称、该服务程序的名称等进行判断，在此不作限定。此外，本实施例需要调用的服务程序可以为另一应用程序的应用进程服务，也可以为系统进程服务，在此不作限定。

需要说明的是，现有技术中，智能设备本地的应用程序一般情况下按照系统给出的预定运行路径与本地的服务程序绑定耦合，在应用程序需要调用指定的服务程序时，将按照默认的预定运行路径查找调用已绑定耦合的本地的服务程序并运行该服务程序以得到数据结果；而本实施例的远程调用可以理解为对应用程序和服务程序之间进行解耦处理，具体可以理解为断开本地的应用程序与本地的服务程序之间的预定运行路径以取消两者之间的绑定关系，使得应用程序需要调用指定的服务程序时，不再按照默认的预定运行路径查找调用本地的服务程序，而需要根据调用请求进行判断处理。

步骤S102′，从远端智能设备调用服务程序。与图1A对应的是，步骤S102′可以由第一代理服务模块执行，其中，第一代理服务模块与远端智能设备的第二代理服务模块之间可以通过有线或无线等网络进行实时或按需的连接，在此不作限定。进一步而言，远端智能设备也可以不设置第二代理服务模块，而直接通过服务进程模块提供服务并进行相应的复杂运算，最终将运算后的数据结果返回给第一服务代理模块即可。

步骤S102″，从本地调用服务程序。与图1A对应的是，步骤S102″可以由第一处理模块执行，第一处理模块可以从本地的服务进程模块（图1A未示）调用服务程序并获得运算后的数据结果返回给应用程序进程模块，在本技术领域人员理解的范围内，不作细述。

不难看出，区别于现有技术应用级解耦的方式，本实施例的服务程序调用方法虽然需要进行网络连接，但与远端智能设备之间仅需要进行参数（譬如函数计算所需的参数）和数据结果的传输，传输量小而不会由于网络情况导致传输不稳定等问题，因此可以有效地降低操作延迟的时间。

本申请对自身的应用程序需要远程调用的服务程序预先进行定义是否进行远程调用，使得应用程序在运行并需要调用服务程序时从远端智能设备进行调用相应的服务程序。本申请可以将需要进行大量复杂运算等特定的服务程序解耦到远端智能设备运行，因此有效地解决了自身运行服务程序所需要的能耗问题。同时，本申请由于应用程序和服务程序分开运行，无需采用现有的VNC技术与远端智能设备之间进行信息交互，因此有效地避免了操作延迟等问题，使得操作、显示性能更加顺畅。

请参阅图2，图2是本申请服务程序调用方法第二实施例的流程示意图，本实施例的服务程序调用方法包括但不限于以下步骤。

步骤S200，接收应用程序调用对应的服务程序的调用请求。

步骤S201，判断服务程序是否已定义为远程调用。若判断到为已定义为远程调用，执行步骤S202，若判断未定义为远程调用，则执行步骤S206。

在步骤S201中，如前所述，系统可以根据哈希表等表结构或者其他标记的方式判断该应用程序的调用请求中所描述的服务程序是否已定义为远程调用，譬如具体根据该应用程序的名称、该服务程序的名称等进行判断，在此不作限定。此外，本实施例需要调用的服务程序可以为另一应用程序的应用进程服务，也可以为系统进程服务，在此不作限定。

具体而言，本实施例可以在步骤S200之前预先进行“对需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦”的设置过程，以将对应的服务程序定义为远程调用。

其中，“对需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦”的具体过程包括如下。

过程a，获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应的服务程序的服务名称。在过程a中，用户可以自行判断应用程序及对应的服务程序的运算量和复杂程度等，如果判断到服务程序的运算量和复杂程度过大，其将导致系统自身的能耗过大，则用户可以手动输入一个或多个应用程序的程序名称及对应的服务程序的服务名称；当然，系统自身也可以实时检测所需要运行的应用程序及对应的服务程序的运算量和复杂程度等，如果系统自身判断到服务程序的运算量和复杂程度过大，其将导致系统自身的能耗过大，则系统可以通过自动生成或选择等方式产生一个或多个应用程序的程序名称及对应的服务程序的服务名称。

过程b，存储程序名称和服务名称。在过程b中，其中，本实施例可以存储于表结构等哈希表中，当然，在其他实施例中也可以存储于系统的其他存储结构中，在此不作限定。结合步骤S201而言，在系统判断调用请求中所描述的服务程序是否已定义为远程调用的过程中，即可根据服务程序的服务名称从本地的表结构进行检索，如果检索到相同的服务名称，则从远端智能设备调用，反之则从本地调用。

此外，在某些特定的场所或时间段内，譬如可以在线充电或者没有网络可用的情况下，用户也可以对已进行动态注册及解耦的应用程序及其服务程序进行注销，其具体过程包括如下。

过程c，获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程序名称及对应的服务程序的服务名称。

过程d，查找并删除程序名称和服务名称，以动态注消至少一个已注册及解耦的应用程序的注册及解耦。

值得注意的是，过程a-过程d的过程中，用户可以实时地、智能地循环执行以进行注册或者注销，使得智能设备可以根据系统的自身状况或者所处环境进行智能操作，更加多样化和智能化。

步骤S202，根据调用请求产生第一binder引用并将第一binder引用返回给应用程序。

在步骤S202中，需要指出的是，本实施例针对基于binder机制（进程间通信机制）的智能设备实现具体的服务程序调用方法。其中，第一binder引用为应用程序需要进行调用服务程序时，需要与服务程序的binder实体之间通信所需要的binder引用，其具体工作过程在本技术领域人员理解的范围内，不作细述。

现有技术中，基于Android的智能设备为了降低系统自身的能耗，还专门采用到组件级解耦的方式来实现服务调用。具体而言，现有技术将应用程序的activity组件、service组件、content provider组件和broadcast receiver组件中的service组件和其它三个组件之间进行解耦，将其运行在远端智能设备，而其它部分运行在本地。然而在解耦的过程中需要将service组件变成桩模块和服务模块，并分别部署在智能设备和远端智能设备。在智能设备的应用程序需要调用服务程序时，需要通过本地的桩模块调用远端智能设备的服务模块，并返回结果。进一步而言，为了将上述解耦及调用的过程自动化，需要将开发者编写的代码重新编译，其需要通过应用程序中的AIDL（Android Interfacedefinition language，安卓接口定义语言）文件，将Service组件划分为桩模块和服务模块，并利用AIDL文件包含的描述Service接口的信息，对程序源代码一起进行编译，自动生成通过Binder机制调用Service的代码框架等。然而，这种解耦方式依赖于应用程序的源代码，必须在源代码基础上进行重新编译，而当前很多应用程序并不是开源程序，所以不能适用，同时，这种解耦方式依赖于应用程序对AIDL的使用，而很多应用程序绕过了AIDL直接使用Android框架所提供的Binder机制，而导致这种解耦方式无法用于这些特殊的应用程序。

不难看出，本实施例在基于Android的智能设备上，只需直接利用现有的binder机制，在智能设备自身和远端智能设备进行过程a-过程d的动态注册解耦及注销等，即可在现有的binder机制上实现现有应用程序从远端智能设备调用服务的过程，从而更加实用性。

步骤S203，将服务程序的识别信息发送至远端智能设备，以使远端智能设备产生与服务程序对应的第二binder引用，并存储第二binder引用与服务程序的对应关系。

在步骤S203中，在调用服务程序之前，需预先在远端智能设备存储第二binder引用与服务程序的对应关系，以备后续调用。

步骤S204，在应用程序根据第一binder引用调用服务程序时，将应用程序的调用信息发送至远端智能设备，以使远端智能设备根据调用信息查找第二binder引用，根据第二binder引用调用服务程序，并返回服务程序运行获得的数据结果。

在步骤S204中，智能设备将应用程序的调用信息譬如运算参数和服务名称等发送至远端智能设备。远端智能设备的binder驱动模块可以驱动管理远端智能设备的服务程序对应的binder实体接收第二binder引用传输过来的运算参数等，使得服务程序根据运算参数运行函数以获得数据结果，接着远端智能设备的binder驱动模块利用第二binder引用将数据结果返回给智能设备。

步骤S205，利用第一binder引用将数据结果返回给应用程序，步骤S205之后，结束或等待再次调用时返回步骤S200。

步骤S206，从本地调用服务程序。

在步骤S206中，具体可以利用binder机制进行调用，本实施例在本地调用服务程序的过程包括以下。

过程e，根据调用请求从本地查找与服务程序对应的第三binder引用并将第三binder引用返回给应用程序。

过程f，在应用程序根据第三binder引用调用服务程序时，利用第三binder引用将服务程序运行获得的数据结果返回给应用程序。

其中，基于binder机制在本地调用服务程序的具体实现过程e和过程f在本技术领域人员理解的范围内，不作细述。

此外，现有技术的基于Android的智能设备上，还采用到方法级解耦来调用服务的方式，然而通过方法级解耦的方式需要在应用程序的开发阶段，获得允许远程调用的服务程序（如函数方法等）的集合，其需要由程序员手动标注允许远程调用的服务程序，或通过静态分析找出服务程序中合法的可分割点（必须是某个应用程序的入口或者出口），再通过动态方法决定计算成本模型得出合适的迁移点。其次，在服务程序运行时，根据当前运行环境的不同参数，动态决定服务程序的运行位置。不难看出，这种方法级解耦的缺点在于需要对程序的代码或者二进制码进行修改，所以不适用于不开源的应用程序，且应用程序均会一般通过签名的方式进行完整性保护，对二进制码进行修改会导致签名验证失败，从而影响应用程序的正常运行。不难看出，本实施例针对基于Android的智能设备而言，应用程序与服务程序之间的解耦方式更加透明，可以将目前市场上已有的应用程序直接运行在现有的Android的智能设备上，而不需要对其进行任何改动或者重新编译，这样提高了本实施例服务程序调用方法的通用性和兼容性。

总而言之，本申请专门针对基于Android的智能设备及其基于binder机制的服务调用进行解耦，只需对应用程序需要远程调用的服务程序预先进行注册，使得应用程序在运行并需要调用服务程序时通过现有的binder机制从远端智能设备进行调用。本申请可以将需要进行大量复杂运算等特定的服务程序解耦到远端智能设备运行，因此有效地解决了自身运行服务程序所需要的能耗问题。同时，本申请服务程序调用方法可以兼容使用到现有的应用程序中，无需进行修改编译等，兼容性能更好而更具实用性。

请结合前面实施例参阅图3，是本申请智能设备第一实施例的结构示意图，本实施例智能设备包括但不限于代理服务模块30、管理模块31和处理模块32。

代理服务模块30可以与远端智能设备之间进行有线或无线网络的实时或按需连接，以用于从远端智能设备调用服务程序或进行数据信息传输等，在本技术领域人员理解的范围内，不作限定。

管理模块31用于接收应用程序进程模块中应用程序的调用请求并判断服务程序是否已定义为远程调用。管理模块31可以根据哈希表等表结构或者其他标记的方式判断该应用程序的调用请求中所描述的服务程序是否已定义为远程调用，譬如具体根据应用程序的名称、服务程序的名称等进行判断，在此不作限定。此外，本实施例需要调用的服务程序可以为另一应用程序的应用进程服务，也可以为系统进程服务，在此不作限定。

处理模块32用于在管理模块31判断到服务程序已定义为远程调用时，通过代理服务模块30从远端智能设备调用服务程序，而在管理模块31判断到服务程序未定义为远程调用时，则从本地调用服务程序。

不难看出，本实施例智能设备与远端智能设备之间仅需要进行参数（譬如函数计算所需的参数）和数据结果的传输，传输量小而不会由于网络情况导致传输不稳定等问题，因此可以有效地降低操作延迟的时间。

本申请智能设备对自身的应用程序需要远程调用的服务程序预先进行定义，使得应用程序在运行并需要调用服务程序时从远端智能设备进行调用。本申请智能设备可以将需要进行大量复杂运算等特定的服务程序解耦到远端智能设备运行，因此有效地解决了自身运行服务程序所需要的能耗问题。同时，本申请由于应用程序和服务程序分开运行，无需采用现有的VNC技术与远端智能设备之间进行信息交互，因此有效地避免了操作延迟等问题，使得操作、显示性能更加顺畅。

请结合图2所述实施例参阅图4，图4是本申请智能设备第二实施例的结构示意图，本实施例智能设备包括但不限于代理服务模块40、管理模块41、处理模块42、注册模块43和注销模块44。

如前所述，管理模块41用于接收应用程序调用对应的服务程序的调用请求并判断服务程序是否已定义为远程调用；处理模块42用于在管理模块41判断到服务程序已定义为远程调用时，通过代理服务模块40从远端智能设备调用服务程序，在管理模块41判断到服务程序未定义为远程调用时，则从本地调用服务程序。

在本实施例中，注册模块43用于对需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦，以将对应的服务程序定义为远程调用。而注册模块43具体可以包括第一获取单元431和第一管理单元432。

第一获取单元431用于获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应的服务程序的服务名称。用户可以自行判断应用程序及对应的服务程序的运算量和复杂程度等，如果判断到服务程序的运算量和复杂程度过大，其将导致智能设备自身的能耗过大，则用户可以手动输入一个或多个应用程序的程序名称及对应的服务程序的服务名称。当然，管理模块41也可以实时检测所需要运行的应用程序及对应的服务程序的运算量和复杂程度等，如果管理模块41判断到服务程序的运算量和复杂程度过大，其将导致系统自身的能耗过大，则系统可以通过自动生成或选择等方式产生一个或多个应用程序的程序名称及对应的服务程序的服务名称。

第一管理单元432用于存储第一获取单元431获取到的程序名称和服务名称，其中，第一管理单元432可以为本地的表结构等。相应地，在管理模块41判断调用请求中所描述的服务程序是否已定义为远程调用的过程中，即可根据服务程序的服务名称从本地的表结构进行检索，如果检索到相同的服务名称，则从远端智能设备调用，反之则从本地调用。具体来说，管理模块41具体用于判断第一管理单元432中是否已存储有调用请求中所描述的服务程序的服务名称，若第一管理单元432中已存储有对应的服务名称则判断为已定义远程调用，若第一管理单元432中未存储有对应的服务名称则判断为未定义远程调用。

注销模块44用于动态注消至少一个已注册及解耦的应用程序的注册及解耦，其具体可以包括第二获取单元441和第二管理单元442。

第二获取单元441用于获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程序名称及对应的服务程序的服务名称。

第二管理单元442，用于查找并删除第二获取单元441获取到的程序名称和服务名称，以动态注消至少一个已注册及解耦的应用程序的注册及解耦。其中，第二管理单元442可以在本地的表结构或其他存储单元中进行查找，在此不作细述。

本实施例通过注销模块44的作用，可以在某些特定的场所或时间段内，譬如在线充电或者没有网络可用的情况下，用户也可以对已进行动态注册及解耦的应用程序及其服务程序进行注销。

结合注册模块43和注销模块44的作用，用户可以实时地、智能地循环执行以进行注册或者注销，使得智能设备可以根据系统的自身状况或者所处环境进行智能操作，更加多样化和智能化。

值得注意的是，本实施例针对基于binder机制的智能设备作了进一步改进，具体来说，本实施例管理模块41具体用于根据应用程序进程模块中应用程序的调用请求产生与代理服务模块40相对应的第一binder引用并将第一binder引用返回给应用程序。具体来说，当应用程序进程模块中应用程序需要调用服务程序时，管理模块41将代理服务模块40作为“等效服务程序”并将“等效服务程序”对应的第一binder引用返回给应用程序，而使得在应用程序端默认其调用的即是服务程序。换而言之，代理服务模块40需要向管理模块41申请注册为“等效服务程序”，在管理模块41确认注册后产生第一binder引用并存储第一binder引用与代理服务模块40的对应关系到表结构中。

而代理服务模块40则可以通过binder机制中的binder实体来接收应用程序通过第一binder引用发送过来运算参数和服务名称等，在本技术领域人员理解的范围内，不作细述。

代理服务模块40具体用于将服务程序的识别信息发送至远端智能设备，以使远端智能设备产生与服务程序对应的第二binder引用，并存储第二binder引用与服务程序的对应关系。值得注意的是，在远端智能设备上，需要另一代理服务模块作为智能设备自身的应用程序在远端智能设备的“等效应用程序”，也即是说在远端智能设备上可以视作“等效应用程序”通过第二binder引用调用远端智能设备自身的服务程序。

代理服务模块40具体还用于在应用程序根据第一binder引用调用服务程序时，将应用程序的调用信息发送至远端智能设备，以使远端智能设备根据调用信息查找第二binder引用，根据第二binder引用调用服务程序，并返回服务程序运行获得的数据结果。

处理模块42具体用于利用第一binder引用将代理服务模块40从远端智能设备接收的数据结果返回给应用程序。

不难看出，本实施例通过代理服务模块40及另一代理服务模块分别实现“等效服务程序”和“等效应用程序”的作用，有效地避免了现有技术在智能设备需要调用远端智能设备的服务程序时、需要修改编译源代码或分析查找服务程序的分割点进行重新编译的无法实现和兼容性低的技术问题，本申请在智能设备和远端智能设备都按照现有的binder机制进行等效调用，可以有效地提高兼容性能。

另一方面，管理模块41具体用于在管理模块41判断到服务程序未定义为远程调用时，根据调用请求从本地（如本地服务进程模块）查找与服务程序对应的第三binder引用并将第三binder引用返回给应用程序。处理模块42具体还用于在应用程序根据第三binder引用调用服务程序时，利用第三binder引用将服务程序运行获得的数据结果返回给应用程序。

在本实施例中，不难理解的是，处理模块42可以为基于binder机制的binder驱动模块，其具体通过binder驱动模块实现应用程序进程模块和代理服务模块40之间的第一binder引用和binder实体之间的管理通信过程，在本技术领域人员理解的范围内，不作赘述。

值得注意的是，本实施例的智能设备可以为用户终端（手机或掌上电脑）而远端智能设备则对应地可以为云终端，因此可以将运算复杂且运算量大的服务程序运行在云终端上，以降低用户终端的能耗。

当然，智能设备也可以为云终端而远端智能设备则对应为用户终端，举例而言，如用户不希望将sensor（传感器）服务、通信录服务和GPS（全球定位系统）服务等服务程序运行在云终端上。此时，本实施例可以在云终端上通过注册模块43注册sensor服务、通信录服务和GPS服务为远程调用的方式，使得云终端需要这些指定的服务程序时，在用户终端自身执行sensor服务、通信录服务和GPS服务后将数据结果返回给云终端即可，通过这种方式，可以有效地保护用户的个人信息和隐私，提高了安全性能。

此外，需要说明的是，服务程序具体可以包括应用进程服务和系统进程服务，即相对于android的智能设备来说，管理模块41具体可以为基于binder机制的AMS（ActivityManager Service，活动管理服务）模块或SM（Service Manager，服务管理器）模块，在本技术领域人员理解的范围内，不作限定。

此外，本实施例的工作过程在图4及相关描述的基础上，其具体实现的工作过程在本技术领域人员容易结合理解的范围内，在此不作细述。

本申请专门针对基于Android的智能设备及其基于binder机制的服务调用进行解耦，只需对应用程序需要远程调用的服务程序预先进行注册，使得应用程序在运行并需要调用服务程序时通过现有的binder机制从远端智能设备进行调用。本申请可以将需要进行大量复杂运算等特定的服务程序解耦到远端智能设备运行，因此有效地解决了自身运行服务程序所需要的能耗问题。同时，本申请服务程序调用方法可以兼容使用到现有的应用程序中，无需进行修改编译等，兼容性能更好而更具实用性。此外，本申请还在一定程度上针对特殊的服务程序提供了更加安全的工作模式，保护了用户的个人信息和隐私。

请结合图1A参阅图5，是本申请服务程序调用方法第三实施例的流程示意图，本实施例服务程序调用方法的执行主体可以为图1A所示的第二管理模块、第二处理模块和第二代理服务模块，具体而言，本实施例的服务程序调用方法包括但不限于以下步骤。

步骤S500，接收远端智能设备发送的需远程调用的服务程序的识别信息，并根据服务程序的识别信息在本地确定对应的服务程序，其中，服务程序在远端智能设备已定义为远程调用，远端智能设备根据应用程序调用对应的服务程序所发出的调用请求产生服务程序的识别信息。

步骤S501，在接收到远端智能设备发送的针对服务程序的调用信息时，根据调用信息调用对应的服务程序，并将服务程序运行获得的数据结果返回给远端智能设备的应用程序。

本实施例服务程序调用方法通过将远端智能设备的服务程序解耦运行在本身的系统内，可以有效地降低远端智能设备的能耗。

请参阅图6，是本申请服务程序调用方法第四实施例的流程示意图，本实施例服务程序调用方法具体包括以下步骤。

步骤S600，接收远端智能设备发送的需远程调用的服务程序的识别信息，其中，服务程序在远端智能设备已定义为远程调用，远端智能设备根据应用程序调用对应的服务程序所发出的调用请求产生服务程序的识别信息。

步骤S601，根据服务程序的识别信息产生与服务程序对应的第一binder引用，并存储第一binder引用与服务程序的对应关系。

值得注意的是，在步骤S601中，本实施例针对基于binder机制的远端智能设备作了进一步改进，具体来说，本实施例在远端智能设备需要调用服务程序前，为了避免现有技术需要对源代码等进行重新编译的技术问题，而采用binder进制在系统自身进行服务程序调用。

步骤S602，在接收到远端智能设备发送的针对服务程序的调用信息时，根据调用信息查找第一binder引用，并根据第一binder引用调用服务程序。

步骤S603，将利用第一binder引用返回的服务程序运行获得的数据结果发送给远端智能设备，以使远端智能设备利用第二binder引用将数据结果返回给应用程序，其中，远端智能设备根据调用请求产生第二binder引用。

本实施例服务程序调用方法在智能设备自身和远端智能设备均通过各自的binder机制进行服务程序调用，无需修改及编译应用程序的源代码等，从而适用于现有技术的应用程序，兼容性更好。

请参阅图7，是本申请智能设备第三实施例的结构示意图，本实施例智能设备包括但不限于代理服务模块70、管理模块71和处理模块72。

代理服务模块70用于接收远端智能设备发送的需远程调用的服务程序的识别信息。其中，服务程序在远端智能设备已定义为远程调用，远端智能设备根据应用程序调用对应的服务程序所发出的调用请求产生服务程序的识别信息。

管理模块71用于根据代理服务模块70接收到的服务程序的识别信息在本地确定对应的服务程序。

处理模块72用于在代理服务模块70接收到远端智能设备发送的针对服务程序的调用信息时，根据调用信息调用对应的服务程序，并通过代理服务模块70将服务程序运行获得的数据结果返回给远端智能设备的应用程序。

本实施例的智能设备可以作为图3所示的“远端智能设备”，其具体实现过程请参阅相关实施例的描述，在此不再赘述。

请参阅图8，是本申请智能设备第四实施例的结构示意图，本实施例智能设备包括但不限于代理服务模块80、管理模块81、处理模块82。

如前所述，代理服务模块80用于接收远端智能设备发送的需远程调用的服务程序的识别信息。管理模块81用于根据代理服务模块80接收到的服务程序的识别信息在本地确定对应的服务程序。处理模块82用于在代理服务模块80接收到远端智能设备发送的针对服务程序的调用信息时，根据调用信息调用对应的服务程序，并将服务程序运行获得的数据结果返回给远端智能设备的应用程序。

需要说明的是，本实施例针对现有技术基于Android的智能设备在调用服务程序时，需要对应用程序或服务程序进行编译修改的技术问题，本实施例在智能设备自身和远端智能设备均通过各自的binder机制进行服务程序调用。

具体而言，管理模块81具体用于根据服务程序的识别信息产生与服务程序对应的第一binder引用，并存储第一binder引用与服务程序的对应关系。

处理模块82具体用于在代理服务模块80接收到远端智能设备发送的针对服务程序的调用信息时，根据调用信息查找第一binder引用，并根据第一binder引用调用服务程序。

代理服务模块80具体用于将处理模块82利用第一binder引用返回的服务程序运行获得的数据结果发送给远端智能设备，以使远端智能设备利用第二binder引用将数据结果返回给应用程序，其中，远端智能设备根据调用请求产生第二binder引用。

值得注意的是，为了实现代理服务模块80从服务进程模块中调用服务程序而需要修改编译等，本实施例需要通过管理模块81对代理服务模块80进行处理，使代理服务模块80作为智能设备自身所运行的“等效应用程序”来调用服务进程模块中的服务程序。具体而言，处理模块82可以为基于binder机制的binder驱动模块，而代理服务模块80和服务进程模块之间通过相应的第一binder引用（即Binder引用）与Binder实体之间进行服务程序调用及数据传输，在本技术领域人员理解的范围内，不作细述。

此外，本实施例的智能设备可以为用户终端，而远端智能设备可以为云终端，此时，本实施例可以在用户终端上执行sensor服务、通信录服务和GPS服务等服务后将数据结果返回给云终端，通过这种方式，可以有效地保护用户的个人信息和隐私，提高了安全性能。当然，本实施例的智能设备可以为云终端而远端智能设备则对应地可以为用户终端，本实施例可以将运算复杂且运算量大的服务程序运行在云终端上，以降低用户终端的能耗。

需要说明的是，服务程序可以为应用进程服务或系统进程服务，相应地，管理模块81为基于binder机制的AMS模块或SM模块，在此不作限定。

请参阅图9，是本申请服务程序调用系统第一实施例的结构示意图，本实施例服务程序调用系统包括但不限于第一智能设备和第二智能设备。

具体而言，第一智能设备包括第一代理服务模块90、第一管理模块91和第一处理模块92。

第一代理服务模块90可以用于从第二智能设备调用服务程序或进行数据信息传输等。

第一管理模块91用于接收应用程序进程模块中应用程序的调用请求并判断服务程序是否已定义为远程调用。

第一处理模块92用于在第一管理模块91判断到服务程序已定义为远程调用时，根据调用请求产生服务程序的识别信息并通过第一代理服务模块90发送给第二智能设备，以通过第一代理服务模块90从第二智能设备调用服务程序，在第一管理模块91判断到服务程序未定义为远程调用时，则从本地调用服务程序。

相应地，第二智能设备包括第二代理服务模块10、第二管理模块11和第二处理模块12。

第二代理服务模块10用于接收第一代理服务模块90发送服务程序的识别信息。

第二管理模块11用于根据第二代理服务模块10接收到的服务程序的识别信息在本地确定对应的服务程序。

第二处理模块12用于在第二代理服务模块10接收到第一代理服务模块90发送的针对服务程序的调用信息时，根据调用信息调用对应的服务程序，并将服务程序运行获得的数据结果通过第二代理服务模块10发送给第一代理服务模块90以返回给应用程序。

请结合图9参阅图10，图10是本申请服务程序调用系统第二实施例的结构示意图，本实施例中的第一智能设备和第二智能设备为基于Android的终端设备，且其对应采用binder机制进行服务程序的调用。

为了在binder机制的Android终端上实现本申请，本实施例的服务程序调用系统的具体过程包括以下。

在第一管理模块91判断到服务程序已定义为远程调用时。

第一管理模块91具体用于根据调用请求产生与第一代理服务模块90相对应的第一binder引用并将第一binder引用返回给应用程序。

第一代理服务模块90具体用于将服务程序的识别信息发送至第二代理服务模块10；接着，第二管理模块11具体用于根据识别信息产生与服务程序对应的第二binder引用，并存储第二binder引用与服务程序的对应关系。

第一代理服务模块90具体还用于在应用程序根据第一binder引用调用服务程序时，将针对应用程序的调用信息发送至第二代理服务模块10。其中，应用程序需要通过第一binder引用调用服务程序时，将进入第一代理服务模块90的处理函数（On Transact函数）中，接着第一代理服务模块90将调用信息通过有线或无线网络原封不动地发送给第二代理服务模块10。之后，第二处理模块12具体用于根据服务程序的调用信息查找第二binder引用，并根据第二binder引用调用服务程序。

第二代理服务模块10具体用于将第二处理模块12利用第二binder引用返回的服务程序运行获得的数据结果发送给第一处理模块92。相应地，第一处理模块92具体用于利用第一binder引用将第一代理服务模块90接收的数据结果返回给应用程序。

在上述过程中，不难看出，第一代理服务模块90在第一智能设备端相当于“等效服务程序”，即应用程序进程模块中应用程序视第一代理服务模块90为其需要调用的服务程序，使得应用程序进程模块与第一代理服务模块90之间直接通过binder机制进行调用。同理，第二代理服务模块10在第二智能设备内则相当于“等效应用程序”，即第二智能设备的服务进程模块视第二代理服务模块10为调用服务程序的应用程序进程模块中的应用程序，使得第二代理服务模块10与第二智能设备的服务进程模块之间直接通过binder机制进行调用。进一步而言，通过这种方式，本申请不再依赖于应用程序的源代码，无需在源代码基础上进行重新编译，也无需依赖于应用程序对AIDL架构的使用；本申请也不需修改服务程序的代码，无需去解决应用程序通过签名进行完整性保护的技术问题，因此本申请更具实用性和普及性。

此外，在第一管理模块91判断到服务程序未定义为远程调用时。

第一管理模块91具体还用于在第一管理模块91判断到服务程序未定义为远程调用时，并根据调用请求从本地查找与服务程序对应的第三binder引用并将第三binder引用返回给应用程序。

第一处理模块92具体还用于在应用程序根据第三binder引用调用服务程序时，利用第三binder引用将服务程序运行获得的数据结果返回给应用程序。不难看出，服务程序运行于本地的服务进程模块（图未示）中，而第一管理模块91、第一处理模块92和第一智能设备内部的服务进程模块之间通过现有的binder机制及其Binder引用和binder实体进行通信，在本技术领域人员理解的范围内，不作细述。

如图10所示，第一智能设备还包括注册模块93和注销模块94。注册模块93用于对需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦，以将对应的应用程序定义为远程调用。注销模块94用于获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程序名称及对应的服务程序的服务名称，查找并删除程序名称和服务名称，以动态注消至少一个已注册及解耦的应用程序的注册及解耦。其中，第一管理模块91具体用于判断注册模块93中是否已存储有服务程序的服务名称，若注册模块93中已存储有对应的服务名称则判断为已定义远程调用，若注册模块93中未存储有对应的服务名称则判断为未定义远程调用。

具体而言，注册模块93具体包括第一获取单元931和第一管理单元932。第一获取单元931用于获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应的服务程序的服务名称；第一管理单元932用于存储第一获取单元931获取到的程序名称和服务名称。对应地，第一管理模块91在判断调用请求中所描述的服务程序是否已注册为远程调用时，即根据该服务程序的服务名称在本地的表结构等存储单元中进行查询，其具体实现过程在本技术领域人员理解的范围内，不作细述。

类似地，注销模块94包括第二获取单元941和第二管理单元942。第二获取单元941用于获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程序名称及对应的服务程序的服务名称；第二管理单元942用于查找并删除第二获取单元941获取到的程序名称和服务名称，以动态注消至少一个已注册及解耦的应用程序的注册及解耦。

需要说明的是，第一获取单元931和第二获取单元941均可以为第一智能设备的人机操作界面的输入窗口等，在本技术领域人员理解的范围内，不作赘述。

在本实施例中，第一智能设备和第二智能设备的其中之一为用户终端、另一为云终端。当然，第一智能设备和第二智能设备均可以为手机等用户终端，譬如为近场通信技术连接的两台手机等，在此不作细述。

应理解地，第一处理模块92和第二处理模块12均可以为基于binder机制的binder驱动模块；第一管理模块91和第二管理模块11均可以为AMS模块、或均为SM模块，对应地，服务程序相应地可以为应用进程服务或系统进程服务。举例而言，若服务程序为应用进程服务，第一智能设备具体为手机，第二智能设备为云终端：则第一管理模块91和第二管理模块11均为AMS模块，第一代理服务模块90为远端智能设备应用服务进程在手机的代理LPS（Local Proxy Service）进程，第二代理服务模块10为本地应用程序进程在云终端的代理RPS（Remote Proxy Service）进程；反之，若服务程序为系统进程服务，第一智能设备具体为手机，第二智能设备为云终端：则第一管理模块91和第二管理模块11均为SM模块，第一代理服务模块90为远端智能设备系统服务进程在本地的代理LPSS（Local Proxy SystemService）进程，第二代理服务模块10为本地应用程序进程在云终端的代理RPSS(RemoteProxy System Service)进程。当然，其具体实现的方式在本技术领域人员理解的范围内，不作赘述。

结合前面一个或多个实施例不难看出，本申请通过设置第一代理服务模块90和第二代理服务模块10的方式，可以实现remote binder（跨网络进程间通信）机制进行远程调用服务。

请参阅图11，是是本申请智能设备一实施例的具体结构示意图，本实施例智能设备包括但不限于包括处理器21、接收器22、发送器23、随机存取存储器24、只读存储器25、总线26以及网络接口单元27。其中，处理器21通过总线26分别耦接接收器22、发送器23、随机存取存储器24、只读存储器25以及网络接口单元27。

在其中一个具体实施例中，处理器21用于接收应用程序调用对应的服务程序的调用请求并判断调用请求中所描述的服务程序是否已定义为远程调用；处理器21在判断到服务程序已定义为远程调用时，根据调用请求产生服务程序的识别信息并通过发送器23或网络接口单元27发送给远端智能设备。举例而言，在处理器21判断到服务程序已定义为远程调用时，根据调用请求产生相对应的第一binder引用并将第一binder引用返回给应用程序；接着，处理器21通过发送器23将服务程序的识别信息发送至远端智能设备；而在应用程序根据第一binder引用调用服务程序时，处理器21将针对应用程序的调用信息发送至远端智能设备；最终，处理器21利用第一binder引用将接收器22接收的数据结果返回给应用程序。

在另一个具体实施例中，处理器21用于接收远端智能设备通过网络发送给接收器22或网络接口单元27的服务程序的识别信息；处理器21根据识别信息在本地确定对应的服务程序；接着在通过接收器22等接收到远端智能设备发送的针对服务程序的调用信息时，处理器21根据调用信息调用对应的服务程序，并将服务程序运行获得的数据结果通过发送器23发送给远端智能设备以返回给应用程序。举例而言，处理器21具体用于根据识别信息产生与服务程序对应的第二binder引用，并存储第二binder引用与服务程序的对应关系；接着，处理器21根据服务程序的调用信息查找第二binder引用，并根据第二binder引用调用服务程序；发送器23具体用于将处理器21利用第二binder引用返回的服务程序运行获得的数据结果发送给远端智能设备。

本申请不再依赖于应用程序的源代码，无需在源代码基础上进行重新编译，也无需依赖于应用程序对AIDL架构的使用；本申请也不需修改服务程序的代码，无需去解决应用程序通过签名进行完整性保护的技术问题，因此本申请更具实用性和普及性。

本实施方式中，处理器31可能是一个中央处理器CPU，或者是特定集成电路ASIC（Application Specific Integrated Circuit），或者是被配置成实施本申请实施方式的一个或多个集成电路。

在本申请所提供的几个实施方式中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。

另外，在本申请各个实施方式中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，管理服务器，或者网络设备等）或处理器（processor）执行本申请各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施方式，并非因此限制本申请的保护范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (22)

1.一种服务程序调用方法，其特征在于，所述服务程序调用方法包括：

对需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦，以定义为远程调用；

接收应用程序调用对应的服务程序的调用请求；

判断所述服务程序是否已定义为远程调用；

若已定义为远程调用，则从远端智能设备调用所述服务程序；

若未定义为远程调用，则从本地调用所述服务程序。

2.根据权利要求1所述的服务程序调用方法，其特征在于，所述从远端智能设备调用所述服务程序的步骤包括：

根据所述调用请求产生第一binder引用并将所述第一binder引用返回给所述应用程序；

将所述服务程序的识别信息发送至远端智能设备，以使远端智能设备产生与所述服务程序对应的第二binder引用，并存储所述第二binder引用与所述服务程序的对应关系；

在所述应用程序根据所述第一binder引用调用所述服务程序时，将所述应用程序的调用信息发送至所述远端智能设备，以使所述远端智能设备根据所述调用信息查找所述第二binder引用，根据所述第二binder引用调用所述服务程序，并返回所述服务程序运行获得的数据结果；

利用所述第一binder引用将所述数据结果返回给所述应用程序。

3.根据权利要求2所述的服务程序调用方法，其特征在于，所述从本地调用所述服务程序的步骤包括：

根据所述调用请求从本地查找与所述服务程序对应的第三binder引用并将所述第三binder引用返回给所述应用程序；

在所述应用程序根据所述第三binder引用调用所述服务程序时，利用所述第三binder引用将所述服务程序运行获得的数据结果返回给所述应用程序。

4.根据权利要求1所述的服务程序调用方法，其特征在于：

所述对需远程调用服务的应用程序及对应的服务程序进行注册及解耦的步骤包括：

获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应的服务程序的服务名称；

存储所述程序名称和所述服务名称；

所述判断所述服务程序是否已定义为远程调用的步骤包括：

判断是否已存储有所述服务程序的服务名称，若已存储有对应的服务名称则判断为已定义远程调用，若未存储有对应的服务名称则判断为未定义远程调用。

5.根据权利要求1所述的服务程序调用方法，其特征在于，所述接收应用程序调用对应的服务程序的调用请求的步骤之前还包括：

获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程序名称及对应的服务程序的服务名称；

查找并删除所述程序名称和所述服务名称，以动态注消所述至少一个已注册及解耦的应用程序的注册及解耦。

6.根据权利要求1-3任一项所述的服务程序调用方法，其特征在于，所述服务程序包括应用进程服务和系统进程服务。

7.一种智能设备，其特征在于，所述智能设备包括：

代理服务模块，用于从远端智能设备调用服务程序；

管理模块，用于接收应用程序调用对应的服务程序的调用请求并判断所述服务程序是否已定义为远程调用；

处理模块，用于在所述管理模块判断到所述服务程序已定义为远程调用时，通过所述代理服务模块从远端智能设备调用所述服务程序，在所述管理模块判断到所述服务程序未定义为远程调用时，则从本地调用所述服务程序；

注册模块，用于对需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦，以定义为远程调用。

8.根据权利要求7所述的智能设备，其特征在于：

所述管理模块具体用于根据所述调用请求产生与所述代理服务模块相对应的第一binder引用并将所述第一binder引用返回给所述应用程序；

所述代理服务模块具体用于将所述服务程序的识别信息发送至远端智能设备，以使远端智能设备产生与所述服务程序对应的第二binder引用，并存储所述第二binder引用与所述服务程序的对应关系；

所述代理服务模块具体还用于在所述应用程序根据所述第一binder引用调用所述服务程序时，将所述应用程序的调用信息发送至所述远端智能设备，以使所述远端智能设备根据所述调用信息查找所述第二binder引用，根据所述第二binder引用调用所述服务程序，并返回所述服务程序运行获得的数据结果；

所述处理模块具体用于利用所述第一binder引用将所述代理服务模块从所述远端智能设备接收的所述数据结果返回给所述应用程序。

9.根据权利要求8所述的智能设备，其特征在于：

所述管理模块具体用于在所述管理模块判断到所述服务程序未定义为远程调用时，根据所述调用请求从本地查找与所述服务程序对应的第三binder引用并将所述第三binder引用返回给所述应用程序；

所述处理模块具体还用于在所述应用程序根据所述第三binder引用调用所述服务程序时，利用所述第三binder引用将所述服务程序运行获得的数据结果返回给所述应用程序。

10.根据权利要求7所述的智能设备，其特征在于，所述注册模块具体包括：

第一获取单元，用于获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应的服务程序的服务名称；

第一管理单元，用于存储所述第一获取单元获取到的所述程序名称和所述服务名称；

其中，所述管理模块具体用于判断所述第一管理单元中是否已存储有所述服务程序的服务名称，若所述第一管理单元中已存储有对应的服务名称则判断为已定义远程调用，若所述第一管理单元中未存储有对应的服务名称则判断为未定义远程调用。

11.根据权利要求10所述的智能设备，其特征在于，所述智能设备还包括注销模块，所述注销模块包括：

第二获取单元，用于获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程序名称及对应的服务程序的服务名称；

第二管理单元，用于查找并删除所述第二获取单元获取到的所述程序名称和所述服务名称，以动态注消所述至少一个已注册及解耦的应用程序的注册及解耦。

12.根据权利要求8或9所述的智能设备，其特征在于，所述智能设备为用户终端或云终端，所述服务程序包括应用进程服务和系统进程服务，所述管理模块为AMS模块或SM模块，所述处理模块为基于binder机制的binder驱动模块。

13.一种服务程序调用方法，其特征在于，所述服务程序调用方法包括：

接收远端智能设备发送的需远程调用的服务程序的识别信息，并根据所述服务程序的识别信息在本地确定对应的所述服务程序，其中，所述服务程序在远端智能设备已定义为远程调用，所述远端智能设备根据应用程序调用对应的服务程序所发出的调用请求产生所述服务程序的识别信息；

在接收到远端智能设备发送的针对所述服务程序的调用信息时，根据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的数据结果返回给所述远端智能设备的应用程序；

所述根据所述服务程序的识别信息在本地确定对应的所述服务程序的步骤具体包括：

根据所述服务程序的识别信息产生与所述服务程序对应的第一binder引用，并存储所述第一binder引用与所述服务程序的对应关系；

所述根据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的数据结果返回给所述远端智能设备的应用程序的步骤具体包括：

根据所述调用信息查找所述第一binder引用，并根据所述第一binder引用调用所述服务程序；

将利用所述第一binder引用返回的所述服务程序运行获得的数据结果发送给所述远端智能设备，以使所述远端智能设备利用第二binder引用将所述数据结果返回给所述应用程序，其中，所述远端智能设备根据所述调用请求产生所述第二binder引用。

14.根据权利要求13所述的服务程序调用方法，其特征在于，所述服务程序包括应用进程服务和系统进程服务。

15.一种智能设备，其特征在于，所述智能设备包括：

代理服务模块，用于接收远端智能设备发送的需远程调用的服务程序的识别信息，其中，所述服务程序在远端智能设备已定义为远程调用，所述远端智能设备根据应用程序调用对应的服务程序所发出的调用请求产生所述服务程序的识别信息；

管理模块，用于根据所述代理服务模块接收到的所述服务程序的识别信息在本地确定对应的所述服务程序；

处理模块，用于在所述代理服务模块接收到远端智能设备发送的针对所述服务程序的调用信息时，根据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的数据结果返回给所述远端智能设备的应用程序；

所述管理模块具体用于根据所述服务程序的识别信息产生与所述服务程序对应的第一binder引用，并存储所述第一binder引用与所述服务程序的对应关系；

所述处理模块具体用于在所述代理服务模块接收到远端智能设备发送的针对所述服务程序的调用信息时，根据所述调用信息查找所述第一binder引用，并根据所述第一binder引用调用所述服务程序；

所述代理服务模块具体用于将所述处理模块利用所述第一binder引用返回的所述服务程序运行获得的数据结果发送给所述远端智能设备，以使所述远端智能设备利用第二binder引用将所述数据结果返回给所述应用程序，其中，所述远端智能设备根据所述调用请求产生所述第二binder引用。

16.根据权利要求15所述的智能设备，其特征在于，所述智能设备为用户终端或云终端，所述服务程序为应用进程服务或系统进程服务，所述管理模块为AMS模块或SM模块，所述处理模块为基于binder机制的binder驱动模块。

17.一种服务程序调用系统，其特征在于，所述服务程序调用系统包括第一智能设备和第二智能设备：

所述第一智能设备包括：

第一代理服务模块，用于从所述第二智能设备调用服务程序；

第一管理模块，用于接收应用程序调用对应的服务程序的调用请求并判断所述服务程序是否已定义为远程调用；

第一处理模块，用于在所述第一管理模块判断到所述服务程序已定义为远程调用时，根据所述调用请求产生所述服务程序的识别信息并通过所述第一代理服务模块发送给所述第二智能设备，以通过所述第一代理服务模块从所述第二智能设备调用所述服务程序，在所述第一管理模块判断到所述服务程序未定义为远程调用时，则从本地调用所述服务程序；

注册模块，用于对需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦，以将对应的服务程序定义为远程调用；

所述第二智能设备包括：

第二代理服务模块，用于接收所述第一代理服务模块发送所述服务程序的识别信息；

第二管理模块，用于根据所述第二代理服务模块接收到的所述服务程序的识别信息在本地确定对应的所述服务程序；

第二处理模块，用于在所述第二代理服务模块接收到所述第一代理服务模块发送的针对所述服务程序的调用信息时，根据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的数据结果通过所述第二代理服务模块发送给所述第一代理服务模块以返回给所述应用程序。

18.根据权利要求17所述的服务程序调用系统，其特征在于：

所述第一管理模块具体用于根据所述调用请求产生与所述第一代理服务模块相对应的第一binder引用并将所述第一binder引用返回给所述应用程序；

所述第一代理服务模块具体用于将所述服务程序的识别信息发送至所述第二代理服务模块，所述第二管理模块具体用于根据所述识别信息产生与所述服务程序对应的第二binder引用，并存储所述第二binder引用与所述服务程序的对应关系；

所述第一代理服务模块具体还用于在所述应用程序根据所述第一binder引用调用所述服务程序时，将针对所述应用程序的调用信息发送至所述第二代理服务模块，所述第二处理模块具体用于根据所述服务程序的调用信息查找所述第二binder引用，并根据所述第二binder引用调用所述服务程序；

所述第二代理服务模块具体用于将所述第二处理模块利用所述第二binder引用返回的所述服务程序运行获得的数据结果发送给所述第一处理模块，所述第一处理模块具体用于利用所述第一binder引用将所述第一代理服务模块接收的所述数据结果返回给所述应用程序。

19.根据权利要求18所述的服务程序调用系统，其特征在于：

所述第一管理模块具体还用于在所述第一管理模块判断到所述服务程序未定义为远程调用时，根据所述调用请求从本地查找与所述服务程序对应的第三binder引用并将所述第三binder引用返回给所述应用程序；

所述第一处理模块具体还用于在所述应用程序根据所述第三binder引用调用所述服务程序时，利用所述第三binder引用将所述服务程序运行获得的数据结果返回给所述应用程序。

20.根据权利要求17-19任一项所述的服务程序调用系统，其特征在于，所述第一智能设备还包括：

注册模块，用于获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应的服务程序的服务名称，并存储所述程序名称和所述服务名称；

注销模块，用于获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程序名称及对应的服务程序的服务名称，查找并删除所述程序名称和所述服务名称，以动态注消所述至少一个已注册及解耦的应用程序的注册及解耦；

其中，所述第一管理模块具体用于判断所述注册模块中是否已存储有所述服务程序的服务名称，若所述注册模块中已存储有对应的服务名称则判断为已定义远程调用，若所述注册模块中未存储有对应的服务名称则判断为未定义远程调用。

21.根据权利要求18或19所述的服务程序调用系统，其特征在于，所述第一智能设备和所述第二智能设备的其中之一为用户终端、另一为云终端，所述第一处理模块和所述第二处理模块为基于binder机制的binder驱动模块。

22.根据权利要求18或19所述的服务程序调用系统，其特征在于，所述第一管理模块和所述第二管理模块均为AMS模块、或均为SM模块，所述服务程序相应地为应用进程服务或系统进程服务。