CN109933960B - 服务调用控制方法、服务调用方法、装置及终端 - Google Patents

Abstract

一种服务调用控制方法、服务调用方法、装置及终端。该方法应用于终端的操作系统，该方法包括：接收终端中的第一应用程序发送的服务调用请求，服务调用请求用于请求调用操作系统中的目标服务；当服务调用请求中携带第一识别码时，根据第一应用程序的包名和第一应用程序的签名信息生成第二识别码；若第二识别码和第一识别码相同，则允许第一应用程序调用目标服务。相比于相关技术中采用白名单方式来判断是否允许应用程序调用操作系统中的服务，本申请实施例提供的技术方案，无需对白名单进行更新维护，也可以避免白名单更新不及时应用程序无法调用操作系统中的服务的情况发生。

Description

服务调用控制方法、服务调用方法、装置及终端

技术领域

本申请实施例涉及终端技术领域，特别涉及一种服务调用控制方法、服务调用方法、装置及终端。

背景技术

目前，终端厂商在操作系统中预置了优化服务，应用程序在运行时可以通过调用上述优化服务，来对应用程序的运行性能进行优化。在应用程序调用该优化服务前，操作系统需要鉴定该应用程序是否具有服务调用权限，以提升安全性。

相关技术中，操作系统通过如下方式对应用程序进行鉴权：操作系统中维护有白名单，该白名单中包括所有具有服务调用权限的应用程序，后续操作系统接收到服务调用请求时，先检测发送该服务调用请求的应用程序是否存在于上述白名单中，若白名单中包括发送该服务调用请求的应用程序，则操作系统允许该应用程序调用优化服务，若白名单中不包括发送该服务调用请求的应用程序，则操作系统不允许该应用程序调用优化服务。

发明内容

本申请实施例提供一种服务调用控制方法、服务调用方法、装置及终端。所述技术方案如下：

一方面，本申请实施例提供一种服务调用控制方法，所述方法应用于终端的操作系统，所述方法包括：

接收所述终端中的第一应用程序发送的服务调用请求，所述优化服务调用请求用于请求调用所述操作系统中的目标服务；

当所述服务调用请求中携带第一识别码时，根据所述第一应用程序的包名和所述第一应用程序的签名信息生成第二识别码；

若所述第二识别码和所述第一识别码相同，则允许所述第一应用程序调用所述目标服务。

另一方面，本申请实施例提供一种一种服务调用方法，其特征在于，所述方法应用于终端中的第二应用程序，所述方法包括：

从所述第二应用程序中的安装包中读取第一识别码；

向所述终端中的操作系统发送服务调用请求，所述服务调用请求中携带所述第一识别码，所述服务调用请求用于请求调用所述操作系统中的目标服务；所述服务调用请求用于指示所述操作系统根据所述第二应用程序的包名和所述第二应用程序的签名信息生成第二识别码，并在所述第二识别码和所述第一识别码相同的情况下，允许所述第二应用程序调用所述目标服务；

调用所述操作系统中的所述目标服务。

再一方面，本申请实施例提供一种服务调用控制装置，所述方法应用于终端的操作系统，所述方法包括：

请求接收模块，用于接收所述终端中的第一应用程序发送的服务调用请求，所述优化服务调用请求用于请求调用所述操作系统中的目标服务；

识别码生成模块，用于当所述服务调用请求中携带第一识别码时，根据所述第一应用程序的包名和所述第一应用程序的签名信息生成第二识别码；

调用控制模块，用于若所述第二识别码和所述第一识别码相同，则允许所述第一应用程序调用所述目标服务。

又一方面，本申请实施例提供一种服务调用装置，其特征在于，所述方法应用于终端中的第二应用程序，所述装置包括：

识别码读取模块，用于从所述第二应用程序中的安装包中读取第一识别码；

请求发送模块，用于向所述终端中的操作系统发送服务调用请求，所述服务调用请求中携带所述第一识别码，所述服务调用请求用于请求调用所述操作系统中的目标服务；所述服务调用请求用于指示所述操作系统根据所述第二应用程序的包名和所述第二应用程序的签名信息生成第二识别码，并在所述第二识别码和所述第一识别码相同的情况下，允许所述第二应用程序调用所述目标服务；

服务调用模块，用于调用所述操作系统中的所述目标服务。

又一方面，本申请实施例提供一种终端，所述终端包括处理器和存储器，所述存储器存储有计算机程序，所述计算机程序由所述处理器加载并执行以实现上述方面所述的服务调用控制方法。

又一方面，本申请实施例提供一种终端，所述终端包括处理器和存储器，所述存储器存储有计算机程序，所述计算机程序由所述处理器加载并执行以实现上述方面所述的服务调用方法。

又一方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序由处理器加载并执行以实现上述方面所述的服务调用控制方法。

又一方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序由处理器加载并执行以实现上述方面所述的服务调用方法。

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

通过在应用程序发送至操作系统的服务调用请求中携带识别码，后续操作系统通过该识别码来判断是否允许该应用程序调用操作系统中的服务，相比于相关技术中采用白名单方式来判断是否允许应用程序调用操作系统中的服务，本申请实施例提供的技术方案，无需对白名单进行更新维护，也可以避免白名单更新不及时时应用程序无法调用操作系统中的服务的情况发生。

附图说明

图1是本申请一个实施例提供的终端的框图；

图2示出了一种操作系统与第三方应用程序之间的通信示意图；

图3是本申请一个实施例示出的操作系统的示意图；

图4示出了另一种操作系统与第三方应用程序之间的通信示意图；

图5示出了另一种操作系统与第三方应用程序之间的通信示意图；

图6是本申请另一个实施例示出的操作系统的示意图；

图7是本申请一个实施例提供的服务调用控制方法的流程图；

图8是本申请一个实施例示出的生成第一识别码的示意图；

图9是本申请一个实施例示出的服务调用控制的示意图；

图10是本申请一个实施例提供的服务调用方法的流程图；

图11是本申请一个实施例示出的服务调用控制装置的框图；

图12是本申请一个实施例示出的服务调用装置的框图。

具体实施方式

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

请参考图1，其示出了本申请一个示例性实施例提供的终端的结构方框图。该终端可以是智能手机、平板电脑、电子书等能够运行应用程序的电子设备。本申请中的终端可以包括一个或多个如下部件：处理器110、存储器120和输入输出装置130。

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

存储器120可以包括随机存储器(Random Access Memory，RAM)，也可以包括只读存储器(Read-Only Memory，ROM)。可选地，该存储器120包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器120可用于存储指令、程序、代码、代码集或指令集。存储器120可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等，该操作系统可以是安卓(Android)系统(包括基于Android系统深度开发的系统)、苹果公司开发的IOS系统(包括基于IOS系统深度开发的系统)或其它系统。存储数据区还可以存储终端在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。

存储器120可分为操作系统空间和用户空间，操作系统即运行于操作系统空间，原生及第三方应用程序即运行于用户空间。为了保证不同第三方应用程序均能够达到较好的运行效果，操作系统针对不同第三方应用程序为其分配相应的系统资源。然而，同一第三方应用程序中不同应用场景对系统资源的需求也存在差异，比如，在本地资源加载场景下，第三方应用程序对磁盘读取速度的要求较高；在动画渲染场景下，第三方应用程序则对GPU性能的要求较高。而操作系统与第三方应用程序之间相互独立，操作系统往往不能及时感知第三方应用程序当前的应用场景，导致操作系统无法根据第三方应用程序的具体应用场景进行针对性的系统资源适配。

如图2所示，为了使操作系统能够区分第三方应用程序的具体应用场景，需要打通第三方应用程序与操作系统之间的数据通信，使得操作系统能够随时获取第三方应用程序当前的场景信息，进而基于当前场景进行针对性的系统资源适配。

以操作系统为Android系统为例，存储器120中存储的程序和数据如图3所示，存储器120中可存储有Linux内核层220、系统运行库层240、应用框架层260和应用层280，其中，Linux内核层220、系统运行库层240和应用框架层260属于操作系统空间，应用层280属于用户空间。Linux内核层220为终端100的各种硬件提供了底层的驱动，如显示驱动、音频驱动、摄像头驱动、蓝牙驱动、Wi-Fi驱动、电源管理等。系统运行库层240通过一些C/C++库来为Android系统提供了主要的特性支持。如SQLite库提供了数据库的支持，OpenGL/ES库提供了3D绘图的支持，Webkit库提供了浏览器内核的支持等。在系统运行库层240中还提供有安卓运行时库(Android Runtime)，它主要提供了一些核心库，能够允许开发者使用Java语言来编写Android应用。应用框架层260提供了构建应用程序时可能用到的各种API，开发者也可以通过使用这些API来构建自己的应用程序，比如活动管理、窗口管理、视图管理、通知管理、内容提供者、包管理、通话管理、资源管理、定位管理。应用层280中运行有至少一个应用程序，这些应用程序可以是操作系统自带的原生应用程序，比如联系人程序、短信程序、时钟程序、相机应用等；也可以是第三方开发者所开发的第三方应用程序，比如游戏类应用程序、即时通信程序、相片美化程序、购物程序等。

操作系统与第三方应用程序之间一种可行的通信方式如图4所示，第三方应用程序中内嵌有用于与操作系统进行通信的软件开发工具包(Software Development Kit，SDK)。

其中，SDK包含若干经过抽象的应用程序编程接口(Application ProgrammingInterface，API)，并由操作系统开发者提供给第三方应用程序开发者，并由第三方应用程序开发者将该SDK内嵌到第三方应用程序中。此类第三方应用程序安装并运行在操作系统后，即可调用SDK提供的API与操作系统进行通信。

如图4所示，系统运行库层240可以额外包括接口通信系统242。该接口通信系统242可以视为操作系统中的一个子系统，或视为操作系统内嵌的一个应用程序。接口通信系统242中设置有SDK接口，第三方应用程序即调用内嵌SDK的API与该SDK接口之间通过粘合(Binder)的方式进行数据通信。这样，第三方应用程序的应用场景相关的数据就可以通过SDK传输给操作系统。借助内嵌SDK，操作系统还可以主动向第三方应用程序传输数据，或者，操作系统与第三方应用程序之间可以进行双向数据传输。

在另一种可行的通信方式中，如图5所示，第三方应用程序还可以采用套接字(Socket)方式与接口通信系统242的Socket接口建立长连接，第三方应用程序的应用场景相关的数据即可以通过该长连接传输给操作系统。

如图4和5所示，接口通信系统242中可设置有不同的策略模块，接收到第三方应用程序发送的数据后，接口通信系统242即采用第三方应用程序对应的策略模块对数据进行分析，得到相应的资源适配优化策略。基于分析得到的资源适配优化策略，接口通信系统242通过控制接口通知Linux内核层220进行系统资源适配优化。其中，该控制接口可以采用Sysfs的方式与Linux内核层220进行通信。

可选的，接口通信系统242中不同的策略模块可以对应不同的第三方应用程序(即针对不同的应用程序设置策略模块)，或者，不同的策略模块对应不同类型的第三方应用程序(即针对不同类型的应用程序设置策略模块)，或者，不同的策略模块对应不同的系统资源(即针对不同系统资源设置策略模块)，或者，不同的策略模块对应不同的应用场景(即针对不同的应用场景设置策略模块)，本申请实施例并不对策略模块的具体设置方式进行限定。

其中，接口通信系统242还可以通过Binder的方式与应用框架层260进行通信，用于接收应用框架层260发送的前景应用信息，从而基于前景应用信息，仅针对当前前台运行的第三方应用程序进行系统资源优化。

以操作系统为IOS系统为例，存储器120中存储的程序和数据如图6所示，IOS系统包括：核心操作系统层320(Core OS layer)、核心服务层340(Core Services layer)、媒体层360(Media layer)、可触摸层380(Cocoa Touch Layer)。核心操作系统层320包括了操作系统内核、驱动程序以及底层程序框架，这些底层程序框架提供更接近硬件的功能，以供位于核心服务层340的程序框架所使用。核心服务层340提供给应用程序所需要的系统服务和/或程序框架，比如基础(Foundation)框架、账户框架、广告框架、数据存储框架、网络连接框架、地理位置框架、运动框架等等。媒体层360为应用程序提供有关视听方面的接口，如图形图像相关的接口、音频技术相关的接口、视频技术相关的接口、音视频传输技术的无线播放(AirPlay)接口等。可触摸层380为应用程序开发提供了各种常用的界面相关的框架，可触摸层380负责用户在终端100上的触摸交互操作。比如本地通知服务、远程推送服务、广告框架、游戏工具框架、消息用户界面接口(User Interface，UI)框架、用户界面UIKit框架、地图框架等等。

在图6所示出的框架中，与大部分应用程序有关的框架包括但不限于：核心服务层340中的基础框架和可触摸层380中的UIKit框架。基础框架提供许多基本的对象类和数据类型，为所有应用程序提供最基本的系统服务，和UI无关。而UIKit框架提供的类是基础的UI类库，用于创建基于触摸的用户界面，iOS应用程序可以基于UIKit框架来提供UI，所以它提供了应用程序的基础架构，用于构建用户界面，绘图、处理和用户交互事件，响应手势等等。

其中，在IOS系统中实现第三方应用程序与操作系统数据通信的方式以及原理可参考Android系统，本申请在此不再赘述。

输入输出装置130可以包括触摸显示屏，该触摸显示屏用于接收用户使用手指、触摸笔等任何适合的物体在其上或附近的触摸操作，以及显示各个应用程序的用户界面。触摸显示屏通常设置在终端的前面板。触摸显示屏可被设计成为全面屏、曲面屏或异型屏。触摸显示屏还可被设计成为全面屏与曲面屏的结合，异型屏与曲面屏的结合，本申请实施例对此不加以限定。

除此之外，本领域技术人员可以理解，上述附图所示出的终端的结构并不构成对终端的限定，终端可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。比如，终端中还包括射频电路、输入单元、传感器、音频电路、无线保真(WirelessFidelity，WiFi)模块、电源、蓝牙模块等部件，在此不再赘述。

相关技术中，采用白名单方式来验证应用程序是否被允许调用操作系统中的服务，该方式需要对白名单进行维护更新，若白名单更新不及时，则有可能出现应用程序无法调用操作系统中的服务的情况发生。

基于此，本申请实施例提供了一种服务调用控制方法、服务调用方法、装置及终端。在本申请实施例提供的技术方案中，通过在应用程序发送至操作系统的服务调用请求中携带识别码，后续操作系统通过该识别码来判断是否允许该应用程序调用操作系统中的服务，相比于相关技术中采用白名单方式来判断是否允许应用程序调用操作系统中的服务，本申请实施例提供的技术方案，无需对白名单进行更新维护，也可以避免白名单更新不及时时应用程序无法调用操作系统中的服务的情况发生。

请参考图7，其示出了本申请一个实施例示出的服务调用控制方法的流程图。该方法可以应用于上文实施例提到的终端中，该方法包括如下步骤：

步骤701，接收终端中的第一应用程序发送的服务调用请求。

第一应用程序是终端中对目标服务具有调用需求的应用程序，其可以是预设类型的应用程序，如游戏类应用程序。服务调用请求用于请求调用操作系统中的目标服务。可选地，服务调用请求中携带第一应用程序的包名、签名信息。可选地，服务调用请求中还携带第一应用程序的场景信息，该场景信息用于指示第一应用程序当前所处或即将所处的应用场景。目标服务可以是操作系统提供的多项服务中的任意一种，本申请实施例对此不作限定。

可选地，操作系统接收第一应用程序通过预设数据通道发送的服务调用请求，预设数据通道是指操作系统与第一应用程序之间预先建立的数据通道。在本申请实施例中，终端中的操作系统与第一应用程序之间建立有数据通道，以实现操作系统与第一应用程序之间的数据交互。

在一种可能的实现方式中，数据通道由第一应用程序通过调用内嵌SDK与操作系统之间以Binder方式建立。可选地，数据通道由目标应用程序在启动运行时通过调用内嵌SDK与操作系统提供的SDK接口之间以Binder方式建立。在另一种可能的实现方式中，数据通道是由第一应用程序采用套接字Socket方式与操作系统之间建立的长连接。可选地，数据通道是由目标应用程序在启动运行时采用Socket方式与操作系统提供的Socket接口之间建立的长连接。

在一种可能的实现方式中，当操作系统监测到第一应用程序所处的运行场景为预设场景或者在预设时长内切换至预设场景时，接收终端中的第一应用程序发送的服务调用请求。预设场景是指所需的终端的处理性能符合第一预设条件的场景。上述第一预设条件是所需的终端的处理性能大于预设值。上述预设场景可以是团战场景或者开镜场景。预设时长可以根据实际需求设定，本申请实施例对此不作限定。

在另一种可能的实现方式中，当操作系统监测到终端的负载达到预设阈值时，接收终端中的第一应用程序发送的服务调用请求。预设阈值可以根据实际需求设定，本申请实施例对此不作限定。

在又一种可能的实现方式中，当操作系统监测到第一应用程序的显示画面符合第二预设条件时，接收终端中的第一应用程序发送的服务调用请求。第二预设条件可以是显示画面的画面质量低于预设质量，也可以是显示画面发生卡顿。其中，当前显示画面出现卡顿可以是指应用程序的帧率小于预设帧率，也可以是指应用程序的帧率发生下降，还可以是应用程序的帧率的下降速度大于预设速度，本申请实施例对此不作限定。其中，上述预设值、预设帧率、预设速度均可以根据实际需求设定，本申请实施例对此不作限定。步骤702，当服务调用请求中携带第一识别码时，根据第一应用程序的包名和第一应用程序的签名信息生成第二识别码；

第一识别码可以通过如下方式生成：

1、第一设备向第二设备发送认证请求；

第一设备可以是应用程序厂商提供的设备，第二设备可以是终端厂商提供的设备。在一种可能的实现方式中，终端厂商建立有联合开发平台，第一设备是上述联合开发平台对应的后台服务器，第二设备访问该联合开发平台的页面，并通过该页面向上述后台服务器发送认证请求。

认证请求用于对应用程序进行认证，以使得应用程序能够调用操作系统中的服务。认证请求中携带第一应用程序的包名和第一应用程序的签名信息。应用程序的包名是指第一应用程序的APK文件的名称，其可以用于唯一标识应用程序。应用程序的签名信息用于标识应用程序的作者与应用程序之间建立信任关系，其可以视作为应用程序的合法标识，用于验证应用程序是否合法。

相应地，第二设备接收第一设备发送的认证请求。

2、第二设备根据认证请求对包名和签名信息进行加密处理，得到第一识别码；

可选地，第二设备对第一应用程序的包名和签名信息进行加密，得到中间值，之后通过哈希算法对中间值进行处理，得到第一识别码。第二设备可以通过对称加密算法对包名和签名信息进行加密处理，得到中间值，也可以通过非对称加密算法对包名和签名信息进行加密处理，得到中间值，本申请实施例对此不作限定。

对称加密算法是指对数据进行加密和解密都采用一个密钥的算法。对称加密算法可以是美国数据加密标准(Data Encrytion Standard，DES)算法，3DES(Triple DES)算法，Blowfish(布鲁斯)算法等。非对称加密算法是指对数据进行加密和解密采用不同密钥的算法。在非对称加密中，以公共密钥和私人密钥中的任一个作为加密密钥，则另一个作为解密密钥。对称加密速度快，效率高，而非对称加密安全性高。

在本申请实施例中，第二设备可以采用终端厂商私有的加密算法对包名和签名信息进行加密，得到第一识别码。上述终端厂商私有的加密算法可以是Ocrypt算法。

3、第二设备向第一设备发送第一识别码；

相应地，第一设备接收第二设备发送的第一识别码。

4、第一设备将第一识别码封装至第一应用程序的安装包中。

可选地，第一设备将第一识别码封装至第一应用程序的安装包中，后续若第一应用程序需要调用操作系统中的服务，则可以从安装包中读取该识别码。

结合参考图8，其示出了本申请一个实施例示出的第一识别码的生成过程的示意图。服务器采用Ocrypt算法对第一应用程序的包名和签名信息进行加密，得到第一应用程序的唯一识别ID，之后将该唯一识别ID提供给第一应用程序的应用厂商。

可选地，操作系统生成第二识别码的过程与第二设备生成第一识别码的过程相同。其中所涉及的哈希算法、加密算法也相同。

操作系统对第一应用程序的包名和签名信息进行加密，得到中间值，之后通过哈希算法对中间值进行处理，得到第一识别码。第二设备可以通过对称加密算法对包名和签名信息进行加密处理，得到中间值，也可以通过非对称加密算法对包名和签名信息进行加密处理，得到中间值，本申请实施例对此不作限定。

步骤703，若第二识别码和第一识别码相同，则允许第一应用程序调用目标服务。

若第二识别码和第一识别码不相同，则不允许第一应用程序调用目标服务。

结合参考图9，其示出了本申请一个实施例示出的服务调用控制的示意图。第一应用程序通过应用程序与操作系统之间的数据通道(也即oiface接口)发送服务调用请求，该请求中携带唯一识别ID，此时操作系统也通过oiface获取发送服务调用请求的应用程序的包名和签名信息，之后操作系统在TEE内采用Ocrypt算法生成唯一识别ID，并通过比较器将生成的唯一识别ID与接收到的唯一识别ID进行比对，得到比对结果，并将比对结果发送至认证模块，若比对结果相同，则认证通过，此时允许应用程序调用操作系统中的服务，若比对结果不相同，则认证不通过，此时不允许应用程序调用操作系统中的服务。

综上所述，本申请实施例提供的技术方案，通过在应用程序发送至操作系统的服务调用请求中携带识别码，后续操作系统通过该识别码来判断是否允许该应用程序调用操作系统中的服务，相比于相关技术中采用白名单方式来判断是否允许应用程序调用操作系统中的服务，本申请实施例提供的技术方案，无需对白名单进行更新维护，也可以避免白名单更新不及时时应用程序无法调用操作系统中的服务的情况发生。

在上文实施例中提到，第一识别码是在应用程序厂商设备向终端厂商设备发起认证请求后获取的，若应用程序厂商未发起认证请求，则应用程序无法从安装包中读取第一识别码。在该种情况下，操作系统可以通过如下方式来决定是否允许应用程序调用操作系统中的服务。

在基于图7所示实施例提供的一个可选实施例中，该方法还包括如下步骤：

步骤801，当服务调用请求中未携带第一识别码时，在设置为可调试模式的应用程序列表中查找是否存在第一应用程序；

可选地，操作系统中维护有设置为可调试模式的应用程序列表，操作系统检测上述处于可调试模式的应用程序列表中是否包括第一应用程序。若上述处于可调试模式的应用程序列表中包括上述第一应用程序，则操作系统确定第一应用程序处于可调试模式；若上述处于可调试模式的应用程序列表中不包括上述第一应用程序，则操作系统确定第一应用程序未处于可调试模式。

步骤802，若设置为可调试模式的应用程序列表中存在第一应用程序，则允许第一应用程序调用目标服务。

若设置为可调试模式的应用程序列表中不存在第一应用程序，则操作系统不允许第一应用程序调用目标服务。

需要说明的是，在应用厂商认证完成后，此时操作系统会删除上述设置为可调试模式的应用程序列表中的第一应用程序，此时第一应用程序未处于可调试模式。在基于图7所示实施例提供的一个可选实施例中，该方法还包括：当服务调用请求中携带第一识别码，且第一应用程序上次发送的服务调用请求中不携带第一识别码时，删除设置为可调试模式的应用程序列表中的第一应用程序。也即操作系统检测到第一应用程序发送的服务调用请求中携带第一识别码时，使第一应用程序不处于可调试模式。

请参考图10，其示出了本申请一个实施例示出的服务调用方法的流程图。该方法应用于终端中的第二应用程序，该方法包括如下几个步骤：

步骤1001，从第二应用程序中的安装包中读取第一识别码。

第二应用程序是终端中对目标服务具有调用需求的应用程序，其可以是预设类型的应用程序，如游戏类应用程序。第二应用程序与第一应用程序可以相同，也可以不同。第二应用程序所对应的第一识别码与第一应用程序所对应的第一识别码的获取过程相同，此处不再赘述。

步骤1002，向终端中的操作系统发送服务调用请求。

可选地，服务调用请求中还携带第二应用程序的包名和签名信息。可选地，第二应用程序在确认出自身具有操作系统中的服务调用需求时，向操作系统发送服务调用请求。例如，第二应用程序运行至指定应用场景时，向操作系统发送服务调用请求。上述指定应用场景可以是对终端的处理性能要求较高的场景，比如团战场景、开镜场景。在该种情况下，第二应用程序所发送的服务调用请求中还携带场景信息，以指示第二应用程序当前所处的应用场景，或者即将进入的应用场景。

相应地，操作系统接收第二应用程序所发送的服务调用请求。

服务调用请求中携带第一识别码，服务调用请求用于请求调用操作系统中的目标服务；服务调用请求用于指示操作系统根据第二应用程序的包名和第二应用程序的签名信息生成第二识别码，并在第二识别码和第一识别码相同的情况下，允许第二应用程序调用目标服务。

步骤1003，调用操作系统中的目标服务。

第二应用程序在操作系统允许调用目标服务之后，调用上述目标服务。可选地，第二应用程序在调用目标服务对上述场景信息进行分析处理，进而制定出第二应用程序对应的运行策略，并按照上述运行策略运行。

综上所述，本申请实施例提供的技术方案，通过在应用程序发送至操作系统的服务调用请求中携带识别码，后续操作系统通过该识别码来判断是否允许该应用程序调用操作系统中的服务，相比于相关技术中采用白名单方式来判断是否允许应用程序调用操作系统中的服务，本申请实施例提供的技术方案，无需对白名单进行更新维护，也可以避免白名单更新不及时时应用程序无法调用操作系统中的服务的情况发生。

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

请参考图11，其示出了本申请一个实施例提供的服务调用控制装置的框图。该装置可以应用于终端的操作系统，该装置具有实现上述方法示例的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。该装置可以包括：

请求接收模块1101，用于接收所述终端中的第一应用程序发送的服务调用请求，所述优化服务调用请求用于请求调用所述操作系统中的目标服务。

识别码生成模块1102，用于当所述服务调用请求中携带第一识别码时，根据所述第一应用程序的包名和所述第一应用程序的签名信息生成第二识别码。

调用控制模块1103，用于若所述第二识别码和所述第一识别码相同，则允许所述第一应用程序调用所述目标服务。

综上所述，本申请实施例提供的技术方案，通过在应用程序发送至操作系统的服务调用请求中携带识别码，后续操作系统通过该识别码来判断是否允许该应用程序调用操作系统中的服务，相比于相关技术中采用白名单方式来判断是否允许应用程序调用操作系统中的服务，本申请实施例提供的技术方案，无需对白名单进行更新维护，也可以避免白名单更新不及时时应用程序无法调用操作系统中的服务的情况发生。

在基于图11所示实施环境提供的一个可选实施例中，所述识别码生成模块1102，用于：

对所述包名和所述签名信息进行加密处理，得到中间值；

通过哈希算法对所述中间值进行处理，得到所述第二识别码。

可选地，所述识别码生成模块1102，用于：

通过对称加密算法对所述包名和所述签名信息进行加密处理，得到所述中间值；

或者，

通过非对称加密算法对所述包名和所述签名信息进行加密处理，得到所述中间值。

在基于图11所示实施例提供的一个可选实施例中，所述请求接收模块1101，用于：

当监测到所述第一应用程序所处的运行场景为预设场景或者在预设时长内切换至所述预设场景时，接收所述终端中的第一应用程序发送的所述服务调用请求，所述预设场景是指所需的所述终端的处理性能符合预设条件的场景；

当监测到所述终端的负载达到预设阈值时，接收所述终端中的第一应用程序发送的所述服务调用请求；

当监测到所述第一应用程序的显示画面符合预设条件时，接收所述终端中的第一应用程序发送的所述服务调用请求。

在基于图11所示实施例提供的一个可选实施例中，所述请求接收模块1101，用于接收所述第一应用程序通过预设数据通道发送的所述服务调用请求，所述预设数据通道是指所述操作系统与所述第一应用程序之间预先建立的数据通道。

在基于图11所示实施例提供的一个可选实施例中，所述装置还包括：

11程序查找模块，用于当所述服务调用请求中未携带所述第一识别码时，在设置为可调试模式的应用程序列表中查找是否存在所述第一应用程序；

所述调用控制模块1103，用于若所述设置为可调试模式的应用程序列表中存在所述第一应用程序，则允许所述第一应用程序调用所述目标服务。

可选地，所述装置还包括：

删除模块，用于当所述服务调用请求中携带所述第一识别码，且所述第一应用程序上次发送的服务调用请求中不携带所述第一识别码时，删除所述设置为可调试模式的应用程序列表中的所述第一应用程序。

请参考图12，其示出了本申请一个实施例提供的服务调用装置的框图。该装置可以应用于终端的第二应用程序，该装置具有实现上述方法示例的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。该装置可以包括：

请求接收模块1201，用于接收所述终端中的第一应用程序发送的服务调用请求，所述优化服务调用请求用于请求调用所述操作系统中的目标服务；

识别码生成模块1202，用于当所述服务调用请求中携带第一识别码时，根据所述第一应用程序的包名和所述第一应用程序的签名信息生成第二识别码；

调用控制模块1203，用于若所述第二识别码和所述第一识别码相同，则允许所述第一应用程序调用所述目标服务。

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

在示例性实施例中，还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序由终端的处理器加载并执行以实现上述方法实施例中的各个步骤。

在示例性实施例中，还提供了一种计算机程序产品，当该计算机程序产品被执行时，其用于实现上述方法实施例中的各个步骤的功能。

应当理解的是，在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

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

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

Claims (11)

1.一种服务调用控制方法，其特征在于，所述方法应用于终端的操作系统，所述方法包括：

接收所述终端中的第一应用程序发送的服务调用请求，所述服务调用请求用于请求调用所述操作系统中的目标服务；所述目标服务为所述操作系统中的优化服务；

当所述服务调用请求中携带第一识别码时，通过所述第一应用程序与所述操作系统之间的数据通道，从所述第一应用程序中获取所述第一应用程序的包名和所述第一应用程序的签名信息；

根据所述第一应用程序的所述包名和所述第一应用程序的所述签名信息生成第二识别码；

若所述第二识别码和所述第一识别码相同，则允许所述第一应用程序调用所述目标服务；

其中，接收所述终端中的第一应用程序发送的服务调用请求，包括以下情况中的至少一种：

当监测到所述第一应用程序所处的运行场景为预设场景或者在预设时长内切换至所述预设场景时，接收所述终端中的第一应用程序发送的所述服务调用请求，所述预设场景是指所需的所述终端的处理性能符合第一预设条件的场景；所述第一预设条件是指所述终端的处理性能大于预设值；

当监测到所述终端的负载达到预设阈值时，接收所述终端中的第一应用程序发送的所述服务调用请求；

当监测到所述第一应用程序的显示画面符合第二预设条件时，接收所述终端中的第一应用程序发送的所述服务调用请求；所述第二预设条件是指所述显示画面的画面质量低于预设质量，或者，所述显示画面发生卡顿，所述显示画面发生卡顿是指所述第一应用程序的帧率小于预设帧率，或者，所述第一应用程序的帧率发生下降，或者，所述第一应用程序的帧率的下降速度大于预设速度。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一应用程序的所述包名和所述第一应用程序的所述签名信息生成第二识别码，包括：

对所述包名和所述签名信息进行加密处理，得到中间值；

通过哈希算法对所述中间值进行处理，得到所述第二识别码。

3.根据权利要求2所述的方法，其特征在于，所述对所述包名和所述签名信息进行加密处理，得到中间值，包括：

通过对称加密算法对所述包名和所述签名信息进行加密处理，得到所述中间值；

或者，

通过非对称加密算法对所述包名和所述签名信息进行加密处理，得到所述中间值。

4.根据权利要求1至3任一项所述的方法，其特征在于，所述接收所述终端中的第一应用程序发送的服务调用请求，包括：

接收所述第一应用程序通过预设数据通道发送的所述服务调用请求，所述预设数据通道是指所述操作系统与所述第一应用程序之间预先建立的数据通道。

5.根据权利要求1至3任一项所述的方法，其特征在于，所述方法还包括：

当所述服务调用请求中未携带所述第一识别码时，在设置为可调试模式的应用程序列表中查找是否存在所述第一应用程序；

若所述设置为可调试模式的应用程序列表中存在所述第一应用程序，则允许所述第一应用程序调用所述目标服务。

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

当所述服务调用请求中携带所述第一识别码，且所述第一应用程序上次发送的服务调用请求中不携带所述第一识别码时，删除所述设置为可调试模式的应用程序列表中的所述第一应用程序。

7.一种服务调用方法，其特征在于，所述方法应用于终端中的第二应用程序，所述方法包括：

从所述第二应用程序中的安装包中读取第一识别码；

向所述终端中的操作系统发送服务调用请求，所述服务调用请求中携带所述第一识别码，所述服务调用请求用于请求调用所述操作系统中的目标服务；所述服务调用请求用于指示所述操作系统通过所述第二应用程序与所述操作系统之间的数据通道，从所述第二应用程序中获取所述第二应用程序的包名和所述第二应用程序的签名信息，并根据所述第二应用程序的所述包名和所述第二应用程序的所述签名信息生成第二识别码，并在所述第二识别码和所述第一识别码相同的情况下，允许所述第二应用程序调用所述目标服务；所述目标服务为所述操作系统中的优化服务；

调用所述操作系统中的所述目标服务；

其中，向所述终端中的操作系统发送服务调用请求，包括以下情况中的至少一种：

当监测到第一应用程序所处的运行场景为预设场景或者在预设时长内切换至所述预设场景时，向所述终端中的操作系统发送服务调用请求，所述预设场景是指所需的所述终端的处理性能符合第一预设条件的场景；所述第一预设条件是所述终端的处理性能大于预设值；

当监测到所述终端的负载达到预设阈值时，向所述终端中的操作系统发送服务调用请求；

当监测到所述第一应用程序的显示画面符合第二预设条件时，向所述终端中的操作系统发送服务调用请求；所述第二预设条件包括显示画面的画面质量低于预设质量，或者，所述显示画面发生卡顿，所述显示画面发生卡顿是指所述第一应用程序的帧率小于预设帧率，或者，所述第一应用程序的帧率发生下降，或者，所述第一应用程序的帧率的下降速度大于预设速度。

8.一种服务调用控制装置，其特征在于，所述装置应用于终端的操作系统，所述装置包括：

请求接收模块，用于接收所述终端中的第一应用程序发送的服务调用请求，所述服务调用请求用于请求调用所述操作系统中的目标服务；所述目标服务为所述操作系统中的优化服务；

识别码生成模块，用于当所述服务调用请求中携带第一识别码时，通过所述第一应用程序与所述操作系统之间的数据通道，从所述第一应用程序中获取所述第一应用程序的包名和所述第一应用程序的签名信息；根据所述第一应用程序的所述包名和所述第一应用程序的所述签名信息生成第二识别码；

调用控制模块，用于若所述第二识别码和所述第一识别码相同，则允许所述第一应用程序调用所述目标服务；

其中，所述请求接收模块，用于当监测到所述第一应用程序所处的运行场景为预设场景或者在预设时长内切换至所述预设场景时，接收所述终端中的第一应用程序发送的所述服务调用请求，所述预设场景是指所需的所述终端的处理性能符合第一预设条件的场景；所述第一预设条件是指所述终端的处理性能大于预设值；

当监测到所述终端的负载达到预设阈值时，接收所述终端中的第一应用程序发送的所述服务调用请求；

当监测到所述第一应用程序的显示画面符合第二预设条件时，接收所述终端中的第一应用程序发送的所述服务调用请求；所述第二预设条件是指所述显示画面的画面质量低于预设质量，或者，所述显示画面发生卡顿，所述显示画面发生卡顿是指所述第一应用程序的帧率小于预设帧率，或者，所述第一应用程序的帧率发生下降，或者，所述第一应用程序的帧率的下降速度大于预设速度。

9.一种服务调用装置，其特征在于，所述装置应用于终端中的第二应用程序，所述装置包括：

识别码读取模块，用于从所述第二应用程序中的安装包中读取第一识别码；

请求发送模块，用于向所述终端中的操作系统发送服务调用请求，所述服务调用请求中携带所述第一识别码，所述服务调用请求用于请求调用所述操作系统中的目标服务；所述服务调用请求用于指示所述操作系统通过所述第二应用程序与所述操作系统之间的数据通道，从所述第二应用程序中获取所述第二应用程序的包名和所述第二应用程序的签名信息，并根据所述第二应用程序的所述包名和所述第二应用程序的所述签名信息生成第二识别码，并在所述第二识别码和所述第一识别码相同的情况下，允许所述第二应用程序调用所述目标服务；

服务调用模块，用于调用所述操作系统中的所述目标服务；

其中，所述请求发送模块，用于当监测到第一应用程序所处的运行场景为预设场景或者在预设时长内切换至所述预设场景时，向所述终端中的操作系统发送服务调用请求，所述预设场景是指所需的所述终端的处理性能符合第一预设条件的场景；所述第一预设条件是指所述终端的处理性能大于预设值；

当监测到所述终端的负载达到预设阈值时，向所述终端中的操作系统发送服务调用请求；

当监测到所述第一应用程序的显示画面符合第二预设条件时，向所述终端中的操作系统发送服务调用请求；所述第二预设条件是指所述显示画面的画面质量低于预设质量，或者，所述显示画面发生卡顿，所述显示画面发生卡顿是指所述第一应用程序的帧率小于预设帧率，或者，所述第一应用程序的帧率发生下降，或者，所述第一应用程序的帧率的下降速度大于预设速度。

10.一种终端，其特征在于，所述终端包括处理器和存储器，所述存储器存储有计算机程序，所述计算机程序由所述处理器加载并执行以实现如权利要求1至6任一项所述的服务调用控制方法，和/或，如权利要求7所述的服务调用方法。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，所述计算机程序由处理器加载并执行以实现如权利要求1至6任一项所述的服务调用控制方法，和/或，如权利要求7所述的服务调用方法。

Images