CN117130772A - 资源调度方法、电子设备及存储介质 - Google Patents

Abstract

本申请实施例提供一种资源调度方法、电子设备及存储介质，涉及终端领域。资源调度方法包括：基于电子设备的焦点窗口，确定应用主场景；在多个应用进程中，确定多个目标进程；根据多个目标进程的进程负载信息，确定多个目标子场景；基于所述多个目标子场景的优先级，确定应用子场景；根据应用主场景和应用子场景，确定应用场景；基于应用场景，获取调度策略；根据调度策略，调整电子设备的性能参数。本申请实施例可以确定更符合用户需求的应用场景，提高了确定调度策略的准确性，能够更好地对电子设备进行资源调度，可以在保证应用进程能够流畅运行的情况下，尽可能降低电子设备的功耗，从而提升电子设备的续航能力。

Description

资源调度方法、电子设备及存储介质

技术领域

本申请涉及终端领域，尤其涉及一种资源调度方法、电子设备及存储介质。

背景技术

随着终端设备性能的提升，终端设备上可以安装越来越多应用程序。随着应用程序的增多，终端设备的功耗也随之增加。但是由于电池容量的限制，导致终端设备的续航能力降低。如果将终端设备设置为节能模式，对终端设备的功耗进行限制，可以提高终端设备的续航能力，但是对终端设备的功耗进行限制，又可能会导致应用程序无法正常的运行，出现卡顿情况。因此，需要对终端设备进行更精准的资源调度，在保证终端设备正常运行的同时尽可能提高终端设备的续航时间。

发明内容

本申请实施例公开了一种资源调度方法、电子设备及存储介质，可以解决不能对终端设备进行精准的资源调度的问题。

本申请第一方面公开了一种资源调度方法，应用于电子设备，所述电子设备运行有多个应用进程，所述方法包括：基于所述电子设备的焦点窗口，确定应用主场景；在所述多个应用进程中，确定多个目标进程；根据所述多个目标进程的进程负载信息，确定多个目标子场景；基于所述多个目标子场景的优先级，确定应用子场景；根据所述应用主场景和所述应用子场景，确定应用场景；基于所述应用场景，获取调度策略；根据所述调度策略，调整所述电子设备的性能参数。上述方法，可以在基于对应用程序对应的应用进程的监控，确定用户在使用电子设备过程中的多个目标子场景，并基于多个目标子场景的优先级，确定最符合用户需求的应用子场景，从而使得根据应用子场景和应用主场景，得到的应用场景更符合用户的实际需求，接着结合确定的应用场景，确定电子设备的调度策略。根据调度策略，控制目标硬件，从而保证应用进程能够流畅运行。此外，由于确定的应用场景尽可能符合用户的需求，提高了确定调度策略的准确性，可以更好地对电子设备进行资源调度，可以在保证应用进程能够流畅运行的情况下，尽可能降低电子设备的功耗，从而提升电子设备的续航能力。

在一些可选的实施方式中，所述在所述多个应用进程中，确定多个目标进程之后，所述方法还包括：对所述多个目标进程的进程负载信息进行监控，包括：在所述多个目标进程中，确定第一目标进程和/或第二目标进程；对所述第一目标进程的进程负载信息进行监控；和/或，取消对所述第二目标进程的进程负载信息的监控。上述方法，可以在多个应用进程中确定需要进行监控的应用进程以及需要取消监控的应用进程。

在一些可选的实施方式中，所述在所述多个目标进程中，确定第一进程和/或第二进程，包括：在所述多个目标进程中，将进程类型为进程创建的目标进程确定为第一目标进程；和/或，在所述多个目标进程中，将进程类型为进程退出的目标进程确定为第二目标进程。上述方法，可以在多个应用进程中快速地确定需要进行监控的应用进程以及需要取消监控的应用进程。

在一些可选的实施方式中，所述在所述多个目标进程中，将进程类型为进程创建的目标进程确定为第一进程，包括：在所述多个目标进程中，将进程类型为进程创建的目标进程确定为第一进程；基于所述第一进程的获取顺序和所述第一进程对应的进程名称，将进程名称为首次出现的第一进程，确定为所述第一目标进程。上述方法，可以实现对同名的应用进程的监控。

在一些可选的实施方式中，所述在所述多个目标进程中，将进程类型为进程退出的目标进程确定为第二目标进程包括：在所述多个目标进程中，将进程类型为进程退出的目标进程确定为第二进程；将不存在同名进程的第二进程，确定为所述第二目标进程。上述方法，可以在存在同名的应用进程的情况下，避免因多个同名进程中的一个应用进程退出，导致多个同名进程中剩余的应用进程也不能正常被监控的情况发生，提高了监控的准确率。

在一些可选的实施方式中，所述方法还包括：确定所述多个目标进程中每个目标进程对应的进程名称，得到多个进程名称；生成每个进程名称的第一计数器；确定所述每个进程名称的第一计数器的数值，包括：当获取到任一进程类型为进程创建的目标进程时，控制所述目标进程对应的进程名称的第一计数器的数值加1；在所述多个目标进程中，当获取到任一进程类型为进程退出的目标进程时，控制所述目标进程对应的进程名称的第一计数器的数值减1。上述方法，生成进程名称的第一计数器，基于第一计数器的数值，可以后续提高确定第二目标进程的效率。

在一些可选的实施方式中，所述将不存在同名进程的第二目标进程，确定为第二进程，包括：若任一第二进程的进程名称对应的计数器的数值为0，将所述第二进程确定为所述第二目标进程。上述方法，基于第二进程的进程名称的第一计数器，可以准确地确定第二目标进程，提高了确定第二目标进程的准确率。

在一些可选的实施方式中，所述在所述多个应用进程中，确定多个目标进程，包括：基于预设的标志位在配置表中确定目标应用程序；将所述多个应用进程中与目标应用程序匹配的应用进程，确定为目标进程，得到所述多个目标进程。上述方法，预设的标志位在配置表中确定目标应用程序，并基于目标应用程序与应用程序的匹配结果确定目标进程，可以提高确定的目标进程的准确率。

在一些可选的实施方式中，所述确定多个目标进程之后，所述方法还包括：基于定时器，按照预设时间间隔，查询所述多个目标进程中是否有一目标进程退出；若确定一目标进程退出，退出对所述目标进程的进程负载信息的监控。上述方法，可以通过定时器，实现了按照预设时间间隔查询进程管理容器中应用进程对应的进程事件是否存在，从而确定应用进程是否退出，使得进程管理容器可以克服进程退出消息为异步传输带来的弊端，清楚地确定其储存的应用进程当前是否退出，尽可能避免进程管理容器中将已退出的应用进程确定为没退出的应用进程的情况发生；同时，可以及时地确认已退出的应用进程，进而可以及时地控制进程负载监控探针停止对退出应用进程的监控，减少了不必要的能耗。

在一些可选的实施方式中，所述确定应用子场景后，所述方法还包括：确定所述多个目标子场景中，是否有一目标子场景对应的进程是否退出；若有一目标子场景对应的进程退出，将进程退出的目标子场景确定为失效子场景；基于所述多个目标子场景中除所述失效子场景外的剩余目标子场景的优先级，重新确定应用子场景。上述方法，可以在一目标子场景退出后，重新确定应用子场景的优先级。

在一些可选的实施方式中，所述根据所述多个目标进程的进程负载信息，确定多个目标子场景，包括：确定目标进程是否存在对应的标记规则；若所述目标进程存在对应的标记规则，确定所述标记规则对应的阈值是否为0；若所述标记规则对应的阈值为0，将所述标记规则对应的子场景确定为所述目标进程对应的目标场景；若所述标记规则对应的阈值不为0且所述目标进程的进程负载信息与所述标记规则对应的阈值匹配时，将所述标记规则对应的子场景确定为所述目标进程对应的目标场景。上述方法，在一目标进程与一标记规则匹配的情况下，基于一标记规则对应的阈值的两种不同情况，使用不同的方法确定目标场景，可以准确地确定目标进程对应的目标场景，提高确定目标场景的准确率。

在一些可选的实施方式中，所述方法还包括：根据所述目标进程对应的标记规则对所述目标进程的进程负载信息的标记，在所述进程负载信息中确定目标值；当所述目标值大于所述标记规则对应的阈值时，确定所述目标进程的进程负载信息与所述标记规则对应的阈值匹配。上述方法，基于标记规则的标记，可以在准确地在进程负载信息中确定目标值，从而可以更准确地确定目标进程是否与其对应的标记规则匹配。

在一些可选的实施方式中，所述方法还包括：确定所述多个目标进程中每个目标进程对应的进程名称，得到多个进程名称；生成每个进程名称的第二计数器；确定所述每个进程名称的第二计数器的数值，包括：当所述目标值大于所述标记规则对应的阈值时，控制所述目标进程的进程名称对应的第二计数器清零；当所述目标值小于或等于所述标记规则对应的阈值时，控制所述目标进程的进程名称对应的第二计数器加1；当一进程名称对应的第二计数器的数值达到预设阈值时，确定退出所述进程名称对应的目标进程的目标子场景。上述方法，基于进程名称对应的第二计数器的数值，可以准确地判断是否退出一进程名称对应的目标进程的目标子场景，从而后续根据确定的目标子场景确定应用子场景时，可以使得计算出的应用子场景更符合用户的需求。

本申请第二方面公开了一种计算机可读存储介质，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如第一方面所述的资源调度方法。

本申请第三方面公开了一种电子设备，所述电子设备包括处理器和存储器，所述存储器用于存储指令，所述处理器用于调用所述存储器中的指令，使得所述电子设备执行如第一方面所述的资源调度方法。

应当理解地，上述提供的第二方面所述的计算机可读存储介质，第三方面所述的电子设备，均与上述第一方面的方法对应，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

附图说明

图1是本申请实施例提供的电子设备的结构示意图。

图2是本申请实施例提供的一种电子设备的软件结构框图。

图3是本申请实施例提供的一种电子设备对资源进行调度的软件及硬件的工作流程示意图。

图4是本申请实施例提供的一种资源调度方法的流程示意图。

图5为本申请实施例提供的一种系统探针模块对应用进程进行监控方法的流程示意图。

图6是本申请实施例提供的一种系统探针模块对应用进程进行监控方法的流程示意图。

图7为本申请实施例提供的一种系统探针模块对应用进程进行监控方法的示意图。

图8为本申请实施例提供的一种场景计算模块根据进程信息确定应用场景方法的示意图。

具体实施方式

以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本申请实施例的描述中，“示例性”、“或者”、“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性”、“或者”、“例如”等词旨在以具体方式呈现相关概念。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请中的技术领域的技术人员通常理解的含义相同。本申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请。应理解，本申请中除非另有说明，“/”表示或的意思。例如，A/B可以表示A或B。本申请中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系。例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B三种情况。“至少一个”是指一个或者多个。“多个”是指两个或多于两个。例如，a、b或c中的至少一个，可以表示：a，b，c，a和b，a和c，b和c，a、b和c七种情况。应当理解的是，本文的流程图中所示步骤的顺序可以改变，某些也可以省略。

为了下述各实施例的描述清楚简洁，首先给出相关概念或技术的简要介绍：

焦点窗口(focus window)，指拥有焦点的窗口。焦点窗口是唯一可以接收键盘输入的窗口。焦点窗口的确定方式与系统的焦点模式(focus mode)关联。焦点窗口的顶层窗口被称为活动窗口(active window)。同一时间只有一个窗口可以是活动窗口。焦点窗口大概率为用户当前需要使用的窗口。在本申请的一实施例中，可以基于系统的焦点模式，确定焦点窗口。

焦点模式，可用于决定鼠标如何使一个窗口获得焦点。一般地，焦点模式可包括三种，分别为：

(1)点击聚焦(click-to focus)，在这种模式下，鼠标点击的窗口即可获得焦点。即当鼠标点击一个可以获得焦点的窗口的任意位置，即可激活该窗口成为焦点窗口，该窗口便被置于所有窗口的最前面，并接收键盘输入。当鼠标点击其他窗口时，该窗口会失去焦点。

(2)焦点跟随鼠标(focus-follow-mouse)，在这种模式下，鼠标下的窗口可以获取焦点。即当鼠标移到一个可以获得焦点的窗口的范围内，用户不需要点击窗口的某个地方就可以激活这个窗口成为焦点窗口，接收输入(例如，键盘输入)，但该窗口不一定被置于所有窗口的最前面。当鼠标移出这个窗口的范围时，这个窗口也会随之失去焦点。

(3)草率聚焦(sloppy focus)，这种焦点模式与focus-follow-mouse比较类似：当鼠标移到一个可以获得焦点的窗口的范围内，用户不需要点击窗口的某个地方就可以激活这个窗口成为焦点窗口，例如，可以接收键盘输入，但该窗口不一定被置于所有窗口的最前面。与focus-follow-mouse不同的是，当鼠标移出这个窗口范围时，焦点并不会随之改变，只有当鼠标移动到别的可以接收焦点的窗口时，系统焦点才会发生改变。

随着终端设备性能的提升，终端设备上可以安装越来越多应用程序。随着应用程序的增多，终端设备的功耗也随之增加。但是由于电池容量的限制，导致终端设备的续航能力降低。如果将终端设备设置为节能模式，对终端设备的功耗进行限制，可以提高终端设备的续航能力，但是对终端设备的功耗进行限制，又可能会导致应用程序无法正常的运行，出现卡顿情况。因此，需要对终端设备进行更精准的资源调度，在保证终端设备正常运行的同时尽可能提高终端设备的续航时间。

传统的资源调度方案是终端设备统计当前执行的所有任务在一段时间内的负载情况，然后根据统计得到的负载情况对当前执行的所有任务进行资源调度。例如，若当前执行的所有任务的负载较大，则可以增加中央处理器(central processing unit，CPU)的功率。传统的资源调度方案不能根据用户的应用场景进行动态的资源调度，导致CPU在绝大多数应用场景下运行在高性能状态，会造成资源浪费和能耗过高的问题，会导致终端设备的续航时间较差。

为了根据解决不能根据终端设备当前执行任务的负载情况进行更加精准的资源调度的技术问题，本申请提供一种资源调度方法，以实现根据用户的应用场景进行动态的资源调度，进行更精准的资源调度，应用于电子设备。

示例性的，本申请实施例中的电子设备可以是手机、平板电脑、桌面型计算机、膝上型计算机、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobile personalcomputer，UMPC)、上网本，以及蜂窝电话、个人数字助理(personal digital assistant，PDA)、人工智能(artificial intelligence，AI)设备、可穿戴式设备、车载设备、智能家居设备和/或智慧城市设备等电子设备。本申请实施例对该电子设备的具体形态不作特殊限制。电子设备上安装有操作系统，操作系统可以是系统、/> 系统和/>系统中的一种系统或者未示出的其他系统。

为便于说明本申请实施例提供的资源调度方法，下文先结合图1至图3介绍执行资源调度方法的电子设备的硬件结构、软件结构以及软件与硬件之间的工作流。

图1为本申请实施例提供的电子设备的结构示意图。如图1所示，电子设备可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serialbus，USB)接口130，充电管理模块140，电源管理模块141，电池142，无线通信模块150，显示屏160等。

可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。在另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。控制器可以是电子设备的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括I2C接口，集成电路内置音频(inter-integrated circuit sound，I2S)接口，脉冲编码调制(pulsecode modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purpose input/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或USB接口等。

可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。在另一些实施例中，电子设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为电子设备供电。

电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110、内部存储器121、外部存储器、显示屏160和无线通信模块150等器件供电。在一些实施例中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

无线通信模块150可以提供应用在电子设备上的包括无线局域网(WirelessLocal Area Network，WLAN)，蓝牙，全球导航卫星系统(global navigation satellitesystem，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near fieldcommunication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。例如，本申请实施例中，电子设备可以通过无线通信模块150与终端设备(如无线耳机100)建立蓝牙连接。

无线通信模块150可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块150经由天线接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块150还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线转为电磁波辐射出去。

电子设备通过GPU，显示屏160，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏160和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

显示屏160用于显示图像，视频等。该显示屏160包括显示面板。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备的各种功能应用以及数据处理。例如，在本申请实施例中，处理器110可以通过执行存储在内部存储器121中的指令，内部存储器121可以包括存储程序区和存储数据区。

其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universalflashstorage，UFS)等。

上述电子设备的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的系统为例，示例性说明电子设备的软件结构。

图2为本申请实施例的电子设备的软件结构框图。电子设备中的分层架构可以将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将系统分为用户态和驱动模块。其中，用户态包括应用层以及子系统动态链接库。驱动模块自下而上分为固件层、硬件抽象层(hard war eabstraction layer，HAL)、内核和驱动层及执行体。

如图2所示，应用层包括编程、绘图、音乐、视频、游戏、办公、社交等应用程序。应用层还包括环境子系统、场景识别引擎以及调度引擎等。其中，图中仅示出部分应用程序，应用层还可以包括其他应用程序，例如购物应用、浏览器等，本申请不做限定。

环境子系统可以将基本的执行体系统服务的某些子集以特定的形态展示给应用程序，为应用程序提供执行环境。

场景识别引擎可以识别电子设备所处的应用场景，并确定与该应用场景匹配的调度策略。调度引擎可以接收场景识别引擎发送的调度策略，并调度相关的硬件完成该调度策略对应的调度操作。其中，关于场景识别引擎和调度引擎的一些具体内容见后文，在此暂不描述。

子系统动态链接库包括API模块，该API模块包括Windows API，Windows原生API等。其中，Windows API，Windows原生API均可以为应用程序提供系统调用入口及内部函数支持，区别在于Windows原生API为Windows系统原生的API。例如，Windows API可包括user.dll、kernel.dll，Windows原生API可包括ntdll.dll。其中，user.dll是Windows用户界面接口，可用于执行创建窗口、发送消息等操作。kernel.dll用于为应用程序提供访问内核的接口。ntdll.dll是重要的Windows NT内核级文件，描述了windows本地NTAPI的接口。当Windows启动时，ntdll.dll就驻留在内存中特定的写保护区域，使别的程序无法占用这个内存区域。

执行体包括进程管理模块、虚拟内存管理器、安全引用监视器、I/O管理器、Windows管理规范(Windows management instrumentation，WMI)、电源管理器、系统事件驱动(operating system event driver，OsEventDriver)节点、系统与芯片驱动(operatingsystem to System on Chip，OS2SOC)节点等。

进程管理模块用于创建及中止进程和线程。

虚拟内存管理器实现“虚拟内存”。虚拟内存管理器也为高速缓存管理器提供基本的支持。

安全引用监视器可在本地计算机上执行安全策略，它保护了操作系统资源，执行运行时对象的保护和监视。

I/O管理器执行独立于设备的输入/输出，并进一步处理调用适当的设备驱动程序。

电源管理器可管理所有支持电源状态更改的设备的电源状态更改。

系统事件驱动节点可以与内核和驱动层进行交互。例如，与显卡驱动进行交互，在确定存在GPU视频解码事件后，向场景识别引擎上报该GPU视频解码事件。

系统与芯片驱动节点，也可称为驱动模块，可基于调度引擎的调度，调度硬件设备完成调度策略对应的调度操作。例如，系统与芯片驱动节点可以向CPU发送包含调度操作的信息，如调整PL1和PL2的信息，以使CPU调整PL1和PL2。

内核和驱动层包括内核以及设备驱动程序。

内核是对处理器体系结构的抽象，将执行体与处理器体系结构的差异相隔离，保证系统的可移植性。内核可以进行线程安排和调度、陷阱处理和异常调度、中断处理和调度等。

设备驱动程序运行在内核模式下，为I/O系统和相关硬件之间的接口。设备驱动程序可包括显卡驱动、Intel DTT驱动、鼠标驱动、音视频驱动、摄像头驱动、键盘驱动等。例如，显卡驱动可以驱动GPU运行，Intel DTT驱动可以驱动CPU运行。

HAL是一个核心态模块，可以隐藏各种与硬件有关的细节，例如I/O接口、中断控制器以及多处理器通信机制等，为运行Windows的不同硬件平台提供统一的服务接口，实现多种硬件平台上的可移植性。需要说明的是，为了维护Windows的可移植性，Windows内部组件和用户编写的设备驱动程序并不直接访问硬件，而是通过调用HAL中的例程。

固件层可以包括基本输入输出系统(basic input output system，bios)，BIOS是一组固化到计算机主板上一个只读存储器(read only memory，ROM)芯片内的程序，它保存着计算机最重要的基本输入输出的程序、开机后自检程序和系统自启动程序，它可从互补金属氧化物半导体(complementary metal oxide semiconductor，CMOS)中读写系统设置的具体信息。其主要功能是为计算机提供最底层的、最直接的硬件设置和控制。Intel DTT驱动可以通过BIOS向CPU发送指令的。

需要说明的是，本申请实施例仅以系统举例来说明，在其他操作系统中(例如安卓系统，IOS系统等)，只要各个功能模块实现的功能和本申请的实施例类似也能实现本申请的方案。

图3为本申请实施例提供的一种电子设备对资源进行调度的软件及硬件的工作流程示意图。如图3所示，电子设备的应用层中包括场景识别引擎。场景识别引擎包括系统探针模块、场景计算模块及策略管理模块。场景计算模块可分别与系统探针模块及策略管理模块进行交互。

场景计算模块可以向系统探针模块发送获取探针状态的请求。系统探针模块可以获取电子设备的运行状态，并基于场景计算模块获取探针状态的请求，向场景计算模块上报探针状态。系统探针模块可以包括进程监控探针、进程负载监控探针、应用状态探针、音频探针、视频探针。

进程监控探针可以向驱动模块订阅进程事件，根据驱动模块反馈的回调函数确定进程事件。进程事件可包括进程创建事件、进程退出事件、线程创建事件等。在本申请的实施例中，进程监控模块可以向驱动模块中的进程管理模块订阅进程事件。在本申请的一实施例中，进程监控探针可向执行体层的OsEventDriver节点发送订阅进程创建事件的请求，由OsEventDriver节点向驱动模块中进程管理模块转发该请求。进程管理模块可在创建进程后，通过该OsEventDriver节点向进程监控探针反馈回调函数。

进程监控探针还向API模块发送订阅焦点窗口变化事件，API模块可监控电子设备的焦点窗口是否发生变化，并在监控到焦点窗口发生变化时，向进程监控探针反馈回调函数。

进程负载监控探针可以向进程监控探针订阅进程事件，根据驱动模块反馈的回调函数确定进程的负载。进程负载监控探针根据进程名进行目标进程的筛选，再根据进程事件来订阅或退出进程负载监控。

应用状态探针用于监测应用程序的性能和运行情况，可以通过收集应用程序的各种指标数据(如CPU使用率、内存使用量、网络流量等)来评估应用的健康状况和性能表现。应用状态探针可以向驱动模块订阅应用状态，根据驱动模块反馈的回调函数确定应用状态。应用状态可以包括启动状态、关闭状态、后台运行状态、错误状态、卸载状态等状态。

视频状态探针可向驱动模块订阅视频事件，根据驱动模块反馈的回调函数确定电子设备当前存在的视频事件。视频事件可包括GPU解码事件等。例如，视频状态探针可向执行体层的OsEventDriver节点发送订阅GPU解码事件的请求，由OsEventDriver节点向内核和驱动层的显卡驱动转发该请求。显卡驱动可以监控GPU的状态，在监控到GPU在进行解码操作后，通过该OsEventDriver节点向视频状态探针反馈回调函数。

音频状态探针可向驱动模块订阅音频事件，根据驱动模块反馈的回调函数确定电子设备当前存在的音频事件。音频事件可包括GPU解码事件等。例如，音频状态探针可向执行体层的OsEventDriver节点发送订阅GPU解码事件的请求，由OsEventDriver节点向内核和驱动层的显卡驱动转发该请求。显卡驱动可以监控GPU的状态，在监控到GPU在进行解码操作后，通过该OsEventDriver节点向音频状态探针反馈回调函数。

在本申请的一实施例中，系统探针模块可以包括系统负载探针。系统负载探针可以向驱动模块订阅系统负载，根据驱动模块反馈的回调函数确定系统负载。

在本申请的一实施例中，系统探针模块可以包括电源状态探针。电源状态探针可以向内核态订阅电源状态事件，根据内核态反馈的回调函数确定电源状态，电源状态包括电池(剩余)电量、电源模式等，电源模式可包括交流电源(alternating current，AC)和直流电源(direct current，DC)。例如，电源状态探针可向执行体层的OsEventDriver节点发送订阅电源状态事件的请求，由OsEventDriver节点向执行体层的电源管理器转发该请求。电源管理器可通过该OsEventDriver节点向电源状态探针反馈回调函数。

在本申请的一实施例中，系统探针模块可以包括外设状态探针。外设状态探针可以向内核态订阅外设事件，根据驱动模块反馈的回调函数确定外设事件。外设事件包括鼠标滚轮滑动事件、鼠标点击事件、键盘输入事件、麦克风输入事件、摄像头输入事件等。在本申请实施例中，系统探针模块通过向驱动模块订阅电子设备的各种事件，再根据驱动模块反馈的回调函数确定电子设备的运行状态，即得到探针状态。系统探针模块得到探针状态后，可向场景识别模块反馈该探针状态。场景识别模块接收到探针状态后，可根据该探针状态确定电子设备所处的应用子场景。在本申请实施例中，场景识别模块可以基于API模块(图中未示出)获取焦点窗口信息，并根据焦点窗口对应的应用程序，确定电子设备的应用主场景；基于电子设备当前运行的应用程序的进程信息，确定电子设备的应用子场景；基于确定的应用主场景和应用子场景，确定应用场景。应用场景可以反映用户当前的使用需求。

策略管理模块可以向场景计算模块发送查询应用场景的请求。场景计算模块基于策略管理模块查询应用场景的请求，向策略管理模块发送确定的应用场景。

策略管理模块基于场景计算模块发送的电子设备的应用场景，确定应用场景对应的调度策略。在本申请的一实施例中，策略管理模块可以通过查询预设的策略库，确定电子设备的应用场景对应的调度策略。在本申请的一实施例中，策略管理模块确定调度策略后，将确定的调度策略发送至电子设备的应用层中的调度引擎。调度引擎根据接收到的策略管理模块发送的调度策略，调度相关的硬件完成该调度策略对应的调度操作。在本申请的实施例中，调度引擎可以将调度策略发送至驱动模块，以调度固件层中相关的硬件完成该调度策略对应的调度操作。例如，调度引擎可以将调度策略发送至驱动模块，以调度固件层中的的GPU完成该调度策略对应的调度操作。

如图3所示，CPU的芯片平台类型通常可以分为两种类型，分别为(Advanced Micro Devices，AMD)的CPU和/>的CPU，这两类CPU对于CPU功耗的调整方式并不相同，因此驱动模块通过不同的方法控制CPU完成调度策略对应的调度操作。例如，若CPU的芯片平台类型为AMD，驱动模块可以向电源管理器发送调整EPP的指令，以调整CPU的EPP。另外，驱动模块还可以向OS2SOC驱动节点发送调整PL1、PL2的指令，以调整CPU的PL1和PL2。若CPU的芯片平台类型为/> 驱动模块可以通过WMI插件向IntelDTT驱动发送调度策略，调度策略可包括PL1的最小值、PL1的最大值、PL2、PL2的持续时间及EPP，由Intel DTT驱动CPU基于该调度策略运行。

图4是本申请实施例提供的一种资源调度方法的流程示意图。结合图4，对图3所示的电子设备中部分模块的交互过程进行说明。根据不同的需求，该流程图中步骤的顺序可以改变，某些步骤可以省略。

101、系统探针模块向API模块发送订阅焦点窗口变化事件的请求。

API模块可包括由user32.dll实现的windows用户界面接口，该接口可用于创建窗口。在一种可选的实施方式中，可以由系统探针模块的进程监控探针向API模块的windows用户界面接口发送订阅焦点窗口变化事件的请求。其中，订阅焦点窗口变化事件的请求也可以称为第一请求。该进程监控探针可向API模块注册一个回调，注册该回调的作用是当API模块(的windows用户界面接口)监控到焦点窗口发生变化时，可以向进程监控探针返回该焦点窗口变化事件。

焦点窗口为拥有焦点的窗口，具有较大的概率可以确定为用户当前需要使用的窗口。因此，通过监控焦点窗口，可以确定用户的使用需求。例如，焦点窗口为编程应用的窗口，则表明用户需求为编程代码。又例如，焦点窗口为渲染应用的窗口，则表明用户需求为渲染文件。通过监控焦点窗口是否发生变化，可以确定用户需求是否发生改变。例如，焦点窗口由编程应用的窗口变为渲染应用的窗口，则表明用户当前的需求由编程代码变成了编程代码。

订阅应用场景用于获取场景计算模块计算出的应用场景。当场景计算模块计算出应用场景后，场景计算模块会基于策略管理模块的订阅应用场景，向策略管理模块上报计算出的应用场景。

102、系统探针模块向驱动模块发送订阅进程的请求。

如图3所示，系统探针模块包括进程监控探针。在本申请的一实施例中，可以由进程监控探针向驱动模块发送订阅进程事件的请求。驱动模块中包括进程管理模块，进程监控探针可以在进程管理模块注册一个回调，注册该回调的作用是当进程管理模块确定进程后，可以向进程监控探针返回该进程事件。

在本申请的一实施方式中，订阅进程的请求可以携带有进程名称。即场景识别引擎可以仅订阅指定进程的创建事件，减少不相干进程的创建事件的干扰。例如，指定进程可以为编程应用的进程、制图应用的基础、视频应用的进程、游戏应用的进程、办公应用的进程、社交应用的进程等等。

当然，在其他实施方式中，场景识别引擎也可以不对订阅的进程创建事件做出限制。在本申请的一实施例中，订阅进程用于获取应用程序的应用进程。应用进程包括但不限于：进程创建、进程就绪、进程运行、阻塞状态、进程终止、进程退出。在本申请的一实施例中，进程包括对应的进程信息。进程信息可以包括进程名称信息、进程标识符、进程所属的应用类型信息、进程负载信息、进程状态等信息。其中进程负载信息可以包括进程的CPU占用率、GPU占用率、I/O读写速度、占用的CPU时间、对系统资源的使用情况、IO操作、调用引擎情况中的一项或多项信息。

103、应用程序向驱动模块发送创建进程请求。

创建进程请求用于控制驱动模块创建与应用程序对应的应用进程。当用户开启一应用程序时，该应用程序会向驱动模块发送创建进程请求。

其中，创建进程请求可以包括应用程序的存储地址。在本申请的一实施例中，应用程序可以通过API模块的kernel32.dll接口及Ntdll.dll接口向驱动模块中的进程管理模块发送创建进程的请求(图未示)。

图4中所示的应用程序不限于一个应用程序，可以指多个应用程序。一个应用程序在运行时通常会请求创建一个应用进程。但是有些应用程序在运行时，需要同时运行多个应用进程，所以会请求创建多个应用进程。编程应用在编译较大工程时，由于过程中涉及大量的计算和并发操作，需要同时运行多个应用进程，如Visual本申请的实施例中，应用程序向驱动模块发送的创建进程请求可以包括一个应用进程或多个应用进程的创建请求，在此不做限定。

需要说明的是，上述步骤101至103之间没有严格的先后顺序，其可以按照图4中所示的顺序依次执行，也可以同时执行，在此不做具体限制。104、驱动模块创建应用程序对应的应用进程。

驱动模块根据创建进程请求，创建应用程序对应的一个或多个应用进程。

在本申请的一实施例中，驱动模块中的进程管理模块创建应用程序对应的应用进程。示例性的，进程管理模块可以通过应用程序的存储地址查询到应用程序的二进制文件。通过加载应用程序的二进制文件，可以创建进程运行的环境，启动应用程序。其中，Windows操作系统将一个应用程序的一次运行定义为一个进程。一个进程可以拥有多个线程。窗口是窗口结构的实例，是一种图形用户界面(graphical user interface，GUI)资源，窗口是由线程创建的，线程可以拥有它所创建的所有窗口。在本申请的实施例中，电子设备运行应用程序时，进程管理模块则可以创建该应用程序需要使用的应用进程。

可以理解的是，驱动模块根据创建进程请求创建一个或多个应用进程时，创建的应用进程中可以包括用于创建应用程序的主窗口的线程，主窗口为集成有应用程序全部功能按键的窗口。

105、驱动模块向系统探针模块上报应用进程。

驱动模块创建应用进程对应的应用进程后，向系统探针模块上报创建的应用进程。

在本申请的一实施例中，如前文描述，系统探针模块中进程监控探针向进程管理模块发送了订阅进程的请求，且注册了回调。因此，进程管理模块在创建应用程序的应用进程后，可根据回调向进程监控探针上报创建的应用进程。

在本申请的一实施例中，上报的应用进程可包括进程管理模块所创建的应用进程的名称。

需要理解的是，由于用户在使用电子设备的期间，可以多次开启相同或不同的应用程序，用户每次开启一应用程序开启后，就会执行步骤103-105，所以步骤103-105可以被多次执行。

106、系统探针模块对应用进程进行监控。

系统探针模块接收到驱动模块上报的应用进程后，会对接收到的应用进程进行监控。系统探针模块对应用进程进行监控，可以得到应用进程对应的进程信息。进程信息可以包括进程状态信息和/或进程负载信息。

在本申请的一实施例中，如图3所示，系统探针模块包括进程监控探针和进程负载探针。其中，进程监控探针可以用于对应用进程的状态进行监控，得到进程状态信息，进程状态包括进程创建、进程运行、进程退出等状态；进程负载探针可以用于对应用进程的负载进行监控，如对CPU占用率、GPU占用率、I/O读写速度、占用的CPU时间、对系统资源的使用情况、IO操作、调用引擎情况中的一项或多项进行监控，得到进程负载信息。在本申请的一实施例中，系统探针模块接收到多个应用进程后，会对接收到的应用进程进行筛选，从中确定目标进程进行监控。关于系统探针模块对应用进程进行监控的一些具体实施方式，可以参见下文中对图5和图6的相关描述。

107、API模块响应于应用进程的调用请求，API创建窗口。

在本申请的一实施例中，应用程序的应用进程中用于创建应用程序的主窗口的线程，可以主动调用API模块的windows用户界面接口创建应用程序的主窗口。

108、API模块向系统探针模块上报焦点窗口事件。

焦点窗口事件用于表示焦点窗口变化。

如上文描述，在系统探针模块向API模块发送订阅焦点窗口变化事件的请求后，若API模块检测到焦点窗口发生变化后，API模块检测会向系统探针模块上报焦点窗口事件。在本申请的一实施例中，API模块可以根据第一进程的名称和第二进程的名称，确定焦点窗口是否发生变化。第一进程为当前的焦点窗口对应的进程，第二进程为上一个焦点窗口对应的进程。当第一进程的名称与第二进程的名称不一致时，API模块确定焦点窗口发生变化，向系统探针模块上报焦点窗口事件。其中，焦点窗口事件包括第一进程的名称。示例性的，当第一进程为编程应用的应用进程时，焦点窗口事件携带有编程应用的应用进程的名称。在本申请的一些实施方式中，API模块可以基于电子设备系统的焦点模式确定当前的焦点窗口。关于根据焦点模式确定当前的焦点窗口的一些具体描述，可参见上文中的相关概念或技术的简要介绍。

在本申请的一实施例中，API模块向系统探针模块的进程监控探针上报焦点窗口事件。

109、系统探针模块向场景计算模块上报焦点窗口事件。

110、场景计算模块根据焦点窗口，确定应用主场景。

场景计算模块可以根据焦点窗口对应的应用进程的进程名称(以下简称焦点窗口对应的进程名称)，确定焦点窗口对应的应用类型，从而确定应用主场景。在本申请的一实施例中，电子设备可以预先配置有应用名单，场景识别模块可以查询应用名单中是否包括焦点窗口对应的进程名称。若应用名单中包括焦点窗口对应的进程名称，场景识别模块可以确定焦点窗口对应的进程名称的应用类型。其中，应用名单包括每个应用进程的进程名称及应用进程所属的应用类型，应用名单包括了进程名称与应用类型之间的映射关系。

在本申请的一实施例中，可以将焦点窗口对应的进程名称所属的类型，确定为电子设备所处的应用主场景的类型。例如，若确定焦点窗口对应的进程名称所属的类型为编程类，则可以确定电子设备处于编程场景；又例如，若确定焦点窗口对应的进程名称所属的类型为制图类，则可以确定电子设备处于制图场景。在本申请的一实施例中，应用主场景可包括编程场景、制图场景、视频场景、游戏场景、办公场景、会议场景、互联场景、浏览器场景及社交场景等。其中，编程场景为编程软件对应的场景、制图场景为图像处理软件对应的场景、视频场景为视频播放软件对应的场景、游戏场景为游戏软件对应的场景、办公场景为办公软件对应的场景、会议场景为在线会议软件对应的场景、互联场景为设备互联软件对应的场景、浏览器场景为浏览器软件对应的场景及社交场景为可用于社交软件对应的场景。

111、系统探针模块向场景计算模块上报进程负载信息。

系统探针模块对多个应用进程进行监控后，会根据监控情况生成多个应用进程的进程负载信息，并将生成的进程负载信息上报至场景计算模块。

112、场景计算模块基于多个应用进程的进程负载信息，确定多个目标子场景。

在本申请的一实施例中，目标子场景包括但不限于：编译子场景、文件导入导出子场景、音频子场景、视频子场景、启动子场景、弹幕子场景等子场景。

在本申请的一实施例中，场景计算模块根据预先设置的场景判断规则，对每个应用进程的进程负载信息进行计算，判断该应用进程是否具有对应的目标子场景。在一些实施方式中，每个场景判断规则包括对应的子场景。每个场景判断规则中包括一项或多项参数，每个参数包括对应的参数阈值。当一应用进程的进程负载信息与一场景判断规则中的每个参数匹配时，确定该应用进程的目标子场景为该场景判断规则对应的子场景。具体的，当应用进程的进程负载信息中的参数值大于或等于场景判断规则中与其对应的参数阈值时，确定该应用进程的进程负载信息与该场景判断规则中的每个参数匹配。例如，编译子场景的场景判断规则为CPU占用率大于10％，当一应用进程的进程负载信息中CPU占用率为12％时，确定该应用进程的进程负载信息与编译子场景的场景判断规则中的每个参数匹配，确定该应用进程的目标子场景为编译子场景。又如，文件导入导出子场景的场景判断规则为磁盘读写速度大于1M/秒，当一应用进程的进程负载信息中磁盘读写速度为2.3M/秒时，确定该应用进程的进程负载信息与文件导入导出子场景的场景判断规则中的每个参数匹配，确定该应用进程的目标子场景为文件导入导出子场景。再如，视频播放场景对应的场景判断规则为GPU占用率大于0且进程调用的GPU引擎为GPU video processing引擎，当一应用进程的进程负载信息中GPU占用率为3％且调用的GPU引擎为GPU video processing引擎时，确定该应用进程的进程负载信息与视频播放场景的场景判断规则中的每个参数匹配，确定该应用进程的目标子场景为视频播放子场景。

在本申请的一实施例中，场景计算模块基于多个应用进程的进程负载信息和进程名单表，确定多个目标子场景。进程名单表中包括进程名称与子场景之间的映射关系。在本申请的一实施例中，场景计算模块基于每个应用进程的进程负载信息，确定每个应用进程的进程名称；并在进程名单表中，查询确定的每个进程名称对应的子场景，从而得到多个目标子场景。

焦点窗口的焦点进程为焦点窗口对应的应用进程。焦点窗口有且仅对应一个应用进程。为了可以基于焦点窗口对应的应用主场景，更好地确定焦点进程对应的目标子场景。在本申请的一实施例中，场景计算模块可以基于如下两种实施方式中选择任意一种方式确定焦点窗口的焦点进程对应的目标子场景。

实施方式一、确定焦点窗口对应的应用主场景后，获取应用主场景对应的目标进程名称；当确定焦点窗口对应的焦点进程的进程名称与目标进程名称一致时，将目标进程名称对应的子场景确定为焦点进程对应的目标子场景。

一个应用主场景可以预先设置至少一个目标进程名称，每个目标进程名称对应一个子场景。例如，编程场景可以对应目标进程名称A和目标进程名称B，其中，目标进程名称A对应编译子场景，目标进程名称B对应测试子场景。当确定焦点窗口对应的焦点进程的进程名称与目标进程名称A一致时，将编译子场景确定为焦点进程对应的目标子场景；当确定焦点窗口对应的焦点进程的进程名称与目标进程名称B一致时，将测试子场景确定为焦点进程对应的目标子场景。上述实施方式中，预先设置应用主场景对应的目标进程名称，以及该目标进程名称对应的子场景，使得可以在焦点窗口对应的焦点进程的进程名称与目标进程名称一致时，可以快速地确定焦点进程对应的目标子场景，提高了目标子场景的确定速度。

实施方式二、确定焦点窗口对应的应用主场景后，获取应用主场景对应的子场景规则；当确定焦点窗口对应的焦点进程与子场景规则匹配时，将子场景规则对应的子场景确定为焦点进程对应的目标子场景。

一个应用主场景可以预先设置至少一个子场景规则，每个子场景规则对应一个子场景。例如，编程场景可以对应子场景规则A，其中，子场景规则A对应编译子场景。子场景规则A为CPU占有率大于5％，当焦点窗口对应的焦点进程的CPU占有率为7％时，确定焦点进程与子场景规则A匹配，将编译子场景确定为焦点进程对应的目标子场景。又如，编程主场景可以对应子场景规则A，其中，子场景规则A对应编译子场景。子场景规则A为CPU占有率大于5％，当焦点窗口对应的焦点进程的CPU占有率为7％时，确定焦点进程与子场景规则A匹配，将编译子场景确定为焦点进程对应的目标子场景。又如，制图主场景可以对应子场景规则B，其中，子场景规则B对应文件导入导出子场景。子场景规则B为磁盘读写速度大于1M/秒，当焦点窗口对应的焦点进程的磁盘读写速度为2.1M/秒时，确定焦点进程与子场景规则B匹配，将编译子场景确定为焦点进程对应的目标子场景。

113、基于多个目标子场景的优先级，确定应用子场景。

在本申请的一实施例中，可以预先设置子场景与优先级之间的映射关系，并基于子场景与优先级之间的映射关系，确定计算出的每个目标子场景对应的优先级。在本申请的实施例中，将优先级最高的子场景确定为当前的应用子场景。

不同的子场景具有不同的优先级，优先级用于表示子场景符合用户需求的程度。优先级与子场景符合用户需求的程度之间的映射关系可以根据实际情况进行设置。在本申请的一实施例中，优先级的值越大，表示该子场景越符合用户需求；优先级的值越小，表示该子场景越不符合用户需求。在另一实施例中，优先级的值越小，表示该子场景越符合用户需求；优先级的值越大，表示该子场景越不符合用户需求。本实施例以优先级的值越大，表示该子场景越符合用户需求的为例进行举例说明。

例如，确定了四个目标子场景：目标子场景A，目标子场景B、目标子场景C、目标子场景D，其中目标子场景A的优先级为7，目标子场景B的优先级为4、目标子场景C的优先级为5、目标子场景D的优先级为3；目标子场景A的优先级为7，目标子场景A的优先级最高，将目标子场景A确定为当前的应用子场景。

在本申请的一实施例中，基于多个目标子场景的优先级，确定应用子场景后，若检测到多个目标子场景一目标子场景的退出，会基于多个目标子场景中剩下的目标子场景的优先级，重新确定应用子场景。关于该实施例的一些具体实施方式，可以参见图8的相关说明。上述实施例，可以基于目标子场景对应进程的实时情况，在有一目标子场景退出时，可以基于剩下的多个目标子场景的优先级，重新确定应用子场景，提高确定的应用子场景的准确性，从而提高了定制调度策略的准确性。

114、基于应用主场景和应用子场景，确定应用场景。

在本申请的一实施例中，可以将应用主场景和应用子场景进行拼接，确定应用场景。例如，确定电子设备当前的应用主场景为编程场景、应用子场景为编译子场景，将应用主场景和应用子场景进行拼接，确定当前应用场景为编程编译场景。又如，确定电子设备当前的应用主场景为制图场景、应用子场景为文件写入写出子场景，将应用主场景和应用子场景进行拼接，确定当前的应用场景为制图文件写入写出场景。再如，确定电子设备当前的应用主场景为编程场景、应用子场景为视频播放子场景，将应用主场景和应用子场景进行拼接，确定当前应用场景为编程视频播放场景。上述对电子设备的应用主场景、应用子场景以及应用场景的举例仅为示意性说明，实际应用中不局限于此。

115、场景计算模块向策略管理模块上报应用场景。

在本申请的一实施例中，策略管理模块向场景计算模块发送了查询应用场景的请求，且注册了回调。因此，策略管理模块在确定应用场景后可向策略管理模块上报确定的应用场景。

116、策略管理模块确定应用场景对应的调度策略。

调度策略用于对电子设备进行调度操作，以调整电子设备的性能参数。调度策略包括调度值，如长时睿频功耗(power limit1，PL1)值、短时睿频功耗(power limit2，PL2)值、CPU能效比(energy performance preference，EPP)值中的一项或多项。通过调度操作，使得电子设备的性能参数调整为调度值。PL1指CPU在正常负载下的功耗，相当于热设计功耗。PL1相当于是一种功率限制，通常以瓦特为单位，表示CPU在正常工作条件下的最大功率消耗水平，可以用于确保CPU不会超过其设计规格，并防止过热和损坏。CPU的PL2值是CPU的瞬时功率限制，表示在一定时间内允许CPU使用的最大功率，即CPU在短时间内可达到的最高功耗，其具有持续时间限制。PL2值通常比PL1值高，以便在需要处理临时高负载任务时提供额外的性能。EPP用于反映CPU的调度倾向，其取值范围为0～255。EPP越小，则表明CPU趋向于高性能；EPP越高，则表明CPU趋向于低功耗。EPP可以根据系统负载动态地调整CPU的时钟频率和电压。

在本申请的一实施例中，可以预先设置应用场景与策略之间的映射关系，并基于应用场景与策略之间的映射关系，确定应用场景对应的调度策略。应用场景可对应多个不同的调度策略。上述实施例，基于映射关系，可以快速地根据应用场景确定其匹配的调度策略，提高了确定调度策略的准确性。

在本申请的一实施例中，策略管理模块可以根据设备负载，确定应用场景对应的调度策略。例如，策略管理模块可以根据应用场景，确定应用场景对应的第一策略；基于设备负载在第一策略中确定应用场景对应的第二策略；并将第二策略确定为应用场景对应的调度策略。一应用场景对应在不同设备负载下的多个调度策略。根据设备负载可以在应用场景对应的多个调度策略中，确定目标调度策略，即第二策略。在本申请的一实施方式中，系统负载划分为三个等级，分别为轻负载、中负载、重负载。在本申请的一实施例中，可以基于系统探针模块中的系统负载探针，确定电子设备对应的系统负载。

在本申请的另一实施例中，策略管理模块可以根据设备负载和设备性能模式，确定应用场景对应的调度策略。例如，策略管理模块可以根据应用场景，确定应用场景对应的第一策略；基于设备负载在第一策略中确定应用场景对应的第二策略；基于设备性能模式在第二策略中确定应用场景对应的第三策略，并将第三策略确定为应用场景对应的调度策略。一应用场景对应的多个在不同设备负载下的调度策略。一应用场景在一设备负载上调度策略中包括在不同设备性能模式各自对应的调度策略。根据设备负载可以在应用场景对应的多个调度策略中，确定多个第二策略；并根据设备性能模式在应用场景对应的多个第二策略中，确定目标调度策略，即第三策略。在本申请的一实施方式中，系统负载划分为三个等级，分别为轻负载、中负载、重负载；设备性能模式包括：平衡模式、性能模式、节电模式。在本申请的一实施例中，可以基于系统探针模块中的系统负载探针，确定电子设备对应的系统负载；可以基于系统探针模块中的电源计划探针，确定电子设备对应的设备性能模式。

在本申请的一实施例中，策略管理模块确定应用场景对应的调度策略包括：根据设备的系统负载情况确定电子设备是否处于卡顿状态，若电子设备不处于卡顿状态，确定应用场景对应的调度策略。可以基于系统探针模块中的系统负载探针，确定电子设备对应的系统负载。在本申请的一实施方式中，系统负载划分为三个等级，分别为轻负载、中负载、重负载；当电子设备的系统负载为重负载时，确定电子设备处于卡顿状态。若电子设备处于卡顿状态，将卡顿状态对应的调度策略确定为应用场景对应的调度策略。可以预先设置卡顿状态对应的调度策略。上述实施例，可以在电子设备为卡顿状态时，直接将卡顿状态对应的调度策略确定为应用场景对应的调度策略，可以使电子设备尽快脱离卡顿状态，避免使用应用场景确定的调度策略，导致电子设备持续卡顿的情况发生。

117、策略管理模块向调度引擎发送调度策略。

118、调度引擎向驱动模块发送调度策略。

119、驱动模块控制目标硬件，执行调度策略对应的调度操作。

在本申请的一实施例中，驱动模块可以基于电子设备的芯片平台类型，确定目标硬件，并控制目标硬件执行调度策略对应的调度操作。

CPU的芯片平台类型主要包括两种，分别为(Advanced MicroDevices，AMD)的CPU和/>的CPU，这两种CPU对于CPU功耗的调整方式并不相同，因此需要进行区分。在本申请的一实施例中，驱动模块可以根据电子设备的芯片平台类型，调度芯片平台类型对应的目标硬件完成该调度策略对应的调度操作。例如，若CPU的芯片平台类型为/>调度引擎则向电源管理器发送调整EPP的指令，以使电源管理器调整CPU的EPP；并向OS2SOC驱动节点发送调整PL1、PL2的指令，以使OS2SOC驱动节点调整CPU的PL1和PL2。又如，若CPU的芯片平台类型为/> 调度引擎则可以通过WMI插件向Intel DTT驱动发送该调度策略，调度策略可包括PL1的最小值、PL1的最大值、PL2、PL2的持续时间及EPP，由Intel DTT驱动CPU基于该调度策略运行。

上述实施例提供的方法，基于对应用程序对应的应用进程的监控，确定用户在使用电子设备过程中的多个目标子场景，并基于多个目标子场景的优先级，确定最符合用户需求的应用子场景，从而使得根据应用子场景和应用主场景得到的应用场景，更符合用户的实际需求，接着根据确定的应用场景，确定电子设备的调度策略。根据调度策略，控制目标硬件，从而保证应用进程能够流畅运行。此外，由于本实施例可以确定更符合用户需求的应用场景，从而提高了确定调度策略的准确性，可以更好地对电子设备进行资源调度，可以在保证应用进程能够流畅运行的情况下，尽可能降低电子设备的功耗，从而提升电子设备的续航能力。

由于电子设备可以同时运行多个应用程序，每个应用程序都有其对应的应用进程，而且一些高功耗应用程序在工作时，可能会同时运行多个进程。例如，编程软件，如Visual Studio、Matlab等，在编译较大工程时，由于涉及大量的计算和并发操作，会同时运行多个进程；又如，绘图软件，如PhotoShop、CAD等，在导入导出图片时涉及大量的IO读写和GPU渲染，会同时运行多个进程，所以电子设备中经常会运行多个应用进程，导致系统探针模块难以对运行的多个应用进程进行监控。为了解决上述问题，本申请实施例提供了一种系统探针模块对应用进程进行监控方法，以提高对多进程的应用程序进行监控的效率，从而提高了后续基于应用进程信息确定应用场景的准确率。

图5为本申请实施例提供的一种系统探针模块对应用进程进行监控方法的流程示意图。根据不同的需求，该流程图中步骤的顺序可以改变，某些步骤可以省略。

S201、进程管理模块向进程监控探针上报应用进程。

在本申请的一实施例中，驱动模块中包括进程管理模块。进程管理模块可以实现进程创建、进程控制、进程查询、进程监控等管理动作。进程管理模块在确定应用进程后，可以基于系统探针模块发送的订阅进程，向系统探针模块中的进程监控探针上报应用进程。

S202、进程监控探针向场景识别引擎的过滤器上报应用进程。

在本申请的一实施例中，由于进程管理模块会上报所有的应用进程，而有时候不需要对所有的应用进程进行监控，所以可以基于场景识别引擎的过滤器对进程管理模块上报的应用进程进行过滤，以确定需要进行监控的目标进程。在一些实施方式中，过滤器可以向进程监控探针发送订阅进程的请求，以使进程监控探针得到应用进程后，向过滤器上报应用进程。

S203、过滤器在应用进程中，确定目标进程。

在本申请的一实施例中，也可以预先设置目标名称表，目标名称表中记录了一个或多个进程名称。当一应用进程的进程名称在目标名称表中，将该应用进程确定为目标进程。

在本申请的一实施例中，过滤器可以基于配置表在应用进程中确定目标进程。配置表中包括多个应用程序。在本申请的一实施方式中，过滤器可以基于预设的标志位在配置表中确定目标应用程序，如将带有预设标志位的应用程序确定为目标应用程序；并将应用进程中与目标应用程序匹配的应用进程，确定为目标进程。可以理解的是，应用进程中包括进程名称，基于进程名称可确定该应用进程是否与目标应用程序匹配。在本申请的一实施例中，可以预先设置进程名称与应用程序之间的映射关系。上述实施方式，基于标志位可以准确地确定目标应用程序，可以提高在配置表中确定目标应用程序的准确率，从而提高了确定目标进程的准确率。

S204、过滤器向进程管理容器发送目标进程。

在本申请的一实施例中，过滤器基于系统探针模块中的进程管理容器发送的订阅进程，向进程管理容器上报目标进程。进程管理容器发送订阅进程的过程在图5中未示出。进程管理容器用于对目标进程进行管理，并可以在目标进程中，确定进程负载监控探针需要进行监控的目标进程。

S205、进程管理容器基于目标进程，确定对第一目标进程的增加监控指令或第二目标进程的取消监控指令。

增加监控指令用于指示进程负载监控探针对目标进程中的第一目标进程进行监控。取消监控指令用于指示进程负载监控探针退出对目标进程中的第二目标进程的监控。

在本申请的一实施方式中，进程管理容器可以基于目标进程对应的事件类型，确定第一目标进程或第二目标进程。应用进程的事件类型包括进程创建、进程运行、进程退出等类型。例如，当目标进程对应的事件类型为进程创建时，进程管理容器确定该目标进程为第一目标进程；当目标进程对应的事件类型为进程退出时，进程管理容器确定该目标进程为第二目标进程。进程管理容器在确定第一目标进程后，生成第一目标进程对应的增加监控指令；进程管理容器在确定第二目标进程后，生成第二目标进程对应的增加监控指令。关于确定第一目标进程和第二目标进程的一些具体实施方式，可以参见图6的相关描述。

上述实施例可以在多个应用进程中确定需要进行监控的应用进程以及需要取消监控的应用进程，例如对事件类型为进程创建的第一目标进程确定对应的增加监控指令，实现对第一目标进程的监控；对事件类型为进程退出的第二目标进程确定对应的取消监控指令，取消对第二目标进程的监控，从而实现对多个应用进程的筛选监控，无需对所有的应用进程进行监控，提高了进程监控的效率。

同一应用程序对应的多个应用进程中可能存在同进程名称的进程，以下简称同名进程，若基于同名进程中的每个进程创建监控，当同名进程中的一个进程退出时，就难以从多个同名进程对应的监控中确定该退出的进程对应的监控，从而不能准确地退出对该进程对应的监控，甚至会导致多个同名进程中不是该进程的其他进程的退出。例如，进程A、进程B、进程C为同名进程，当进程A退出时，就难以从进程A、进程B、进程C对应的多个监控中确定进程A对应的监控，从而不能准确地退出对进程A对应的监控，甚至会导致进程B或进程C的退出。

为了解决上述技术问题，在本申请的一实施例中，为多个同名进程设置同一个监控；基于该监控，可以对多个同名进程中的每个进程进行监控。同时，为了更好地控制多个同名进程对应的监控的退出，可以基于同名进程对应的计数器，确定是否退出同名进程对应的监控。图6为本申请实施例提供的一种系统探针模块对应用进程进行监控的方法的流程示意图。如图6所示，过滤器将目标进程上报给进程管理容器后，进程管理容器确定每个目标进程的事件类型，并基于事件类型，确定第一目标进程或第二目标进程，从而确定是否生成增加监控指令或取消监控指令。

在本申请的一实施例中，进程管理容器在其存储的多个应用进程中，将进程类型为进程创建的应用进程确定为第一进程；并基于所述第一进程的获取顺序和所述第一进程对应的进程名称，将进程名称首次出现的第一进程，确定为第一目标进程，并生成第一目标进程对应的增加监控指令。

如图6所示，当一目标进程的事件类型为进程创建时，进程管理容器将该目标进程确定为第一进程，并判断该目标进程的进程名是否首次出现。若该目标进程的进程名是首次出现，进程管理容器确定未添加过该进程对应的监控，并将该进程进一步确定为第一目标进程，并生成该目标进程对应的增加监控指令。若确定该目标进程的进程名不是首次出现，进程管理容器确定已添加过该进程对应的监控，流程结束。

在本申请一实施例中，一进程名称对应的增加监控指令可以控制进程负载监控探针对具有该进程名称的所有应用进程(同名进程)进行监控。例如，进程名称ABC对应了三个进程，分别是：进程A、进程B和进程C，进程名称ABC对应的增加监控指令，可以控制进程负载监控探针对进程名称为ABC的所有进程进行监控，如对进程A、进程B和进程C都进行监控。可以理解的是，进程负载监控探针根据进程名ABC对应的增加监控指令，对进程名ABC对应的所有进程添加监控后，若后续有新增的、进程名称也为ABC的进程，进程负载监控探针也会对该新增的同名进程进行监控，例如后续新增了进程名称为ABC的进程D，进程负载监控探针也会对进程D进行监控。

在本申请的一实施例中，进程管理容器在其存储的多个应用进程中，将进程类型为进程退出的应用进程确定为第二进程；并将不存在同名进程的第二进程，确定为第二目标进程。

在本申请的一实施例中，进程管理容器在确定其存储的多个应用进程中，每个应用进程对应的进程名称，得到多个进程名称；并生成每个进程名称的计数器；并确定每个进程名称的计数器的数值。

在该实施例中，一进程名称的计数器的计数用于表示进程管理容器中该进程名称应用进程的数量，进程名称对应的计数器又被称为第一计数器。例如，当一进程名的第一计数器的计数为0时，确定进程管理容器中不存在该进程名对应的应用进程；又如，当一进程名的第一计数器的计数为3时，确定进程管理容器中存在该进程名对应的3个应用进程。具体地，在进程管理容器存储的多个应用进程中，当进程管理容器获取到任一进程类型为进程创建的应用进程时，控制该应用进程对应的进程名称的第一计数器的数值加1；在进程管理容器存储的多个应用进程中，当获取到任一进程类型为进程退出的应用进程时，控制该应用进程对应的进程名称的第一计数器的数值减1。在本申请的一实施例中，若任一第二进程的进程名称对应的第一计数器的数值为0，确定进程管理容器中不存在该第二进程同名的应用进程，将第二进程确定为第二目标进程。如图6所示，当一目标进程的事件类型为进程退出时，将该目标进程确定为第二进程，将该目标进程的进程名对应的第一计数器减1；并判断第一计数器的计数是否等于0。若确定第一计数器的计数等于0，确定进程管理容器中不存在该目标进程同名的应用进程，不再需要对该进程名称对应的应用进程进行监控，将该目标进程进一步确定为第二目标进程，并生成该目标进程对应的进程名称对应的取消监控指令。若确定第一计数器的计数不等于0，确定进程管理容器中还存在该目标进程同名的应用进程，需要继续对该进程名称对应的应用进程进行监控，流程结束。

一进程名称对应的取消监控指令可以控制进程负载监控探针取消对该进程名称的所有应用进程的监控。例如，进程负载监控探针接收到一进程名称对应的取消监控指令后，会确定是否存在对该进程名称的监控；若存在对该进程名称的监控，进程负载监控探针则删除该进程名称的监控。可以理解的是，若进程负载监控探针确定不存在对该进程名称的监控，则不做任何处理。

S206、进程管理容器向进程负载监控探针发送增加监控指令或取消监控指令。

S207、进程负载监控探针添加增加监控指令对应的第一进程的监控，或退出取消监控指令对应第二进程的监控。

进程负载监控可以对监控的进程进行负载信息探测，确定进程对应的负载信息。

上述实施例，进程负载监控探针根据接收到的增加监控指令或取消监控指令，实现了对监控的应用进程的动态调整，使得监控的应用进程与电子设备中运行的应用进程同步，从而提高了对应用进程进行监控的准确率，提高了对电子设备存在多个应用进程时的监控效率。

进程管理模块向系统探针模块上报应用进程时，进程退出消息为异步传输，所以如果进程管理模块进程创建/退出消息通知太快，可能会导致出现消息顺序错误或者通知失败的问题。例如，一应用进程退出后，由于进程退出消息为异步传输，进程监控探针接收到其对应的进程退出消息的时间可能早于创建该应用进程时的进程创建消息，使得系统探针模块中的进程管理容器无法清楚地确定该应用进程当前是否退出，从而导致进程管理容器可能将已退出的应用进程确定为没退出的应用进程的情况发生。为了解决上述技术问题，本申请实施例提供了一种系统探针模块对应用进程进行监控方法，以提高对电子设备存在多个应用进程时的监控效率，从而提高了后续基于应用进程信息确定应用场景的准确率。

图7为本申请实施例提供的一种系统探针模块对应用进程进行监控方法的示意图，应用于电子设备。如上文描述，进程管理容器用于存储过滤器发送的多个目标进程。在本申请的一实施例中，进程管理容器定时查询储存的多个目标进程是否存在。如图7所示，进程管理容器设置了一个定时器，以按照预设时间间隔，查询进程管理容器中应用进程对应的进程事件是否存在，从而确定应用进程是否退出。若一应用进程对应的进程事件不存在，确定该应用进程退出；若一应用进程对应的进程事件存在，确定该应用进程未退出。定时器按照预设时间间隔进行循环定时，当每一次定时时间到达后，都会查询进程管理容器中应用进程对应的进程事件是否存在。若确定一目标进程退出，进程管理容器控制进程负载监控探针退出对所述目标进程的进程负载信息的监控。

如图7所示，进程管理容器可以根据其存储的应用进程，确定是否增加应用进程对应的监控或退出应用进程对应的监控。进程管理容器可以通过确定第一目标进程或第二目标进程，并生成第一目标进程对应的增加监控指令或第二目标进程对应的取消监控指令，调整进程负载监控探针的监控内容，如增加第一目标进程对应的监控或退出第二目标进程对应的监控。关于进程管理容器调整调整进程负载监控探针的监控内容的一些具体实施方式，可以参见图5和图6中的相关描述。

在本实施例中，进程负载监控探针中包括性能监控模块。性能监控模块对监控的应用进程进行负载信息探测，确定应用进程对应的负载信息。如图7所示，性能监控模块会进行定时更新，重新确定应用进程对应的负载信息，更新负载信息对应的数据。在本申请的一实施例中，性能监控模块会将更新后的负载信息上报至场景计算模块，以使场景计算模块重新计算应用场景。

上述实施例，通过定时器，实现了按照预设时间间隔查询进程管理容器中应用进程对应的进程事件是否存在，从而确定应用进程是否退出，使得进程管理容器可以克服进程退出消息为异步传输带来的弊端，清楚地确定其储存的应用进程当前是否退出，尽可能避免进程管理容器中将已退出的应用进程确定为没退出的应用进程的情况发生；同时，可以及时地确认已退出的应用进程，进而可以及时地控制进程负载监控探针停止对退出应用进程的监控，减少了不必要的能耗。

如上文中的描述，一些高功耗应用程序在工作时，可能会同时运行多个进程。由于应用程序运行的进程较多，导致电子设备难以根据多个进程确定应用场景，可能确定的应用场景与用户的需求不符合，从而导致确定应用场景的准确率较差。为了解决上述问题，本申请实施例提供了一种场景计算模块根据进程信息确定应用场景方法，以提高在应用程序存在多进程情况下，确定应用场景的准确率。图8为本申请实施例提供的一种场景计算模块根据进程信息确定应用场景方法的示意图。根据不同的需求，该流程图中步骤的顺序可以改变，某些步骤可以省略。

301、进程负载探针向场景计算模块发送进程负载信息后，场景计算模块确定进程负载信息对应的进程是否退出。

在本申请的一些实施例中，场景计算模块可以基于进程监控探针上报的进程信息，确定进程负载信息对应的进程是否退出。在本申请另一实施例中，场景计算模块可以基于进程管理容器查询进程事件的结果，确定进程负载信息对应的进程是否退出。进程管理容器查询进程事件可以参见图7的相关描述。场景计算模块确定进程负载信息对应的进程是否退出，可以根据实际情况进行确定，在此不做任何限定。

若进程负载信息对应的进程退出，执行步骤302，场景计算模块场景计算。场景计算模块根据场景计算，确定应用场景。

在本申请的一实施例中，若进程负载信息对应的应用进程退出后，场景计算模块执行的场景计算包括：将退出的应用进程对应的目标子场景确定为失效子场景；确定已计算出的子场景集中是否存在失效子场景；若子场景集中存在失效子场景，根据所述子场景集中除失效子场景外的其他子场景，重新确定电子设备的应用场景。

子场景集为场景计算模块计算出的目标子场景构成的集合。子场景集中可以包括一个至多个目标子场景。例如，场景计算模块已计算出的子场景集中包括四个目标子场景：目标子场景A，目标子场景B、目标子场景C、目标子场景D，其中，目标子场景A的优先级为7，目标子场景B的优先级为4、目标子场景C的优先级为5、目标子场景D的优先级为3，预设优先级为1。若目标子场景A对应的应用进程退出后，将目标子场景A确定为失效场景，根据所述子场景集中除失效子场景外的其他子场景：目标子场景B、目标子场景C、目标子场景D，重新确定应用子场景，如因为目标子场景B当前的优先级最高，将目标子场景B确定为应用子场景。

基于目标子场景，确定应用子场景的一些具体实施方式，可以参见上文对图4的相关描述。

若进程负载信息对应的进程未退出，执行步骤303，场景计算模块为应用进程匹配规则。

场景计算模块为应用进程匹配对应的标记规则。应用进程对应的标记规则用于对应用进程的进程负载信息中与应用场景相关的参数进行标记。与应用场景相关的参数为可以判断一应用进程是否进入应用场景的参数。每个标记规则对应了一个子场景。

在本申请的一实施例中，可以根据应用程序设置应用进程对应的标记规则。同一应用程序的多个应用进程可以对应一样的规则。例如，Visual应用的应用进程的进程负载信息中与应用场景相关的参数为进程存在参数，Visual/>应用的应用进程对应的标记规则可以用于对其进程负载信息中的进程存在参数进行标记。又如，/>应用的应用进程的进程负载信息中与应用场景相关的参数为CPU占用率，/>应用的应用进程对应的规则可以用于对其进程负载信息中的CPU占用率进行标记。再如，/>应用的应用进程的进程负载信息中与应用场景相关的参数为I/O读写速度，/>应用的应用进程对应的规则可以用于对其进程负载信息中的I/O读写速度进行标记。在本申请的一实施例中，可以根据进程名称为每个应用进程设置其对应的标记规则，同一应用程序的不同应用进程可以对应不同的标记规则。例如，进程名称为cl.exe的应用进程设置的标记规则可以用于对CPU占用率进行标记。又如，进程名称为photoshop.exe的应用进程设置的标记规则可以用于对磁盘读写速度进行标记。

场景计算模块匹配到应用进程对应的标记规则后，会根据标记规则对应用进程的进程负载信息中用于判断是否进入应用场景的参数进行标记。

在本申请的一实施方式中，场景计算模块可以在应用进程对应的应用程序初始化时，加载该应用程序对应的标记规则，并将加载完成的标记规则存储在电子设备的内存中。可以理解的是，当根据进程名称为每个应用进程设置其对应的标记规则时，会建立应用程序与进程名称之间的映射关系，以便可以在应用进程对应的应用程序初始化时，加载该应用程序对应的标记规则，即进程名称对应的标记规则。

304，场景计算模块确定进程负载信息是否匹配成功。

场景计算模块确定进程负载信息是否存在被标记的参数。

若确定进程负载信息不存在被标记的参数，确定该进程负载信息不可以用于判断是否进入子场景，确定该进程负载信息匹配失败，流程结束。

若确定进程负载信息存在被标记的参数，确定该进程负载信息可以用于判断应用进程是否进入目标子场景，并确定该进程负载信息匹配成功，执行305，确定应用进程对应的标记规则中记载的阈值是否为零。应用进程对应的标记规则中记载的阈值为零，表示该应用进程无需考虑进程负载阈值的情况，当该应用进程没退出时，则可以直接确定该应用进程进入了标记规则对应的子场景，即标记规则对应的子场景为该应用进程对应的目标子场景；例如，Visual应用的应用进程对应的标记规则中进程存在参数没有对应的阈值，也就是说Visual/>应用的应用进程对应的标记规则中记载的阈值是否为零，只要Visual/>应用的应用进程存在时，即可确定Visual/>应用的应用进程进入了目标子场景。

当确定应用进程对应的标记规则的阈值为零时，执行306，场景计算模块确定该应用进程进入了标记规则对应的子场景，即标记规则对应的子场景为该应用进程对应的目标子场景。例如，标记规则对应的子场景为编译子场景，若Visual应用的应用进程对应的标记规则的阈值为零，确定Visual/>应用的应用进程进入其对应的标记规则对应的子场景，Visual/>应用的应用进程对应的目标子场景为编译子场景。

当确定应用进程对应的标记规则的阈值不为零时，执行307，场景计算模块进行阈值比较。场景计算模块将进程负载信息中目标值与对应标记规则记载的阈值进行比较。目标值即为被标记的参数对应的参数值。

308，场景计算模块确定是否达到阈值。

场景计算模块确定进程负载信息中的目标值是否达到阈值。当确定目标值达到阈值时，确定达到阈值，执行309，计数器清零。

计数器用于判断是否退出当前应用进程对应的目标子场景，可以根据应用进程的进程名称设置不同的计数器，在该实施例中的计数器被称为第二计数器。当第二计数器的值达到预设阈值时，确定当前要退出当前应用进程对应的目标子场景；当第二计数器的值未达到预设阈值时，确定当前不要退出当前应用进程对应的目标子场景。在本申请实施例中，场景计算模块确定目标值达到阈值时，确定要进入当前应用进程对应的目标子场景，所以不会退出当前应用进程的目标子场景，所以此时将第二计数器清零。每种应用进程都具有对应的第二计数器。同名的多个应用进程，为一种应用进程，对应同一个第二计数器。可以理解的是，即使一个应用进程没有进入其对应的目标子场景时，也会具有其对应的第二计数器。当该应用进程的第二计数器达到预设阈值后，由于该应用进程并未进入其对应的目标子场景，所以确定要退出目标子场景时，也不会执行需要的动作。在本实施例中，通过设置第二计数器，使得应用进程退出目标子场景较为困难，可以避免应用进程在一次测试中，由于测试误差导致目标值小于阈值，就退出应用进程对应的目标子场景的情况发生，减少了电子设备退出目标子场景的次数，从而也减少了后续基于目标子场景退出的场景计算次数。

当确定未达到阈值时，确定当前进程不能进入其对应的目标子场景，执行310，第二计数器加1。

311，场景计算模块确定是否退出目标子场景。

场景计算模块可以通过确定第二计数器是否达到预设阈值，从而确定是否退出该进程对应的目标子场景。具体地，当第二计数器未达到预设阈值，场景计算模块确定不退出该应用进程对应的目标子场景，流程结束。当第二计数器达到预设阈值，确定退出该应用进程对应的目标子场景，执行312，场景计算模块确定是否计算场景。如图6所示，执行306后，也会执行312。

在本申请的一实施例中，场景计算模块可以根据上一次确定退出的目标子场景或上一次确定进入的目标子场景，确定是否计算场景。若当前确定退出的目标子场景与上一次退出的目标子场景相同时，确定当前确定退出的目标子场景已经退出，目标子场景数量不会减少，不会影响已确定的目标子场景，确定不计算场景；若当前确定退出的目标子场景与上一次退出的目标子场景不相同时，确定当前确定退出的目标子场景可能未退出，可能会影响已确定的目标子场景，确定计算场景。若当前确定进入的目标子场景与上一次进入的目标子场景相同时，确定当前确定进入的目标子场景已经进入，不会影响已确定的目标子场景，目标子场景数量不会增加，确定不计算场景；若当前确定进入的目标子场景与上一次进入的目标子场景不相同时，确定当前确定进入的目标子场景可能是新增加的目标子场景，可能会影响已确定的目标子场景，确定计算场景。上一次增加的目标子场景为上一次在步骤306确定进入的目标子场景；上一次退出的目标子场景为上一次在步骤311确定退出的目标子场景。在该实施例中，场景计算模块可以会记载上一次增加的目标子场景和/或上一次退出的目标子场景。上述实施例中，可以基于上一次增加的目标子场景或上一次退出的目标子场景，确定是否计算场景，避免了在目标子场景之前已退出或已增加，本次目标子场景增加或退出对应用场景没有影响的情况下，计算场景带来的算力浪费，减少了计算场景的次数，从而减少了能量的损耗。

在本申请的一实施例中，场景计算模块可以根据历史子场景，确定是否需要通知计算。历史子场景为之前确定且未删除的目标子场景。例如，执行306确定进入应用进程对应的编译子场景后，若确定历史子场景中包括编译子场景，确定本次增加的目标子场景对历史子场景的数量没有影响，实质未增加新的目标子场景，不需通知计算；若确定历史子场景中不包括编译子场景，则确定本次增加的目标子场景对历史子场景的数量有影响，增加新的目标子场景，需要通知计算。又如，执行311确定退出进程对应的目标子场景为文件导入导出子场景后，若确定历史子场景中不包括文件导入导出子场景，则确定本次退出的目标子场景对历史子场景的数量没有影响，实质未减少目标子场景，不需通知计算；若确定历史子场景中包括编译子场景，则确定本次退出的目标子场景对历史子场景的数量有影响，减少了目标子场景，需要通知计算。

场景计算模块确定不计算场景，流程结束。

若场景计算模块确定计算场景，执行302，场景计算模块场景计算。在本申请的一实施例中，场景计算模块可以基于多个目标子场景的优先级，在所述多个目标子场景中确定应用子场景，并基于焦点窗口，确定应用主场景；根据确定的应用子场景和应用主场景，确定电子设备的应用场景。关于执行302的一些具体实施方式，可以参见上文中的描述，如图4的相关描述。

上述实施例，基于预设的规则，确定是否进入或退出进程对应的目标子场景，可以准确地确定目标子场景，并在进入或退出进程对应的应用子场景时，判断是否需要重新计算电子设备对应的应用场景，实现了根据应用子场景的实时情况，对应用场景进行更新的目的，从而使得即使电子设备运行的应用进程较多的情况下，也能根据多个应用进程各自确定的目标子场景，确定应用场景，使得确定的应用场景尽可能符合用户的需求，从而提高了确定调度策略的准确性，可以更好地对电子设备进行资源调度，可以在保证终端设备正常运行的同时尽可能提高终端设备的续航时间。

在本申请的一实施例中，可以无需执行图8中的步骤312，即步骤306或步骤312后直接执行步骤302。

本实施例还提供一种计算机存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的资源调度方法。

本实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的资源调度方法。

另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的资源调度方法。

其中，本实施例提供的电子设备、计算机存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

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

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

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

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

最后应说明的是，以上实施例仅用以说明本申请的技术方案而非限制，尽管参照较佳实施例对本申请进行了详细说明，本领域的普通技术人员应当理解，可以对本申请的技术方案进行修改或等同替换，而不离本申请技术方案的精神和范围。

Claims (15)

1.一种资源调度方法，应用于电子设备，其特征在于，所述电子设备运行有多个应用进程，所述方法包括：

基于所述电子设备的焦点窗口，确定应用主场景；

在所述多个应用进程中，确定多个目标进程；

根据所述多个目标进程的进程负载信息，确定多个目标子场景；

基于所述多个目标子场景的优先级，确定应用子场景；

根据所述应用主场景和所述应用子场景，确定应用场景；

基于所述应用场景，获取调度策略；

根据所述调度策略，调整所述电子设备的性能参数。

2.如权利要求1所述的资源调度方法，其特征在于，所述在所述多个应用进程中，确定多个目标进程之后，所述方法还包括：

对所述多个目标进程的进程负载信息进行监控，包括：

在所述多个目标进程中，确定第一目标进程和/或第二目标进程；

对所述第一目标进程的进程负载信息进行监控；和/或

取消对所述第二目标进程的进程负载信息的监控。

3.如权利要求2所述的资源调度方法，其特征在于，所述在所述多个目标进程中，确定第一进程和/或第二进程，包括：

在所述多个目标进程中，将进程类型为进程创建的目标进程确定为第一目标进程；和/或

在所述多个目标进程中，将进程类型为进程退出的目标进程确定为第二目标进程。

4.如权利要求3所述的资源调度方法，其特征在于，所述在所述多个目标进程中，将进程类型为进程创建的目标进程确定为第一进程，包括：

在所述多个目标进程中，将进程类型为进程创建的目标进程确定为第一进程；

基于所述第一进程的获取顺序和所述第一进程对应的进程名称，将进程名称为首次出现的第一进程，确定为所述第一目标进程。

5.如权利要求3所述的资源调度方法，其特征在于，所述在所述多个目标进程中，将进程类型为进程退出的目标进程确定为第二目标进程包括：

在所述多个目标进程中，将进程类型为进程退出的目标进程确定为第二进程；

将不存在同名进程的第二进程，确定为所述第二目标进程。

6.如权利要求5所述的资源调度方法，其特征在于，所述方法还包括：

确定所述多个目标进程中每个目标进程对应的进程名称，得到多个进程名称；

生成每个进程名称的第一计数器；

确定所述每个进程名称的第一计数器的数值，包括：当获取到任一进程类型为进程创建的目标进程时，控制所述目标进程对应的进程名称的第一计数器的数值加1；在所述多个目标进程中，当获取到任一进程类型为进程退出的目标进程时，控制所述目标进程对应的进程名称的第一计数器的数值减1。

7.如权利要求6所述的资源调度方法，其特征在于，所述将不存在同名进程的第二目标进程，确定为第二进程，包括：

若任一第二进程的进程名称对应的计数器的数值为0，将所述第二进程确定为所述第二目标进程。

8.如权利要求1所述的资源调度方法，其特征在于，所述在所述多个应用进程中，确定多个目标进程，包括：

基于预设的标志位在配置表中确定目标应用程序；

将所述多个应用进程中与目标应用程序匹配的应用进程，确定为目标进程，得到所述多个目标进程。

9.如权利要求1所述的资源调度方法，其特征在于，所述确定多个目标进程之后，所述方法还包括：

基于定时器，按照预设时间间隔，查询所述多个目标进程中是否有一目标进程退出；

若确定一目标进程退出，退出对所述目标进程的进程负载信息的监控。

10.如权利要求1至7中任意一项所述的资源调度方法，其特征在于，所述确定应用子场景后，所述方法还包括：

确定所述多个目标子场景中，是否有一目标子场景对应的进程是否退出；

若有一目标子场景对应的进程退出，将进程退出的目标子场景确定为失效子场景；

基于所述多个目标子场景中除所述失效子场景外的剩余目标子场景的优先级，重新确定应用子场景。

11.如权利要求1所述的资源调度方法，其特征在于，所述根据所述多个目标进程的进程负载信息，确定多个目标子场景，包括：

确定目标进程是否存在对应的标记规则；

若所述目标进程存在对应的标记规则，确定所述标记规则对应的阈值是否为0；

若所述标记规则对应的阈值为0，将所述标记规则对应的子场景确定为所述目标进程对应的目标场景；

若所述标记规则对应的阈值不为0且所述目标进程的进程负载信息与所述标记规则对应的阈值匹配时，将所述标记规则对应的子场景确定为所述目标进程对应的目标场景。

12.如权利要求11所述的资源调度方法，其特征在于，所述方法还包括：

根据所述目标进程对应的标记规则对所述目标进程的进程负载信息的标记，在所述进程负载信息中确定目标值；

当所述目标值大于所述标记规则对应的阈值时，确定所述目标进程的进程负载信息与所述标记规则对应的阈值匹配。

13.如权利要求12所述的资源调度方法，其特征在于，所述方法还包括：

确定所述多个目标进程中每个目标进程对应的进程名称，得到多个进程名称；

生成每个进程名称的第二计数器；

确定所述每个进程名称的第二计数器的数值，包括：当所述目标值大于所述标记规则对应的阈值时，控制所述目标进程的进程名称对应的第二计数器清零；当所述目标值小于或等于所述标记规则对应的阈值时，控制所述目标进程的进程名称对应的第二计数器加1；

当一进程名称对应的第二计数器的数值达到预设阈值时，确定退出所述进程名称对应的目标进程的目标子场景。

14.一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1至13中任一项所述的资源调度方法。

15.一种电子设备，其特征在于，所述电子设备包括处理器和存储器，所述存储器用于存储指令，所述处理器用于调用所述存储器中的指令，使得所述电子设备执行如权利要求1至13中任一项所述的资源调度方法。