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

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

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

【背景技术】
[0002] 随着用户终端(如手机和掌上电脑）以及云终端等智能设备技术的高速发展，智能 设备也越来越普及。然而在实现智能化的同时，另一方面伴随而来的是越来越复杂的应用 程序及其大量复杂的运算，这些大量复杂的运算需要频繁大量地在智能设备本地调用运行 一个或多个服务程序进行服务，进而必然导致智能设备自身的能耗越来越大。因此，目前本 领域技术人员急于解决智能设备的能耗问题。
[0003] 为了降低智能设备的能耗，现有技术采用了一种应用级解耦的方式。
[0004] 举例而言，对于手机来说，用户希望充电次数和时间越少越好，即希望降低其能 耗。现有技术将本应运行在手机端的整个应用程序都部署在云终端进行运行，而应用程序 运行时即可在云终端调用运行相关的服务程序进行运算，手机仅负责输入和显示结果。在 工作时，手机端将用户通过⑶I (Graphic User Interface,图形用户接口）操作利用网络 发送给云终端，云终端在应用程序每次更新屏幕时候将图像信息传送回给手机进行显示。
[0005] 这种应用级解耦的方式虽然在一定程度上可实现云终端与手机的无缝整合，从 用户的角度看，应用程序仿佛运行在手机上。但是这种解耦方式需要采用VNC (Virtual Network Computing,虚拟网络计算）技术在手机与云终端之间进行交互，因此虽然在一定 程度上降低了智能设备的能耗，但容易造成手机端用户的操作延迟增加，界面切换不 顺畅。


【发明内容】

[0006] 有鉴于此，本申请提供了一种服务程序调用方法、系统及智能设备，以解决现有技 术的智能设备由于运行服务程序的大量复杂运算而导致能耗过多的技术问题。
[0007] 为解决上述问题，本申请第一方面提供一种服务程序调用方法，所述服务程序调 用方法包括：接收应用程序调用对应的服务程序的调用请求；判断所述服务程序是否已定 义为远程调用；若已定义为远程调用，则从远端智能设备调用所述服务程序；若未定义为 远程调用，则从本地调用所述服务程序。
[0008] 结合第一方面，在第一种可能的实现方式中，所述从远端智能设备调用所述服务 程序的步骤包括：根据所述调用请求产生第一 binder引用并将所述第一 binder引用返回 给所述应用程序；将所述服务程序的识别信息发送至远端智能设备，以使远端智能设备产 生与所述服务程序对应的第二 binder引用，并存储所述第二 binder引用与所述服务程序 的对应关系；在所述应用程序根据所述第一 binder引用调用所述服务程序时，将所述应用 程序的调用信息发送至所述远端智能设备，以使所述远端智能设备根据所述调用信息查找 所述第二 binder引用，根据所述第二 binder引用调用所述服务程序，并返回所述服务程序 运行获得的数据结果；利用所述第一 binder引用将所述数据结果返回给所述应用程序。
[0009] 结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，所述从本 地调用所述服务程序的步骤包括：根据所述调用请求从本地查找与所述服务程序对应的第 三binder引用并将所述第三binder引用返回给所述应用程序；在所述应用程序根据所述 第三binder引用调用所述服务程序时，利用所述第三binder引用将所述服务程序运行获 得的数据结果返回给所述应用程序。
[0010] 结合第一方面、第一方面的第一种可能或第二种可能的实现方式，在第三种可能 的实现方式中，所述接收应用程序调用对应的服务程序的调用请求的步骤之前还包括：对 需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦，以定义为远程调用。
[0011] 结合第一方面的第三种可能的实现方式，在第四种可能的实现方式中，所述对需 远程调用服务的应用程序及对应的服务程序进行注册及解耦的步骤包括：获取用户输入或 系统检测产生的至少一个应用程序的程序名称及对应的服务程序的服务名称；存储所述程 序名称和所述服务名称。所述判断所述服务程序是否已定义为远程调用的步骤包括：判断 是否已存储有所述服务程序的服务名称，若已存储有对应的服务名称则判断为已定义远程 调用，若未存储有对应的服务名称则判断为未定义远程调用。
[0012] 结合第一方面的第三种可能的实现方式，在第五种可能的实现方式中，所述接收 应用程序调用对应的服务程序的调用请求的步骤之前还包括：获取用户输入或系统检测产 生的至少一个已注册及解耦的应用程序的程序名称及对应的服务程序的服务名称；查找并 删除所述程序名称和所述服务名称，以动态注消所述至少一个已注册及解耦的应用程序的 注册及解耦。
[0013] 结合第一方面、第一方面的第一种可能或第二种可能的实现方式，在第六种可能 的实现方式中，所述服务程序为应用进程服务或系统进程服务。
[0014] 为解决上述问题，本申请第二方面提供一种智能设备，所述智能设备包括：代理服 务模块，用于从远端智能设备调用服务程序；管理模块，用于接收应用程序调用对应的服务 程序的调用请求并判断所述服务程序是否已定义为远程调用；处理模块，用于在所述管理 模块判断到所述服务程序已定义为远程调用时，通过所述代理服务模块从远端智能设备调 用所述服务程序，在所述管理模块判断到所述服务程序未定义为远程调用时，则从本地调 用所述服务程序。
[0015] 结合第二方面，在第一种可能的实现方式中，所述管理模块具体用于根据所述调 用请求产生与所述代理服务模块相对应的第一 binder引用并将所述第一 binder引用返回 给所述应用程序。所述代理服务模块具体用于将所述服务程序的识别信息发送至远端智 能设备，以使远端智能设备产生与所述服务程序对应的第二 binder引用，并存储所述第二 binder引用与所述服务程序的对应关系。所述代理服务模块具体还用于在所述应用程序根 据所述第一 binder引用调用所述服务程序时，将所述应用程序的调用信息发送至所述远 端智能设备，以使所述远端智能设备根据所述调用信息查找所述第二 binder引用，根据所 述第二 binder引用调用所述服务程序，并返回所述服务程序运行获得的数据结果。所述处 理模块具体用于利用所述第一 binder引用将所述代理服务模块从所述远端智能设备接收 的所述数据结果返回给所述应用程序。
[0016] 结合第二方面的第一种可能的实现方式，在第二种可能的实现方式中，所述管理 模块具体用于在所述管理模块判断到所述服务程序未定义为远程调用时，根据所述调用请 求从本地查找与所述服务程序对应的第三binder引用并将所述第三binder引用返回给所 述应用程序。所述处理模块具体还用于在所述应用程序根据所述第三binder引用调用所 述服务程序时，利用所述第三binder引用将所述服务程序运行获得的数据结果返回给所 述应用程序。
[0017] 结合第二方面、第二方面的第一种可能或第二种可能的实现方式，在第三种可能 的实现方式中，所述智能设备还包括：注册模块，用于对需远程调用服务的应用程序及对应 的服务程序进行动态注册及解耦，以定义为远程调用。
[0018] 结合第二方面的第三种可能的实现方式，在第四种可能的实现方式中，所述注册 模块具体包括：第一获取单元，用于获取用户输入或系统检测产生的至少一个应用程序的 程序名称及对应的服务程序的服务名称；第一管理单元，用于存储所述第一获取单元获取 到的所述程序名称和所述服务名称。其中，所述管理模块具体用于判断所述第一管理单元 中是否已存储有所述服务程序的服务名称，若所述第一管理单元中已存储有对应的服务名 称则判断为已定义远程调用，若所述第一管理单元中未存储有对应的服务名称则判断为未 定义远程调用。
[0019] 结合第二方面的第四种可能的实现方式，在第五种可能的实现方式中，所述智能 设备还包括注销模块，所述注销模块包括：第二获取单元，用于获取用户输入或系统检测产 生的至少一个已注册及解耦的应用程序的程序名称及对应的服务程序的服务名称；第二管 理单元，用于查找并删除所述第二获取单元获取到的所述程序名称和所述服务名称，以动 态注消所述至少一个已注册及解耦的应用程序的注册及解耦。
[0020] 结合第二方面的第一种或第二种可能的实现方式，在第六种可能的实现方式中， 所述智能设备为用户终端或云终端，所述服务程序为应用进程服务或系统进程服务，所述 管理模块为AMS模块或SM模块，所述处理模块为基于binder机制的binder驱动模块。
[0021] 为解决上述问题，本申请第三方面提供一种服务程序调用方法，所述服务程序调 用方法包括：接收远端智能设备发送的需远程调用的服务程序的识别信息，并根据所述服 务程序的识别信息在本地确定对应的所述服务程序，其中，所述服务程序在远端智能设备 已定义为远程调用，所述远端智能设备根据所述应用程序调用对应的服务程序所发出的调 用请求产生所述服务程序的识别信息；在接收到远端智能设备发送的针对所述服务程序的 调用信息时，根据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的 数据结果返回给所述远端智能设备的应用程序。
[0022] 结合第三方面，在第一种可能的实现方式中，所述根据所述服务程序的识别信息 在本地确定对应的所述服务程序的步骤具体包括：根据所述服务程序的识别信息产生与 所述服务程序对应的第一 binder引用，并存储所述第一 binder引用与所述服务程序的对 应关系。所述根据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的 数据结果返回给所述远端智能设备的应用程序的步骤具体包括：根据所述调用信息查找 所述第一 binder引用，并根据所述第一 binder引用调用所述服务程序；将利用所述第一 binder引用返回的所述服务程序运行获得的数据结果发送给所述远端智能设备，以使所述 远端智能设备利用第二 binder引用将所述数据结果返回给所述应用程序。其中，所述远端 智能设备根据所述调用请求产生所述第二 binder引用。
[0023] 结合第三方面或第三方面的第一种可能的实现方式，在第二种可能的实现方式 中，所述服务程序为应用进程服务或系统进程服务。
[0024] 为解决上述问题，本申请第四方面提供一种智能设备，所述智能设备包括：代理服 务模块，用于接收远端智能设备发送的需远程调用的服务程序的识别信息，其中，所述服务 程序在远端智能设备已定义为远程调用，所述远端智能设备根据所述应用程序调用对应的 服务程序所发出的调用请求产生所述服务程序的识别信息；管理模块，用于根据所述代理 服务模块接收到的所述服务程序的识别信息在本地确定对应的所述服务程序；处理模块， 用于在所述代理服务模块接收到远端智能设备发送的针对所述服务程序的调用信息时，根 据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的数据结果返回给 所述远端智能设备的应用程序。
[0025] 结合第四方面，在第一种可能的实现方式中，所述管理模块具体用于根据所述服 务程序的识别信息产生与所述服务程序对应的第一 binder引用，并存储所述第一 binder 引用与所述服务程序的对应关系。所述处理模块具体用于在所述代理服务模块接收到远端 智能设备发送的针对所述服务程序的调用信息时，根据所述调用信息查找所述第一 binder 引用，并根据所述第一 binder引用调用所述服务程序。所述代理服务模块具体用于将所述 处理模块利用所述第一 binder引用返回的所述服务程序运行获得的数据结果发送给所述 远端智能设备，以使所述远端智能设备利用第二 binder引用将所述数据结果返回给所述 应用程序，其中，所述远端智能设备根据所述调用请求产生所述第二 binder引用。
[0026] 结合第四方面或第四方面的第一种可能的实现方式，在第二种可能的实现方式 中，所述智能设备为用户终端或云终端，所述服务程序为应用进程服务或系统进程服务，所 述管理模块为AMS模块或SM模块，所述处理模块为基于binder机制的binder驱动模块。
[0027] 为解决上述问题，本申请第五方面提供一种服务程序调用系统，所述服务程序调 用系统包括第一智能设备和第二智能设备。所述第一智能设备包括：第一代理服务模块，用 于从所述第二智能设备调用服务程序；第一管理模块，用于接收应用程序调用对应的服务 程序的调用请求并判断所述服务程序是否已定义为远程调用；第一处理模块，用于在所述 第一管理模块判断到所述服务程序已定义为远程调用时，根据所述调用请求产生所述服务 程序的识别信息并通过所述第一代理服务模块发送给所述第二智能设备，以通过所述第一 代理服务模块从第二智能设备调用所述服务程序，在所述第一管理模块判断到所述服务程 序未定义为远程调用时，则从本地调用所述服务程序。所述第二智能设备包括：第二代理服 务模块，用于接收所述第一代理服务模块发送所述服务程序的识别信息；第二管理模块，用 于根据所述第二代理服务模块接收到的所述服务程序的识别信息在本地确定对应的所述 服务程序；第二处理模块，用于在所述第二代理服务模块接收到所述第一代理服务模块发 送的针对所述服务程序的调用信息时，根据所述调用信息调用对应的所述服务程序，并将 所述服务程序运行获得的数据结果通过所述第二代理服务模块发送给所述第一代理服务 模块以返回给所述应用程序。
[0028] 结合第五方面，在第一种可能的实现方式中，所述第一管理模块具体用于根据所 述调用请求产生与所述第一代理服务模块相对应的第一 binder引用并将所述第一 binder 引用返回给所述应用程序。所述第一代理服务模块具体用于将所述服务程序的识别信息发 送至所述第二代理服务模块，所述第二管理模块具体用于根据所述识别信息产生与所述服 务程序对应的第二binder引用，并存储所述第二binder引用与所述服务程序的对应关系。 所述第一代理服务模块具体还用于在所述应用程序根据所述第一 binder引用调用所述服 务程序时，将针对所述应用程序的调用信息发送至所述第二代理服务模块，所述第二处理 模块具体用于根据所述服务程序的调用信息查找所述第二 binder引用，并根据所述第二 binder引用调用所述服务程序。所述第二代理服务模块具体用于将所述第二处理模块利 用所述第二 binder引用返回的所述服务程序运行获得的数据结果发送给所述第一处理模 块，所述第一处理模块具体用于利用所述第一 binder引用将所述第一代理服务模块接收 的所述数据结果返回给所述应用程序。
[0029] 结合第五方面的第一种可能的实现方式，在第二种可能的实现方式中，所述第一 管理模块具体还用于在所述第一管理模块判断到所述服务程序未定义为远程调用时，根据 所述调用请求从本地查找与所述服务程序对应的第三binder引用并将所述第三binder 引用返回给所述应用程序。所述第一处理模块具体还用于在所述应用程序根据所述第三 binder引用调用所述服务程序时，利用所述第三binder引用将所述服务程序运行获得的 数据结果返回给所述应用程序。
[0030] 结合第五方面、第五方面的第一种或第二种可能的实现方式，在第三种可能的实 现方式中，所述第一智能设备还包括：注册模块，用于获取用户输入或系统检测产生的至少 一个应用程序的程序名称及对应的服务程序的服务名称，并存储所述程序名称和所述服务 名称；注销模块，用于获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序 的程序名称及对应的服务程序的服务名称，查找并删除所述程序名称和所述服务名称，以 动态注消所述至少一个已注册及解耦的应用程序的注册及解耦。其中，所述第一管理模块 具体用于判断所述注册模块中是否已存储有所述服务程序的服务名称，若所述注册模块中 已存储有对应的服务名称则判断为已定义远程调用，若所述注册模块中未存储有对应的服 务名称则判断为未定义远程调用。
[0031] 结合第五方面的第一种或第二种可能的实现方式，在第四种可能的实现方式中， 所述第一智能设备和所述第二智能设备的其中之一为用户终端、另一为云终端，所述第一 处理模块和所述第二处理模块为基于binder机制的binder驱动模块。
[0032] 结合第五方面的第一种或第二种可能的实现方式，在第五种可能的实现方式中， 所述第一管理模块和所述第二管理模块均为AMS模块、或均为SM模块，所述服务程序相应 地为应用进程服务或系统进程服务。
[0033] 本申请在智能设备上设置代理服务模块并对自身的应用程序需要远程调用的服 务程序预先进行定义，使得应用程序在运行并需要调用服务程序时通过代理服务模块从远 端智能设备进行调用。本申请可以将需要进行大量复杂运算等特定的服务程序定义到远端 智能设备运行，因此有效地解决了自身运行服务程序所需要的能耗问题。同时，本申请由 于应用程序在智能设备自身进行运行而服务程序在远端智能设备上运行，无需采用现有的 VNC技术进行智能设备之间的信息交互，因此有效地避免了操作延迟等问题，使得操作、显 示性能更加顺畅。

【专利附图】

【附图说明】
[0034] 图1A是实现本申请服务程序调用方法的服务程序调用系统的其中一实施例结构 示意图；
[0035] 图IB是本申请服务程序调用方法第一实施例的流程示意图；
[0036] 图2是本申请服务程序调用方法第二实施例的流程示意图；
[0037] 图3是本申请智能设备第一实施例的结构示意图；
[0038] 图4是本申请智能设备第二实施例的结构示意图；
[0039] 图5是本申请服务程序调用方法第三实施例的流程示意图；
[0040] 图6是本申请服务程序调用方法第四实施例的流程示意图；
[0041] 图7是本申请智能设备第三实施例的结构示意图；
[0042] 图8是本申请智能设备第四实施例的结构示意图；
[0043] 图9是本申请服务程序调用系统第一实施例的结构示意图；
[0044] 图10是本申请服务程序调用系统第二实施例的结构示意图；以及
[0045] 图11是本申请智能设备一实施例的具体结构示意图。

【具体实施方式】
[0046] 以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、接口、技术之 类的具体细节，以便透切理解本申请。然而，本领域的技术人员应当清楚，在没有这些具体 细节的其它实施方式中也可以实现本申请。在其它情况中，省略对众所周知的装置、电路以 及方法的详细说明，以免不必要的细节妨碍本申请的描述。
[0047] 下面结合附图和具体的实施方式进行说明。
[0048] 请参阅图1A和图1B，图1A是实现本申请服务程序调用方法的服务程序调用系统 的其中一实施例结构示意图，图1B是本申请服务程序调用方法第一实施例的流程示意图。 需要说明的是，图1A中显示了智能设备以及远端智能设备的部分结构，但不应构成对本实 施例服务程序调用方法的限定，在本【技术领域】人员理解的范围内，还可以通过其他结构的 服务程序调用系统实现本实施例，在此不作细述。
[0049] 在本实施例中，如图1B所示，本实施例的服务程序调用方法包括但不限于以下步 骤。
[0050] 步骤S100，接收应用程序调用对应的服务程序的调用请求。与图1A对应的是，步 骤S100可以由第一管理模块执行，其中，第一管理模块从应用程序进程模块接收应用程序 调用对应的服务程序的调用请求。
[0051] 步骤S101，判断服务程序是否已定义为远程调用，若判断到为已定义为远程调用 时，执行步骤S102'，若判断到未定义为远程调用时，执行步骤S102"。与图1A对应的是， 步骤S101可以由第一管理模块执行，也可以由第一处理模块执行，在此不作限定。
[0052] 在步骤S101中，系统可以根据哈希表等表结构或者其他标记的方式判断该应用 程序的调用请求中所描述的服务程序是否已定义为远程调用，譬如具体根据该应用程序的 名称、该服务程序的名称等进行判断，在此不作限定。此外，本实施例需要调用的服务程序 可以为另一应用程序的应用进程服务，也可以为系统进程服务，在此不作限定。
[0053] 需要说明的是，现有技术中，智能设备本地的应用程序一般情况下按照系统给出 的预定运行路径与本地的服务程序绑定耦合，在应用程序需要调用指定的服务程序时，将 按照默认的预定运行路径查找调用已绑定耦合的本地的服务程序并运行该服务程序以得 到数据结果；而本实施例的远程调用可以理解为对应用程序和服务程序之间进行解耦处 理，具体可以理解为断开本地的应用程序与本地的服务程序之间的预定运行路径以取消两 者之间的绑定关系，使得应用程序需要调用指定的服务程序时，不再按照默认的预定运行 路径查找调用本地的服务程序，而需要根据调用请求进行判断处理。
[0054] 步骤S102'，从远端智能设备调用服务程序。与图1A对应的是，步骤S102'可以 由第一代理服务模块执行，其中，第一代理服务模块与远端智能设备的第二代理服务模块 之间可以通过有线或无线等网络进行实时或按需的连接，在此不作限定。进一步而言，远端 智能设备也可以不设置第二代理服务模块，而直接通过服务进程模块提供服务并进行相应 的复杂运算，最终将运算后的数据结果返回给第一服务代理模块即可。
[0055] 步骤S102"，从本地调用服务程序。与图1A对应的是，步骤S102"可以由第一处 理模块执行，第一处理模块可以从本地的服务进程模块（图1A未示)调用服务程序并获得运 算后的数据结果返回给应用程序进程模块，在本【技术领域】人员理解的范围内，不作细述。
[0056] 不难看出，区别于现有技术应用级解耦的方式，本实施例的服务程序调用方法虽 然需要进行网络连接，但与远端智能设备之间仅需要进行参数(譬如函数计算所需的参数） 和数据结果的传输，传输量小而不会由于网络情况导致传输不稳定等问题，因此可以有效 地降低操作延迟的时间。
[0057] 本申请对自身的应用程序需要远程调用的服务程序预先进行定义是否进行远程 调用，使得应用程序在运行并需要调用服务程序时从远端智能设备进行调用相应的服务程 序。本申请可以将需要进行大量复杂运算等特定的服务程序解耦到远端智能设备运行，因 此有效地解决了自身运行服务程序所需要的能耗问题。同时，本申请由于应用程序和服务 程序分开运行，无需采用现有的VNC技术与远端智能设备之间进行信息交互，因此有效地 避免了操作延迟等问题，使得操作、显示性能更加顺畅。
[0058] 请参阅图2，图2是本申请服务程序调用方法第二实施例的流程示意图，本实施例 的服务程序调用方法包括但不限于以下步骤。
[0059] 步骤S200，接收应用程序调用对应的服务程序的调用请求。
[0060] 步骤S201，判断服务程序是否已定义为远程调用。若判断到为已定义为远程调用， 执行步骤S202，若判断未定义为远程调用，则执行步骤S206。
[0061] 在步骤S201中，如前所述，系统可以根据哈希表等表结构或者其他标记的方式判 断该应用程序的调用请求中所描述的服务程序是否已定义为远程调用，譬如具体根据该应 用程序的名称、该服务程序的名称等进行判断，在此不作限定。此外，本实施例需要调用的 服务程序可以为另一应用程序的应用进程服务，也可以为系统进程服务，在此不作限定。
[0062] 具体而言，本实施例可以在步骤S200之前预先进行"对需远程调用服务的应用程 序及对应的服务程序进行动态注册及解耦"的设置过程，以将对应的服务程序定义为远程 调用。
[0063] 其中，"对需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦"的 具体过程包括如下。
[0064] 过程a，获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应的 服务程序的服务名称。在过程a中，用户可以自行判断应用程序及对应的服务程序的运算 量和复杂程度等，如果判断到服务程序的运算量和复杂程度过大，其将导致系统自身的能 耗过大，则用户可以手动输入一个或多个应用程序的程序名称及对应的服务程序的服务名 称；当然，系统自身也可以实时检测所需要运行的应用程序及对应的服务程序的运算量和 复杂程度等，如果系统自身判断到服务程序的运算量和复杂程度过大，其将导致系统自身 的能耗过大，则系统可以通过自动生成或选择等方式产生一个或多个应用程序的程序名称 及对应的服务程序的服务名称。
[0065] 过程b，存储程序名称和服务名称。在过程b中，其中，本实施例可以存储于表结构 等哈希表中，当然，在其他实施例中也可以存储于系统的其他存储结构中，在此不作限定。 结合步骤S201而言，在系统判断调用请求中所描述的服务程序是否已定义为远程调用的 过程中，即可根据服务程序的服务名称从本地的表结构进行检索，如果检索到相同的服务 名称，则从远端智能设备调用，反之则从本地调用。
[0066] 此外，在某些特定的场所或时间段内，譬如可以在线充电或者没有网络可用的情 况下，用户也可以对已进行动态注册及解耦的应用程序及其服务程序进行注销，其具体过 程包括如下。
[0067] 过程c，获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程 序名称及对应的服务程序的服务名称。
[0068] 过程d，查找并删除程序名称和服务名称，以动态注消至少一个已注册及解耦的应 用程序的注册及解耦。
[0069] 值得注意的是，过程a_过程d的过程中，用户可以实时地、智能地循环执行以进行 注册或者注销，使得智能设备可以根据系统的自身状况或者所处环境进行智能操作，更加 多样化和智能化。
[0070] 步骤S202,根据调用请求产生第一 binder引用并将第一 binder引用返回给应用 程序。
[0071] 在步骤S202中，需要指出的是，本实施例针对基于binder机制(进程间通信机制） 的智能设备实现具体的服务程序调用方法。其中，第一 binder引用为应用程序需要进行调 用服务程序时，需要与服务程序的binder实体之间通信所需要的binder引用，其具体工作 过程在本【技术领域】人员理解的范围内，不作细述。
[0072] 现有技术中，基于Android的智能设备为了降低系统自身的能耗，还专门采用到 组件级解耦的方式来实现服务调用。具体而言，现有技术将应用程序的activity组件、 service 组件、content provider 组件和 broadcast receiver 组件中的 service 组件和 其它三个组件之间进行解耦，将其运行在远端智能设备，而其它部分运行在本地。然而在 解耦的过程中需要将service组件变成桩模块和服务模块，并分别部署在智能设备和远端 智能设备。在智能设备的应用程序需要调用服务程序时，需要通过本地的桩模块调用远端 智能设备的服务模块，并返回结果。进一步而言，为了将上述解耦及调用的过程自动化， 需要将开发者编写的代码重新编译，其需要通过应用程序中的AIDL (Android Interface definition language,安卓接口定义语言）文件，将Service组件划分为桩模块和服务模 ±夹，并利用AIDL文件包含的描述Service接口的信息，对程序源代码一起进行编译，自动生 成通过Binder机制调用Service的代码框架等。然而，这种解耦方式依赖于应用程序的源 代码，必须在源代码基础上进行重新编译，而当前很多应用程序并不是开源程序，所以不能 适用，同时，这种解耦方式依赖于应用程序对AIDL的使用，而很多应用程序绕过了 AIDL直 接使用Android框架所提供的Binder机制，而导致这种解耦方式无法用于这些特殊的应用 程序。
[0073] 不难看出，本实施例在基于Android的智能设备上,只需直接利用现有的binder 机制，在智能设备自身和远端智能设备进行过程a-过程d的动态注册解耦及注销等，即可 在现有的binder机制上实现现有应用程序从远端智能设备调用服务的过程，从而更加实 用性。
[0074] 步骤S203，将服务程序的识别信息发送至远端智能设备，以使远端智能设备产生 与服务程序对应的第二 binder引用，并存储第二 binder引用与服务程序的对应关系。
[0075] 在步骤S203中，在调用服务程序之前，需预先在远端智能设备存储第二 binder引 用与服务程序的对应关系，以备后续调用。
[0076] 步骤S204，在应用程序根据第一 binder引用调用服务程序时，将应用程序的调用 信息发送至远端智能设备，以使远端智能设备根据调用信息查找第二 binder引用，根据第 二 binder引用调用服务程序，并返回服务程序运行获得的数据结果。
[0077] 在步骤S204中，智能设备将应用程序的调用信息譬如运算参数和服务名称等发 送至远端智能设备。远端智能设备的binder驱动模块可以驱动管理远端智能设备的服 务程序对应的binder实体接收第二 binder引用传输过来的运算参数等,使得服务程序 根据运算参数运行函数以获得数据结果，接着远端智能设备的binder驱动模块利用第二 binder引用将数据结果返回给智能设备。
[0078] 步骤S205，利用第一 binder引用将数据结果返回给应用程序，步骤S205之后，结 束或等待再次调用时返回步骤S200。
[0079] 步骤S206，从本地调用服务程序。
[0080] 在步骤S206中，具体可以利用binder机制进行调用，本实施例在本地调用服务程 序的过程包括以下。
[0081] 过程e，根据调用请求从本地查找与服务程序对应的第三binder引用并将第三 binder引用返回给应用程序。
[0082] 过程f,在应用程序根据第三binder引用调用服务程序时，利用第三binder引用 将服务程序运行获得的数据结果返回给应用程序。
[0083] 其中，基于binder机制在本地调用服务程序的具体实现过程e和过程f在本技术 领域人员理解的范围内，不作细述。
[0084] 此外，现有技术的基于Android的智能设备上，还采用到方法级解耦来调用服务 的方式，然而通过方法级解耦的方式需要在应用程序的开发阶段，获得允许远程调用的服 务程序(如函数方法等）的集合，其需要由程序员手动标注允许远程调用的服务程序，或通 过静态分析找出服务程序中合法的可分割点（必须是某个应用程序的入口或者出口），再通 过动态方法决定计算成本模型得出合适的迁移点。其次，在服务程序运行时，根据当前运行 环境的不同参数，动态决定服务程序的运行位置。不难看出，这种方法级解耦的缺点在于需 要对程序的代码或者二进制码进行修改，所以不适用于不开源的应用程序，且应用程序均 会一般通过签名的方式进行完整性保护，对二进制码进行修改会导致签名验证失败，从而 影响应用程序的正常运行。不难看出，本实施例针对基于Android的智能设备而言，应用程 序与服务程序之间的解耦方式更加透明，可以将目前市场上已有的应用程序直接运行在现 有的Android的智能设备上，而不需要对其进行任何改动或者重新编译，这样提高了本实 施例服务程序调用方法的通用性和兼容性。
[0085] 总而言之,本申请专门针对基于Android的智能设备及其基于binder机制的服务 调用进行解耦，只需对应用程序需要远程调用的服务程序预先进行注册，使得应用程序在 运行并需要调用服务程序时通过现有的binder机制从远端智能设备进行调用。本申请可 以将需要进行大量复杂运算等特定的服务程序解耦到远端智能设备运行，因此有效地解决 了自身运行服务程序所需要的能耗问题。同时，本申请服务程序调用方法可以兼容使用到 现有的应用程序中，无需进行修改编译等，兼容性能更好而更具实用性。
[0086] 请结合前面实施例参阅图3，是本申请智能设备第一实施例的结构示意图，本实施 例智能设备包括但不限于代理服务模块30、管理模块31和处理模块32。
[0087] 代理服务模块30可以与远端智能设备之间进行有线或无线网络的实时或按需连 接，以用于从远端智能设备调用服务程序或进行数据信息传输等，在本【技术领域】人员理解 的范围内，不作限定。
[0088] 管理模块31用于接收应用程序进程模块中应用程序的调用请求并判断服务程序 是否已定义为远程调用。管理模块31可以根据哈希表等表结构或者其他标记的方式判断 该应用程序的调用请求中所描述的服务程序是否已定义为远程调用，譬如具体根据应用程 序的名称、服务程序的名称等进行判断，在此不作限定。此外，本实施例需要调用的服务程 序可以为另一应用程序的应用进程服务，也可以为系统进程服务，在此不作限定。
[0089] 处理模块32用于在管理模块31判断到服务程序已定义为远程调用时，通过代理 服务模块30从远端智能设备调用服务程序，而在管理模块31判断到服务程序未定义为远 程调用时，则从本地调用服务程序。
[0090] 不难看出，本实施例智能设备与远端智能设备之间仅需要进行参数(譬如函数计 算所需的参数）和数据结果的传输，传输量小而不会由于网络情况导致传输不稳定等问题， 因此可以有效地降低操作延迟的时间。
[0091] 本申请智能设备对自身的应用程序需要远程调用的服务程序预先进行定义，使得 应用程序在运行并需要调用服务程序时从远端智能设备进行调用。本申请智能设备可以将 需要进行大量复杂运算等特定的服务程序解耦到远端智能设备运行，因此有效地解决了自 身运行服务程序所需要的能耗问题。同时，本申请由于应用程序和服务程序分开运行，无需 采用现有的VNC技术与远端智能设备之间进行信息交互，因此有效地避免了操作延迟等问 题，使得操作、显示性能更加顺畅。
[0092] 请结合图2所述实施例参阅图4，图4是本申请智能设备第二实施例的结构示意 图，本实施例智能设备包括但不限于代理服务模块40、管理模块41、处理模块42、注册模块 43和注销模块44。
[0093] 如前所述，管理模块41用于接收应用程序调用对应的服务程序的调用请求并判 断服务程序是否已定义为远程调用；处理模块42用于在管理模块41判断到服务程序已定 义为远程调用时，通过代理服务模块40从远端智能设备调用服务程序，在管理模块41判断 到服务程序未定义为远程调用时，则从本地调用服务程序。
[0094] 在本实施例中，注册模块43用于对需远程调用服务的应用程序及对应的服务程 序进行动态注册及解耦，以将对应的服务程序定义为远程调用。而注册模块43具体可以包 括第一获取单元431和第一管理单元432。
[0095] 第一获取单元431用于获取用户输入或系统检测产生的至少一个应用程序的程 序名称及对应的服务程序的服务名称。用户可以自行判断应用程序及对应的服务程序的运 算量和复杂程度等，如果判断到服务程序的运算量和复杂程度过大，其将导致智能设备自 身的能耗过大，则用户可以手动输入一个或多个应用程序的程序名称及对应的服务程序的 服务名称。当然，管理模块41也可以实时检测所需要运行的应用程序及对应的服务程序的 运算量和复杂程度等，如果管理模块41判断到服务程序的运算量和复杂程度过大，其将导 致系统自身的能耗过大，则系统可以通过自动生成或选择等方式产生一个或多个应用程序 的程序名称及对应的服务程序的服务名称。
[0096] 第一管理单元432用于存储第一获取单元431获取到的程序名称和服务名称，其 中，第一管理单元432可以为本地的表结构等。相应地，在管理模块41判断调用请求中所描 述的服务程序是否已定义为远程调用的过程中，即可根据服务程序的服务名称从本地的表 结构进行检索，如果检索到相同的服务名称，则从远端智能设备调用，反之则从本地调用。 具体来说，管理模块41具体用于判断第一管理单元432中是否已存储有调用请求中所描述 的服务程序的服务名称，若第一管理单元432中已存储有对应的服务名称则判断为已定义 远程调用，若第一管理单元432中未存储有对应的服务名称则判断为未定义远程调用。
[0097] 注销模块44用于动态注消至少一个已注册及解耦的应用程序的注册及解耦，其 具体可以包括第二获取单元441和第二管理单元442。
[0098] 第二获取单元441用于获取用户输入或系统检测产生的至少一个已注册及解耦 的应用程序的程序名称及对应的服务程序的服务名称。
[0099] 第二管理单元442，用于查找并删除第二获取单元441获取到的程序名称和服务 名称，以动态注消至少一个已注册及解耦的应用程序的注册及解耦。其中，第二管理单元 442可以在本地的表结构或其他存储单元中进行查找，在此不作细述。
[0100] 本实施例通过注销模块44的作用，可以在某些特定的场所或时间段内，譬如在线 充电或者没有网络可用的情况下，用户也可以对已进行动态注册及解耦的应用程序及其服 务程序进行注销。
[0101] 结合注册模块43和注销模块44的作用，用户可以实时地、智能地循环执行以进行 注册或者注销，使得智能设备可以根据系统的自身状况或者所处环境进行智能操作，更加 多样化和智能化。
[0102] 值得注意的是,本实施例针对基于binder机制的智能设备作了进一步改进,具体 来说，本实施例管理模块41具体用于根据应用程序进程模块中应用程序的调用请求产生 与代理服务模块40相对应的第一 binder引用并将第一 binder引用返回给应用程序。具 体来说，当应用程序进程模块中应用程序需要调用服务程序时，管理模块41将代理服务模 块40作为"等效服务程序"并将"等效服务程序"对应的第一 binder引用返回给应用程序， 而使得在应用程序端默认其调用的即是服务程序。换而言之，代理服务模块40需要向管理 模块41申请注册为"等效服务程序"，在管理模块41确认注册后产生第一 binder引用并存 储第一 binder引用与代理服务模块40的对应关系到表结构中。
[0103] 而代理服务模块40则可以通过binder机制中的binder实体来接收应用程序通 过第一 binder引用发送过来运算参数和服务名称等，在本【技术领域】人员理解的范围内，不 作细述。
[0104] 代理服务模块40具体用于将服务程序的识别信息发送至远端智能设备，以使远 端智能设备产生与服务程序对应的第二 binder引用，并存储第二 binder引用与服务程序 的对应关系。值得注意的是，在远端智能设备上，需要另一代理服务模块作为智能设备自身 的应用程序在远端智能设备的"等效应用程序"，也即是说在远端智能设备上可以视作"等 效应用程序"通过第二 binder引用调用远端智能设备自身的服务程序。
[0105] 代理服务模块40具体还用于在应用程序根据第一 binder引用调用服务程序时， 将应用程序的调用信息发送至远端智能设备，以使远端智能设备根据调用信息查找第二 binder引用，根据第二 binder引用调用服务程序，并返回服务程序运行获得的数据结果。
[0106] 处理模块42具体用于利用第一 binder引用将代理服务模块40从远端智能设备 接收的数据结果返回给应用程序。
[0107] 不难看出，本实施例通过代理服务模块40及另一代理服务模块分别实现"等效服 务程序"和"等效应用程序"的作用，有效地避免了现有技术在智能设备需要调用远端智能 设备的服务程序时、需要修改编译源代码或分析查找服务程序的分割点进行重新编译的无 法实现和兼容性低的技术问题，本申请在智能设备和远端智能设备都按照现有的binder 机制进行等效调用，可以有效地提高兼容性能。
[0108] 另一方面，管理模块41具体用于在管理模块41判断到服务程序未定义为远程调 用时，根据调用请求从本地(如本地服务进程模块）查找与服务程序对应的第三binder引 用并将第三binder引用返回给应用程序。处理模块42具体还用于在应用程序根据第三 binder引用调用服务程序时，利用第三binder引用将服务程序运行获得的数据结果返回 给应用程序。
[0109] 在本实施例中，不难理解的是，处理模块42可以为基于binder机制的binder驱 动模块，其具体通过binder驱动模块实现应用程序进程模块和代理服务模块40之间的第 一 binder引用和binder实体之间的管理通信过程,在本【技术领域】人员理解的范围内，不作 赘述。
[0110] 值得注意的是，本实施例的智能设备可以为用户终端(手机或掌上电脑）而远端智 能设备则对应地可以为云终端，因此可以将运算复杂且运算量大的服务程序运行在云终端 上，以降低用户终端的能耗。
[0111] 当然，智能设备也可以为云终端而远端智能设备则对应为用户终端，举例而言，如 用户不希望将sensor (传感器）服务、通信录服务和GPS (全球定位系统）服务等服务程序 运行在云终端上。此时，本实施例可以在云终端上通过注册模块43注册sensor服务、通信 录服务和GPS服务为远程调用的方式，使得云终端需要这些指定的服务程序时，在用户终 端自身执行sensor服务、通信录服务和GPS服务后将数据结果返回给云终端即可，通过这 种方式，可以有效地保护用户的个人信息和隐私，提高了安全性能。
[0112] 此外，需要说明的是，服务程序具体可以包括应用进程服务和系统进程服务，即相 对于android的智能设备来说，管理模块41具体可以为基于binder机制的AMS(Activity Manager Service,活动管理服务)模块或SM (Service Manager,服务管理器)模块,在本技 术领域人员理解的范围内，不作限定。
[0113] 此外，本实施例的工作过程在图4及相关描述的基础上，其具体实现的工作过程 在本【技术领域】人员容易结合理解的范围内，在此不作细述。
[0114] 本申请专门针对基于Android的智能设备及其基于binder机制的服务调用进行 解耦，只需对应用程序需要远程调用的服务程序预先进行注册，使得应用程序在运行并需 要调用服务程序时通过现有的binder机制从远端智能设备进行调用。本申请可以将需要 进行大量复杂运算等特定的服务程序解耦到远端智能设备运行，因此有效地解决了自身运 行服务程序所需要的能耗问题。同时，本申请服务程序调用方法可以兼容使用到现有的应 用程序中，无需进行修改编译等，兼容性能更好而更具实用性。此外，本申请还在一定程度 上针对特殊的服务程序提供了更加安全的工作模式，保护了用户的个人信息和隐私。
[0115] 请结合图1A参阅图5，是本申请服务程序调用方法第三实施例的流程示意图，本 实施例服务程序调用方法的执行主体可以为图1A所示的第二管理模块、第二处理模块和 第二代理服务模块，具体而言，本实施例的服务程序调用方法包括但不限于以下步骤。
[0116] 步骤S500，接收远端智能设备发送的需远程调用的服务程序的识别信息，并根据 服务程序的识别信息在本地确定对应的服务程序，其中，服务程序在远端智能设备已定义 为远程调用，远端智能设备根据应用程序调用对应的服务程序所发出的调用请求产生服务 程序的识别信息。
[0117] 步骤S501，在接收到远端智能设备发送的针对服务程序的调用信息时，根据调用 信息调用对应的服务程序，并将服务程序运行获得的数据结果返回给远端智能设备的应用 程序。
[0118] 本实施例服务程序调用方法通过将远端智能设备的服务程序解耦运行在本身的 系统内，可以有效地降低远端智能设备的能耗。
[0119] 请参阅图6，是本申请服务程序调用方法第四实施例的流程示意图，本实施例服务 程序调用方法具体包括以下步骤。
[0120] 步骤S600，接收远端智能设备发送的需远程调用的服务程序的识别信息，其中，月艮 务程序在远端智能设备已定义为远程调用，远端智能设备根据应用程序调用对应的服务程 序所发出的调用请求产生服务程序的识别信息。
[0121] 步骤S601，根据服务程序的识别信息产生与服务程序对应的第一 binder引用，并 存储第一 binder引用与服务程序的对应关系。
[0122] 值得注意的是,在步骤S601中，本实施例针对基于binder机制的远端智能设备作 了进一步改进，具体来说，本实施例在远端智能设备需要调用服务程序前，为了避免现有技 术需要对源代码等进行重新编译的技术问题，而采用binder进制在系统自身进行服务程 序调用。
[0123] 步骤S602，在接收到远端智能设备发送的针对服务程序的调用信息时，根据调用 信息查找第一 binder引用，并根据第一 binder引用调用服务程序。
[0124] 步骤S603，将利用第一 binder引用返回的服务程序运行获得的数据结果发送给 远端智能设备，以使远端智能设备利用第二 binder引用将数据结果返回给应用程序，其 中，远端智能设备根据调用请求产生第二 binder引用。
[0125] 本实施例服务程序调用方法在智能设备自身和远端智能设备均通过各自的 binder机制进行服务程序调用，无需修改及编译应用程序的源代码等，从而适用于现有技 术的应用程序，兼容性更好。
[0126] 请参阅图7，是本申请智能设备第三实施例的结构示意图，本实施例智能设备包括 但不限于代理服务模块70、管理模块71和处理模块72。
[0127] 代理服务模块70用于接收远端智能设备发送的需远程调用的服务程序的识别信 息。其中，服务程序在远端智能设备已定义为远程调用，远端智能设备根据应用程序调用对 应的服务程序所发出的调用请求产生服务程序的识别信息。
[0128] 管理模块71用于根据代理服务模块70接收到的服务程序的识别信息在本地确定 对应的服务程序。
[0129] 处理模块72用于在代理服务模块70接收到远端智能设备发送的针对服务程序的 调用信息时，根据调用信息调用对应的服务程序，并通过代理服务模块70将服务程序运行 获得的数据结果返回给远端智能设备的应用程序。
[0130] 本实施例的智能设备可以作为图3所示的"远端智能设备"，其具体实现过程请参 阅相关实施例的描述，在此不再赘述。
[0131] 请参阅图8，是本申请智能设备第四实施例的结构示意图，本实施例智能设备包括 但不限于代理服务模块80、管理模块81、处理模块82。
[0132] 如前所述，代理服务模块80用于接收远端智能设备发送的需远程调用的服务程 序的识别信息。管理模块81用于根据代理服务模块80接收到的服务程序的识别信息在本 地确定对应的服务程序。处理模块82用于在代理服务模块80接收到远端智能设备发送的 针对服务程序的调用信息时，根据调用信息调用对应的服务程序，并将服务程序运行获得 的数据结果返回给远端智能设备的应用程序。
[0133] 需要说明的是，本实施例针对现有技术基于Android的智能设备在调用服务程序 时，需要对应用程序或服务程序进行编译修改的技术问题，本实施例在智能设备自身和远 端智能设备均通过各自的binder机制进行服务程序调用。
[0134] 具体而言，管理模块81具体用于根据服务程序的识别信息产生与服务程序对应 的第一 binder引用，并存储第一 binder引用与服务程序的对应关系。
[0135] 处理模块82具体用于在代理服务模块80接收到远端智能设备发送的针对服务程 序的调用信息时，根据调用信息查找第一 binder引用，并根据第一 binder引用调用服务程 序。
[0136] 代理服务模块80具体用于将处理模块82利用第一 binder引用返回的服务程序 运行获得的数据结果发送给远端智能设备，以使远端智能设备利用第二 binder引用将数 据结果返回给应用程序，其中，远端智能设备根据调用请求产生第二 binder引用。
[0137] 值得注意的是，为了实现代理服务模块80从服务进程模块中调用服务程序而需 要修改编译等，本实施例需要通过管理模块81对代理服务模块80进行处理，使代理服务模 块80作为智能设备自身所运行的"等效应用程序"来调用服务进程模块中的服务程序。具 体而言，处理模块82可以为基于binder机制的binder驱动模块，而代理服务模块80和服 务进程模块之间通过相应的第一 binder引用（即Binder引用）与Binder实体之间进行服 务程序调用及数据传输，在本【技术领域】人员理解的范围内，不作细述。
[0138] 此外，本实施例的智能设备可以为用户终端，而远端智能设备可以为云终端，此 时，本实施例可以在用户终端上执行sensor服务、通信录服务和GPS服务等服务后将数据 结果返回给云终端，通过这种方式，可以有效地保护用户的个人信息和隐私，提高了安全性 能。当然，本实施例的智能设备可以为云终端而远端智能设备则对应地可以为用户终端，本 实施例可以将运算复杂且运算量大的服务程序运行在云终端上，以降低用户终端的能耗。
[0139] 需要说明的是，服务程序可以为应用进程服务或系统进程服务，相应地，管理模块 81为基于binder机制的AMS模块或SM模块，在此不作限定。
[0140] 请参阅图9，是本申请服务程序调用系统第一实施例的结构示意图，本实施例服务 程序调用系统包括但不限于第一智能设备和第二智能设备。
[0141] 具体而言，第一智能设备包括第一代理服务模块90、第一管理模块91和第一处理 模块92。
[0142] 第一代理服务模块90可以用于从第二智能设备调用服务程序或进行数据信息传 输等。
[0143] 第一管理模块91用于接收应用程序进程模块中应用程序的调用请求并判断服务 程序是否已定义为远程调用。
[0144] 第一处理模块92用于在第一管理模块91判断到服务程序已定义为远程调用时， 根据调用请求产生服务程序的识别信息并通过第一代理服务模块90发送给第二智能设 备，以通过第一代理服务模块90从第二智能设备调用服务程序，在第一管理模块91判断到 服务程序未定义为远程调用时，则从本地调用服务程序。
[0145] 相应地，第二智能设备包括第二代理服务模块10、第二管理模块11和第二处理模 块12。
[0146] 第二代理服务模块10用于接收第一代理服务模块90发送服务程序的识别信息。
[0147] 第二管理模块11用于根据第二代理服务模块10接收到的服务程序的识别信息在 本地确定对应的服务程序。
[0148] 第二处理模块12用于在第二代理服务模块10接收到第一代理服务模块90发送 的针对服务程序的调用信息时，根据调用信息调用对应的服务程序，并将服务程序运行获 得的数据结果通过第二代理服务模块10发送给第一代理服务模块90以返回给应用程序。
[0149] 请结合图9参阅图10，图10是本申请服务程序调用系统第二实施例的结构示意 图，本实施例中的第一智能设备和第二智能设备为基于Android的终端设备，且其对应采 用binder机制进行服务程序的调用。
[0150] 为了在binder机制的Android终端上实现本申请，本实施例的服务程序调用系统 的具体过程包括以下。
[0151] 在第一管理模块91判断到服务程序已定义为远程调用时。
[0152] 第一管理模块91具体用于根据调用请求产生与第一代理服务模块90相对应的第 一 binder引用并将第一 binder引用返回给应用程序。
[0153] 第一代理服务模块90具体用于将服务程序的识别信息发送至第二代理服务模块 10 ;接着，第二管理模块11具体用于根据识别信息产生与服务程序对应的第二 binder引 用，并存储第二 binder引用与服务程序的对应关系。
[0154] 第一代理服务模块90具体还用于在应用程序根据第一 binder引用调用服务程 序时，将针对应用程序的调用信息发送至第二代理服务模块10。其中，应用程序需要通过 第一 binder引用调用服务程序时，将进入第一代理服务模块90的处理函数（On Transact 函数）中，接着第一代理服务模块90将调用信息通过有线或无线网络原封不动地发送给第 二代理服务模块10。之后，第二处理模块12具体用于根据服务程序的调用信息查找第二 binder引用，并根据第二 binder引用调用服务程序。
[0155] 第二代理服务模块10具体用于将第二处理模块12利用第二 binder引用返回的 服务程序运行获得的数据结果发送给第一处理模块92。相应地，第一处理模块92具体用于 利用第一 binder引用将第一代理服务模块90接收的数据结果返回给应用程序。
[0156] 在上述过程中，不难看出，第一代理服务模块90在第一智能设备端相当于"等效 服务程序"，即应用程序进程模块中应用程序视第一代理服务模块90为其需要调用的服务 程序，使得应用程序进程模块与第一代理服务模块90之间直接通过binder机制进行调用。 同理，第二代理服务模块10在第二智能设备内则相当于"等效应用程序"，即第二智能设备 的服务进程模块视第二代理服务模块10为调用服务程序的应用程序进程模块中的应用程 序，使得第二代理服务模块10与第二智能设备的服务进程模块之间直接通过binder机制 进行调用。进一步而言，通过这种方式，本申请不再依赖于应用程序的源代码，无需在源代 码基础上进行重新编译，也无需依赖于应用程序对AIDL架构的使用；本申请也不需修改服 务程序的代码，无需去解决应用程序通过签名进行完整性保护的技术问题，因此本申请更 具实用性和普及性。
[0157] 此外，在第一管理模块91判断到服务程序未定义为远程调用时。
[0158] 第一管理模块91具体还用于在第一管理模块91判断到服务程序未定义为远程调 用时，并根据调用请求从本地查找与服务程序对应的第三binder引用并将第三binder引 用返回给应用程序。
[0159] 第一处理模块92具体还用于在应用程序根据第三binder引用调用服务程序时， 利用第三binder引用将服务程序运行获得的数据结果返回给应用程序。不难看出，服务程 序运行于本地的服务进程模块（图未示)中，而第一管理模块91、第一处理模块92和第一智 能设备内部的服务进程模块之间通过现有的binder机制及其Binder引用和binder实体 进行通信，在本【技术领域】人员理解的范围内，不作细述。
[0160] 如图10所示，第一智能设备还包括注册模块93和注销模块94。注册模块93用于 对需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦，以将对应的应用程 序定义为远程调用。注销模块94用于获取用户输入或系统检测产生的至少一个已注册及 解耦的应用程序的程序名称及对应的服务程序的服务名称，查找并删除程序名称和服务名 称，以动态注消至少一个已注册及解耦的应用程序的注册及解耦。其中，第一管理模块91 具体用于判断注册模块93中是否已存储有服务程序的服务名称，若注册模块93中已存储 有对应的服务名称则判断为已定义远程调用，若注册模块93中未存储有对应的服务名称 则判断为未定义远程调用。
[0161] 具体而言，注册模块93具体包括第一获取单元931和第一管理单元932。第一获 取单元931用于获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应的 服务程序的服务名称；第一管理单元932用于存储第一获取单元931获取到的程序名称和 服务名称。对应地，第一管理模块91在判断调用请求中所描述的服务程序是否已注册为远 程调用时，即根据该服务程序的服务名称在本地的表结构等存储单元中进行查询，其具体 实现过程在本【技术领域】人员理解的范围内，不作细述。
[0162] 类似地，注销模块94包括第二获取单元941和第二管理单元942。第二获取单元 941用于获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程序名称及 对应的服务程序的服务名称；第二管理单元942用于查找并删除第二获取单元941获取到 的程序名称和服务名称，以动态注消至少一个已注册及解耦的应用程序的注册及解耦。
[0163] 需要说明的是，第一获取单元931和第二获取单元941均可以为第一智能设备的 人机操作界面的输入窗口等，在本【技术领域】人员理解的范围内，不作赘述。
[0164] 在本实施例中，第一智能设备和第二智能设备的其中之一为用户终端、另一为云 终端。当然，第一智能设备和第二智能设备均可以为手机等用户终端，譬如为近场通信技术 连接的两台手机等，在此不作细述。
[0165] 应理解地，第一处理模块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 System Service)进程，第二代理服务模块10为本地应用程序进程在云终端的代理 RPSS(Remote Proxy System Service)进程。当然，其具体实现的方式在本【技术领域】人员理 解的范围内，不作赘述。
[0166] 结合前面一个或多个实施例不难看出，本申请通过设置第一代理服务模块90和 第二代理服务模块10的方式，可以实现remote binder (跨网络进程间通信）机制进行远 程调用服务。
[0167] 请参阅图11，是是本申请智能设备一实施例的具体结构示意图，本实施例智能设 备包括但不限于包括处理器21、接收器22、发送器23、随机存取存储器24、只读存储器25、 总线26以及网络接口单元27。其中，处理器21通过总线26分别耦接接收器22、发送器 23、随机存取存储器24、只读存储器25以及网络接口单元27。
[0168] 在其中一个具体实施例中，处理器21用于接收应用程序调用对应的服务程序的 调用请求并判断调用请求中所描述的服务程序是否已定义为远程调用；处理器21在判断 到服务程序已定义为远程调用时，根据调用请求产生服务程序的识别信息并通过发送器23 或网络接口单元27发送给远端智能设备。举例而言，在处理器21判断到服务程序已定义 为远程调用时，根据调用请求产生相对应的第一 binder引用并将第一 binder引用返回给 应用程序；接着，处理器21通过发送器23将服务程序的识别信息发送至远端智能设备；而 在应用程序根据第一 binder引用调用服务程序时，处理器21将针对应用程序的调用信息 发送至远端智能设备；最终，处理器21利用第一 binder引用将接收器22接收的数据结果 返回给应用程序。
[0169] 在另一个具体实施例中，处理器21用于接收远端智能设备通过网络发送给接收 器22或网络接口单元27的服务程序的识别信息；处理器21根据识别信息在本地确定对 应的服务程序；接着在通过接收器22等接收到远端智能设备发送的针对服务程序的调用 信息时，处理器21根据调用信息调用对应的服务程序，并将服务程序运行获得的数据结果 通过发送器23发送给远端智能设备以返回给应用程序。举例而言，处理器21具体用于根 据识别信息产生与服务程序对应的第二 binder引用，并存储第二 binder引用与服务程序 的对应关系；接着，处理器21根据服务程序的调用信息查找第二 binder引用，并根据第二 binder引用调用服务程序；发送器23具体用于将处理器21利用第二 binder引用返回的 服务程序运行获得的数据结果发送给远端智能设备。
[0170] 本申请不再依赖于应用程序的源代码，无需在源代码基础上进行重新编译，也无 需依赖于应用程序对AIDL架构的使用；本申请也不需修改服务程序的代码，无需去解决应 用程序通过签名进行完整性保护的技术问题，因此本申请更具实用性和普及性。
[0171] 本实施方式中，处理器31可能是一个中央处理器CPU，或者是特定集成电路ASIC (Application Specific Integrated Circuit),或者是被配置成实施本申请实施方式的一 个或多个集成电路。
[0172] 在本申请所提供的几个实施方式中，应该理解到，所揭露的系统，装置和方法，可 以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，所述模 块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个 单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一 点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或 单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。
[0173] 所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显 示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个 网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的 目的。
[0174] 另外，在本申请各个实施方式中的各功能单元可以集成在一个处理单元中，也可 以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的 单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0175] 所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用 时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上 或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式 体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机 设备(可以是个人计算机，管理服务器，或者网络设备等)或处理器（processor)执行本申请 各个实施方式所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读 存储器（ROM, Read-Only Memory)、随机存取存储器（RAM, Random Access Memory)、磁碟或 者光盘等各种可以存储程序代码的介质。
[0176] 以上所述仅为本申请的实施方式，并非因此限制本申请的保护范围，凡是利用本 申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的 【技术领域】，均同理包括在本申请的专利保护范围内。
【权利要求】
1. 一种服务程序调用方法，其特征在于，所述服务程序调用方法包括： 接收应用程序调用对应的服务程序的调用请求； 判断所述服务程序是否已定义为远程调用； 若已定义为远程调用，则从远端智能设备调用所述服务程序； 若未定义为远程调用，则从本地调用所述服务程序。
2.根据权利要求1所述的服务程序调用方法，其特征在于，所述从远端智能设备调用 所述服务程序的步骤包括： 根据所述调用请求产生第一 binder引用并将所述第一 binder引用返回给所述应用程 序; 将所述服务程序的识别信息发送至远端智能设备，以使远端智能设备产生与所述服务 程序对应的第二 binder引用，并存储所述第二 binder引用与所述服务程序的对应关系； 在所述应用程序根据所述第一 binder引用调用所述服务程序时，将所述应用程序的 调用信息发送至所述远端智能设备，以使所述远端智能设备根据所述调用信息查找所述第 二 binder引用，根据所述第二 binder引用调用所述服务程序，并返回所述服务程序运行获 得的数据结果； 利用所述第一 binder引用将所述数据结果返回给所述应用程序。
3.根据权利要求2所述的服务程序调用方法，其特征在于，所述从本地调用所述服务 程序的步骤包括： 根据所述调用请求从本地查找与所述服务程序对应的第三binder引用并将所述第三 binder引用返回给所述应用程序； 在所述应用程序根据所述第三binder引用调用所述服务程序时，利用所述第三 binder引用将所述服务程序运行获得的数据结果返回给所述应用程序。
4.根据权利要求1-3任一项所述的服务程序调用方法，其特征在于，所述接收应用程 序调用对应的服务程序的调用请求的步骤之前还包括： 对需远程调用服务的应用程序及对应的服务程序进行动态注册及解耦，以定义为远程 调用。
5.根据权利要求4所述的服务程序调用方法，其特征在于： 所述对需远程调用服务的应用程序及对应的服务程序进行注册及解耦的步骤包括： 获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应的服务程序的 服务名称； 存储所述程序名称和所述服务名称； 所述判断所述服务程序是否已定义为远程调用的步骤包括： 判断是否已存储有所述服务程序的服务名称，若已存储有对应的服务名称则判断为已 定义远程调用，若未存储有对应的服务名称则判断为未定义远程调用。
6.根据权利要求4所述的服务程序调用方法，其特征在于，所述接收应用程序调用对 应的服务程序的调用请求的步骤之前还包括： 获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的程序名称及对 应的服务程序的服务名称； 查找并删除所述程序名称和所述服务名称，以动态注消所述至少一个已注册及解耦的 应用程序的注册及解耦。
7.根据权利要求1-3任一项所述的服务程序调用方法，其特征在于，所述服务程序包 括应用进程服务和系统进程服务。
8. 一种智能设备，其特征在于，所述智能设备包括： 代理服务模块，用于从远端智能设备调用服务程序； 管理模块，用于接收应用程序调用对应的服务程序的调用请求并判断所述服务程序是 否已定义为远程调用； 处理模块，用于在所述管理模块判断到所述服务程序已定义为远程调用时，通过所述 代理服务模块从远端智能设备调用所述服务程序，在所述管理模块判断到所述服务程序未 定义为远程调用时，则从本地调用所述服务程序。
9.根据权利要求8所述的智能设备，其特征在于： 所述管理模块具体用于根据所述调用请求产生与所述代理服务模块相对应的第一 binder引用并将所述第一 binder引用返回给所述应用程序； 所述代理服务模块具体用于将所述服务程序的识别信息发送至远端智能设备，以使远 端智能设备产生与所述服务程序对应的第二 binder引用，并存储所述第二 binder引用与 所述服务程序的对应关系； 所述代理服务模块具体还用于在所述应用程序根据所述第一 binder引用调用所述服 务程序时，将所述应用程序的调用信息发送至所述远端智能设备，以使所述远端智能设备 根据所述调用信息查找所述第二 binder引用，根据所述第二 binder引用调用所述服务程 序，并返回所述服务程序运行获得的数据结果； 所述处理模块具体用于利用所述第一 binder引用将所述代理服务模块从所述远端智 能设备接收的所述数据结果返回给所述应用程序。
10.根据权利要求9所述的智能设备，其特征在于： 所述管理模块具体用于在所述管理模块判断到所述服务程序未定义为远程调用时，根 据所述调用请求从本地查找与所述服务程序对应的第三binder引用并将所述第三binder 引用返回给所述应用程序； 所述处理模块具体还用于在所述应用程序根据所述第三binder引用调用所述服务程 序时，利用所述第三binder引用将所述服务程序运行获得的数据结果返回给所述应用程 序。
11.根据权利要求8-10任一项所述的智能设备，其特征在于，所述智能设备还包括： 注册模块，用于对需远程调用服务的应用程序及对应的服务程序进行动态注册及解 耦，以定义为远程调用。
12.根据权利要求11所述的智能设备，其特征在于，所述注册模块具体包括： 第一获取单元，用于获取用户输入或系统检测产生的至少一个应用程序的程序名称及 对应的服务程序的服务名称； 第一管理单元，用于存储所述第一获取单元获取到的所述程序名称和所述服务名称； 其中，所述管理模块具体用于判断所述第一管理单元中是否已存储有所述服务程序的 服务名称，若所述第一管理单元中已存储有对应的服务名称则判断为已定义远程调用，若 所述第一管理单元中未存储有对应的服务名称则判断为未定义远程调用。
13.根据权利要求12所述的智能设备，其特征在于，所述智能设备还包括注销模块，所 述注销模块包括： 第二获取单元，用于获取用户输入或系统检测产生的至少一个已注册及解耦的应用程 序的程序名称及对应的服务程序的服务名称； 第二管理单元，用于查找并删除所述第二获取单元获取到的所述程序名称和所述服务 名称，以动态注消所述至少一个已注册及解耦的应用程序的注册及解耦。
14.根据权利要求9或10所述的智能设备，其特征在于，所述智能设备为用户终端或云 终端，所述服务程序包括应用进程服务和系统进程服务，所述管理模块为AMS模块或SM模 块，所述处理模块为基于binder机制的binder驱动模块。
15. 一种服务程序调用方法，其特征在于，所述服务程序调用方法包括： 接收远端智能设备发送的需远程调用的服务程序的识别信息，并根据所述服务程序的 识别信息在本地确定对应的所述服务程序，其中，所述服务程序在远端智能设备已定义为 远程调用，所述远端智能设备根据所述应用程序调用对应的服务程序所发出的调用请求产 生所述服务程序的识别信息； 在接收到远端智能设备发送的针对所述服务程序的调用信息时，根据所述调用信息调 用对应的所述服务程序，并将所述服务程序运行获得的数据结果返回给所述远端智能设备 的应用程序。
16.根据权利要求15所述的服务程序调用方法，其特征在于： 所述根据所述服务程序的识别信息在本地确定对应的所述服务程序的步骤具体包 括： 根据所述服务程序的识别信息产生与所述服务程序对应的第一 binder引用，并存储 所述第一 binder引用与所述服务程序的对应关系； 所述根据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的数据 结果返回给所述远端智能设备的应用程序的步骤具体包括： 根据所述调用信息查找所述第一 binder引用，并根据所述第一 binder引用调用所述 服务程序； 将利用所述第一 binder引用返回的所述服务程序运行获得的数据结果发送给所述远 端智能设备，以使所述远端智能设备利用第二 binder引用将所述数据结果返回给所述应 用程序，其中，所述远端智能设备根据所述调用请求产生所述第二 binder引用。
17.根据权利要求15或16所述的服务程序调用方法，其特征在于，所述服务程序包括 应用进程服务和系统进程服务。
18. 一种智能设备，其特征在于，所述智能设备包括： 代理服务模块，用于接收远端智能设备发送的需远程调用的服务程序的识别信息，其 中，所述服务程序在远端智能设备已定义为远程调用，所述远端智能设备根据所述应用程 序调用对应的服务程序所发出的调用请求产生所述服务程序的识别信息； 管理模块，用于根据所述代理服务模块接收到的所述服务程序的识别信息在本地确定 对应的所述服务程序； 处理模块，用于在所述代理服务模块接收到远端智能设备发送的针对所述服务程序的 调用信息时，根据所述调用信息调用对应的所述服务程序，并将所述服务程序运行获得的 数据结果返回给所述远端智能设备的应用程序。
19.根据权利要求18所述的智能设备，其特征在于： 所述管理模块具体用于根据所述服务程序的识别信息产生与所述服务程序对应的第 一 binder引用，并存储所述第一 binder引用与所述服务程序的对应关系； 所述处理模块具体用于在所述代理服务模块接收到远端智能设备发送的针对所述 服务程序的调用信息时，根据所述调用信息查找所述第一 binder引用，并根据所述第一 binder引用调用所述服务程序； 所述代理服务模块具体用于将所述处理模块利用所述第一 binder引用返回的所述 服务程序运行获得的数据结果发送给所述远端智能设备，以使所述远端智能设备利用第二 binder引用将所述数据结果返回给所述应用程序，其中，所述远端智能设备根据所述调用 请求产生所述第二 binder引用。
20.根据权利要求18或19所述的智能设备，其特征在于，所述智能设备为用户终端或 云终端，所述服务程序为应用进程服务或系统进程服务，所述管理模块为AMS模块或SM模 块，所述处理模块为基于binder机制的binder驱动模块。
21. 一种服务程序调用系统，其特征在于，所述服务程序调用系统包括第一智能设备和 第二智能设备： 所述第一智能设备包括： 第一代理服务模块，用于从所述第二智能设备调用服务程序； 第一管理模块，用于接收应用程序调用对应的服务程序的调用请求并判断所述服务程 序是否已定义为远程调用； 第一处理模块，用于在所述第一管理模块判断到所述服务程序已定义为远程调用时， 根据所述调用请求产生所述服务程序的识别信息并通过所述第一代理服务模块发送给所 述第二智能设备，以通过所述第一代理服务模块从所述第二智能设备调用所述服务程序， 在所述第一管理模块判断到所述服务程序未定义为远程调用时，则从本地调用所述服务程 序; 所述第二智能设备包括： 第二代理服务模块，用于接收所述第一代理服务模块发送所述服务程序的识别信息； 第二管理模块，用于根据所述第二代理服务模块接收到的所述服务程序的识别信息在 本地确定对应的所述服务程序； 第二处理模块，用于在所述第二代理服务模块接收到所述第一代理服务模块发送的针 对所述服务程序的调用信息时，根据所述调用信息调用对应的所述服务程序，并将所述服 务程序运行获得的数据结果通过所述第二代理服务模块发送给所述第一代理服务模块以 返回给所述应用程序。
22.根据权利要求21所述的服务程序调用系统，其特征在于： 所述第一管理模块具体用于根据所述调用请求产生与所述第一代理服务模块相对应 的第一 binder引用并将所述第一 binder引用返回给所述应用程序； 所述第一代理服务模块具体用于将所述服务程序的识别信息发送至所述第二代理服 务模块，所述第二管理模块具体用于根据所述识别信息产生与所述服务程序对应的第二 binder引用，并存储所述第二 binder引用与所述服务程序的对应关系； 所述第一代理服务模块具体还用于在所述应用程序根据所述第一 binder引用调用所 述服务程序时，将针对所述应用程序的调用信息发送至所述第二代理服务模块，所述第二 处理模块具体用于根据所述服务程序的调用信息查找所述第二 binder引用，并根据所述 第二 binder引用调用所述服务程序； 所述第二代理服务模块具体用于将所述第二处理模块利用所述第二 binder引用返回 的所述服务程序运行获得的数据结果发送给所述第一处理模块，所述第一处理模块具体用 于利用所述第一 binder引用将所述第一代理服务模块接收的所述数据结果返回给所述应 用程序。
23.根据权利要求22所述的服务程序调用系统，其特征在于： 所述第一管理模块具体还用于在所述第一管理模块判断到所述服务程序未定义为远 程调用时，根据所述调用请求从本地查找与所述服务程序对应的第三binder引用并将所 述第三binder引用返回给所述应用程序； 所述第一处理模块具体还用于在所述应用程序根据所述第三binder引用调用所述服 务程序时，利用所述第三binder引用将所述服务程序运行获得的数据结果返回给所述应 用程序。
24.根据权利要求21-23任一项所述的服务调用系统，其特征在于，所述第一智能设备 还包括： 注册模块，用于获取用户输入或系统检测产生的至少一个应用程序的程序名称及对应 的服务程序的服务名称，并存储所述程序名称和所述服务名称； 注销模块，用于获取用户输入或系统检测产生的至少一个已注册及解耦的应用程序的 程序名称及对应的服务程序的服务名称，查找并删除所述程序名称和所述服务名称，以动 态注消所述至少一个已注册及解耦的应用程序的注册及解耦； 其中，所述第一管理模块具体用于判断所述注册模块中是否已存储有所述服务程序的 服务名称，若所述注册模块中已存储有对应的服务名称则判断为已定义远程调用，若所述 注册模块中未存储有对应的服务名称则判断为未定义远程调用。
25.根据权利要求22或23所述的服务调用系统，其特征在于，所述第一智能设备和所 述第二智能设备的其中之一为用户终端、另一为云终端，所述第一处理模块和所述第二处 理模块为基于binder机制的binder驱动模块。
26.根据权利要求22或23所述的服务调用系统，其特征在于，所述第一管理模块和所 述第二管理模块均为AMS模块、或均为SM模块，所述服务程序相应地为应用进程服务或系 统进程服务。
【文档编号】H04L29/08GK104142856SQ201310164835
【公开日】2014年11月12日 申请日期:2013年5月7日 优先权日:2013年5月7日
【发明者】刘宇涛, 吴晓昕, 夏虞斌, 陈海波 申请人:华为技术有限公司