CN109542614A - 资源配置方法、装置、终端及存储介质 - Google Patents

Abstract

本申请实施例公开了一种资源配置方法、装置、终端及存储介质，属于应用优化领域。所述方法包括：目标应用程序通过与操作系统之间的binder连接，向操作系统发送应用运行信息，应用运行信息用于表征目标应用程序所处的运行状态；操作系统接收应用运行信息；操作系统根据应用运行信息确定资源配置策略，资源配置策略指为运行状态下目标应用程序分配系统资源的策略；操作系统根据资源配置策略为目标应用程序分配系统资源。本实施例中的操作系统可以针对应用程序所处的运行状态，针对性地为其分配相应系统资源，使得应用程序在不同运行状态下均能够达到良好的运行效果，并降低对终端硬件的依赖。

Description

资源配置方法、装置、终端及存储介质

技术领域

本申请实施例涉及应用优化技术领域，特别涉及一种资源配置方法、装置、终端及存储介质。

背景技术

随着移动终端技术的不断发展，移动终端中应用程序的种类也越来越多。比如，移动终端中同时安装有游戏类应用程序、社交类应用程序、视频播放类应用程序、即时通信类应用程序和购物类应用程序。

为了提高应用程序的使用体验，移动终端厂商都在不断提升自身的硬件配置，以提高应用程序的运行速度及质量。比如，移动终端通过配置高性能的中央处理器(CPU，Central Processing Unit)和图形处理器(Graphics Processing Unit，GPU)，来提高游戏类应用程序的运行速度和画面质量。

发明内容

本申请实施例提供了一种资源配置方法、装置、终端及存储介质，可以解决仅通过提升终端硬件配置的性能来提高应用程序的运行质量，成本较高且提升效果不佳的问题。所述技术方案如下：

第一方面，提供了一种资源配置方法，所述方法应用于终端，所述终端运行有操作系统和至少一个应用程序，所述方法包括：

目标应用程序通过与所述操作系统之间的粘合(binder)连接，向所述操作系统发送应用运行信息，所述应用运行信息用于表征所述目标应用程序所处的运行状态；

所述操作系统接收所述应用运行信息；

所述操作系统根据所述应用运行信息确定资源配置策略，所述资源配置策略指为所述运行状态下所述目标应用程序分配系统资源的策略；

所述操作系统根据所述资源配置策略为所述目标应用程序分配系统资源。

第二方面，提供了一种资源配置装置，所述装置应用于终端，所述终端运行有操作系统和至少一个应用程序，所述装置包括：

目标应用程序模块，用于通过与所述操作系统之间的binder连接，向所述操作系统发送应用运行信息，所述应用运行信息用于表征所述目标应用程序所处的运行状态；

操作系统模块，用于接收所述应用运行信息；

所述操作系统模块，用于根据所述应用运行信息确定资源配置策略，所述资源配置策略指为所述运行状态下所述目标应用程序分配系统资源的策略；

所述操作系统模块，用于根据所述资源配置策略为所述目标应用程序分配系统资源。

第三方面，提供了一种终端，所述终端包括处理器和存储器；所述存储器存储有至少一条指令，所述至少一条指令用于被所述处理器执行以实现如第一方面所述的资源配置方法。

第四方面，提供了一种计算机可读存储介质，所述存储介质存储有至少一条指令，所述至少一条指令用于被处理器执行以实现如第一方面所述的资源配置方法。

本申请实施例提供的资源配置方法中，目标应用程序通过预先与操作系统建立binder连接，使得目标应用程序能够通过该binder连接向操作系统发送自身的应用运行信息，以便操作系统基于应用运行信息制定相应的资源配置策略，从而根据该资源配置策略为目标应用程序分配相应的系统资源；相较于单纯提升终端的硬件性能，本实施例中的操作系统可以针对应用程序所处的运行状态，针对性地为其分配相应系统资源，使得应用程序在不同运行状态下均能够达到良好的运行效果，并降低对终端硬件的依赖。

附图说明

图1是本申请一个示例性实施例提供的终端的结构示意图；

图2是终端中应用程序与操作系统通信过程的实施示意图；

图3是本申请一个示例性实施例提供的终端的结构示意图；

图4和图5是图3所示终端中应用程序与操作系统通信过程的实施示意图；

图6是本申请另一个示例性实施例提供的终端的结构示意图；

图7示出了本申请一个示例性实施例示出的资源配置方法的流程图；

图8示出了本申请另一个示例性实施例示出的资源配置方法的流程图；

图9示出了本申请另一个示例性实施例示出的资源配置方法的流程图；

图10示出了本申请另一个示例性实施例示出的资源配置方法的流程图；

图11示出了本申请一个实施例提供的资源配置装置的结构框图。

具体实施方式

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

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

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

处理器110可以包括一个或者多个处理核心。处理器110利用各种接口和线路连接整个终端100内的各个部分，通过运行或执行存储在存储器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)。可选地，该存储器120包括非瞬时性计算机可读介质(non-transitory computer-readable storage medium)。存储器120可用于存储指令、程序、代码、代码集或指令集。存储器120可包括存储程序区和存储数据区，其中，存储程序区可存储用于实现操作系统的指令、用于实现至少一个功能的指令(比如触控功能、声音播放功能、图像播放功能等)、用于实现下述各个方法实施例的指令等，该操作系统可以是安卓(Android)系统(包括基于Android系统深度开发的系统)、苹果公司开发的IOS系统(包括基于IOS系统深度开发的系统)或其它系统。存储数据区还可以存储终端100在使用中所创建的数据(比如电话本、音视频数据、聊天记录数据)等。

存储器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所示，第三方应用程序中内嵌有用于与操作系统进行通信的binder通讯模块。

其中，该binder通讯模块中包含若干个binder接口函数，不同的binder接口函数用于实现不同的功能。比如，binder通讯模块中包含用于更新应用信息(包括当前帧率、当前延迟等信息)的binder接口函数，以及用于更新应用场景信息(比如游戏加载场景、游戏团战场景等等)的binder接口函数。本申请实施例并不对binder接口函数所实现的具体功能进行限定。

可选的，操作系统开发者预设设置对应不同功能的binder接口，并将调用binder接口的binder接口函数提供给第三方应用程序开发者，由第三方应用程序开发者根据实际需求，将相应的binder接口函数封装成binder通讯模块后内嵌到第三方应用程序中。内嵌有binder通讯模块的第三方应用程序运行时，即可调用相应的binder接口函数与操作系统的binder接口建立连接，进而通过该连接进行通信，实现数据传输。

相应的，如图4所示，系统运行层240可以额外包括接口通信系统242。接口通信系统242可以视为操作系统中的一个子系统，或视为操作系统内嵌的一个应用程序。接口通信系统242用于管理与第三方应用程序与操作系统提供binder接口之间的binder通道。可选的，接口通信系统242用于为新建立binder连接的第三方应用程序建立binder通道，和/或，为断开binder连接的第三方应用程序清理binder通道，和/或，对没有权限的第三方应用程序的binder连接进行过滤等等。

第三方应用程序与操作系统之间建立binder连接后，与应用场景相关的数据就可以通过binder连接传输给操作系统。借助binder连接，操作系统还可以主动向第三方应用程序传输数据，或者，操作系统与第三方应用程序之间可以进行双向数据传输。

在另一种可行的通信方式中，如图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可以包括触摸显示屏，该触摸显示屏用于接收用户使用手指、触摸笔等任何适合的物体在其上或附近的触摸操作，以及显示各个应用程序的用户界面。触摸显示屏通常设置在终端100的前面板。触摸显示屏可被设计成为全面屏、曲面屏或异型屏。触摸显示屏还可被设计成为全面屏与曲面屏的结合，异型屏与曲面屏的结合，本申请实施例对此不加以限定。

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

请参考图7，其示出了本申请一个示例性实施例示出的资源配置方法的流程图。本实施例以该方法应用于运行有操作系统和至少一个应用程序的终端100来举例说明。该方法包括：

步骤701，目标应用程序通过与操作系统之间的binder连接，向操作系统发送应用运行信息，应用运行信息用于表征目标应用程序所处的运行状态。

在一种可能的实施方式中，目标应用程序启动过程中，即与操作系统之间建立binder连接。该目标应用程序可以为游戏类应用程序、视频播放类应用程序、即时通信应用程序等等，本申请实施例并不对目标应用程序进行具体限定。

目标应用程序运行过程中，即对应用运行信息进行采集，并通过预先建立的binder连接，将采集到的应用运行信息发送至操作系统。

可选的，目标应用程序所处的运行状态包括所处的应用场景以及应用运行质量，相应的，该应用运行信息中可以包括指示当前应用场景的应用场景标识，以及指示应用当前运行质量的应用运行参数。其中，应用场景指目标应用程序中不同运行阶段对应的场景，比如，对于游戏类应用程序，该应用场景包括游戏数据加载场景、游戏数据更新场景和游戏对战场景等等。

针对发送应用运行信息的时机，在一种可能的实施方式中，目标应用程序每隔预定时间间隔通过binder连接向操作系统发送采集到的应用运行信息，比如，该预定时间间隔为5s或10s；在另一种可能的实施方式中，目标应用程序在运行至指定应用场景时，通过binder连接向操作系统发送采集到的应用运行信息。

步骤702，操作系统接收应用运行信息。

如图4所示，操作系统通过接口通信系统242的binder接口，接收目标应用程序发送的应用运行信息。

为了避免非法应用程序通过建立binder连接与操作系统进行通信，造成系统安全隐患，可选的，操作系统接收到应用运行信息后，获取目标应用程序的应用标识。

可选的，操作系统获取应用运行信息中包含的应用标识。

操作系统中预设应用标识列表，该预设应用标识列表中包含支持进行资源配置的应用程序的应用标识。可选的，该列表由操作系统开发商设置，且加密存储在终端内。

若目标应用程序的应用标识属于预设应用标识列表，操作系统则执行步骤703，若目标应用程序的应用标识不属于预设应用标识列表，操作系统则不响应应用运行信息。

可选的，当目标应用程序的应用标识不属于预设应用标识列表时，操作系统断开并清理与目标应用程序之间的连接。

步骤703，操作系统根据应用运行信息确定资源配置策略，资源配置策略指为运行状态下目标应用程序分配系统资源的策略。

操作系统能够分配的系统资源包括CPU资源、GPU资源、内存资源、磁盘资源和网络资源等等，而不同应用场景下，目标应用程序对不同系统资源的需求程度不同，因此，为了实现针对不同的应用场景，为应用程序动态配置系统资源，操作系统根据目标应用程序当前的应用运行信息，制定相应的资源配置策略。

在一种可能的实施方式中，操作系统根据应用运行信息中的应用运行参数，确定当前应用场景下目标应用程序的运行质量，并在运行质量不符合预期时，制定动态配置相关系统资源的资源配置策略。其中，该相关系统资源指与当前应用场景相关的系统资源。

可选的，该资源配置策略中至少包括：待配置系统资源的类型以及资源数量。

步骤704，操作系统根据资源配置策略为目标应用程序分配系统资源。

进一步的，根据制定出的资源配置策略，操作系统与内核层进行通信，从而指示内核层对相应的系统资源进行配置。

示意性的，如图4所示，操作系统中接口通信系统242即通过控制接口与Linux内核层220进行通信，最终完成系统资源优化配置。

可选的，对于能够通过直接通讯的方式进行控制的系统资源(比如CPU资源和GPU资源)，操作系统直接调用此类系统资源对应的抽象接口完成资源配置；而对于操作系统无法直接访问控制的系统资源(比如网络资源)，操作系统采用代理的方式，通过代理与此类系统资源对应的子系统(比如网络资源对应的子系统可以为WiFi子系统)进行间接通讯，从而完成系统资源配置。

可选的，当目标应用程序结束生命周期时(应用程序的进程结束)，即当接收到目标应用程序的进程结束信号时，操作系统断开与目标应用程序之间的连接，并清理数据通道，以便后续与其他应用程序建立连接。

综上所述，本申请实施例提供的资源配置方法中，目标应用程序通过预先与操作系统建立binder连接，使得目标应用程序能够通过该binder连接向操作系统发送自身的应用运行信息，以便操作系统基于应用运行信息制定相应的资源配置策略，从而根据该资源配置策略为目标应用程序分配相应的系统资源；相较于单纯提升终端的硬件性能，本实施例中的操作系统可以针对应用程序所处的运行状态，针对性地为其分配相应系统资源，使得应用程序在不同运行状态下均能够达到良好的运行效果，并降低对终端硬件的依赖。

另外，操作系统基于预设应用标识列表实现应用程序合法性检测，从而避免与非法应用程序进行通信，提高了操作系统的安全性。

综合考虑功耗、数据传输量等诸多因素，在一种可能的实施方式中，目标应用程序仅在运行至特定应用场景时，才会采集该应用场景下的应用运行参数，并发送至操作系统，相应的，操作系统根据接收到的应用运行参数，为该应用场景下的目标应用程序配置系统资源。下面采用示意性的实施例进行说明。

请参考图8，其示出了本申请另一个示例性实施例示出的资源配置方法的流程图。本实施例以该方法应用于终端100中来举例说明，终端100中运行有操作系统和至少一个应用程序。该方法包括：

步骤801，目标应用程序调用binder接口函数与操作系统的binder接口建立binder连接，binder接口函数由操作系统的开发者提供。

在一种可能的实施方式中，操作系统的开发者将调用自身binder接口的binder接口函数提供给第三方应用程序开发者，由第三方应用程序开发者根据需要将部分或全部binder接口函数封装成binder通讯模块后，内嵌到第三方应用程序中。本申请实施例中，目标应用程序可以为内嵌有该binder通讯模块的第三方应用程序。

可选的，在目标应用程序启动过程中，或，在账号登陆过程中，即调用binder接口函数请求与操作系统的binder接口建立binder连接。操作系统接受请求后，目标应用程序与操作系统之间即建立起binder连接。

可选的，操作系统接收到请求后，可以对目标应用程序进行验证，并在目标应用程序具备连接权限(即目标应用程序为支持资源优化配置的授权应用)时，与目标应用程序之间建立binder连接，否则，操作系统将不会与目标应用程序建立binder连接。

步骤802，若当前应用场景为预设应用场景，目标应用程序则获取预设应用场景对应的应用场景标识，并采集当前应用场景下的应用运行参数。

在一种可能的实施方式中，开发人员在开发目标应用程序时，针对可能需要进行系统资源优化配置的场景，设置包含至少一个预设应用场景的场景列表。示意性的，针对游戏类应用程序，该场景列表中可以包括：游戏启动场景、游戏资源更新场景、游戏账号登陆场景、游戏主界面场景、游戏商城界面场景、游戏内部加载场景、游戏对战场景。

目标应用程序在运行过程中(已与操作系统建立binder连接)，即检测当前应用场景是否属于该场景列表，若属于，目标应用程序则获取当前运行场景(即匹配的预设应用场景)对应的场景标识，并进一步采集当前运行场景下的应用运行参数；若不属于，目标应用程序则继续监测当前应用场景，而不采集应用运行参数。其中，该应用运行参数包括操作系统无法获取到的一系列指标参数。

其中，不同类型应用程序采集的应用运行参数可以相同(比如，由操作系统开发商统一制定)，或者，不同类型应用程序采集的应用运行参数也可以不同。

比如，当目标应用程序为即时通信类应用程序时，采集的应用运行参数包括帧率、加载速度、丢帧率、下载速率、网络延迟中的至少一种；当目标应用程序为游戏类应用程序时，采集的应用运行参数中还可以包括游戏画面质量、游戏画面分辨率、游戏模型质量以及游戏画面内模型数量等等。

步骤803，目标应用程序通过binder连接，向操作系统发送包含应用场景标识和应用运行参数的应用运行信息。

完成应用运行参数采集后，目标应用程序即将应用场景标识和应用运行参数作为应用运行信息，发送至操作系统。

可选的，目标应用程序在检测到处于预设应用场景后，持续采集应用运行参数，并持续向操作系统发送包含应用场景标识和应用运行参数的应用运行信息。

可选的，对于采集到的应用运行信息，目标应用程序还需要对其进行数据整理，比如合并重复信息、删除冗余信息。同时，目标应用程序还可以根据应用场景或应用运行参数的重要程度，设置应用运行信息的发送优先级，从而优先发送重要应用场景下的应用运行信息，或包含重要应用运行参数(比如帧率以及丢帧率)的应用运行信息，过滤或延迟发送非重要应用场景下的应用运行信息。

可选的，当不同类型应用程序对应的应用场景标识相同时，比如，即时通信类应用程序中应用场景标识“001”对应“视频聊天场景”，而游戏类应用程序中应用场景标识“001”则对应“游戏主界面场景”，该应用运行信息中还包括应用类型标识，操作系统即根据应用类型标识和应用场景标识区分不同类型应用程序下的应用场景。

可选的，该应用运行信息中还包括采集应用运行参数时的时间戳，根据该时间戳，操作系统即可确定应用运行信息是否及时发送，并确定应用运行信息的发送时序，从而避免应用运行信息发送超时以及发送时序颠倒的问题。

需要说明的是，在实际应用过程中，该应用运行信息中还可以根据需求携带其他信息，比如应用程序标识，本申请实施例并不对应用运行信息中包含的具体信息进行限定。

可选的，目标应用程序采用数据包的形式发送应用运行信息，且数据包的格式预先与操作系统进行约定。其中，数据包的格式可以为Java脚本对象标记(JavaScriptObject Notation，JSON)、协议缓冲区(ProtocolBuffer，Protobuf)或自定义格式等。

步骤804，操作系统接收应用运行信息。

在一种可能的实施方式中，操作系统接收到目标应用程序发送的数据包后，采用预先约定的数据包格式对该数据包进行解析，从而得到其中包含的应用运行信息。

步骤805，操作系统确定应用场景标识对应的第一运行指标，第一运行指标是在应用场景标识对应的应用场景下，与应用运行质量相关的指标。

由于评价同一应用程序在不同应用场景下运行质量的指标不同，因此为了确定目标应用程序在当前应用场景下的运行质量是否符合预期，操作系统根据应用场景标识，确定当前应用场景下的第一运行指标。

可选的，第一运行指标是当前应用场景下，为达到预期运行质量，目标应用程序所需达到的指标。其中，第一运行指标包括(最低)帧率指标、(最低)加载速度指标、(最高)丢帧率指标、(最低)内存指标、(最低)下载速率指标和(最高)网络延迟指标中的至少一种。

可选的，当应用场景标识对应的应用场景为数据加载场景时，第一运行指标包括加载速度指标和内存指标中的至少一种。

其中，数据加载场景为目标应用程序加载本地数据的场景，且不同类型应用程序对应的本地数据可能不同，比如，对于游戏类应用程序，该本地数据可以包括多媒体数据、游戏模型数据、游戏场景数据等等；对于导航类应用程序，该本地数据可以包括导航语音数据、地图数据等等。凡是涉及加载本地数据的场景均可以被归为数据加载场景，本申请实施例并不对此进行限定。

可选的，当应用场景标识对应的应用场景为数据传输场景时，第一运行指标包括下载速率指标和网络延迟指标的至少一种。

其中，数据传输场景为目标应用程序通过网络进行数据传输的场景。对于不同类型的应用程序，该数据传输场景可能不同。比如，对于即时通信类应用程序，该数据传输场景可以为文件传输场景、语音场景、视频场景或网络多媒体浏览场景等等；对于游戏类应用程序，该数据传输场景可以为游戏数据包更新场景、在线游戏场景等等。凡是涉及网络数据传输的场景均可以被归为数据传输场景，本申请实施例并不对此进行限定。

由于可以采用传输速度和传输延迟衡量数据传输场景下的运行质量，因此，当应用场景为动态画面显示场景时，操作系统确定第一运行指标为下载速率指标和网络延迟指标中的至少一种。

可选的，当应用场景标识对应的应用场景为动态画面显示场景时，第一运行指标包括帧率指标、丢帧率指标和网络延迟指标中的至少一种。

其中，动态画面显示场景为涉及动态图像渲染显示的场景，对于不同类型的应用程序，该动态图像可能不同。比如，对于即时通信类应用程序，该动态图像可以为短视频、动态表情、视频会话等等；对于游戏类应用程序，该动态图像可以为过场动画、动态游戏场景等等。凡是涉及动态图像显示的场景均可以被归为动态画面显示场景，本申请实施例并不对此进行限定。

由于画面流畅度、画面质量和画面延迟可以衡量动态画面显示场景下的运行质量，因此，当应用场景为动态画面显示场景时，操作系统确定第一运行指标为帧率指标、丢帧率指标和网络延迟指标中的至少一种。

在一种可能的实施方式中，操作系统中预先设置有不同应用场景标识与第一运行指标之间的对应关系，操作系统即基于该对应关系确定当前应用场景下的第一运行指标。示意性，以游戏类应用程序为例，该对应关系如表一所示。

表一

应用场景	应用场景标识	第一运行指标
			游戏加载场景	001	加载速度指标：20M/s，内存指标：1G
游戏对战场景	002	帧率指标：60fps；网络延迟指标：50ms；丢帧率指标：5％
			游戏更新场景	003	下载速度指标：250k/s

步骤806，若应用运行参数未达到第一运行指标，操作系统确定第一运行指标对应的第一目标系统资源。

进一步的，操作系统通过分析目标应用程序当前的应用运行参数与查询到的第一运行指标，确定当前应用场景下目标应用程序的运行质量是否达到预期。

可选的，当应用运行参数未达到第一运行指标时，操作系统确定目标应用程序的运行质量不佳，需要优化系统资源配置；当应用运行参数达到第一运行指标时，操作系统确定目标应用程序的运行质量良好，无需优化系统资源配置。

当分析发现目标应用程序需要优化系统资源配置时，操作系统确定第一运行指标对应的第一目标系统资源，以便后续制定针对第一目标系统资源的配置优化策略，其中，该第一目标系统资源即为与第一运行指标相关的系统资源。

在一种可能的实施方式中，操作系统中预先设置有不同运行指标与系统资源之间的对应关系，操作系统即基于该对应关系确定第一运行指标对应的第一目标系统资源。示意性，该对应关系如表二所示。

表二

运行指标	系统资源
		帧率	CPU资源、GPU资源
加载速度	CPU资源、磁盘资源、内存资源
		丢帧率	CPU资源、GPU资源、网络资源
下载速率	网络资源
		网络延迟	网络资源

在一个示意性的例子中，目标应用程序为游戏类应用程序，且目标应用程序运行至游戏对战场景时，采集包含当前帧率(55fps)、当前丢帧率(2％)和当前网络延迟(100ms)的应用运行参数，并发送至操作系统。操作系统根据目标应用程序所处的应用场景，确定该游戏对战场景对应的第一运行指标包括帧率指标(60fps)、网络延迟指标(50ms)和丢帧率指标(5％)。由于当前帧率小于帧率指标，且当前网络延迟大于网络延迟指标，因此，操作系统确定需要对帧率和网络延迟进行优化，并进一步确定基于表二所示的对应关系，确定需要优化的第一目标系统资源包括CPU资源、GPU资源和网络资源。

步骤807，操作系统根据第一目标系统资源确定第一资源配置策略，第一资源配置策略指上调第一目标系统资源性能的策略。

确定出需要优化的系统资源后，操作系统进一步制定出用于上调第一目标系统资源性能的第一资源配置策略。

可选的，操作系统确定出的第一资源配置策略中还包括系统资源上调量。其中，当待上调的系统资源为CPU资源时，该系统资源上调量包括CPU核心数量、CPU最高频率、CPU最低频率的至少一种；当待上调的系统资源为GPU资源时，该系统资源上调量包括GPU核心数量、GPU最高频率、GPU最低频率、的至少一种；当待上调的系统资源为内存资源时，该系统资源上调量包括内存带宽最大值和内存带宽最小值中的至少一种；当待上调的系统资源为磁盘资源时，该系统资源上调量包括磁盘读写最低读写速度和磁盘最高读写速度中的至少一种；当待上调的系统资源为网络资源时，该系统资源上调量包括网络吞吐量、网络延迟率和网络功耗中的至少一种；当待上调的系统资源为无线连接资源(比如蓝牙、红外等等)时，该系统资源上调量包括无线连接强度。

针对系统资源上调量的确定方式，在一种可能的实施方式中，该系统资源上调量为固定值，操作系统每进行一次上调后，即检测目标应用程序当前的应用运行参数是否达到第一运行指标，若达到，则停止上调，若未达到，则根据系统资源上调量进行上调。

在其他可能的实施方式中，操作系统中存储有第一运行指标对应的第一系统资源性能参数，当目标应用程序当前的应用运行参数未达到第一运行指标时，操作系统即根据当前系统资源性能参数和第一系统资源性能参数确定系统资源上调量。

示意性的，结合步骤806中的示例，操作系统确定出的第一资源配置策略为：增加启用1个CPU核心、增加启用1个CPU核心以及降低网络延迟50ms。

步骤808，操作系统根据第一资源配置策略为目标应用程序分配系统资源。

进一步的，操作系统根据确定出的第一资源配置策略为目标应用程序分配系统资源，从而通过优化系统资源配置的方式，使得目标应用程序在当前应用场景下的应用运行参数达到第一运行指标，即达到预期运行质量。

本实施例中，当运行至预设应用场景时，目标应用程序向操作系统发送包含应用场景标识和应用运行参数的应用运行信息，以便操作系统根据该应用运行参数，确定目标应用程序的当前应用场景下的运行质量；同时，在运行质量不佳的情况下，操作系统能够基于与该应用场景相关的系统资源制定资源配置策略，从而根据资源配置策略对系统资源进行优化，进而达到优化该应用场景下目标应用程序运行质量的效果。

目标应用程序采集的应用运行参数中，除了包含与运行质量相关的参数外，还包含部分与运行质量无关的参数，因此，为了在保证目标应用程序运行质量的前提下，降低终端的功耗，在一种可能的实施方式中，操作系统下调无关运行参数对应系统资源的性能。在图8的基础上，如图9所示，上述步骤804之后还可以包括如下步骤。

步骤809，操作系统确定应用场景标识对应的第二运行指标，第二运行指标是在应用场景标识对应的应用场景下，与应用运行质量无关的指标。

由于并非所有运行指标都与目标应用程序在当前应用场景下的应用运行质量相关，因此，操作系统根据应用场景标识确定与应用运行质量相关的第一运行指标的同时，根据该应用场景标识确定与应用运行质量无关的第二运行指标。

可选的，对于同一应用程序的不同应用场景，该第二运行指标不同。其中，第二运行指标包括(最低)帧率指标、(最低)加载速度指标、(最高)丢帧率指标、(最低)内存指标、(最低)下载速率指标和(最高)网络延迟指标中的至少一种。

可选的，当应用场景标识对应的应用场景为数据加载场景时，第二运行指标包括帧率指标、丢帧率指标、下载速率指标和网络延迟指标中的至少一种。

由于数据加载场景下的运行质量与画面质量、画面流畅度以及网络状态无关，因此，应用场景为数据加载场景时，操作系统确定第二运行指标包括帧率指标、丢帧率指标、下载速率指标和网络延迟指标中的至少一种。

可选的，当应用场景标识对应的应用场景为数据传输场景时，第二运行指标包括帧率指标、丢帧率指标和内存指标中的至少一种。

由于数据传输场景下的运行质量与画面质量、画面流畅度以及内存大小无关，因此，当应用场景为数据传输场景时，操作系统确定第二运行指标包括帧率指标、丢帧率指标和内存指标中的至少一种。

在一种可能的实施方式中，操作系统中预先设置有不同应用场景标识与第二运行指标之间的对应关系，操作系统即基于该对应关系确定当前应用场景下的第二运行指标。示意性，以游戏类应用程序为例，该对应关系如表三所示。

表三

应用场景	应用场景标识	第二运行指标
			游戏加载场景	001	帧率指标:30fps；丢帧率指标：10％
游戏对战场景	002	-
			游戏更新场景	003	加载速度指标：10M/s；内存指标：1G

步骤810，若应用运行参数优于第二运行指标，操作系统确定第二运行指标对应的第二目标系统资源。

进一步的，操作系统通过分析目标应用程序当前的应用运行参数与查询到的第二运行指标，确定能够在下调部分系统资源性能的情况下，保证目标应用程序正常运行。

可选的，当目标应用程序当前的应用运行参数优于(超过)第二运行指标时，操作系统确定能够下调相应系统资源的性能；当第二运行指标低于目标应用程序当前的应用运行参数时，操作系统确定需要上调相应系统资源的性能。

当分析发现能够下调目标应用程序的部分系统资源时，操作系统确定第二运行指标对应的第二目标系统资源，以便后续指定针对第二目标系统资源的配置优化策略。

在一种可能的实施方式中，操作系统基于表二所示的对应关系，确定出第二运行指标对应的第二目标系统资源。

在一个示意性的例子中，目标应用程序为游戏类应用程序，且目标应用程序运行至游戏加载场景时，采集包含当前帧率(60fps)、当前丢帧率(0％)和当前网络延迟(100ms)的应用运行参数，并发送至操作系统。操作系统根据目标应用程序所处的应用场景，确定该游戏对战场景对应的第二运行指标包括帧率指标(30fps)、网络延迟指标(100ms)和丢帧率指标(10％)。由于当前帧率大于帧率指标，且当前丢帧率低于丢帧率指标，因此，操作系统基于表二所示的对应关系，确定能够下调的第二目标系统资源为GPU资源。

步骤811，操作系统根据第二目标系统资源确定第二资源配置策略，第二资源配置策略指下调第二目标系统资源性能的策略。

确定出可以下调的系统资源后，操作系统进一步制定出用于下调第二目标系统资源性能的第二资源配置策略。

可选的，操作系统确定出的第二资源配置策略中还包括系统资源下调量。

针对系统资源下调量的确定方式，在一种可能的实施方式中，操作系统中存储有第二运行指标对应的第二系统资源性能指标，当目标应用程序当前的应用运行参数优于到第二运行指标时，操作系统即根据当前系统资源性能和第二系统资源性能指标确定系统资源下调量，使得下调后系统资源性能等于第二系统资源性能指标

示意性的，结合步骤810中的示例，操作系统确定出的第二资源配置策略为：关闭1个GPU核心。

步骤812，操作系统根据第二资源配置策略为目标应用程序分配系统资源。

进一步的，操作系统根据确定出的第二资源配置策略为目标应用程序分配系统资源，从而通过优化系统资源配置的方式，降低部分不影响运行质量的系统资源的性能，达到了降低终端功耗的效果。

本实施例中，操作系统通过确定与应用运行质量无关的运行指标，并针对该运行指标制定相应的系统资源性能下调策略，在保证应用程序运行质量的同时，进一步降低终端的功耗。

由于终端中可能安装并运行有多个内嵌binder通讯模块的应用程序，且操作系统可能同时与多个应用程序建立连接。为了保证前台应用程序的运行质量，在一种可能的实施方式中，在图8的基础上，如图10所示，步骤803之后还包括步骤813。

步骤813，操作系统获取前台应用的前台应用标识。

在一种可能的实现方式中，如图4所示，应用框架层250与接口通信系统242之间建立有Binder连接，操作系统即从应用框架层250处获取前景应用信息，该前景应用信息中即包含前台应用标识。

步骤814，操作系统检测目标应用程序的应用标识与前台应用标识是否一致。

获取到前台应用标识后，操作系统即检测目标应用程序的应用标识与前台应用标识是否一致，若两者一致，则确定发送应用运行信息的目标应用程序正在前台运行，从而执行步骤804；若两者不一致，则确定发送应用运行信息的目标应用程序在后台运行，并执行步骤815。

步骤815，若目标应用程序的应用标识与前台应用标识不一致，操作系统则不响应应用运行信息。

当目标应用程序未在前台运行，操作系统则不响应目标应用程序发送的应用运行信息(继续维持与目标应用程序之间的连接)，并优先响应前台应用程序发送的应用运行信息。

进一步的，当运行在前台的目标应用程序切换至后台时，操作系统执行步骤816。

步骤816，当由前台运行切换至后台运行时，目标应用程序停止通过binder连接向操作系统发送应用运行信息。

可选的，为了避免长时间占用与操作系统之间的数据通道，目标应用程序由前台运行切换至后台运行时，自动停止向操作系统发送应用运行信息，并维持与操作系统之间的连接。

本实施例中，操作系统中增加了前台应用检测机制，实现仅为前台运行的目标应用程序提供系统资源配置优化服务。

请参考图11，其示出了本申请一个实施例提供的资源配置装置的结构框图。该资源配置装置可以通过软件、硬件或者两者的结合实现成为终端的全部或一部分。该装置包括：目标应用程序模块1110和操作系统模块1120。

目标应用程序模块1110，用于通过与所述操作系统之间的粘合binder连接，向所述操作系统发送应用运行信息，所述应用运行信息用于表征所述目标应用程序所处的运行状态；

操作系统模块1120，用于接收所述应用运行信息；

所述操作系统模块1120，用于根据所述应用运行信息确定资源配置策略，所述资源配置策略指为所述运行状态下所述目标应用程序分配系统资源的策略；

所述操作系统模块1120，用于根据所述资源配置策略为所述目标应用程序分配系统资源。

可选的，目标应用程序模块1110。用于：

调用binder接口函数与所述操作系统的binder接口建立所述binder连接，所述binder接口函数由所述操作系统的开发者提供；

若当前应用场景为预设应用场景，则获取所述预设应用场景对应的应用场景标识，并采集当前应用场景下的应用运行参数；

通过所述binder连接，向所述操作系统发送包含所述应用场景标识和所述应用运行参数的所述应用运行信息。

可选的，操作系统模块1120，用于：

确定所述应用场景标识对应的第一运行指标，所述第一运行指标是在所述应用场景标识对应的应用场景下，与应用运行质量相关的指标；

若所述应用运行参数未达到所述第一运行指标，确定所述第一运行指标对应的第一目标系统资源；

根据所述第一目标系统资源确定第一资源配置策略，所述第一资源配置策略指上调第一目标系统资源性能的策略。

可选的，当所述第一运行指标为帧率指标时，所述第一目标系统资源包括中央处理器CPU资源和图形处理器GPU资源中的至少一种；

当所述第一运行指标为加载速度指标时，所述第一目标系统资源包括CPU资源、磁盘资源和内存资源中的至少一种；

当所述第一运行指标为丢帧率指标时，所述第一目标系统资源包括CPU资源、GPU资源和网络资源中的至少一种；

当所述第一运行指标为下载速率指标或网络延迟指标时，所述第一目标系统资源至少包括网络资源。

可选的，操作系统模块1120，用于：

确定所述应用场景标识对应的第二运行指标，所述第二运行指标是在所述应用场景标识对应的应用场景下，与应用运行质量无关的指标；

若所述应用运行参数优于所述第二运行指标，确定所述第二运行指标对应的第二目标系统资源；

根据所述第二目标系统资源确定第二资源配置策略，所述第二资源配置策略指下调第二目标系统资源性能的策略。

可选的，当所述第二运行指标为帧率指标时，所述第二目标系统资源包括中央处理器CPU资源和图形处理器GPU资源中的至少一种；

当所述第二运行指标为加载速度指标时，所述第二目标系统资源包括CPU资源、磁盘资源和内存资源中的至少一种；

当所述第二运行指标为丢帧率指标时，所述第二目标系统资源包括CPU资源、GPU资源和网络资源中的至少一种；

当所述第二运行指标为下载速率指标或网络延迟指标时，所述第二目标系统资源至少包括网络资源。

可选的，操作系统模块1120，用于：

获取前台应用的前台应用标识；

若所述目标应用程序的应用标识与所述前台应用标识一致，则执行所述根据所述应用运行信息确定资源配置策略的步骤；

若所述目标应用程序的应用标识与所述前台应用标识不一致，则不响应所述应用运行信息。

可选的，操作系统模块1120，用于：

获取所述目标应用程序的应用标识；

若所述目标应用程序的应用标识属于预设应用标识列表，则执行所述根据所述应用运行信息确定资源配置策略的步骤，所述预设应用标识列表中包含支持进行资源配置的应用程序的应用标识；

若所述目标应用程序的应用标识不属于预设应用标识列表，则不响应所述应用运行信息。

可选的，目标应用程序模块1110，用于：

当由前台运行切换至后台运行时，停止通过所述binder连接向所述操作系统发送所述应用运行信息。

可选的，操作系统模块1120，用于当接收到所述目标应用程序的进程结束信号时，清理与所述目标应用程序之间的binder连接。

综上所述，本申请实施例提供的资源配置装置中，目标应用程序通过预先与操作系统建立binder连接，，使得目标应用程序能够通过该Sbinder连接，向操作系统发送自身的应用运行信息，以便操作系统基于应用运行信息制定相应的资源配置策略，从而根据该资源配置策略为目标应用程序分配相应的系统资源；相较于单纯提升终端的硬件性能，本实施例中的操作系统可以针对应用程序所处的运行状态，针对性地为其分配相应系统资源，使得应用程序在不同运行状态下均能够达到良好的运行效果，并降低对终端硬件的依赖。

另外，操作系统基于预设应用标识列表实现应用程序合法性检测，从而避免与内嵌SDK的非法应用程序进行通信，提高了操作系统的安全性。

本实施例中，当运行至预设应用场景时，目标应用程序向操作系统发送包含应用场景标识和应用运行参数的应用运行信息，以便操作系统根据该应用运行参数，确定目标应用程序的当前应用场景下的运行质量；同时，在运行质量不佳的情况下，操作系统能够基于与该应用场景相关的系统资源制定资源配置策略，从而根据资源配置策略对系统资源进行优化，进而达到优化该应用场景下目标应用程序运行质量的效果。

本实施例中，操作系统通过确定与应用运行质量无关的运行指标，并针对该运行指标制定相应的系统资源性能下调策略，在保证应用程序运行质量的同时，进一步降低终端的功耗。

本实施例中，操作系统中增加了通前台应用检测机制，实现仅为前台运行的目标应用程序提供系统资源配置优化服务。

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

本申请实施例还提供了一种计算机程序产品，该计算机程序产品存储有至少一条指令，所述至少一条指令由所述处理器加载并执行以实现如上各个实施例所述的资源配置方法。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

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

Claims (13)

1.一种资源配置方法，其特征在于，所述方法应用于终端，所述终端运行有操作系统和至少一个应用程序，所述方法包括：

目标应用程序通过与所述操作系统之间的粘合binder连接，向所述操作系统发送应用运行信息，所述应用运行信息用于表征所述目标应用程序所处的运行状态；

所述操作系统接收所述应用运行信息；

所述操作系统根据所述应用运行信息确定资源配置策略，所述资源配置策略指为所述运行状态下所述目标应用程序分配系统资源的策略；

所述操作系统根据所述资源配置策略为所述目标应用程序分配系统资源。

2.根据权利要求1所述的方法，其特征在于，所述目标应用程序通过与所述操作系统之间的binder连接，向所述操作系统发送应用运行信息，包括：

所述目标应用程序调用binder接口函数与所述操作系统的binder接口建立所述binder连接，所述binder接口函数由所述操作系统的开发者提供；

若当前应用场景为预设应用场景，所述目标应用程序则获取所述预设应用场景对应的应用场景标识，并采集当前应用场景下的应用运行参数；

所述目标应用程序通过所述binder连接，向所述操作系统发送包含所述应用场景标识和所述应用运行参数的所述应用运行信息。

3.根据权利要求2所述的方法，其特征在于，所述操作系统根据所述应用运行信息确定资源配置策略，包括：

所述操作系统确定所述应用场景标识对应的第一运行指标，所述第一运行指标是在所述应用场景标识对应的应用场景下，与应用运行质量相关的指标；

若所述应用运行参数未达到所述第一运行指标，所述操作系统确定所述第一运行指标对应的第一目标系统资源；

所述操作系统根据所述第一目标系统资源确定第一资源配置策略，所述第一资源配置策略指上调第一目标系统资源性能的策略。

4.根据权利要求3所述的方法，其特征在于，

当所述第一运行指标为帧率指标时，所述第一目标系统资源包括中央处理器CPU资源和图形处理器GPU资源中的至少一种；

当所述第一运行指标为加载速度指标时，所述第一目标系统资源包括CPU资源、磁盘资源和内存资源中的至少一种；

当所述第一运行指标为丢帧率指标时，所述第一目标系统资源包括CPU资源、GPU资源和网络资源中的至少一种；

当所述第一运行指标为下载速率指标或网络延迟指标时，所述第一目标系统资源至少包括网络资源。

5.根据权利要求2所述的方法，其特征在于，所述操作系统根据所述应用运行信息确定资源配置策略，包括：

所述操作系统确定所述应用场景标识对应的第二运行指标，所述第二运行指标是在所述应用场景标识对应的应用场景下，与应用运行质量无关的指标；

若所述应用运行参数优于所述第二运行指标，所述操作系统确定所述第二运行指标对应的第二目标系统资源；

所述操作系统根据所述第二目标系统资源确定第二资源配置策略，所述第二资源配置策略指下调第二目标系统资源性能的策略。

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

当所述第二运行指标为帧率指标时，所述第二目标系统资源包括中央处理器CPU资源和图形处理器GPU资源中的至少一种；

当所述第二运行指标为加载速度指标时，所述第二目标系统资源包括CPU资源、磁盘资源和内存资源中的至少一种；

当所述第二运行指标为丢帧率指标时，所述第二目标系统资源包括CPU资源、GPU资源和网络资源中的至少一种；

当所述第二运行指标为下载速率指标或网络延迟指标时，所述第二目标系统资源至少包括网络资源。

7.根据权利要求1至6任一所述的方法，其特征在于，所述操作系统接收所述应用运行信息之后，所述方法还包括：

所述操作系统获取前台应用的前台应用标识；

若所述目标应用程序的应用标识与所述前台应用标识一致，所述操作系统则执行所述根据所述应用运行信息确定资源配置策略的步骤；

若所述目标应用程序的应用标识与所述前台应用标识不一致，所述操作系统则不响应所述应用运行信息。

8.根据权利要求1至6任一所述的方法，其特征在于，所述操作系统接收所述应用运行信息之后，所述方法还包括：

所述操作系统获取所述目标应用程序的应用标识；

若所述目标应用程序的应用标识属于预设应用标识列表，所述操作系统则执行所述根据所述应用运行信息确定资源配置策略的步骤，所述预设应用标识列表中包含支持进行资源配置的应用程序的应用标识；

若所述目标应用程序的应用标识不属于预设应用标识列表，所述操作系统则不响应所述应用运行信息。

9.根据权利要求1至6任一所述的方法，其特征在于，所述目标应用程序通过与所述操作系统之间的binder连接，向所述操作系统发送应用运行信息之后，所述方法还包括：

当由前台运行切换至后台运行时，所述目标应用程序停止通过所述binder连接向所述操作系统发送所述应用运行信息。

10.根据权利要求1至6任一所述的方法，其特征在于，所述操作系统根据所述资源配置策略为所述目标应用程序分配系统资源之后，所述方法还包括：

当接收到所述目标应用程序的进程结束信号时，所述操作系统清理与所述目标应用程序之间的所述binder连接。

11.一种资源配置装置，其特征在于，所述装置应用于终端，所述终端运行有操作系统和至少一个应用程序，所述装置包括：

目标应用程序模块，用于通过与所述操作系统之间的粘合binder连接，向所述操作系统发送应用运行信息，所述应用运行信息用于表征所述目标应用程序所处的运行状态；

操作系统模块，用于接收所述应用运行信息；

所述操作系统模块，用于根据所述应用运行信息确定资源配置策略，所述资源配置策略指为所述运行状态下所述目标应用程序分配系统资源的策略；

所述操作系统模块，用于根据所述资源配置策略为所述目标应用程序分配系统资源。

12.一种终端，其特征在于，所述终端包括处理器和存储器；所述存储器存储有至少一条指令，所述至少一条指令用于被所述处理器执行以实现如权利要求1至10任一所述的资源配置方法。

13.一种计算机可读存储介质，其特征在于，所述存储介质存储有至少一条指令，所述至少一条指令用于被处理器执行以实现如权利要求1至10任一所述的资源配置方法。