CN116028210B

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

Info

Publication number: CN116028210B
Application number: CN202210750240.8A
Authority: CN
Inventors: 尚明
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-05-16
Filing date: 2022-06-29
Publication date: 2023-10-20
Anticipated expiration: 2042-06-29
Also published as: CN116028210A; CN117873693A

Abstract

本申请提供了一种资源调度方法、电子设备及存储介质，涉及计算机技术领域。通过本申请方案，根据当前的用户场景和系统负载等确定第一调度策略，并执行第一调度策略，实现动态资源调度，使得降低CPU功耗的同时，满足流畅不卡顿的需求。同时，在调度过程中实时监测是否出现卡顿，能够根据卡顿时长以及卡顿标记信息Flags准确识别出用户可感知的卡顿事件(如鼠标延迟、输入延迟、窗口无响应等卡顿场景)，并采用针对卡顿场景预设的CPU功耗调度策略，以避免卡顿，由此根据实际场景动态调整电子设备的CPU功耗，持续保障流畅不卡顿的使用体验。

Description

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

本申请要求于2022年05月16日提交国家知识产权局、申请号为202210530866.8、申请名称为“资源调度方法及电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

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

背景技术

随着电子设备性能的提升，电子设备的功耗也越来越高。为了提升用户使用体验，电子设备在运行过程中往往需要进行资源调度。例如，当Windows前台应用出现卡顿时，用户体验非常差，甚至出现卡顿无法恢复的情况。因此需要对系统性能进行调优，保证整体使用体验的流畅。然而，在传统的资源调度方案中，CPU在绝大多数用户场景下运行在高性能状态，造成资源浪费和能耗过高的问题。

发明内容

本申请提供一种资源调度方法、电子设备及存储介质，可以在降低电子设备的能耗，保证电子设备性能的同时，满足流畅不卡顿的使用体验。

为达到上述目的，本申请采用如下技术方案：

第一方面，本申请提供一种资源调度方法，该方法应用于电子设备，该电子设备包括图形处理器GPU及中央处理器CPU，该方法包括：

响应于用户的第一操作，电子设备显示第一窗口，该第一窗口为焦点窗口；获取第一窗口对应的第一进程的进程信息及第一信息，该第一信息包括如下信息中的至少一种：第一进程的GPU占用信息、外设事件或电源模式信息；然后，根据第一进程的进程信息及第一信息确定电子设备所处的用户场景；然后，根据用户场景以及电子设备的系统负载得到第一调度策略，并根据第一调度策略调整CPU的功耗；当检测到卡顿事件且该卡顿事件的卡顿时长大于第一预设时长时，根据该卡顿事件的卡顿标记信息确定该卡顿事件是用户可感知的卡顿事件；根据第二调度策略，调整CPU的功耗；其中，通过第二调度策略调整后的CPU功耗大于通过第一调度策略调整后的CPU功耗。

通过本申请实施例提供的资源调度方法，可以识别电子设备所处的用户场景，并根据当前的用户场景和系统负载等确定第一调度策略，并执行第一调度策略，实现动态资源调度，使得降低CPU功耗的同时，满足流畅不卡顿的需求。同时，在调度过程中实时监测是否出现卡顿，能够根据卡顿时长以及卡顿标记信息Flags准确识别出用户可感知的卡顿事件(如鼠标延迟、输入延迟、窗口无响应等卡顿场景)，并采用针对卡顿场景预设的CPU功耗调度策略，以避免卡顿，由此根据实际场景动态调整电子设备的CPU功耗，持续保障流畅不卡顿的使用体验。

在一些实现方式中，第二调度策略可以为电子设备默认的CPU功耗调度策略。在另一些实现方式中，第二调度策略可以是针对用户可感知的卡顿事件预设的调度策略。

举例来说，电子设备识别当前用户场景，并根据用户场景和系统负载确定第一调度策略，例如第一调度策略为：将CPU的长时睿频功耗参数PL1调整至15W，将短时睿频功耗参数PL2调整至60W，以及将CPU能效比EPP调整至210。在采用第一调度策略后，可以实时监测是否出现用户可感知的卡顿事件，在识别出用户可感知的卡顿事件的情况下，采用第二调度策略：将CPU的长时睿频功耗参数PL1调整至35W，将短时睿频功耗参数PL2调整至60W，以及将EPP调整至153。由此通过提升CPU性能，以避免卡顿，提升用户体验。可以理解，在动态调度过程中实时监测是否出现卡顿，能够准确识别出用户可感知的卡顿事件(如鼠标延迟、输入延迟、窗口无响应等卡顿场景)，并采用针对卡顿场景预设的CPU功耗调度策略，以避免卡顿。因此本方案能够动态调整电子设备的CPU功耗，并且能够持续保持流畅不卡顿的使用体验。

本申请实施例提供的资源调度方法，主要包括：主要分为三个过程，分别为：(1)确定电子设备所处的用户场景；(2)根据电子设备所处的用户场景及电子设备的系统负载进行资源调度；(3)在调度过程中实时监测是否发生用户可感知的卡顿事件，并在识别出用户可感知的卡顿事件时切换到预设的资源调度策略，以避免卡顿；并在预设时长后继续执行上述的过程(1)和过程(2)。

其中，识别用户可感知的卡顿事件的过程可包括：首先，通过Windows系统35/37/38/173事件检测卡顿事件；然后根据卡顿时长等因素初步过滤，例如卡顿时长大于第一预设时长(如3秒)的卡顿对用户体验影响较大，可能是用户可感知的卡顿事件，需要进一步识别；然后再结合卡顿标记信息(Flags)识别用户可感知的卡顿事件。例如，可以将Flags映射值和0xCE0进行按位与运算，并根据与运算得到的结果判断当前卡顿事件是否为用户可感知的卡顿事件。步骤A至C描述了本申请实施例提供的卡顿识别算法，通过检测、初步过滤以及精准识别等一系列操作，确定出对用户体验影响较大的卡顿事件，可提升卡顿识别的准确性。

在识别发生了用户可感知的卡顿事件之后，需要相应地进行资源调度策略的调整，以避免卡顿。其中，实施针对卡顿场景预设的资源调度策略的过程可包括：如果当前正在实施第一调度策略，那么先停止执行第一调度策略，切换到针对卡顿场景预设的资源调度策略(第二调度策略)，以避免卡顿。并且，启动定时器(也称为第一定时器)，在定时器超过第二预设时长的情况下停止执行针对卡顿场景预设的资源调度策略，再切回到第一调度策略进行资源调度。

本申请方案可以根据电子设备当前执行任务的负载情况以及用户场景的资源需求，对当前任务动态地进行更加精准的资源调度。并且，可以准确识别出用户可感知的卡顿事件，并在发生用户可感知的卡顿事件时，智能调度CPU的性能使用资源，以避免卡顿。通过本方案，可以在保证电子设备性能的同时，满足流畅不卡顿的使用体验。

在一些实现方式中，在上述根据所述卡顿事件的卡顿标记信息确定所述卡顿事件是用户可感知的卡顿事件之后，所述方法还包括：开启第一定时器，该第一定时器的定时时长为第二预设时长；当第一定时器超过第二预设时长时，从第二调度策略切换到第一调度策略。

可以理解，经过资源调度提升CPU功耗以避免卡顿，在第二预设时长后已经不再处于卡顿场景，因此可以不再执行针对卡顿场景预设的资源调度策略，可继续采用第一调度策略调整CPU的功耗，这样根据场景进行动态调度，可以持续保障流畅不卡顿的使用体验。

在一些实现方式中，在从第二调度策略切换到第一调度策略之前，方法还包括：确定电子设备所处用户场景未发生改变。可以理解，在第二预设时长后，如果电子设备所处用户场景未发生改变，可以恢复采用第一调度策略。

可以理解，在下发针对卡顿场景预设的资源调度策略的情况下，启动定时器，定时某一时长，以保证在定时器计时期间锁定调节机制，使得这一段时间内不重新进行CPU参数调整，使系统平稳运行一段时间，消除卡顿影响。

在一些实现方式中，上述方法还包括：在确定所述卡顿事件是用户可感知的卡顿事件的情况下，将卡顿状态标识设置为第一标识，以表示卡顿场景。其中，所述根据针对所述用户可感知的卡顿事件预设的第二调度策略，调整所述CPU的功耗，包括：响应于所述卡顿状态标识被设置为所述第一标识，根据针对所述用户可感知的卡顿事件预设的第二调度策略，调整所述CPU的功耗。

示例性地，第一标识可以为TRUE，第二表示可以为FALSE。或者，第一标识可以为1，第二表示可以为0。

在一些实现方式中，上述当所述第一定时器超过所述第二预设时长时，从所述第二调度策略切换到所述第一调度策略，包括：当所述第一定时器超过所述第二预设时长时，将卡顿状态标识设置为第二标识，以表示非卡顿场景；响应于所述卡顿状态标识被设置为所述第二标识，从第二调度策略切换到所述第一调度策略。

可以理解，在卡顿状态标识重置为FALSE的情况下，表明当前不再处于卡顿场景，可以按照本申请上述实施例提供的资源调度方法根据用户场景和系统负载等确定新的资源调度策略，并执行新的资源调度策略，不断动态调整电子设备的CPU功耗，使得降低CPU功耗的同时，持续保持流畅不卡顿的使用体验。

在一些实现方式中，上述卡顿事件的卡顿标记信息包括用于指示卡顿事件类型的标记参数值。示例性地，当所述标记参数值为0x400或者0x800时，指示的卡顿事件类型为前台发生的卡顿事件；当所述标记参数值为0x20时，指示的卡顿事件类型为幻像窗口导致的卡顿事件；当所述标记参数值为0x40时，指示的卡顿事件类型为退出窗口时发生的卡顿事件；当所述标记参数值为0x80时，指示的卡顿事件类型为处理窗口消息导致的卡顿事件。

在一些实现方式中，上述根据所述卡顿事件的卡顿标记信息确定所述卡顿事件是用户可感知的卡顿事件，包括：将所述标记参数值与预设数值按照二进制位进行与运算，得到第一运算结果；若所述第一运算结果大于零，则确定所述卡顿事件是所述用户可感知的卡顿事件。

在一些实现方式中，上述预设数值的十六进制表示为0xCE0，预设数值的二进制表示为1100 1110 0000。

在一些实现方式中，第一调度策略包括操作系统OS调度策略以及CPU功耗调度策略。其中，所述根据所述第一调度策略调整所述CPU的功耗，包括：根据所述第一调度策略中的CPU功耗调度策略调整所述CPU的功耗。所述方法还包括：根据所述OS调度策略调整所述第一进程的进程优先级、输入/输出I/O优先级。

通过本申请方案，根据电子设备当前执行任务的负载情况以及用户场景的资源需求，对当前任务动态地进行精准的资源调度。可以保证第一进程可以优先占用CPU资源以及进行I/O访问，保证第一进程能够流畅运行。

在一些实现方式中，根据所述用户场景以及所述电子设备的系统负载得到第一调度策略，包括：根据所述用户场景确定第三调度策略，所述第三调度策略包括所述第一进程的第一进程优先级、第一输入/输出I/O优先级，所述CPU的第一长时睿频功耗PL1、第一短时睿频功耗PL2及第一能效比EPP；根据所述系统负载、所述用户场景及所述第三调度策略得到所述第一调度策略，所述第一调度策略至少包括所述第一进程的第二进程优先级、第二I/O优先级，CPU的第二PL1、第二PL2以及第二EPP；其中，所述系统负载大于预设的第一数值，所述第二进程优先级高于或等于所述第一进程优先级，所述第二I/O优先级高于或等于第一I/O优先级，所述第二PL1大于所述第一PL1，所述第二PL2大于所述第一PL2，所述第二EPP小于所述第一EPP。

可以理解地，负载越高，则第一进程的进程优先级和I/O优先级越高，可以保证第一进程可以优先占用CPU资源以及进行I/O访问，保证第一进程能够流畅运行。另外，在负载增加时，适当增加PL1、PL2，并降低EPP，以平衡电子设备的性能和功耗。

在一些实现方式中，第二调度策略包括所述CPU的第三PL1、第三PL2以及第三EPP。其中，所述第三PL1大于所述第二PL1，所述第三PL2大于所述第二PL2，所述第三EPP小于所述第二EPP。

在一些实现方式中，电子设备中设置有卡顿事件探针(也称卡顿检测模块)。其中，所述当检测到卡顿事件且卡顿事件的卡顿时长大于第一预设时长时，根据卡顿事件的卡顿标记信息确定所述卡顿事件是用户可感知的卡顿事件，包括：在卡顿事件探针检测到卡顿事件且卡顿事件的卡顿时长大于第一预设时长的情况下，根据所述卡顿事件的卡顿标记信息确定所述卡顿事件是用户可感知的卡顿事件。

在一些实现方式中，电子设备中还设置有场景识别模块。方法还包括：卡顿事件探针向场景识别模块发送进程间通信IPC消息，该IPC消息用于指示已发生用户可感知的卡顿事件；场景识别模块接收到所述IPC消息，场景识别模块响应于所述IPC消息，确定所述电子设备处于卡顿场景。

在一些实现方式中，电子设备中还设置有调度执行器。上述方法还包括：场景识别模块向调度执行器发送通知消息，该通知消息用于指示电子设备处于卡顿场景；调度执行器接收该通知消息，调度执行器响应于该通知消息，向所述CPU下发第二调度策略。

在一些实现方式中，电子设备还包括因特尔Intel动态调谐技术DTT驱动。其中，所述调度执行器向所述CPU下发所述第二调度策略，包括：调度执行器确定与第二调度策略对应的DTT策略号；调度执行器调用Intel DTT驱动，驱动CPU基于该DTT策略号运行。

第一方面的一种可能设计方式中，方法还包括：确定CPU的芯片平台类型，芯片平台类型包括第一类型和第二类型。其中，第一类型的CPU可以为的CPU芯片，第二类型的CPU可以为/>的CPU芯片。

第一方面的一种可能设计方式中，CPU功耗调度策略包括第一子策略和第二子策略，第二子策略为根据第一子策略确定的动态调谐技术DTT策略。若芯片平台类型为第一类型，则根据第一子策略调整CPU的功耗。若芯片平台类型为第二类型，则根据第二子策略调整CPU的功耗。也即，针对和/>的CPU，本申请可以适应性匹配不同的功耗调度策略。

第一方面的一种可能设计方式中，第一进程的GPU占用信息包括第一进程的GPU占用率以及GPU引擎；根据进程信息及第一信息确定电子设备所处的用户场景，包括：

根据进程信息确定第一进程的类型；若第一进程的类型为视频类，第一进程的GPU占用率大于0，且GPU引擎为GPU视频进程引擎，确定电子设备所处的用户场景为视频播放场景。可以理解地，若第一进程的类型为视频类，则可以先确定用户当前正在使用视频类应用。若第一进程的GPU占用率大于0，则表明第一进程运行过程中有占用GPU的资源。若第一进程的GPU引擎为GPU video processing(视频进程)引擎，则表明第一进程在运行过程中使用GPU进行解码操作。如此，可以确定用户大概率在使用电子设备进行播放视频，即电子设备所处的用户场景为视频播放场景。

若第一进程的类型为视频类，第一进程的GPU占用率大于0，且GPU引擎为GPU 3D引擎，确定电子设备所处的用户场景为视频浏览场景。相应地，若第一进程的GPU引擎为GPU3D引擎，则表明第一进程仅使用GPU进行2D或者3D渲染操作，可以推断用户在使用电子设备浏览视频资源，而非播放视频，即电子设备所处的用户场景为视频浏览场景。

第一方面的一种可能设计方式中，方法还包括：若第一进程的类型为游戏类，电源模式为游戏模式，第一进程的GPU占用率大于0，且GPU引擎为GPU 3D引擎，确定电子设备所处的用户场景为游戏场景。

可以理解地，若第一进程的类型为游戏类，则可以先确定用户当前正在使用游戏类应用。若第一进程的GPU占用率大于0，则表明第一进程运行过程中有占用GPU的资源。若第一进程的GPU引擎为GPU 3D引擎，则表明第一进程使用GPU进行2D或者3D渲染操作。如此，可以确定用户大概率在使用电子设备打游戏，即电子设备所处的用户场景为游戏场景。

第一方面的一种可能设计方式中，外设事件包括键盘输入事件、鼠标输入事件、麦克风输入事件、摄像头输入事件中的一种或多种；根据进程信息及第一信息确定电子设备所处的用户场景，包括：根据进程信息确定第一进程的类型。

若第一进程的类型为社交类，且检测到键盘输入事件，确定电子设备所处的用户场景为文字聊天场景。也即，若检测到用户在使用社交应用且同时在打字，则用户大概率在使用社交应用进行聊天，可以确定电子设备所处的用户场景为文字聊天场景。

若第一进程的类型为社交类，检测到麦克风输入事件，且未检测到摄像头输入事件，确定电子设备所处的用户场景为语音聊天场景。也即，若检测到用户在使用社交应用且同时在语音输入，则用户大概率在使用社交应用进行语音聊天，可以确定电子设备所处的用户场景为语音聊天场景。

若第一进程的类型为社交类，检测到麦克风输入事件以及摄像头输入事件，确定电子设备所处的用户场景为视频聊天场景。也即，若检测到用户在使用社交应用且同时在视频输入，则用户大概率在使用社交应用进行视频聊天，可以确定电子设备所处的用户场景为视频聊天场景。

第一方面的一种可能设计方式中，方法还包括：

若第一进程的类型为办公类，且检测到键盘输入事件，确定电子设备所处的用户场景为文档编辑场景。若检测到用户在使用办公应用且同时在打字，则用户大概率在使用办公应用编辑文档，可以确定电子设备所处的用户场景为文档编辑场景。

若第一进程的类型为办公类，检测到鼠标输入事件，且未检测到键盘输入事件，确定电子设备所处的用户场景为文档浏览场景。也即，若检测到用户在使用办公应用的过程中使用鼠标但未使用键盘，则用户大概率在使用办公应用浏览文档，可以确定电子设备所处的用户场景为文档浏览场景。

若第一进程的类型为办公类，检测到麦克风输入事件以及摄像头输入事件，确定电子设备所处的用户场景为视频会议场景。也即，若检测到用户在使用办公应用的过程中使用摄像头，则用户大概率在使用办公应用进行视频会议，可以确定电子设备所处的用户场景为视频会议场景。

第一方面的一种可能设计方式中，电子设备还包括场景识别引擎、系统事件驱动OsEventDriver节点及进程管理器，方法还包括：场景识别引擎向OsEventDriver节点发送第一请求；OsEventDriver节点向进程管理器发送第一请求；响应于第一请求，进程管理器在创建第二进程后，向OsEventDriver节点发送第二进程的进程信息；OsEventDriver节点向场景识别引擎发送第二进程的进程信息。

第一方面的一种可能设计方式中，电子设备还包括场景识别引擎及API模块，方法还包括：场景识别引擎向API模块发送第二请求；响应于第二请求，API模块在检测到焦点窗口发生变化后，向场景识别引擎发送第一进程的进程信息。

第一方面的一种可能设计方式中，电子设备还包括场景识别引擎、OsEventDriver节点及显卡驱动，方法还包括：场景识别引擎向OsEventDriver节点发送第三请求；OsEventDriver节点向显卡驱动发送第三请求；响应于第三请求，显卡驱动在检测到在GPU进行解码操作后向OsEventDriver节点上报GPU解码事件；OsEventDriver节点向场景识别引擎发送GPU解码事件。

第一方面的一种可能设计方式中，电子设备还包括场景识别引擎、OsEventDriver节点及外设驱动，方法还包括：场景识别引擎向OsEventDriver节点发送第四请求；OsEventDriver节点向显卡驱动发送第四请求；响应于第四请求，外设驱动在检测到在外设操作后向OsEventDriver节点上报外设事件；OsEventDriver节点向场景识别引擎发送外设事件。

第一方面的一种可能设计方式中，方法包括：响应于用户的第一操作，API模块获取第一进程的名称及第二进程的名称，第二进程为历史的焦点窗口对应的进程；若第一进程的名称与第二进程的名称不一致，向场景识别引擎发送第一进程的进程信息。

第一方面的一种可能设计方式中，根据进程信息及第一信息确定电子设备所处的用户场景，包括：场景识别引擎根据进程信息及第一信息确定电子设备所处的用户场景。

第一方面的一种可能设计方式中，电子设备还包括调度引擎，根据系统负载、用户场景得到调度策略包括：场景识别引擎根据用户场景确定第二调度策略；场景识别引擎向调度引擎发送第二调度策略和用户场景；调度引擎向场景识别引擎发送第五请求；响应于第五请求，场景识别引擎获取系统负载，向调度引擎发送系统负载；调度引擎根据系统负载、用户场景及第二调度策略得到第一调度策略。

第一方面的一种可能设计方式中，电子设备还包括进程管理器、I/O管理器，OS调度策略包括第一进程的第二进程优先级、第二I/O优先级，根据OS调度策略调整第一进程的进程优先级、输入/输出I/O优先级，包括：调度引擎向进程管理器发送第一指令，第一指令携带有第一进程的第二进程优先级；响应于接收到第一指令，进程管理器将第一进程的进程优先级调整为第二进程优先级；调度引擎向I/O管理器发送第二指令，第二指令携带有第一进程的第二I/O优先级；响应于接收到第二指令，I/O管理器将第一进程的I/O优先级调整为第二I/O优先级。

第一方面的一种可能设计方式中，确定CPU的芯片平台类型包括：调度引擎判断CPU的芯片平台类型为第一类型或者第二类型。

第一方面的一种可能设计方式中，电子设备还包括电源管理器、系统和芯片OS2SOC驱动节点，第一子策略包括CPU的第二PL1、第二PL2及第二EPP，根据第一子策略调整CPU的功耗，包括：调度引擎向OS2SOC驱动节点发送第三指令，第三指令携带有CPU的第二PL1、第二PL2；OS2SOC驱动节点向CPU发送第三指令；响应于第三指令，CPU将PL1调整为第二PL1，将PL2调整为第二PL2；调度引擎向电源管理器发送第四指令，第四指令携带有CPU的第二EPP；电源管理器向CPU发送第四指令；响应于第四指令，CPU将EPP调整为第二EPP。

第一方面的一种可能设计方式中，电子设备还包括英特尔DTT驱动，根据第二子策略调整CPU的功耗包括：调度引擎向英特尔DTT驱动发送第五指令，第五指令携带有第二子策略；英特尔DTT驱动向CPU发送第五指令；响应于第五指令，CPU基于第二子策略运行。

第二方面，本申请提供一种资源调度装置，该装置包括用于执行上述第一方面中的方法的单元。该装置可对应于执行上述第一方面中描述的方法，该装置中的单元的相关描述请参照上述第一方面的描述，为了简洁，在此不再赘述。

其中，上述第一方面描述的方法可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或单元。例如，处理模块或单元、显示模块或单元等。

第三方面，本申请提供一种电子设备，该电子设备包括存储器和一个或多个处理器；其中，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令；当所述计算机指令被所述处理器执行时，使得所述电子设备执行第一方面中任一项所述的方法。

第四方面，本申请提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令。当计算机指令在电子设备(如电脑)上运行时，使得该电子设备执行如第一方面及其任一种可能的设计方式所述的方法。

第五方面，本申请提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如第一方面及其任一种可能的设计方式所述的方法。

第六方面，本申请提供一种芯片系统，该芯片系统包括一个或多个接口电路和一个或多个处理器。该接口电路和处理器通过线路互联。上述芯片系统可以应用于包括通信模块和存储器的电子设备。该接口电路用于从电子设备的存储器接收信号，并向处理器发送接收到的信号，该信号包括存储器中存储的计算机指令。当处理器执行该计算机指令时，电子设备可以执行如第一方面及其任一种可能的设计方式所述的方法。

可以理解，上述提供的第二方面所述的资源调度装置、第三方面所述的电子设备，第四方面所述的计算机可读存储介质，第五方面所述的计算机程序产品及第六方面所述的芯片系统所能达到的有益效果，可参考如第一方面及其任一种可能的设计方式中的有益效果，此处不再赘述。

附图说明

图1为本申请实施例提供的资源调度方法应用的一种电子设备的结构示意图；

图2为本申请实施例提供的资源调度方法应用的一种软件模块架构示意图；

图3为本申请实施例提供的资源调度方法应用的软件模块间的交互示意图；

图4为本申请实施例提供的资源调度方法的一种信号交互示意图；

图5为本申请实施例提供的资源调度方法应用的一种界面图；

图6为本申请实施例提供的资源调度方法的另一种信号交互示意图；

图7为本申请实施例提供的资源调度方法的另一种信号交互示意图；

图8为本申请实施例提供的资源调度方法的另一种信号交互示意图；

图9为本申请实施例提供的资源调度方法的另一种信号交互示意图；

图10为本申请实施例提供的一种芯片结构示意图。

具体实施方式

本文中术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。

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

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

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

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

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

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

进程包括多个线程，线程可以创建窗口。焦点进程为创建焦点窗口的线程所属的进程。

长时睿频功耗(power limit1，PL1)，指CPU在正常负载下的功耗，相当于热设计功耗，CPU绝大部分时间的运行功耗不超过PL1。

短时睿频功耗(power limit2，PL2)，指CPU在短时间内可达到的最高功耗，其具有持续时间限制。一般地，PL2大于PL1。

CPU能效比(energy performance preference，EPP)，用于反映CPU的调度倾向，其取值范围为0～255。CPU能效比越小，则表明CPU趋向于高性能；CPU能效比越高，则表明CPU趋向于低功耗。

本申请提供一种资源调度方法，提供内核层(kernel层)节点，该节点可以向应用层上报焦点窗口变化事件以及第一信息(包括焦点进程的进程信息、焦点进程对GPU的占用情况、外设事件以及电源模式等)，应用层可以根据焦点窗口变化事件以及第一信息确定电子设备当前所处的用户场景，并结合用户场景和电子设备的系统负载确定第一调度策略，基于第一调度策略调整焦点进程的进程优先级、I/O优先级以及CPU的功耗，在流畅满足用户需求(保证焦点进程流畅运行)的情况下，降低电子设备的能耗。

通过该方案，可以根据电子设备当前执行任务的负载情况以及用户场景的资源需求，对当前任务动态地进行更加精准的资源调度。并且，可以准确识别出用户可感知的卡顿事件(如鼠标延迟、输入延迟、窗口无响应等)，并在发生用户可感知的卡顿事件时，智能调度CPU的性能使用资源，以避免卡顿。通过本方案，可以在保证电子设备性能的同时，满足流畅不卡顿的使用体验。

请参考图1，为本申请实施例提供的电子设备100的结构示意图。

如图1所示，电子设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，无线通信模块150，显示屏160等。

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

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

处理器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接口等。

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

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

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

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

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

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

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

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

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

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

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

图2为本申请实施例的电子设备100的软件结构框图。

分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Windows系统分为用户态和内核态。其中，用户态包括应用层以及子系统动态链接库。内核态自下而上分为固件层、硬件抽象层(hardwareabstraction layer，HAL)、内核和驱动层及执行体。上述软件架构在电子设备的硬件层之上运行，硬件层中可以包括GPU、CPU、鼠标、麦克风、摄像头、键盘等。

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

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

场景识别引擎可以识别电子设备100所处的用户场景，并确定与该用户场景匹配的基础调度策略(也可称为第三调度策略)。调度引擎可以获取电子设备100的负载情况，并结合电子设备100的负载情况及上述基础调度策略确定符合电子设备100实际运行情况的实际调度策略(也可称为第一调度策略)。其中，关于场景识别引擎和调度引擎的具体内容见后文，在此暂不描述。

子系统动态链接库包括应用程序接口(application programming interface，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启动时，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的信息。

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

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

设备驱动程序运行在内核模式下，为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发送指令。

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

图3示出了电子设备100对资源进行调度时软件和硬件的工作流程示意图。

如图3所示，应用层的场景识别引擎包括系统探针模块、场景识别模块及基础策略匹配管理器。场景识别模块可分别与系统探针模块及基础策略匹配管理器进行交互。场景识别模块可以向系统探针模块发送用于获取探针状态的请求。系统探针模块可以获取电子设备100的运行状态。例如，系统探针模块可以包括电源状态探针、外设状态探针、进程负载探针、音视频状态探针、系统负载探针、系统事件探针，以及卡顿事件探针(也称为卡顿检测模块)等。需要说明的是，卡顿事件可以被认为是系统事件，相应地，系统事件探针和卡顿事件探针可以是集成一体的一个功能模块，或者可以是独立的两个功能模块。为了描述更清楚且便于理解，以下实施例中以系统事件探针和卡顿事件探针是独立的两个功能模块为例进行示例性地说明。

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

外设状态探针可以向内核态订阅外设事件，根据内核态反馈的回调函数确定外设事件。外设事件包括鼠标滚轮滑动事件、鼠标点击事件、键盘输入事件、麦克风输入事件、摄像头输入事件等。

进程负载探针可以向内核态订阅进程负载，根据内核态反馈的回调函数确定进程(例如，第一进程)的负载。

系统负载探针可以向内核态订阅系统负载，根据内核态反馈的回调函数确定系统负载。

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

系统事件探针可以向内核态订阅系统事件，根据内核态反馈的回调函数确定系统事件。其中，系统事件可包括窗口变化事件、进程创建事件、线程创建事件等。例如，系统事件探针可以向执行体层的OsEventDriver节点发送订阅进程创建事件的请求，由OsEventDriver节点向进程管理器转发该请求。进程管理器可在创建进程后，通过该OsEventDriver节点向系统事件探针反馈回调函数。又例如，系统事件探针还向API模块发送订阅焦点窗口变化事件的请求，API模块可监控电子设备100的焦点窗口是否发生变化，并在监控到焦点窗口发生变化时，向系统事件探针反馈回调函数。

可见，系统探针模块通过向内核态订阅电子设备100的各种事件，再根据内核态反馈的回调函数确定电子设备100的运行状态，即得到探针状态。系统探针模块得到探针状态后，可向场景识别模块反馈该探针状态。场景识别模块接收到探针状态后，可根据该探针状态确定电子设备100所处的用户场景。该用户场景可包括视频场景、游戏场景、办公场景及社交场景等。用户场景可以反映用户当前的使用需求。例如，场景识别引擎在识别出焦点窗口为视频应用的窗口时，确定出电子设备100处于视频场景，这说明用户需要使用视频应用观看、浏览视频。又例如，场景识别引擎识在识别出焦点窗口为微信^TM的聊天窗口时，确定电子设备100处于社交场景。场景识别模块还可向基础策略匹配管理器发送该用户场景。基础策略匹配管理器可根据该用户场景确定基础调度策略(也可称为第三调度策略，具体可以参见下文S301、S302中的说明)。基础策略匹配管理器可向场景识别模块反馈该基础调度策略。场景识别模块可向应用层的调度引擎发送该基础调度策略及用户场景。

如图3所示，调度引擎包括负载管控器、芯片策略融合器以及调度执行器。其中，负载管控器可接收场景识别模块发送的基础调度策略及用户场景。负载管控器还可从系统探针模块获取系统负载，并根据系统负载和用户场景对该基础调度策略进行调整，得到实际调度策略(也可称为第一调度策略，具体可以参见下文S310中的说明)。实际调度策略中包括OS调度策略和第一CPU功耗调度策略(也可称为第一子策略)。其中，负载管控器可向调度执行器发送该OS调度策略，由调度执行器基于该OS调度策略进行调度。OS调度策略用于调整焦点进程的进程优先级及I/O优先级。示例性的，调度执行器可向进程管理器发送调整焦点进程的进程优先级的指令，响应于该指令，进程管理器对焦点进程的进程优先级进行调整。又例如，调度执行器可向I/O管理器发送调整焦点进程的I/O优先级的指令，响应于该指令，I/O管理器对焦点进程的I/O优先级进行调整。

负载管控器还可向芯片策略融合器发送第一CPU功耗调度策略，芯片策略融合器可基于CPU的芯片平台类型及该第一CPU功耗调度策略，得到第二CPU功耗调度策略(也可称为第二子策略，具体可以参见下文S317～S325中的说明)。CPU的芯片平台类型主要分为两种，分别为(advanced micro devices，AMD)的CPU和/>的CPU，这两类CPU对于CPU功耗的调整方式并不相同，因此需要进行区分。

若CPU的芯片平台类型为AMD(也可以称为第一类型)，调度执行器可以向电源管理器发送调整EPP的指令，以调整CPU的EPP。另外，调度执行器还可以向OS2SOC驱动节点发送调整PL1、PL2的指令，以调整CPU的PL1和PL2。

若CPU的芯片平台类型为调度执行器可以通过WMI插件向Intel DTT驱动发送该第二CPU功耗调度策略，第二CPU功耗调度策略可包括PL1的最小值、PL1的最大值、PL2、PL2的持续时间及EPP，由Intel DTT驱动CPU基于该第二CPU功耗调度策略运行。

需要说明的是，在电子设备调度过程中可能会出现各种原因导致的卡顿事件，有些卡顿事件对用户使用体验影响较小，而有些卡顿事件对用户使用体验影响较大。本申请实施例中针对大量可能的卡顿事件，识别出其中对用户使用体验影响较大的一些卡顿事件，这类卡顿事件被称为用户可感知的卡顿事件。在本申请实施例中通过卡顿事件探针来检测并识别用户可感知的卡顿事件。

卡顿事件探针可以向内核态订阅卡顿事件，根据内核态反馈的回调函数确定卡顿事件。示例性地，卡顿事件探针可以向OsEventDriver节点发送订阅卡顿事件的请求，由OsEventDriver节点向进程管理器转发该请求。进程管理器可监控是否发生卡顿事件。进程管理器在监控到卡顿事件时通过该OsEventDriver节点向系统事件探针反馈回调函数，例如该回调函数可以包括卡顿时长以及卡顿标记信息，其中该卡顿标记信息可以包括卡顿原因描述以及对应的Flags映射值。然后，卡顿事件探针可以根据卡顿时长以及卡顿标记信息判断是否发生了用户可感知的卡顿事件。例如，若卡顿时长大于第一预设时长(如3秒)，且卡顿标记信息中的Flags映射值满足预设条件，则卡顿事件探针可以确定发生了用户可感知的卡顿事件。其中如何判断Flags映射值是否满足预设条件将在下文中进行详细描述。

可选地，在卡顿事件探针确定发生了用户可感知的卡顿事件之后，卡顿事件探针可以向场景识别模块通知发生了用户可感知的卡顿事件。相应地，在预设时长内(例如采用计时器进行计时；或者启动定时器，定时时长为预设时长)，场景识别模块不再进行场景识别。场景识别模块向调度引擎通知已发生用户可感知的卡顿事件。调度引擎可以从已执行的第一调度策略切换到第二调度策略(例如高CPU性能的默认调度策略)，以避免卡顿。在预设时长后(例如计时器的累计时间大于预设时长，或者定时器超时)，场景识别模块重新开始识别用户场景，并结合调度引擎继续执行本申请实施例提供的智能调度机制：调度引擎根据系统负载和当前用户场景对基础调度策略进行调整，得到实际调度策略，并执行该实际调度策略。因此本申请方案能够动态调整电子设备的CPU功耗，并且能够持续保持流畅不卡顿的使用体验。

或者，在卡顿事件探针确定发生了用户可感知的卡顿事件之后，卡顿事件探针还可以直接向调度引擎通知已发生用户可感知的卡顿事件。基于已发生用户可感知的卡顿事件，调度引擎可以从已执行的第一调度策略切换到第二调度策略，以避免卡顿。例如第二调度策略用于指示在第一调度策略基础上提高CPU功耗，提升CPU性能。并且，在预设时长(例如5分钟)后，调度引擎控制从第二调度策略恢复到第一调度策略，并继续执行本申请实施例提供的智能调度机制。因此本申请方案能够动态调整电子设备的CPU功耗，并且能够持续保持流畅不卡顿的使用体验。

其中，卡顿事件探针和系统事件探针可以是独立的两个功能模块，也可以是集成为一体的一个功能模块，可以理解的是，图3中是以卡顿事件探针和系统事件探针为独立的两个探针为例进行示例性说明的，本申请实施例对此不作限定。

本申请实施方式所提供的资源调度方法，主要分为三个过程，分别为：(1)确定电子设备所处的用户场景；(2)根据电子设备所处的用户场景及电子设备的系统负载进行资源调度；(3)在调度过程中实时监测是否发生用户可感知的卡顿事件，并在识别出用户可感知的卡顿事件时切换到预设的资源调度策略，以避免卡顿；并在预设时长后继续执行上述的过程(1)和过程(2)。下面将结合附图分别说明上述两个过程。

下面将以电子设备处于视频播放场景为例，结合图4，对图3所示的电子设备中部分模块的交互过程进行说明。如图4所示，本申请实施例提供的一种资源调度方法，其确定电子设备所处的用户场景的流程如下：

S101、系统探针模块向OsEventDriver节点发送订阅进程创建事件的请求。

如图3所示，场景识别引擎包括系统探针模块，系统探针模块包括系统事件探针。在本申请实施例中，可以由系统事件探针向位于执行体层的OsEventDriver节点发送订阅进程创建事件的请求。其中，订阅进程创建事件的请求也可以称为第一请求。

在一种可选的实施方式中，订阅进程创建事件的请求可以携带有进程名称。即场景识别引擎可以仅订阅指定进程的创建事件，减少不相干进程的创建事件的干扰。例如，指定进程可以为视频应用的进程、游戏应用的进程、办公应用的进程、社交应用的进程等等。当然，在其他实施方式中，场景识别引擎也可以不对订阅的进程创建事件做出限制。

S102、OsEventDriver节点向进程管理器发送订阅进程创建事件的请求。

进程创建事件的请求可以参考S101的描述，在此不做赘述。

也就是说，场景识别引擎的系统事件探针可以通过OsEventDriver节点向进程管理器发送订阅进程创建事件的请求。

可以理解地，OsEventDriver节点会向进程管理器注册一个回调，注册该回调的作用是当进程管理器创建进程后，可以向OsEventDriver节点返回该进程创建事件。

S103、系统探针模块向OsEventDriver节点发送订阅GPU解码事件的请求。

仍然如图3所示，系统探针模块还包括音视频状态探针。在本申请实施例中，可以由系统探针模块的音视频状态探针向OsEventDriver节点发送订阅GPU解码事件的请求。其中，订阅GPU解码事件的请求也可以称为第三请求。

S104、OsEventDriver节点向显卡驱动发送订阅GPU解码事件的请求。

也就是说，场景识别引擎的音视频状态探针可以通过OsEventDriver节点向显卡驱动发送订阅GPU解码事件的请求。同样地，OsEventDriver节点可向显卡驱动注册一个回调，注册该回调的作用是当显卡驱动监控到GPU进行解码操作后，可以向OsEventDriver节点返回该GPU解码事件。

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

API模块可包括由user32.dll实现的windows用户界面接口，该接口可用于创建窗口。在一种可选的实施方式中，可以由系统探针模块的系统事件探针向API模块的windows用户界面接口发送订阅焦点窗口变化事件的请求。其中，订阅焦点窗口变化事件的请求也可以称为第二请求。

同样地，该系统事件探针可向API模块注册一个回调，注册该回调的作用是当API模块(的windows用户界面接口)监控到焦点窗口发生变化时，可以向系统事件探针返回该焦点窗口变化事件。

焦点窗口为拥有焦点的窗口，大概率为用户当前需要使用的窗口。因此，通过监控焦点窗口，可以确定用户的使用需求。例如，焦点窗口为视频应用的窗口，则表明用户需求浏览、播放视频。又例如，焦点窗口为游戏应用的窗口，则表明用户需求打游戏。通过监控焦点窗口是否发生变化，可以确定用户需求是否发生改变。例如，焦点窗口由视频应用的窗口变为游戏应用的窗口，则表明用户当前的需求由看视频变成了打游戏。

需要说明的是，上述S101、S103及S105之间没有严格的先后顺序，其可以按照图4中所示的顺序依次执行，也可以同时执行，也可以按照S103、S101、S105的顺序依次执行、按照S103、S105、S101的顺序依次执行、按照S105、S101、S103的顺序依次执行或者按照S105、S103、S101的顺序依次执行。相应地，S102、S104及S106之间也没有严格的先后顺序，只要满足S102在S101之后执行、S104在S103之后执行以及S106在S105之后执行即可，在此不做具体限制。

S106、响应于接收到用户开启视频应用的操作，视频应用向进程管理器发送创建进程请求。

其中，创建进程请求包括视频应用程序的存储地址。

视频应用可以通过API模块的kernel32.dll接口及Ntdll.dll接口向进程管理器发送创建进程的请求(图中未示出)。

S107、进程管理器创建视频应用进程。

具体的，进程管理器可以通过该存储地址查询到视频应用程序的二进制文件。通过加载视频应用程序的二进制文件，可以创建进程运行的环境，启动视频应用进程。

其中，Windows操作系统将一个应用程序的一次运行定义为一个进程。一个进程可以拥有多个线程。窗口是窗口结构的实例，是一种图形用户界面(graphical userinterface，GUI)资源，窗口是由线程创建的，线程可以拥有它所创建的所有窗口。在本申请实施例中，电子设备运行视频应用，则进程管理器需创建该视频应用的进程，即视频应用进程(即第一进程)。视频应用进程包括多个线程，多个线程包括线程1，线程1可用于创建视频应用的主窗口。

S108、进程管理器向OsEventDriver节点上报进程创建事件。

其中，进程创建事件可包括进程管理器所创建的进程的名称。在本申请实施例中，该进程的名称为视频应用进程的名称。当然，若进程管理器创建的是其他应用的进程，该进程的名称也对应为其他应用进程的名称。

前文已经说明，OsEventDriver节点向进程管理器发送了订阅进程创建事件的请求，且注册了回调。因此，进程管理器在创建视频应用进程后可向OsEventDriver节点上报进程创建事件。

S109、OsEventDriver节点向系统探针模块上报进程创建事件，携带有视频应用进程的名称和PID。

其中，关于进程创建事件的描述见S108，在此不再赘述。

在本申请实施例中，该OsEventDriver节点可向系统探针模块的系统事件探针上报该进程创建事件。

S110、系统探针模块向场景识别模块上报进程创建事件。

S111、响应于线程1的调用请求，API模块创建窗口1。

其中，线程1可用于创建视频应用的主窗口，该主窗口为集成有视频应用全部功能按键的窗口。

进程管理器创建视频应用进程后，视频应用进程的线程1主动调用API模块的windows用户界面接口创建窗口1。示例性的，如图5中(a)所示，电子设备可以显示窗口101，该窗口101可以为桌面，也可以称为主界面。该窗口101包括视频应用的图标102。电子设备可以接收用户点击该视频应用的图标102的操作，响应于该操作，如图5中(b)所示，电子设备显示窗口103(即窗口1，也可以称为第一窗口)。在上述过程中，焦点窗口由原本的窗口101变为窗口103。

S112、API模块向系统探针模块上报焦点窗口事件，携带有第一进程的名称。

在本申请实施例中，API模块的windows用户界面接口创建窗口1后，可以获取第一进程(即焦点进程)的名称及第二进程的名称，第一进程为当前的焦点窗口(即窗口1)对应的进程，第二进程为上一个焦点窗口(例如，窗口2)对应的进程。示例性的，窗口1对应的进程为视频应用进程(第一进程)，该进程的名称例如为hlive.exe，窗口2对应的进程为windows程序管理器的进程(第二进程)，该进程的名称例如为explorer.exe。由于第一进程的名称与第二进程的名称不一致，API模块确定焦点窗口发生变化，向系统探针模块的系统事件探针上报焦点窗口事件。其中，焦点窗口变化事件包括第一进程(即焦点进程)的名称。示例性的，第一进程为视频应用进程，焦点窗口变化事件携带有视频应用进程的名称。

需要说明的是，在电子设备已经启动视频应用的情况下，电子设备可以不用执行S106～S111。在系统探针模块向API模块发送订阅焦点窗口变化事件的请求后，若用户将焦点窗口切换为视频应用的窗口，API模块同样可以检测到焦点窗口发生变化，并向系统探针模块上报焦点窗口事件。

S113、系统探针模块向场景识别模块上报焦点窗口事件。

S114、场景识别模块确定第一进程所属的类型为视频类。

电子设备可以预先配置有应用名单，场景识别模块可以查询应用名单中是否包括第一进程。若应用名单中包括第一进程，场景识别模块可以确定第一进程所属的类型。其中，应用名单包括每个应用的进程名称及应用所属的类型。示例性的，应用名单可以如表1所示：

例如，第一进程的名称为hlive.exe，则场景识别模块可以确定第一进程所属的类型为视频类。又例如，第一进程的名称为wechat.exe，则场景识别模块可以确定第一进程所属的类型为社交类。需要说明的是，上述表1仅作为示例，实际上表1还可包括更多应用的进程名称及其所属的类型。

表1

应用	进程名称	类型
			荣耀视频	hlive.exe	视频类
word	word.exe	办公类
			射击游戏	shot.exe	游戏类
微信^TM	wechat.exe	社交类
			……	……	……

需要说明的是，此步骤的目的在于初步判断电子设备所处的用户场景。电子设备所处的用户场景可包括视频场景、游戏场景、社交场景、办公场景、浏览器场景等等。其中，视频场景进一步可包括视频播放场景、视频浏览场景。社交场景进一步可包括文字聊天场景、语音聊天场景、视频聊天场景等。办公场景进一步可包括文档编辑场景、文档浏览场景、视频会议场景等。浏览器场景可包括浏览网页场景及播放视频场景等。

在本步骤中，通过第一进程所属的类型，可以确定电子设备所处的用户场景的类型。例如，若确定第一进程所属的类型为视频类，则可以确定电子设备处于视频场景；又例如，若确定第一进程所属的类型为游戏类，则可以确定电子设备处于游戏场景。为了进一步分析用户需求，场景识别模块还可以进一步结合其他参数(例如，外设事件、GPU运行状态等)来分析电子设备所处的具体场景，以达到分析结果更加准确的效果，其具体内容参见后文，在此暂不描述。

S115，响应于接收到用户播放视频的操作，视频应用向API模块发送视频播放指令。

具体的，视频应用可向API模块的DirectX API发送该视频播放指令。该视频播放指令可包括视频的缓存地址。

S116、API模块读取视频文件。

API模块可根据视频播放指令中携带的缓存地址，读取对应的视频文件。

S117、API模块向显卡驱动发送解码指令。

S118、显卡驱动向GPU发送启动指令。

S119、GPU进行解码。

具体的，GPU可通过GPU video processing引擎对该视频文件进行解码操作。

S120、GPU向显卡驱动上报解码事件。

S121、显卡驱动向OsEventDriver节点上报解码事件。

S122、OsEventDriver节点向系统探针模块上报解码事件。

具体的，OsEventDriver节点向系统探针模块的音视频状态探针上报该解码事件。

S123、系统探针模块向场景识别模块发送解码事件。

S124、场景识别模块向系统探针模块发送指令1。

其中，指令1指示系统探针模块获取第一进程的GPU占用率。该指令1可携带有第一进程的名称。

S125、系统探针模块向进程管理器发送获取第一进程的GPU占用率的请求。

其中，该获取焦点进程的GPU占用率的请求可以包括第一进程的名称。

在一种可选的实施方式中，可以由系统探针模块的音视频状态探针向进程管理器发送获取第一进程的GPU占用率的请求。

S126、进程管理器采集第一进程的GPU占用率。

具体的，进程管理器可以通过显卡驱动的图像核心(graphics kernel)接口采集第一进程的GPU占用率。

S127、进程管理器向系统探针模块发送第一进程的GPU占用率。

进程管理器可向系统探针模块的音视频状态探针发送第一进程的GPU占用率。

S128、系统探针模块向场景识别引擎发送第一进程的GPU占用率。

S129、场景识别模块判断第一进程的GPU占用率是否大于0。

其中，若第一进程的GPU占用率大于0，则执行S130。

通过第一进程的GPU占用率，可以确定第一进程在运行过程中是否使用GPU，若第一进程的GPU占用率大于0，则可以认为第一进程在运行过程中使用了GPU；若第一进程的GPU占用率为0，则表明第一进程在运行过程中未使用GPU。

S130、场景识别模块向系统探针模块发送指令2。

其中，指令2指示系统探针模块获取第一进程的GPU引擎。该指令2可携带有第一进程的名称。

S131、系统探针模块向进程管理器发送获取第一进程的GPU引擎的请求。

其中，可以由系统探针模块的音视频状态探针向进程管理器发送获取第一进程的GPU引擎的请求。获取第一进程的GPU引擎的请求包括第一进程的名称。

GPU引擎包括GPU 3D引擎、GPU copy引擎、GPU video encode引擎、GPU videoprocessing引擎。其中，GPU 3D引擎主要负责处理2D或者3D图形。GPU copy引擎主要用于传输数据。GPU video encode引擎主要用于进行编码操作。GPU video processing引擎主要进行解码操作。在一些实施例中，GPU video processing引擎也可以由GPU video decode引擎代替。

S132、进程管理器获取第一进程的GPU引擎。

具体的，进程管理器可以通过显卡驱动的graphics kernel接口获取第一进程的GPU引擎。

S133、进程管理器向系统探针模块发送消息1，消息1指示第一进程的GPU引擎为GPU video processing引擎。

具体的，进程管理器可向系统探针模块的音视频状态探针发送该消息，再由音视频状态将该消息转发给场景识别模块。

S134、系统探针模块向场景识别模块发送消息1。

S135、场景识别模块判断第一进程的GPU引擎是否为GPU video processing引擎。

若第一进程的GPU引擎为GPU video processing引擎，则执行S129；若第一进程的GPU引擎不为GPU video processing引擎，则执行S130。

在S114步骤中，场景识别引擎已经确定第一进程所属的类型为视频类，即可以确定电子设备处于视频场景。通过步骤S135，场景识别引擎可以确定第一进程通过GPU执行的具体操作，进而确定用户在使用视频应用的具体操作。例如，若第一进程的GPU引擎为GPUvideo processing引擎，则表明第一进程在使用GPU进行解码操作，可以认为用户在使用视频应用播放视频。又例如，第一进程的GPU引擎不为GPU video processing引擎，则表明第一进程没有在使用GPU进行解码操作，那么用户大概率在视频应用上浏览视频资源，还未播放视频。

S136、场景识别模块根据第一进程的进程信息确定用户场景为视频播放场景。

其中，第一进程的进程信息包括第一进程的名称、第一进程所属的应用类型、第一进程的GPU占用率及第一进程使用的GPU引擎等信息。

综合上述内容可知，若第一进程(焦点进程)的类型为视频类、第一进程的GPU占用率大于0且第一进程的GPU引擎为GPU video processing引擎，则可以确定电子设备处于视频播放场景。

需要说明的是，上述S101～S136仅以电子设备处于视频场景下的视频播放场景为例进行说明。实际上，电子设备还可以处于其他用户场景(例如，游戏场景、办公场景、社交场景、视频浏览场景等)。

在一种可选的实施方式中，若场景识别引擎确定第一进程(焦点进程)的类型属于游戏类、CPU的电源模式变为游戏模式(game mode)、第一进程的GPU占用率大于0且第一进程的GPU引擎为GPU 3D引擎，则可以确定电子设备处于游戏场景。

其中，系统探针模块的电源状态探针可以向电源管理器发送订阅电源模式变化事件的请求。电源管理器可以在电源模块转换为游戏模式(game mode)时，向系统探针模块的电源状态探针上报该电源模式变化事件。如此，场景识别引擎可通过电源模式变化事件确定CPU的电源模式是否为game mode。

另外，场景识别引擎获取第一进程的类型的过程可以参阅图4中S101、S102、S105、S106～S114，场景识别引擎判断第一进程的GPU占用率是否大于0且第一进程的GPU引擎是否为GPU 3D引擎的过程参阅S124～S135。区别在于将视频应用更换为游戏应用，在此不再赘述。

下面，再结合图6简单说明电子设备处于办公场景时，其确定自身所处的用户场景的流程。需要说明的是，图6所示的流程图与图4所示的流程图，其原理及流程基本详细，下面仅具体说明两者的不同之处，类似之处不再赘述，详情参见图4中相关步骤的说明。图6示出了本申请实施例提供的一种资源调度方法，其确定电子设备所处的用户场景的流程如下：

S201、系统探针模块向OsEventDriver节点发送订阅进程创建事件的请求。

S202、OsEventDriver节点向进程管理器发送订阅进程创建事件的请求。

S203、系统探针模块向OsEventDriver节点发送订阅外设事件的请求。

系统探针模块还包括外设状态探针(参见图3所示)。在本申请实施例中，可以由系统探针模块的外设状态探针向OsEventDriver节点发送订阅外设事件的请求。其中，订阅外设事件的请求也可以称为第四请求。

其中，外设事件包括鼠标滚轮滑动、鼠标点击、键盘输入、摄像头输入、麦克风输入等事件。

S204、OsEventDriver节点向外设驱动发送订阅外设事件的请求。

需要说明的是，外设驱动为所有外设的驱动的统称，例如可以包括鼠标驱动、键盘驱动、摄像头驱动、麦克风驱动等。

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

S206、响应于接收用户开启办公应用的操作，办公应用向进程管理器发送创建办公应用进程的请求。

其中，创建办公应用进程的请求可包括办公应用程序的存储地址。

S207、进程管理器创建办公应用进程。

具体的，进程管理器可以通过该存储地址查询到办公应用程序的二进制文件。通过加载办公应用程序的二进制文件，可以创建进程运行的环境，启动办公应用进程。另外，办公应用进程包括线程2，线程2可用于创建办公应用的主窗口。

S208、进程管理器向OsEventDriver节点上报进程创建事件。

S209、OsEventDriver节点向系统探针模块上报进程创建事件。

其中，该进程创建事件携带有办公应用进程的名称。

S210、系统探针模块向场景识别模块发送进程创建事件。

S211、响应于线程2的调用请求，API模块创建办公应用窗口。

其中，线程2可用于创建办公应用的主窗口，该主窗口为集成有办公应用全部功能按键的窗口。

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

其中，焦点窗口事件中携带有第一进程(焦点进程)的名称。可以理解地，在本申请实施例中，第一进程即为办公应用进程。

S213、系统探针模块向场景识别模块发送焦点窗口事件。

S214、场景识别模块确定第一进程所属的类型为办公类。

例如，第一进程的名称为word.exe，则可以确定第一进程所属的类型为办公类。

S215、响应于用户对外设的操作，外设驱动检测到外设事件。

S216、外设驱动向OsEventDriver节点上报外设事件。

S217、OsEventDriver节点向系统探针模块发送外设事件。

S218、系统探针模块向场景识别模块发送外设事件。

S219、场景识别模块根据外设事件及第一进程所属的类型确定用户场景。

在一种可选的实施方式中，若场景识别引擎确定第一进程(焦点进程)的类型属于办公类，且外设事件为鼠标滚轮滑动事件或点击事件，则可以确定电子设备具体处于办公场景下的文档浏览场景。又或者，若场景识别引擎确定第一进程(焦点进程)的类型属于办公类，且在接收到键盘输入事件后的预设时间(例如，10秒)内未再次接收到鼠标滚轮滑动事件、鼠标击事件、键盘输入事件，可以确定电子设备具体处于办公场景下的文档浏览场景。

在一种可选的实施方式中，若场景识别引擎确定第一进程(焦点进程)的类型属于办公类，且接收到键盘输入事件，则可以确定电子设备具体处于办公场景下的文档编辑场景。

在一种可选的实施方式中，若场景识别引擎确定第一进程(焦点进程)的类型属于办公类，且接收到摄像头输入事件(即摄像头处于开启状态且存在视频流输入)，可以确定电子设备具体处于办公场景下的视频会议场景。

电子设备还可以处于社交场景。社交场景包括三个具体场景，分别为：文字聊天场景、语音聊天场景及视频聊天场景。判断电子设备处于社交场景的原理与判断电子设备处于办公场景的原理类似，在此暂不赘述，下面仅说明判断电子设备处于社交场景需要满足的条件。

在一种可选的实施方式中，若场景识别引擎确定第一进程(焦点进程)的类型属于社交类，且接收到键盘输入事件，则可以确定电子设备具体处于社交场景下的文字聊天场景。

在一种可选的实施方式中，若场景识别引擎确定第一进程(焦点进程)的类型属于社交类，且接收到麦克风输入事件且摄像头处于关闭状态，则可以确定电子设备具体处于社交场景下的语音聊天场景。

在一种可选的实施方式中，若场景识别引擎确定第一进程(焦点进程)的类型属于社交类，且接收到麦克风输入事件、摄像头输入事件，则可以确定电子设备具体处于社交场景下的视频聊天场景。

上述内容说明了如何识别电子设备所处的用户场景，在确定电子设备所处的用户场景后，电子设备还可根据自身所处的用户场景和系统负载进行资源调度，使得电子设备的CPU可以按照用户的实际需求进行运行，达到在不影响用户体验的情况下避免CPU出现性能过剩的效果。

下面，继续以电子设备处于视频播放场景为例，说明电子设备的资源调度过程。如图7所示，本申请实施例提供的一种资源调度方法，其进行资源调度的流程如下：

如图7所示，本申请实施方式提供的资源调度方法还包括：

S301、场景识别模块向基础调度策略匹配管理器发送场景信息。

其中，场景信息用于指示电子设备所处的用户场景。示例性的，电子设备可以预先为不同的用户场景分配唯一标识，该场景信息则可包括用户场景所的唯一标识。例如，该标识(例如为V01)可指示电子设备处于视频播放场景。又例如，该标识(例如为V02)可指示电子设备处于视频浏览场景。

关于场景识别模块确定电子设备所处的用户场景的过程，具体参阅S101～S136，在此不再赘述。

S302、基础策略匹配管理器根据场景信息得到调度策略1。

其中，调度策略1包括OS调度策略1及CPU功耗调度策略1。OS调度策略1包括第一进程的第一进程优先级及第一I/O优先级。其中，调度策略1也可称为第三调度策略。

第一进程的优先级用于衡量第一进程抢占CPU的能力，其优先级越高，则可以优先满足其对CPU资源的占用需求，从而使得第一进程的运行流畅度越高。在一种可选的实施方式中，焦点进程的优先级从高到低依次包括等级：实时、高、高于正常、正常、低于正常、低。其中，第一进程的优先级也可以理解为焦点进程优先级(focus process priority，FPP)。

第一进程的I/O优先级用于衡量系统对第一进程的磁盘和I/O请求的响应度，期优先级越高，则第一进程的磁盘和I/O请求的响应度越高，即响应速度越快。在一种可选的实施方式中，焦点进程I/O优先级从高到低依次包括等级：关键、高、正常、低、非常低。其中，第一进程的I/O优先级也可以理解为焦点进程I/O优先级(focus process IO priority，FPP_IO)。

CPU功耗调度策略1包括CPU的第一PL1、第一PL2以及第一EPP。

可见，调度策略1可以调整第一进程的进程优先级、I/O优先级以及CPU功耗。

在一种可选的实施方式中，电子设备可以预先配置各种用户场景和其对应的调度策略。示例性的，各种用户场景和其对应的调度策略的对应关系可以如表2所示。

表2

示例性的，若确定电子设备所处的用户场景为社交场景下的文字聊天场景，则调度策略1包括：第一进程的第一进程优先级为正常，第一进程的第一I/O优先级为正常，CPU的第一PL1为12W，第一PL2为60W，第一EPP为220。需要说明的是，表2中的调度策略仅作为示例，在实际应用中，进程优先级、I/O优先级、PL1、PL2及EPP的值可以与表2中的值不一致。另外，表2仅示出了部分场景的调度策略，实际电子设备还可配置比表2更多的调度策略。

需要说明的是，上述调度策略为默认电子设备处于轻负载状态时的调度策略，其可以为电子设备预先统计每个应用在对应的负载特征下的CPU功耗，并根据统计得到的负载特征及CPU功耗配置的。因此，基础策略匹配管理器得到的调度策略1可作为电子设备进行调度的策略的参考方案，电子设备还可根据该调度策略1并结合实际的系统负载来得到实际的调度策略。

S303、基础策略匹配管理器向场景识别模块发送调度策略1。

S304、场景识别模块向负载管控器发送调度策略1和场景信息。

也即，基础策略匹配管理器确定调度策略1后，通过场景识别模块向负载管控器转发调度策略1。在一种可选的实施方式中，场景识别模块可以分两个步骤分别向负载管控器发送调度策略1和场景信息。

S305、负载管控器向系统探针模块发送获取系统负载的请求。

其中，系统负载是处于可运行状态的进程和不可中断状态的进程的平均数。可运行状态的进程指正在使用CPU或者等待使用CPU的进程。不可中断状态的进程为等待I/O访问(例如，磁盘I/O)的进程。

S306、系统探针模块向进程管理器发送获取系统负载的请求。

系统探针模块包括系统负载探针(参见图3所示)，可以由系统负载探针向进程管理器发送获取系统负载的请求。在一种可选的实施方式中，也可以由OsEventDriver节点向进程管理器转发系统负载探针的获取系统负载的请求(图中未示出)。

S307、进程管理器获取系统负载。

S308、进程管理器向系统探针模块发送系统负载。

具体的，进程管理器可以向系统探针模块的系统负载探针发送该系统负载。在一种可选的实施方式中，也可以由OsEventDriver节点向系统负载探针转发该系统负载(图中未示出)。

S309、系统探针模块向负载管控器发送系统负载。

S310、负载管控器根据系统负载、场景信息及调度策略1，得到调度策略2。

调度策略2可包括OS调度策略2(也可以称为OS调度策略)和CPU功耗调度策略2(也可以称为第一子策略)。CPU功耗调度策略2包括PL1`、PL2`、EPP`，PL1`为负载管控器调整后的PL1，也可以称为第二PL1。PL2`为负载管控器调整后的PL2，也可以称为第二PL2。EPP`为负载管控器调整后的EPP，也可以称为第二EPP。其中，调度策略2也可以称为第一调度策略。

在一种可选的实施方式中，负载管控器可将系统负载划分为三个等级，分别为轻负载、中负载、重负载。电子设备可预先配置各种用户场景和其对应的调整策略。例如，调整策略可以如表3所示：

表3

示例性的，若电子设备处于视频播放场景，且根据表2可知调度策略1为：视频应用进程的进程优先级为正常，视频应用进程的I/O优先级为正常，CPU的PL1(即第一PL1)为18W，PL2(即第一PL2)为60W，EPP(即第一EPP)为200。在这种情况下，若系统负载为轻负载，则不需要调整调度策略，即调度策略2为调度策略1。若系统负载为中负载，则需保持视频应用进程的进程优先级为正常，视频应用进程的I/O优先级为正常，PL1在18W的基础上增加22W，PL2在60W的基础上增加30W，EPP在200的基础上减少50，即调度策略2为：视频应用进程的进程优先级为正常、视频应用进程的I/O优先级为正常(OS调度策略2)，PL1`为40W，PL2`为90W，EPP`为150(CPU调度策略2)。若系统负载为重负载，则需保持视频应用进程的进程优先级为正常，调整视频应用进程的I/O优先级为高，PL1在18W的基础上增加37W，PL2在60W的基础上增加45W，EPP在200的基础上减少100，即调度策略2为：视频应用进程的进程优先级为正常，视频应用进程的I/O优先级为高，PL1`为55W，PL2`为105W，EPP`为100。

需要说明的是，表3仅示出了部分用户场景及其对应的调整策略，电子设备还可配置比表3更多的调整策略，在此不做具体限制。

在一种可选的实施方式中，系统负载与CPU功耗之间满足特定的映射关系(例如通过特定算式进行映射)，负载管控器也可以通过该特定算式和系统负载计算得到CPU功耗，进而得到调度策略2。

S311、负载管控器向调度执行器发送OS调度策略2。

其中，OS调度策略2包括第一进程的第二进程优先级、第二I/O优先级。

S312、调度执行器向I/O管理器发送指令1。

其中，指令1携带有第一进程的第二I/O优先级。另外，调度执行器包括I/O优先级接口(参见图3所示)，可以由该I/O优先级接口向I/O管理器发送指令1。其中，该指令1也可以称为第二指令。

S313、响应于指令1，I/O管理器调整第一进程的I/O优先级。

也即，I/O管理器可将第一进程的I/O优先级调整为第二I/O优先级。如此，可以保证第一进程可以优先进行I/O访问，减少第一进程在I/O访问过程中的响应时间。

S314、调度执行器向进程管理器发送指令2。

其中，指令2携带有第一进程的第二进程优先级。另外，调度执行器还包括进程优先级接口(参见图3所示)，可以由该进程优先级接口向进程管理器发送指令2。其中，该指令2也可以称为第一指令。

S315、响应于接收到指令2，进程管理器调整第一进程的进程优先级。

也即，进程管理器可将第一进程的进程优先级调整为第二进程优先级。如此，第一进程可以优先占用CPU资源，保证第一进程能够流畅运行。

可见，通过调整第一进程的I/O优先级和进程优先级，可以优先保证第一进程的I/O访问以及对CPU资源的消耗，使得第一进程可以正常、流畅地运行，保证用户有良好的体验。

需要说明的是，S312与S314之间不存在严格的先后顺序，可以先执行S312再执行S314，也可以先执行S314再执行S312，也可以同时执行S314和S312。

S316、负载管控器向芯片策略融合器发送CPU功耗调度策略2。

S317、芯片策略融合器判断CPU的芯片平台类型为或者/>

公司的CPU芯片和/>公司的CPU，对于CPU功耗的调整方式并不相同，因此需要进行区分。其中，若CPU的芯片平台类型为/>(也可以称为第一类型)，则执行S318；若PU的芯片平台类型为/>(也可以称为第二类型)，则执行S325。

S318、芯片策略融合器向调度执行器发送CPU功耗调度策略2。

其中，CPU功耗调度策略2包括PL1`、PL2`、EPP`。

S319、调度执行器向OS2SOC驱动节点发送指令3。

其中，指令3携带有PL1`、PL2`。也即，指令3用于调整CPU的PL1和PL2。其中，指令3也可以称为第三指令。

在一种可选的实施方式中，可以由调度执行器的CPU功耗调度接口向OS2SOC驱动节点发送指令3。

S320、OS2SOC驱动节点向CPU发送指令3。

S321、响应于指令3，CPU调整PL1和PL2。

也即，CPU可将PL1调整为PL1`，将PL2调整为PL2`。

S322、调度执行器向电源管理器发送指令4。

其中，指令4携带有EPP`。也即，指令4用于调整CPU的EPP。指令4也可以称为第四指令。

S323、电源管理器向CPU发送指令4。

S324、响应于指令4，CPU调整EPP。

也即，CPU可将EPP调整为EPP`。

S325、芯片策略融合器根据CPU功耗调度策略2确定动态调谐技术策略号。

动态调谐技术(dynamic tuning technology，DTT)是公司在/>处理器和/> 独立显卡之间自动并动态分配功耗，以优化性能并延长电池续航时间的技术，其可以使CPU和GPU的性能得到提升，智能混合工作负载功率平衡。

可以理解地，DTT策略号与CPU功耗调度策略2可以存在映射关系。在BIOS中会构建一张DTT策略表，任何一条CPU功耗调度策略2都能通过其内的参数(PL1`、PL2`、EPP`)映射到DTT策略表中某个DTT策略号，如表4所示。

其中，DTT策略号可用于标识一种DTT策略(也可以称为第二子策略)，DTT策略号对应的DTT策略用于调整CPU的PL1_MINI、PL1_MAX、PL2、PL2_TIME、EPO Gear。PL1_MINI为PL1的最小值，PL1_MAX为PL1的最大值，PL2_TIME为PL2的持续时间。能效-性能优化挡位(energy performance optimize gear，EPO Gear)用来表征DTT调节CPU能效比(EPP)的力度，取值范围1～5，值越大，调节EPP时越倾向能效；值越小，调节EPP时越倾向性能。

表4

需要说明的是，表4仅示出部分PL1'、PL2'、EPP'和DTT策略号的对应关系，实际上还可包括比表4更多的信息。示例性的，若CPU功耗调度策略2指示PL1`为-1，PL2`为-1且EPP`为-1，则可以确定DTT策略号为0，其对应的PL1_MINI为30，PL1_MAX为40，PL2为95，PL2_TIME为28，EPO Gear为3。

S326、芯片策略融合器向调度执行器发送DTT策略号。

在一种可选的实施方式中，芯片策略融合器也可直接向调度执行器发送该DTT策略号对应的功DTT策略(即第二子策略)。

S327、调度执行器向Intel DTT驱动发送DTT策略号。

S328、Intel DTT驱动向CPU发送DTT策略号。

可以理解地，该Intel DTT驱动可通过BIOS向CPU发送DTT策略号。

S329、CPU基于DTT策略号运行。

可见，若CPU的芯片平台类型为芯片策略融合器可以通过调度执行器向电源管理器发送调整EPP的指令，电源管理器可调整CPU的EPP。另外，调度执行器还可以向OS2SOC驱动节点发送调整PL1、PL2的指令，OS2SOC驱动节点驱动CPU的PL1和PL2。

若CPU的芯片平台类型为则芯片策略融合器可以确定CPU功耗调度策略2得到DTT策略号，并通过调度执行器通过bios向Intel DTT驱动发送DTT策略号，使得CPU基于该DTT策略号运行，达到调整功耗的效果。

可以理解地，本申请可以获取焦点窗口变化事件以及第一信息(包括焦点进程的进程信息、焦点进程对GPU的占用情况、外设事件以及电源模式等)，并根据焦点窗口变化事件以及第一信息确定电子设备当前所处的用户场景，并结合用户场景和电子设备的系统负载确定第一调度策略，基于第一调度策略调整焦点进程的进程优先级、I/O优先级以及CPU的功耗，在流畅满足用户需求(保证焦点进程流畅运行)的情况下，降低电子设备的能耗。

以上实施例介绍了根据用户场景以及系统负载进行智能调度的各种实施例，在保证焦点进程流畅满足用户需求的情况下，降低电子设备的能耗。而在上述智能调度的过程中，可能还会出现卡顿场景(可能是短时卡顿，也可能是长时卡顿)，如果不作处理可能对用户体验有较大影响。例如，当Windows前台应用出现卡顿时，可能会出现卡顿无法恢复的情况，用户体验变差。此时，需要对系统性能进行调优，保证整体使用体验的流畅。本申请实施例提供的资源调度方法，可以识别用户可感知的卡顿事件并对应地调整资源调度策略，避免出现卡顿。下面对本申请实施例提供的资源调度方法进行详细描述。

具体地，在上述图4、图6和图7中根据用户场景确定出对应的调度策略并采用该调度策略之后，可以通过本申请提供的卡顿识别算法判断是否发生用户可感知的卡顿事件，当识别出已发生用户可感知的卡顿事件时，不再按照原来的调度策略(第一调度策略)进行调度，而是将调度策略切换到针对卡顿场景预设的资源调度策略(第二调度策略)，调整CPU能耗及性能，以避免卡顿。然后，在预设时长后从第二调度策略恢复到第一调度策略，并继续执行图4、图6和图7中的步骤对CPU功耗进行实时动态调度，满足流畅不卡顿的使用体验。

本申请实施例提供对应的资源调度方法，主要包括：(1)识别用户可感知的卡顿事件的过程；以及2)实施针对卡顿场景预设的资源调度策略的过程。

其中，识别用户可感知的卡顿事件的过程可包括下述步骤A至C。

A.通过Windows系统35/37/38/173事件检测卡顿事件；

B.然后根据卡顿时长等因素初步过滤，例如卡顿时长大于第一预设时长(如3秒)的卡顿对用户体验影响较大，可能是用户可感知的卡顿事件，需要进一步识别；

C.再结合卡顿标记信息(Flags)识别用户可感知的卡顿事件。例如，可以将Flags映射值和0xCE0进行按位与运算，并根据与运算得到的结果判断当前卡顿事件是否为用户可感知的卡顿事件。

上述步骤A至C描述了本申请实施例提供的卡顿识别算法，通过检测、初步过滤以及精准识别等一系列操作，确定出对用户体验影响较大的卡顿事件，可提升卡顿识别的准确性。

在识别发生了用户可感知的卡顿事件之后，需要相应地进行资源调度策略的调整，以避免卡顿。其中，实施针对卡顿场景预设的资源调度策略的过程可包括下述步骤D至E。

D.如果当前正在实施第一调度策略，那么停止执行第一调度策略，切换到针对卡顿场景预设的资源调度策略(第二调度策略)，以避免卡顿。

E.启动定时器(也称为第一定时器)，在定时器超过第二预设时长的情况下停止执行针对卡顿场景预设的资源调度策略，再切回到第一调度策略进行资源调度。

通过本申请方案，可以根据电子设备当前执行任务的负载情况以及用户场景的资源需求，对当前任务动态地进行更加精准的资源调度。并且，可以准确识别出用户可感知的卡顿事件(如鼠标延迟、输入延迟、窗口无响应等)，并在发生用户可感知的卡顿事件时，智能调度CPU的性能使用资源，以避免卡顿。通过本方案，可以在保证电子设备性能的同时，满足流畅不卡顿的使用体验。

下面结合图8的时序图说明本申请实施例提供的资源调度方法的具体实现过程。图8示例性地说明了本申请实施例中如何识别用户可感知的卡顿事件以及实施针对卡顿场景预设的资源调度策略的过程。如图8所示，该方法包括S400至416。

S400，CPU执行第一调度策略，该第一调度策略是根据用户场景和系统负载确定的调度策略。

其中，根据用户场景和系统负载确定第一调度策略，以及CPU执行第一调度策略的详细描述，具体可参见上述实施例中结合图4、图6和图7所描述的过程，此处不再赘述。

S401，卡顿事件探针检测到卡顿事件。

在电子设备运行时，卡顿事件探针实时监测是否发生卡顿并识别是否为用户可感知的卡顿事件。需要说明的是，卡顿事件探针也可以称为卡顿检测模块，其位于应用层。

在本申请实施例中，卡顿事件探针可以订阅窗口追踪事件(event tracing forwindows，ETW)，通过回调进行时延检测(delay detect)，确定时延或卡顿时长。示例性地，卡顿事件探针通过检测Windows系统35/37/38/173事件获取时间数据，从而根据时间数据确定卡顿时长(也称为卡顿时延，或者卡顿事件的时延或时长)。其中可以通过35/37/38/173事件的代码查看时间数据并确定卡顿时长。下面示出了Windows系统的35/37/38/173事件的示例性代码。

38事件描述了消息检测延迟(MessageCheckDelay)，其代码表示如下：

<data name＝"DelayTimeMs"inType＝"win:UInt32"/>//卡顿时长

</template>

具体到本申请方案，通过38事件代码中的DelayTimeMs获知延迟时间，即卡顿时长。

173事件描述了隐藏消息检测延迟(ImmersiveMessageCheckDelay)，其代码表示如下：

<data name＝"DelayTimeMs"inType＝"win:UInt32"/>//卡顿时长

</template>

具体到本申请方案，通过173事件代码中的DelayTimeMs获知延迟时间，即卡顿时长。

37事件描述了输入进程延迟(InputProcessDelay)，其代码表示如下：

<data name＝"TimeSinceInputRemoveMs"inType＝"win:UInt32"/>//卡顿时长

</template>

具体到本申请方案，通过37事件代码中的TimeSinceInputRemoveMs获知输入延迟时间，即卡顿时长。

35事件描述了等待光标(WaitCursor)，其代码表示如下：

<data name＝"CursorProcessId"inType＝"win:UInt32"/>//CursorProcessId为卡顿进程PID

<data name＝"DisplayTimeMs"inType＝"win:UInt32"/>//卡顿时长

</template>

其中，如果CursorType！＝111，则认为用户可感知卡顿。CursorProcessId为卡顿进程标识(process identification，PID)，通过PID可以查询卡顿进程名称。

具体到本申请方案，可以通过上述35事件代码中的DisplayTimeMs获知显示时间，即卡顿时长。

S402，卡顿事件探针解析卡顿事件，得到卡顿时长以及卡顿标记信息(Flags)。

S403，卡顿事件探针判断卡顿时长是否大于3秒。

在本申请实施例中，卡顿事件探针解析卡顿时长等数据，基于卡顿时长可以过滤出一些可能会影响用户使用体验的卡顿事件。例如，将卡顿时长大于某一预设时长(如3秒)的事件，确定为卡顿事件；以及针对卡顿时长小于或等于预设时长(如3秒)的事件可以排除，不作处理。其中，该卡顿事件是否为用户可感知的卡顿事件，需要进一步识别才能确定。

在本申请实施例中，当监测到卡顿事件时，会触发获取卡顿事件对应的卡顿标记信息，该卡顿标记信息可以用于识别该卡顿事件是否为用户可感知的卡顿事件。其中，卡顿标记信息可以包括卡顿原因描述以及映射数值(成为Flags映射值)。下面的示例性代码描述了各种类型的卡顿事件及其对应的卡顿标记信息。

<map value＝"0x20"message＝"$(string.map_ThreadInfoFlagsThread hasghosted windows)"/>//Flags映射值为0x20，卡顿原因描述为幻像窗口导致的卡顿事件。

<map value＝"0x40"message＝"$(string.map_ThreadInfoFlagsThread isbeing destroyed)"/>//Flags映射值为0x40，卡顿原因描述为处理窗口消息导致的卡顿事件。

<map value＝"0x80"message＝"$(string.map_ThreadInfoFlagsThread pumpedper-window messages)"/>//Flags映射值为0x80，卡顿原因描述为退出窗口时发生的卡顿事件。

<map value＝"0x400"message＝"$(string.map_ThreadInfoFlagsThread haswindow focus)"/>//Flags映射值为0x400，卡顿原因描述为前台发生的卡顿事件。

<map value＝"0x800"message＝"$(string.map_ThreadInfoFlagsThread isforeground)"/>//Flags映射值为0x800，卡顿原因描述为前台发生的卡顿事件。

</bitMap>

其中，针对前台进程或者有用户输入操作的进程，进行卡顿事件检测与识别。上述卡顿检测方案可应用到用户异常卡顿大数据收集模块，用于用户体验分析。

在上述各种类型的卡顿事件中，从用户使用体验来看，有些卡顿是用户不容易感知的，对用户使用体验影响较小；而有些卡顿是用户容易感知的，对用户使用体验影响较大，例如鼠标延迟、输入延迟、窗口无响应等均属于用户可感知的卡顿事件。

可选地，在本申请实施例中，用户可感知的卡顿事件可以包括以下任一种卡顿事件：

1)前台发生的卡顿事件(has window focus或者is foreground)：针对该卡顿事件，Flags映射值可以被标记为0x400或者0x800，统称为0xC00。

2)幻像窗口导致的卡顿事件(has ghosted windows)：针对该卡顿事件，Flags映射值可以被标记为0x20。其中，幻像窗口也称为幻影窗口。幻像窗口不同于正常使用的应用程序窗口，幻像窗口可以是空白窗口。

3)处理窗口消息导致的卡顿事件(pumped per-window messages)：针对该卡顿事件，Flags映射值可以被标记为0x80。

4)退出窗口时发生的卡顿事件(is being destroyed)：针对该卡顿事件，Flags映射值可以被标记为0x40。

需要说明的是，上述用户可感知的卡顿事件为示例性地举例，可以理解，在实际实现时，用户可感知的卡顿事件还可以包括其他可能的情况，具体可以根据实际需求确定，本申请实施例不作限定。为了便于理解，下面以针对上述用户可感知的卡顿事件中的任一种卡顿事件进行识别为例进行示例性说明。

在本申请实施例中，先通过S403的算法先检测出卡顿时长大于3秒的卡顿事件，再进一步根据下述的S404的算法识别是否为用户可感知的卡顿事件，从而可以更准确地识别出对用户体验影响较大的卡顿事件。

S404，卡顿事件探针根据Flags识别是否发生用户可感知的卡顿事件。

卡顿事件探针通过解析备选卡顿事件对应的卡顿标记信息(Flags)，识别用户可感知的卡顿事件。

示例性地，在本申请实施例中，可以通过本申请的下述算法解析备选卡顿事件对应的卡顿标记信息，判断该备选卡顿事件是否为用户可感知的卡顿事件。这样通过识别出对用户使用体验具有较大影响的卡顿事件，可以进一步对调度策略进行相应调整，以避免卡顿。

下面详细说明本申请实施例中解析备选卡顿事件对应的卡顿标记信息并判断该备选卡顿事件是否为用户可感知的卡顿事件的可能实现过程。

在本申请实施例中，通过大量试验数据研究后发现，可以预先设定一个数值0xCE0，在检测卡顿事件时将0xCE0与卡顿标记信息的Flags映射值进行运算，更便于电子设备快速解析卡顿标记信息并判断是否发生用户可感知的卡顿事件。具体地，可以将卡顿标记信息中的Flags映射值(记为F)与0xCE0进行按位与运算，并根据按位与运算得到的结果判断当前卡顿事件是否为用户可感知的卡顿事件。

例如，若“F&0xCE0>0”，即按位与运算得到的结果大于0，则认为当前卡顿事件对用户使用体验影响较大，已发生用户可感知的卡顿事件，需要进行相应策略调整以避免卡顿。若“F&0xCE0＝0”，即按位与运算得到的结果等于0，则认为当前卡顿事件对用户使用体验影响较小，可不作处理。

需要说明的是，上述符号“&”为按位与运算符，表示参与运算的两数各对应的二进位相与。在C/C++中，“按位与”规则为：1&1＝1；1&0＝0；0&1＝0；0&0＝0。可以理解，相同位的两个数字都为1，则这两个数字的与运算结果为1；若相同位的两个数字中有一个不为1，则这两个数字的与运算结果为0。

还需要说明的是，在C语言中，前缀0x或者0X通常表示十六进制的数字。具体到本申请方案，0xCE0为十六进制的表示方式，为了进行按位与运算，需要将0xCE0转换为二进制。0xCE0对应的二进制表示为1100 1110 0000。另外，同样需要将十六进制形式表示的Flags映射值转换为二进制，以便进行按位与运算。

可选地，在本申请实施例中，满足F&0xCE0>0条件的Flags映射值可以包括0x20，0x40，0x80，0x400，或者0x800。下面分别以示例说明如何根据Flags映射值判断是否发生用户可感知的卡顿事件。

示例1：假设解析出Flags映射值为0x20。0x20对应二进制0000 0010 0000。

下面将0xCE0和0x40进行按位与运算：

1100 1110 0000

&0000 0010 0000

＝0000 0010 0000

其中，按位与运算结果为0000 0100 0000。由于按位与运算结果大于0，因此可以判断已发生用户可感知的卡顿事件。

示例2：假设解析出Flags映射值为0x40，0x40对应二进制0000 0100 0000。

下面将0xCE0与0x40进行按位与运算：

1100 1110 0000

&0000 0100 0000

＝0000 0100 0000。

示例3：假设解析出Flags映射值为0x80，0x80对应二进制0000 1000 0000。

下面将0xCE0与0x80进行按位与运算：

1100 1110 0000

&0000 1000 0000

＝0000 1000 0000。

其中，按位与运算结果为0000 1000 0000。由于按位与运算结果大于0，因此可以判断已发生用户可感知的卡顿事件。

示例4：假设解析出Flags映射值为0x400，0x400对应二进制0100 0000 0000。

下面将0xCE0与0x80进行按位与运算：

1100 1110 0000

&0100 0000 0000

＝0100 0000 0000。

其中，按位与运算结果为0100 0000 0000。由于按位与运算结果大于0，因此可以判断已发生用户可感知的卡顿事件。

示例5：假设解析出Flags映射值为0x800，0x800对应二进制1000 0000 0000。

下面将0xCE0和0x800进行按位与运算：

1100 1110 0000

&1000 0000 0000

＝1000 0000 0000。

其中，按位与运算结果为1000 0000 0000。由于按位与运算结果大于0，因此可以判断已发生用户可感知的卡顿事件。

由上述算法可知，在电子设备运行过程中，当检测到系统发生卡顿且卡顿持续时长大于第一预设时长(例如3秒)，且检测到Flags映射值满足F&0xCE0>0条件(例如Flags映射值为0x20，0x40，0x80，0x400或者0x800)时，可以判断出已发生用户可感知的卡顿事件。

需要说明的是，这里以Flags映射值是否满足F&0xCE0>0条件为例示例性地说明如何识别用户可感知的卡顿事件，在实际实现时，与Flags映射值进行按位与运算的数值不限于是0xCE0，还可以替换为其他数值，或者本申请实施例还可以采用其他可能的算法来识别用户可感知的卡顿事件，具体可以根据实际使用需求确定，本申请实施例不作限定。

S405，当卡顿事件探针识别出用户可感知的卡顿事件时，卡顿事件探针生成卡顿事件内容，封装成进程间通信(inter-process communication，IPC)消息。

S406，卡顿事件探针向场景识别模块发送IPC消息。

在识别出用户可感知的卡顿事件后，卡顿事件探针生成事件内容，封装成IPC消息，并通过IPC消息通知场景识别模块。

S407，响应于接收到IPC消息，场景识别模块确定当前处于卡顿场景，并判断卡顿状态标识是否指示卡顿场景。

其中，卡顿状态标识默认为FALSE，表示当前不是卡顿场景或者为非卡顿场景。当识别出用户可感知的卡顿事件时，会将卡顿状态标识设置为TRUE，指示当前处于卡顿场景。

在卡顿场景中，场景识别模块可以根据卡顿状态标识的结果执行对应的动作。在一种可能实现方式中，当识别出用户可感知的卡顿事件时，如果卡顿状态标识为FALSE，那么表明此时没有执行针对卡顿场景预设的资源调度策略，因此继续执行下述的S408-S416，即将卡顿状态标识设置为TRUE，并在第二预设时长内执行针对卡顿场景预设的资源调度策略。在另一种可能实现方式中，当识别出用户可感知的卡顿事件时，如果卡顿状态标识已经被设置为TRUE，那么表明当前已经是卡顿场景，此时正在执行针对卡顿场景预设的资源调度策略，因此无需再触发执行针对卡顿场景预设的资源调度策略。通过设置卡顿状态标识，可以避免在一段时间内重复触发操作。

S408，当卡顿状态标识为FALSE时，场景识别模块将卡顿状态标识设置为TRUE。

S409，场景识别模块向CPU通知执行针对卡顿场景预设的资源调度策略(第二调度策略)。

可选地，针对卡顿场景预设的资源调度策略也可以是电子设备的默认调度策略，默认调度策略对应的CPU性能应当优于第一调度策略对应的CPU性能。或者，针对卡顿场景预设的资源调度策略还可以是基于当前用户场景确定的基础调度策略，基础调度策略对应的CPU性能应当优于第一调度策略对应的CPU性能。

需要说明的是，针对卡顿场景预设的资源调度策略对应的CPU性能应当优于第一调度策略对应的CPU性能，以避免卡顿。

其中，针对卡顿场景预设的资源调度策略主要用于提升CPU的性能，保证性能要求，避免卡顿。例如，针对卡顿场景预设的资源调度策略包括：将CPU的功耗参数PL1提升至35W，将PL2调整至80W，以及将EPP调整至153。需要说明的是，这里为示例性地举例，在实际实现时，CPU各个参数的调整数值还可以根据实际情况取其他数值；并且对于不同的CPU，PL1、PL2和EPP等参数的调整值可能不同。

在本申请实施例中，场景识别模块可以通知调度执行器当前为卡顿场景，通过调度执行器将针对卡顿场景预设的资源调度策略下发给底层芯片，底层芯片根据接收到的调度策略参数进行CPU参数调整，由此实现从第一调度策略切换到针对卡顿场景预设的资源调度策略(第二调度策略)。

S410，CPU执行第二调度策略，停止执行第一调度策略。

其中，针对卡顿场景预设的资源调度策略(也称为预设的卡顿调度策略)可用于提升CPU的性能，保证性能要求。通过执行针对卡顿场景预设的资源调度策略，可以增大CPU功耗，提升CPU性能，避免卡顿。

S411，场景识别模块启动定时器，例如定时5分钟。

在下发针对卡顿场景预设的资源调度策略的情况下，启动定时器，定时某一时长(例如5分钟)，以保证系统流程，在定时器计时期间锁定调节机制，保证这一段时间内不重新进行CPU参数调整，使系统平稳运行一段时间，消除卡顿影响。

S412，场景识别模块判断定时器是否超时。

其中，“定时器超时”指的是，定时器超过第二预设时长，第二预设时长为定时器的定时时长。定时器的定时时长可以根据实际使用需求设置，本申请实施例不作限定。例如，定时器的定时时长可以为5分钟。可以理解，在5分钟内持续执行针对卡顿场景预设的资源调度策略，在5分钟后停止执行针对卡顿场景预设的资源调度策略。

若判断定时器超时，则继续执行下述的S413和S416。

S413，当定时器超时，场景识别模块将卡顿状态标识重置为FALSE。

S414，场景识别模块重新识别场景。

其中，“重新识别场景”可以指识别电子设备当前所处的用户场景，并且实时检测当前是否为卡顿场景。可以理解的是，识别用户场景的过程可以参考上述图4或图6中识别用户场景的步骤的描述。在识别用户场景之后，可以继续执行上述图7中的步骤：根据用户场景确定出对应的调度策略并智能调度CPU的功耗及性能，满足流畅不卡顿的使用体验，且降低CPU功耗。

S415，若用户场景未改变，则场景识别模块通知CPU执行第一调度策略。

S416，CPU停止执行第二调度策略，恢复执行第一调度策略。

在定时器超时情况下不再采用卡顿场景对应的资源调度策略，而是切换到第一调度策略或者新的资源调度策略，该新的资源调度策略可以根据当前用户场景和系统负载确定。

综上所述，在电子设备运行时，可以按照本申请实施例提供的资源调度方法，识别电子设备所处的用户场景，并根据当前的用户场景和系统负载等确定第一调度策略，并执行第一资源调度策略，不断动态调整电子设备的CPU功耗，使得降低CPU功耗的同时，持续保持流畅不卡顿的使用体验。同时，实时监测是否出现卡顿，一旦识别出现用户可感知的卡顿事件，即卡顿场景，则从第一调度策略切换到针对卡顿场景预设的资源调度策略，并在第二预设时长后从针对卡顿场景预设的资源调度策略再切换到第一调度策略，由此根据场景进行动态调度，持续保障流畅不卡顿的使用体验。

下面在图8的基础上结合图9的时序图进一步详细说明本申请实施例提供的资源调度方法的具体实现过程。如图9所示，该方法包括S510至S539。需要说明的是，图9中以CPU的芯片平台为Intel为例进行示例性说明，在此情况下通过DTT策略号来下发对应的CPU功耗调度策略。

S510、场景识别模块识别场景，得到场景信息及调度策略1。

其中，场景识别模块可以获取焦点窗口变化事件以及第一信息(包括焦点进程的进程信息、焦点进程对GPU的占用情况、外设事件以及电源模式等)，并根据焦点窗口变化事件以及第一信息确定电子设备当前所处的用户场景。

其中，场景信息用于指示用户场景的类型，例如办公场景、游戏场景或者视频场景等，具体可以参见上述实施例对用户场景的详细描述。调度策略1可以由基础策略匹配管理器根据根据场景信息得到，具体可以参见上述实施例对调度策略1的详细描述，此处不再赘述。

S511、场景识别模块将场景信息及调度策略1发送给负载管控器。

S512、负载管控器根据系统负载、场景信息及调度策略1，得到调度策略2。

调度策略2可包括OS调度策略2和CPU功耗调度策略2。CPU功耗调度策略2包括PL1`、PL2`、EPP`，PL1`为负载管控器调整后的PL1。PL2`为负载管控器调整后的PL2。EPP`为负载管控器调整后的EPP。其中，调度策略2也可以称为第一调度策略。

S513、负载管控器向调度执行器发送OS调度策略2。

其中，OS调度策略2包括第一进程的进程优先级、I/O优先级。

S514、调度执行器向I/O管理器发送指令1。

其中，指令1携带有第一进程的I/O优先级。调度执行器包括I/O优先级接口，可以由该I/O优先级接口向I/O管理器发送指令1。

S515、响应于指令1，I/O管理器调整第一进程的I/O优先级。

通过调高第一进程的I/O优先级，可以保证第一进程优先进行I/O访问，减少第一进程在I/O访问过程中的响应时间。

S516、调度执行器向进程管理器发送指令2。

其中，指令2携带有第一进程的进程优先级。调度执行器还包括进程优先级接口，可以由该进程优先级接口向进程管理器发送指令2。

S517、响应于接收到指令2，进程管理器调整第一进程的进程优先级。

通过调高第一进程的进程优先级，可以保证第一进程优先占用CPU资源，保证第一进程能够流畅运行。

需要说明的是，S514与S516之间不存在严格的先后顺序，可以先执行S514再执行S516，也可以先执行S516再执行S514，也可以同时执行S514和S516。

S518、负载管控器向芯片策略融合器发送CPU功耗调度策略2。

S519、芯片策略融合器判断CPU的芯片平台类型为或者/>

公司的CPU芯片和/>公司的CPU，对于CPU功耗的调整方式并不相同，因此需要进行区分。若CPU的芯片平台类型为/>则继续执行S520。

需要说明的是，这里以CPU的芯片平台类型为为例进行说明，对于/>公司的CPU芯片，其CPU功耗的调整方式可以参考图7中S318至S324的描述，此处不再赘述。

S520、芯片策略融合器根据CPU功耗调度策略2确定动态调谐技术策略号。

如前所述，在BIOS中会构建一张DTT策略表，任何一条CPU功耗调度策略2都能通过其内的参数(PL1`、PL2`、EPP`)映射到DTT策略表中某个DTT策略号。

其中，CPU功耗调度策略2与第一DTT策略号存在映射关系。

S521、芯片策略融合器将第一DTT策略号发送给调度执行器，然后调度执行器将第一DTT策略号发送给Intel DTT驱动，Intel DTT驱动将第一DTT策略号发送给CPU。

示例性地，第一DTT策略号对应的CPU功耗调度策略为：将CPU的功耗参数PL1调整至15W，将PL2调整至60W，以及将EPP调整至210。

其中，Intel DTT驱动可通过BIOS向CPU发送DTT策略号。

S522、CPU基于第一DTT策略号运行。

对于上述S512至S522的描述具体可以参见上述图7中S310至S329的详细描述。

在CPU的芯片平台类型为的情况下，芯片策略融合器可以确定CPU功耗调度策略2得到第一DTT策略号，并通过调度执行器通过BIOS向Intel DTT驱动发送第一DTT策略号，使得CPU基于该第一DTT策略号运行，达到调整功耗的效果。

通过上述步骤S510至S522，本申请可以识别电子设备当前所处的用户场景，并结合用户场景和电子设备的系统负载确定第一调度策略，基于第一调度策略调整焦点进程的进程优先级、I/O优先级以及CPU的功耗，在流畅满足用户需求(保证焦点进程流畅运行)的情况下，降低电子设备的能耗。

S523，卡顿事件探针检测到卡顿事件。

在电子设备运行时，可以实时检测是否出现卡顿，一旦检测到卡顿则进一步识别是否为用户可感知的卡顿事件，即卡顿场景，此时需要进行调度策略调整，以降低卡顿对用户体验造成的影响。

S524，卡顿事件探针解析卡顿事件，得到卡顿时长以及卡顿标记信息(Flags)。

S525，卡顿事件探针判断卡顿时长是否大于3秒。

其中，阈值以3秒为例进行示例性说明，可以根据实际需求进行设置。若卡顿时长大于3秒，需要进一步识别，则继续执行S526；若卡顿时长小于或等于3秒，对用户使用较小，因此可以无需处理。

S526，卡顿事件探针根据Flags识别是否发生用户可感知的卡顿事件。

S527，当卡顿事件探针识别出用户可感知的卡顿事件时，卡顿事件探针生成卡顿事件内容，封装成IPC消息。

S528，卡顿事件探针向场景识别模块发送IPC消息。

S529，响应于接收到IPC消息，场景识别模块确定当前处于卡顿场景，并将卡顿状态标识设置为TRUE。

S530，场景识别模块向芯片策略融合器通知当前处于卡顿场景。

S531，芯片策略融合器确定与卡顿场景对应的第二DTT策略号。

可以理解，第二DTT策略号与针对卡顿场景预设的CPU功耗调度策略存在映射关系。

示例性地，第二DTT策略号对应的CPU功耗调度策略为：将CPU的功耗参数PL1调整至35W，将PL2调整至80W，以及将EPP调整至153。与第一DTT策略号对应的CPU功耗调度策略(PL1调整至15W，PL2调整至60W，EPP调整至210)相比，第二DTT策略号对应的CPU功耗调度策略中增大PL1，增大PL2且降低EPP，这样通过增大CPU的功耗，提升CPU的性能，以避免卡顿。

S532，芯片策略融合器将第二DTT策略号发送给调度执行器，然后调度执行器将第二DTT策略号发送给Intel DTT驱动，Intel DTT驱动将第二DTT策略号发送给CPU。

S533，CPU基于第二DTT策略号运行。

其中，在卡顿场景中，通过执行针对卡顿场景预设的资源调度策略，增大CPU功耗，提升CPU性能，以避免卡顿。

S534，当卡顿状态标识设置为TRUE时，启动定时器。

S535，场景识别模块判断定时器是否超时。

S536，当定时器超时，场景识别模块将卡顿状态标识重置为FALSE，并重新识别场景。

在一种实现方式中，通过重新识别场景，发现电子设备当前所处的用户场景未改变，在此情况下可以恢复CUP功耗调度策略。

S537，场景识别模块向芯片策略融合器通知当前不处于卡顿场景且用户场景未改变。

S538，芯片策略融合器通过调度执行器和Intel DTT驱动，指示CPU从第二DTT策略号切换为第一DTT策略号。

S539，CPU基于第一DTT策略号运行。

在另一种实现方式中，通过重新识别场景，发现电子设备当前所处的用户场景已发生改变，在此情况下可以返回继续执行上述S510至S522，即根据用户场景及系统负载确定新的调度策略，动态调整电子设备的CPU功耗，持续保持流畅不卡顿的使用体验。

本申请实施例还提供一种电子设备，所述电子设备包括存储器和一个或多个处理器。

其中，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令；当所述计算机指令被所述处理器执行时，使得所述电子设备执行上述方法实施例中的各个功能或者步骤。该电子设备的结构可以参考图1所示的电子设备100的结构。

本申请实施例中的电子设备可以为笔记本电脑或者个人计算机(personalcomputer，PC)等，本申请实施例不作具体限定。

本申请实施例还提供一种芯片系统，如图10所示，该芯片系统包括至少一个处理器801和至少一个接口电路802。处理器801和接口电路802可通过线路互联。例如，接口电路802可用于从其它装置(例如电子设备的存储器)接收信号。又例如，接口电路802可用于向其它装置(例如处理器801)发送信号。示例性的，接口电路802可读取存储器中存储的指令，并将该指令发送给处理器801。当所述指令被处理器801执行时，可使得电子设备执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本申请实施例还提供一种计算机存储介质，该计算机存储介质包括计算机指令，当所述计算机指令在上述电子设备上运行时，使得该电子设备执行上述方法实施例中手机执行的各个功能或者步骤。

本申请实施例还提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行上述方法实施例中手机执行的各个功能或者步骤。

可以理解的是，本申请实施例提供的电子设备为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请实施例能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

本申请实施例可以根据上述方法示例对上述电子设备进行功能模块的划分，例如，可以对应各个功能划分各个功能模块，也可以将两个或两个以上的功能集成在一个处理模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。

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

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

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

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

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

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims

1.一种资源调度方法，其特征在于，应用于电子设备，所述电子设备包括图形处理器GPU及中央处理器CPU，所述方法包括：

响应于用户的第一操作，所述电子设备显示第一窗口，所述第一窗口为焦点窗口；获取所述第一窗口对应的第一进程的进程信息及第一信息，所述第一信息包括如下信息中的至少一种：所述第一进程的GPU占用信息、外设事件或电源模式信息；

根据所述第一进程的进程信息及所述第一信息确定所述电子设备所处的用户场景；

根据所述用户场景以及所述电子设备的系统负载得到第一调度策略，并根据所述第一调度策略调整所述CPU的功耗；

当检测到卡顿事件且所述卡顿事件的卡顿时长大于第一预设时长时，根据所述卡顿事件的卡顿标记信息确定所述卡顿事件是用户可感知的卡顿事件；

开启第一定时器，并根据第二调度策略，调整所述CPU的功耗；其中，通过所述第二调度策略调整后的CPU功耗大于通过所述第一调度策略调整后的CPU功耗；所述第一定时器的定时时长为第二预设时长；

当所述第一定时器超过所述第二预设时长时，从所述第二调度策略切换到所述第一调度策略。

2.根据权利要求1所述的方法，其特征在于，在从所述第二调度策略切换到所述第一调度策略之前，所述方法还包括：

确定所述电子设备所处用户场景未发生改变。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：在确定所述卡顿事件是用户可感知的卡顿事件的情况下，将卡顿状态标识设置为第一标识；

其中，所述根据第二调度策略，调整所述CPU的功耗，包括：响应于所述卡顿状态标识为所述第一标识，根据所述第二调度策略，调整所述CPU的功耗。

4.根据权利要求1所述的方法，其特征在于，所述当所述第一定时器超过所述第二预设时长时，从所述第二调度策略切换到所述第一调度策略，包括：

当所述第一定时器超过所述第二预设时长时，将卡顿状态标识设置为第二标识；

响应于所述卡顿状态标识为所述第二标识，从所述第二调度策略切换到所述第一调度策略。

5.根据权利要求1所述的方法，其特征在于，所述卡顿事件的卡顿标记信息包括用于指示卡顿事件类型的标记参数值；

所述根据所述卡顿事件的卡顿标记信息确定所述卡顿事件是用户可感知的卡顿事件，包括：

将所述标记参数值与预设数值按照二进制位进行与运算，得到第一运算结果；

若所述第一运算结果大于零，则确定所述卡顿事件是所述用户可感知的卡顿事件。

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

所述标记参数值为0x400或者0x800，指示的卡顿事件类型为前台发生的卡顿事件；或者，

所述标记参数值为0x20，指示的卡顿事件类型为幻像窗口导致的卡顿事件；或者，

所述标记参数值为0x40，指示的卡顿事件类型为退出窗口时发生的卡顿事件；或者，

所述标记参数值为0x80，指示的卡顿事件类型为处理窗口消息导致的卡顿事件。

7.根据权利要求5所述的方法，其特征在于，所述预设数值的二进制表示为110011100000。

8.根据权利要求1至7中任一项所述的方法，其特征在于，所述第一调度策略包括操作系统OS调度策略以及CPU功耗调度策略；

其中，所述根据所述第一调度策略调整所述CPU的功耗，包括：根据所述第一调度策略中的CPU功耗调度策略调整所述CPU的功耗；

所述方法还包括：根据所述OS调度策略调整所述第一进程的进程优先级、输入/输出I/O优先级。

9.根据权利要求1至7中任一项所述的方法，其特征在于，所述根据所述用户场景以及所述电子设备的系统负载得到第一调度策略，包括：

根据所述用户场景确定第三调度策略，所述第三调度策略包括所述第一进程的第一进程优先级、第一输入/输出I/O优先级，所述CPU的第一长时睿频功耗PL1、第一短时睿频功耗PL2及第一能效比EPP；

根据所述系统负载、所述用户场景及所述第三调度策略得到所述第一调度策略，所述第一调度策略至少包括所述第一进程的第二进程优先级、第二I/O优先级，CPU的第二PL1、第二PL2以及第二EPP；

其中，所述系统负载大于预设的第一数值，所述第二进程优先级高于或等于所述第一进程优先级，所述第二I/O优先级高于或等于第一I/O优先级，所述第二PL1大于所述第一PL1，所述第二PL2大于所述第一PL2，所述第二EPP小于所述第一EPP。

10.根据权利要求9所述的方法，其特征在于，所述第二调度策略包括所述CPU的第三PL1、第三PL2以及第三EPP；

其中，所述第三PL1大于所述第二PL1，所述第三PL2大于所述第二PL2，所述第三EPP小于所述第二EPP。

11.根据权利要求1至7中任一项所述的方法，其特征在于，所述第二调度策略为所述电子设备默认的CPU功耗调度策略。

12.根据权利要求1至7中任一项所述的方法，其特征在于，所述当检测到卡顿事件且所述卡顿事件的卡顿时长大于第一预设时长时，根据所述卡顿事件的卡顿标记信息确定所述卡顿事件是用户可感知的卡顿事件，包括：

在卡顿事件探针检测到卡顿事件且所述卡顿事件的卡顿时长大于所述第一预设时长的情况下，根据所述卡顿事件的卡顿标记信息确定所述卡顿事件是用户可感知的卡顿事件。

13.根据权利要求1至7中任意一项所述的方法，其特征在于，所述外设事件包括键盘输入事件、鼠标输入事件、麦克风输入事件、摄像头输入事件中的一种或多种；

所述根据所述进程信息及所述第一信息确定所述电子设备所处的用户场景，包括：

根据所述进程信息确定所述第一进程的类型；

若所述第一进程的类型为社交类，且检测到所述键盘输入事件，确定所述电子设备所处的用户场景为文字聊天场景；

若所述第一进程的类型为社交类，检测到所述麦克风输入事件，且未检测到所述摄像头输入事件，确定所述电子设备所处的用户场景为语音聊天场景；

若所述第一进程的类型为社交类，检测到所述麦克风输入事件以及所述摄像头输入事件，确定所述电子设备所处的用户场景为视频聊天场景。

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

若所述第一进程的类型为办公类，且检测到所述键盘输入事件，则确定所述电子设备所处的用户场景为文档编辑场景；

若所述第一进程的类型为办公类，检测到所述鼠标输入事件，且未检测到所述键盘输入事件，则确定所述电子设备所处的用户场景为文档浏览场景；

若所述第一进程的类型为办公类，检测到所述麦克风输入事件以及所述摄像头输入事件，则确定所述电子设备所处的用户场景为视频会议场景。

15.一种电子设备，其特征在于，所述电子设备包括：存储器和一个或多个处理器；

其中，所述存储器用于存储计算机程序代码，所述计算机程序代码包括计算机指令；当所述计算机指令被所述处理器执行时，使得所述电子设备执行如权利要求1至14中任一项所述的方法。

16.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至14中任一项所述的方法。