CN116025580A - 调节风扇转速的方法和电子设备 - Google Patents

Abstract

本申请实施例提供了一种调节风扇转速的方法和电子设备，该方法由电子设备执行，电子设备包括风扇，该方法包括：在检测到电子设备处理的业务所对应的用户场景发生变化的情况下，基于获取到的电子设备的当前温度、当前用户场景和第一关联关系，确定电子设备的当前温度对应的风扇目标转速，第一关联关系指示多个第一信息、电子设备的多个温度与风扇的多个转速之间的对应关系，第一信息包括用户场景；根据风扇目标转速，调节风扇的当前转速。该方法可以结合电子设备的用户场景对风扇转速进行调节，较大程度满足了电子设备的实际需求。

Description

调节风扇转速的方法和电子设备

技术领域

本申请涉及电子技术领域，具体涉及一种调节风扇转速的方法和电子设备。

背景技术

随着电子设备的迅速发展，其对各个器件的性能需求也越来越高。风扇是电子设备(如个人计算机(personal computer，PC)、笔记本电脑)中最为核心的散热器件，风扇转速的调节对电子设备的性能、续航以及各芯片器件的安全性有着举足轻重的影响，因此，需要适时的调节风扇转速。

当前风扇转速的调节方案通常是根据电子设备的温度确定风扇的转速，然而这种调节方式比较单一，不能满足电子设备的实际需求。

发明内容

本申请提供了一种调节风扇转速的方法和电子设备，能够按照电子设备的实际需求调节风扇转速。

第一方面，本申请提供一种调节风扇转速的方法，该方法由电子设备执行，电子设备包括风扇，该方法包括：

在检测到电子设备处理的业务所对应的用户场景发生变化的情况下，基于获取到的电子设备的当前温度、当前用户场景和第一关联关系，确定电子设备的当前温度对应的风扇目标转速，第一关联关系指示多个第一信息、电子设备的多个温度与风扇的多个转速之间的对应关系，第一信息包括用户场景；

根据风扇目标转速，调节风扇的当前转速。

在该实现方式中，电子设备中存储有第一关联关系，该第一关联关系指示的是多个用户场景、电子设备的多个温度以及风扇的多个转速之间的对应关系，那么电子设备通过当前温度和当前用户场景，便可以确定当前温度对应的风扇目标转速，进而可以根据该风扇目标转速调节风扇的当前转速。

在一个实现方式中，上述第一关联关系可以为一个数据表，该数据表中的一条记录为一个用户场景与电子设备的一个温度区间、风扇的一个转速(可以包括左风扇的转速和右风扇的转速)的对应关系。

在另一个实现方式中，上述第一关联关系可以为一个数据表，该数据表具有三个维度，一个维度表征用户场景、另一个维度表征电子设备的温度区间、又一个维度表征风扇的转速，一个用户场景与一个温度区间对应有一个风扇的转速。

在又一个实现方式中，上述第一关联关系中还可以包括两个子关联关系，第一子关联关系的个数为多个，指示电子设备的多个温度以及风扇的多个转速之间的对应关系，第二子关联关系指示多个用户场景与多个第一子关联关系之间的对应关系。

示例性地，假设当前用户场景为V1，通过第二子关联关系，电子设备可以确定V1对应的第一子关联关系，也即确定了V1场景下的电子设备的多个温度以及风扇的多个转速之间的对应关系。然后，假设电子设备的当前温度为40℃，则可以通过该第一子关联关系确定40℃对应的风扇转速。

可选地，上述所获取的电子设备的温度为CPU的温度。

可选地，上述调节风扇的当前转速的方式为脉冲宽度调制PWM方式。

上述实现方式中，电子设备在确定用户场景发生变化的情况下，根据当前用户场景及电子设备的当前温度确定风扇目标转速，也即考虑到不同用户场景下电子设备的实际需求不同，以此对风扇转速进行调节。由此可结合电子设备的用户场景对风扇转速进行调节，较大程度满足了电子设备的实际需求。

结合第一方面，在第一方面的有些实现方式中，上述根据风扇目标转速，调节风扇的当前转速，包括：在获取到的风扇的当前转速和风扇目标转速之间的差值大于预设差值的情况下，根据风扇目标转速，调节风扇的当前转速。

该实现方式中，因风扇会受到外界因素的影响，其转速可能会存在一些波动，因此，为减少电子设备频繁调节风扇转速产生的功耗，本申请可以只在风扇的当前转速与风扇目标转速之间的差值大于预设差值(例如预设差值为50rpm)的情况下对风扇转速进行调节，而在当前转速与风扇目标转速之间的差值不大于预设差值的情况下不进行调节。

结合第一方面，在第一方面的有些实现方式中，上述任意用户场景与多个温度中的部分温度、多个转速中的部分转速对应。

因上述第一关联关系中包括多个用户场景、多个温度和多个转速之间的对应关系，那么，对于某一个用户场景，其对应的是该第一关联关系中的部分温度和部分转速，该部分温度和部分转速对应的是同一个用户场景。

结合第一方面，在第一方面的有些实现方式中，上述第一信息还包括电子设备的系统负载，基于获取到的电子设备的当前温度、当前用户场景和第一关联关系，确定电子设备的当前温度对应的风扇目标转速，包括：

基于电子设备的当前温度、当前用户场景、电子设备的当前系统负载和第一关联关系，确定电子设备的当前温度对应的风扇目标转速。

该实现方式中，考虑到电子设备在不同的系统负载下所产生的功耗不同、电子设备的温度也会不同的情况，那么电子设备所要调节的风扇转速也可能不同，因此，本申请在确定当前温度对应的风扇目标转速时，还可以同时考虑电子设备的当前系统负载。可以理解，上述第一关联关系即包括了多个用户场景、多个系统负载、电子设备的多个温度与风扇的多个转速之间的对应关系。

在一个实现方式中，上述第一关联关系中还可以包括两个子关联关系，第一子关联关系的个数为多个，指示电子设备的多个温度以及风扇的多个转速之间的对应关系，第二子关联关系指示多个用户场景、多个系统负载与多个第一子关联关系之间的对应关系。

示例性地，假设当前用户场景为V1，当前系统负载为中级，通过第二子关联关系，电子设备可以确定V1及中级负载对应的第一子关联关系，也即确定了V1场景及中级负载下的电子设备的多个温度以及风扇的多个转速之间的对应关系。然后，假设电子设备的当前温度为40℃，则可以通过该第一子关联关系确定40℃对应的风扇转速。

上述实现方式中，电子设备在确定用户场景发生变化的情况下，除了考虑当前用户场这一因素之外，电子设备还考虑到当前系统负载，也即考虑到不同用户场景和不同系统负载下电子设备的实际需求不同，以此对风扇转速进行调节。由此可进一步满足电子设备的实际需求。

结合第一方面，在第一方面的有些实现方式中，一个用户场景对应多个系统负载，每个系统负载与多个温度中的部分温度、多个转速中的部分转速对应。

可以理解，在一个用户场景下，可以对应有不同的系统负载，比如在会议场景下电子设备还运行有多个其他进程，因此可以将系统负载等级划分为轻级、中级和重级，每个用户场景都可以对应有多个系统负载。在一个用户场景的某个系统负载下，其还可以对应有部分温度和部分转速，该部分温度和部分转速对应的是同一个用户场景的同一个系统负载。

结合第一方面，在第一方面的有些实现方式中，在基于获取到的电子设备的当前温度、当前用户场景和第一关联关系，确定电子设备的当前温度对应的风扇目标转速之前，方法还包括：按照预设频率获取电子设备的温度，得到电子设备的当前温度。

因电子设备的温度会随时发生变化，而不同温度对应的风扇转速不同，因此，为尽可能适应电子设备的温度随时变化的场景，电子设备可以按照预设频率(例如1次/秒)获取电子设备的温度，并根据上述第一关联关系确定该温度下的风扇转速，以对风扇转速进行调节。

结合第一方面，在第一方面的有些实现方式中，上述检测到电子设备处理的业务所对应的用户场景发生变化，包括：获取电子设备当前显示的第一窗口对应的第一进程的进程信息及第一信息，第一信息包括以下信息中的至少一种：第一进程的GPU占用信息、外设事件信息或电源模式信息；根据第一进程的进程信息及第一信息确定当前用户场景的场景标识；在当前用户场景的场景标识与上一用户场景的场景标识不同的情况下，确定用户场景发生变化。

此实现方式中，电子设备可以通过当前显示窗口的进程信息及第一信息，确定当前用户场景，若当前用户场景和上一用户场景不同，则可认为用户场景发生了变化。例如，若第一进程的类型为视频类，第一进程的GPU占用率大于0，且GPU引擎为GPU视频进程引擎，确定电子所处的用户场景为视频播放场景。可以理解地，若第一进程的类型为视频类，则可以先确定用户当前正在使用视频类应用。若第一进程的GPU占用率大于0，则表明第一进程运行过程中有占用GPU的资源。若第一进程的GPU引擎为GPU video processing(视频进程)引擎，则表明第一进程在运行过程中使用GPU进行解码操作。如此，可以确定用户大概率在使用电子设备进行播放视频，即电子所处的用户场景为视频播放场景。

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

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

结合第一方面，在第一方面的有些实现方式中，上述外设事件信息可以包括键盘输入事件、鼠标输入事件、麦克风输入事件、摄像头输入事件中的一种或多种；

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

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

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

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

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

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

结合第一方面，在第一方面的有些实现方式中，电子设备还包括场景识别引擎、调度引擎、基本输入输出系统BIOS和嵌入式控制器EC，上述方法包括：

场景识别引擎在检测到电子设备处理的业务所对应的用户场景发生变化的情况下，向调度引擎发送当前用户场景的场景标识；

调度引擎根据当前用户场景的场景标识、电子设备的当前系统负载以及第二关联关系，确定第一调节策略表，第二关联关系指示多个用户场景标识、多个系统负载与多个调节策略表之间的对应关系，第一调节策略表指示电子设备的多个温度与风扇的多个转速之间的对应关系；

调度引擎向BIOS发送第一调节策略表；

BIOS向EC发送第一调节策略表；

EC基于获取到的电子设备的当前温度和第一调节策略表，确定电子设备的当前温度对应的风扇目标转速；

在获取到的风扇的当前转速和风扇目标转速之间的差值大于预设差值的情况下，EC根据风扇目标转速调节风扇的当前转速。

上述实现方式中，电子设备通过确定用户场景是否发生变化，并在用户场景发生变化时，根据当前用户场景和系统负载确定对应的调节策略表，然后根据当前CPU温度确定不同用户场景下的风扇转速，以对风扇转速进行调节。由此可结合电子设备的用户场景对风扇转速进行调节，较大程度满足了电子设备的实际需求。

第二方面，本申请提供一种装置，该装置包含在电子设备中，该装置具有实现上述第一方面及上述第一方面的可能实现方式中电子设备行为的功能。功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或单元。例如，接收模块或单元、处理模块或单元等。

第三方面，本申请提供一种电子设备，电子设备包括：处理器、存储器和接口；处理器、存储器和接口相互配合，使得电子设备执行第一方面的技术方案中任意一种方法。

第四方面，本申请提供一种芯片，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。

可选地，芯片还包括存储器，存储器与处理器通过电路或电线连接。

进一步可选地，芯片还包括通信接口。

第五方面，本申请提供一种计算机可读存储介质，计算机可读存储介质中存储了计算机程序，当计算机程序被处理器执行时，使得该处理器执行第一方面的技术方案中任意一种方法。

第六方面，本申请提供一种计算机程序产品，计算机程序产品包括：计算机程序代码，当计算机程序代码在电子设备上运行时，使得该电子设备执行第一方面的技术方案中任意一种方法。

附图说明

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

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

图3是本申请实施例提供的一例电子设备中软件模块间的交互示意图；

图4是本申请实施例提供的另一例电子设备中软件模块间的交互示意图；

图5是本申请实施例提供的一例调节风扇转速的方法的流程示意图；

图6是本申请实施例提供的一例调节风扇转速的方法的信令交互示意图；

图7是本申请实施例提供的另一例调节风扇转速的方法的信令交互示意图；

图8是本申请实施例提供的一例窗口变化界面图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“多个”是指两个或多于两个。

以下，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”、“第三”的特征可以明示或者隐含地包括一个或者更多个该特征。

当前，诸多电子设备上都安装有风扇，风扇是电子设备中最为核心的散热器件，风扇转速通常与电子设备的温度(例如CPU温度)具有对应关系，电子设备的温度越高，则需要风扇转速越大以降低电子设备的温度；比如，CPU温度为40℃时，风扇转速为2000rpm；CPU温度为50℃时，风扇转速为5000rpm。但是传统技术的这种对应关系比较单一，并不能满足电子设备的实际用户场景，例如，在不同的用户场景下，用户对风扇转速有不同的需求：在办公场景下，用户可能希望环境尽可能的安静，这时就需要风扇以较低的速率运转，而在游戏场景下则需要以较高的速率运转以满足更快的散热需求。

有鉴于此，本申请实施例提供的一种调节风扇转速的方法，可以应用于笔记本电脑、PC、超级移动个人计算机(ultra-mobile personal computer，UMPC)等电子设备上，该方法可以先识别电子设备的用户场景，根据用户场景和电子设备的当前温度共同确定如何调节风扇转速，由此较大程度的满足了电子设备的实际需求，也提升了用户的使用体验。

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

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

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

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

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

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

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

可以理解的是，本实施例示意的结构并不构成对电子设备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)接口，脉冲编码调制(pulsecodemodulation，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包括显示面板。风扇170用于为电子设备散热，例如为CPU进行散热。

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

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

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

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

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

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

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

场景识别引擎可以识别电子设备100所处的用户场景。调度引擎可以获取电子设备100的负载情况，并结合电子设备100的负载情况及电子设备100的用户场景确定电子设备的温度与风扇转速的对应关系(以下可称为table)。其中，关于场景识别引擎和调度引擎的具体内容见后文，在此暂不描述。

子系统动态链接库包括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的信息。

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

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

设备驱动程序运行在内核模式下，为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)中读写系统设置的具体信息。其主要功能是为计算机提供最底层的、最直接的硬件设置和控制。例如，IntelDTT驱动可以通过BIOS向CPU发送指令的。可选地，固件层还可以包括嵌入式控制器(embedded controller，EC)，其可以接收硬件层传递的参数，并进行相应处理后发送至BIOS，由BIOS再向上层传递。本申请实施例中，EC还可以根据上层传递的table确定电子设备在当前温度下对应的风扇转速，并相应的调节风扇转速。

硬件层可以包括GPU、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处于社交场景。通常情况下，场景识别模块通过上述探针状态确定到电子设备的用户场景发生变化时(例如探针状态发生变化可认为用户场景发生变化)，可以确定电子设备当前所处的用户场景。

如图3所示，调度引擎包括负载管控器。其中，负载管控器可接收场景识别模块发送的用户场景信息。负载管控器还可从系统探针模块获取系统负载，并根据系统负载和用户场景确定当前对应的table。

负载管控器确定了当前对应的table后，可以将该table经由WMI插件发送至BIOS，再由BIOS发送至EC，EC根据电子设备的温度在table中查找到对应的风扇转速，进而根据该风扇转速对风扇进行调节。

由上述图3的工作流程可知，本申请实施例所提供的调节风扇转速的方法，主要包括两个过程，分别为：(1)确定电子设备所处的用户场景发生变化；(2)根据用户场景和系统负载确定对应的table；(3)根据电子设备的温度在对应的table中查找对应的风扇转速。下面将结合附图分别说明上述两个过程。可以理解，这两个过程可由图1所示的电子设备执行，也可由图3所示的电子设备中各模块执行。

为更方便了解本申请实施例提供的调节风扇转速的方法，先结合上述图3简化说明本申请实施例涉及的软件架构，如图4所示，该软件架构包括：场景识别引擎、调度引擎、BIOS、EC和风扇。

其中，场景识别引擎识别到电子设备所处的用户场景发生变化后，将当前的用户场景信息发送至调度引擎。调度引擎根据当前用户场景和系统负载确定对应的table，并将该table经由WMI插件发送至BIOS，再由BIOS发送至EC。EC通常会按照固定时间间隔(一般为1秒)读取电子设备的温度，本申请实施例，电子设备的温度可以为CPU温度，为方便理解，以下实施例都以CPU温度为例进行说明。当EC读取到CPU温度后，便可从对应的table中获取该CPU温度对应的风扇转速，进而根据该风扇转速调整风扇的运转速度。

可以理解，因电子设备的用户场景不同，那么对于不同的table，同一个CPU温度可能对应的是不同的风扇转速。例如在一个table中，CPU温度为40℃时，风扇转速为2000rpm；另一个table中，CPU温度为40℃时，风扇转速为3000rpm。还可以理解，在电子设备的用户场景没有发生变化时，电子设备会持续使用同一个table来获取CPU温度对应的风扇转速。

下面介绍本申请实施例提供的调节风扇转速的方法的具体过程，如图5所示，该方法可以由电子设备执行，包括：

S1、在检测到电子设备所处的用户场景发生变化的情况下，根据当前用户场景的场景标识和系统负载确定对应的调节策略表。

其中，确定电子设备的用户场景发生变化的过程详见下述实施例的描述。可选地，电子设备在确定用户场景发生变化时，可以设置一个标识，例如标识1表示场景发生变化。可选地，当前用户场景的场景标识可以为场景号、场景名称等可以唯一标识一个场景的信息。

其中，电子设备中可以存储有不同用户场景的场景标识、不同系统负载下对应的调节策略表(即table)，那么，电子设备便可以根据当前用户场景的场景标识和系统负载确定当前对应的table。

可以理解，系统负载可以是处于可运行状态的进程和不可中断状态的进程的平均数。可运行状态的进程指正在使用CPU或者等待使用CPU的进程。不可中断状态的进程为等待I/O访问(例如，磁盘I/O)的进程。可选地，系统负载可以分为轻负载、中负载、重负载，可选地，系统负载可以由进程管理器所获取。

示例性地，不同用户场景的场景标识、不同系统负载下对应的table可以参见表1。例如，在社交场景下，轻负载对应的是table1，中负载对应的是table2、重负载对应的是table3；在视频场景下，轻负载对应的是table4，中负载对应的是table5、重负载对应的是table6，等等。

表1

由上述可知，在table中存储的是CPU温度与风扇转速之间的对应关系，示例性地，table1的存储数据可以参见表2。

表2 table1

由表2可知，不同的CPU温度区间对应有不同的风扇转速。例如，当CPU温度处于[44℃，47℃]区间时，左风扇转速为2530rmp，右风扇转速为2330rpm；当CPU温度处于[46℃，48℃]区间时，左风扇转速为2950rmp，右风扇转速为2750rpm等等。由表2可以看出，CPU温度所设置的区间之间具有重叠，这是为了避免频繁的调节风扇转速而增加调节功耗；示例性地，当CPU温度为45℃时，其左风扇转速为2530rmp，右风扇转速为2330rpm，若CPU温度升高至48℃时，需要将左风扇转速调节为2950rmp，右风扇转速调节为2750rpm；若CPU温度又降低为47℃，因其还是在[46℃，48℃]区间，则并不需要再调节风扇转速，但是如果CPU温度所设置的区间没有重叠，则可能就需要再调节风扇转速，大大增加了调节功耗。

由表1和表2还可知，不同的用户场景、不同的系统负载下对应的table不同，不同的table中的对应关系也不同。因此，在不同的用户场景下，同一CPU温度对应的风扇转速也不同。

可选地，在一些实现方式中，电子设备在检测到所处的用户场景发生变化的情况下，也可只根据当前用户场景的场景标识确定对应的调节策略表，即上述表1中只包含有用户场景与table的对应关系。

S2、获取CPU的当前温度。

在本申请实施例中，电子设备可以按照固定时间间隔(例如1秒)持续的获取CPU温度，在一个可实现的方式中，电子设备可通过放置于CPU旁边的热敏电阻来获取CPU温度。

S3、根据CPU的当前温度和上述确定的table，确定是否需要调节风扇转速，若是，执行S4，若否，在固定时间间隔后执行S2。

其中，对于判断是否需要调节风扇转速的方式为：首先确定当前CPU温度在上述确定的table中所对应的风扇目标转速，然后再判断当前风扇转速是否达到风扇目标转速。如果当前风扇转速已达到风扇目标转速，则不需要再调节风扇转速，电子设备可继续获取下一个时间点的CPU温度，判断下一个时间点的风扇转速是否达到下一个CPU温度所对应的风扇目标转速，以此类推。如果当前风扇转速未达到风扇目标转速，则需要调节风扇转速。

或者，因风扇会受到外界因素的影响，其转速可能会存在一些波动，因此，为减少电子设备频繁调节风扇转速产生的功耗，如果当前风扇转速与风扇目标转速之间的差值大于预设差值(例如预设差值为50rpm)，则需要调节风扇转速；如果当前风扇转速与风扇目标转速之间的差值不大于预设差值，则不需要再调节风扇转速。

此步骤确定CPU的当前温度在上述确定的table中所对应的风扇目标转速的过程可以为：假设上述确定的table即为表2，首先确定CPU的当前温度位于上述表2中的哪个区间，因上述表2中CPU温度所设置的区间之间具有重叠，因此，本次确定CPU的当前温度位于哪个区间时，可以参考上一CPU温度所在的区间。例如，上一CPU温度所在的区间为[47℃，50℃]，若当前CPU温度为50℃，即和上一CPU温度位于同一区间，则确定当前CPU温度还是位于[47℃，50℃]；若当前CPU温度为51℃，即和上一CPU温度没有位于同一区间，则确定当前CPU温度为[47℃，50℃]区间之后的第一个区间，即[48℃，54℃]。待确定了CPU的当前温度位于哪个温度区间之后，便可获取到该温度区间对应的风扇目标转速。

S4、根据CPU的当前温度对应的风扇目标转速调节当前风扇转速。

可以理解，若当前风扇转速大于风扇目标转速，则需要降低当前风扇转速；若当前风扇转速小于风扇目标转速，则需要提高当前风扇转速。示例性地，若当前CPU温度为50℃，则风扇目标转速为：左风扇转速3300rpm、右风扇转速3080rpm，然后根据当前风扇转速与风扇目标转速的大小进行调节。

目前对风扇进行调速的方式主要为脉冲宽度调制(pulse width modulation，PWM)方式，PWM是一种将数字转换为模拟信号的模块。本申请实施例中可以通过EC控制器来调节风扇转速，那么，EC控制器对PWM输入的是数字，通过PWM输出脉冲信号。其中，所输入的数字可以为高低压占空比(该高低压占空比可由上述风扇目标转速所确定)，脉冲信号为通过该高低压占空比调整风扇电机的功率的信号，由此EC根据该信号调整风扇转速。示例性地，若一个风扇的最大转速为5000rpm，目标转速为2500rpm，则需要风扇电机输出50％的功率，即可以通过调整高低压占空比使风扇电机输出50％的功率。

由上述过程可知，若电子设备的用户场景不再发生变化，则所对应的table也不变，之后电子设备可根据不同时间点的CPU温度直接从该table中获取对应的风扇目标转速即可。若电子设备的用户场景再次发生变化，则需要重新确定新的table，之后电子设备可根据不同时间点的CPU温度从新的table中获取对应的风扇目标转速。

本申请实施例中，电子设备通过确定用户场景是否发生变化，并在用户场景发生变化时，根据当前用户场景和系统负载确定对应的调节策略表，然后根据当前CPU温度确定不同用户场景下的风扇转速，以对风扇转速进行调节。由此可结合电子设备的用户场景对风扇转速进行调节，较大程度满足了电子设备的实际需求。

结合上述图4的软件架构和图5所示的流程图，下面再以一个实施例介绍本申请实施例提供的调节风扇转速的方法，如图6所示，具体可以包括：

S11、场景识别引擎在检测到电子设备所处的用户场景发生变化的情况下，将当前用户场景的场景标识发送至调度引擎。

其中，场景识别引擎确定电子设备的用户场景发生变化的过程可参见下述图7所示的实施例的过程。场景识别引擎确定了电子设备的用户场景发生变化后，还可以确定当前用户场景的场景标识，例如当前用户场景的场景号或场景名称。

S12、调度引擎根据当前用户场景的场景标识和系统负载确定对应的调节策略表。

其中，调度引擎确定对应的调节策略表的过程可以参见上述S2。可选地，可以由调度引擎中的负载管理器根据当前用户场景的场景标识和系统负载确定调节策略表。

在一个实现方式中，调度引擎获取系统负载的方式可以为：负载管控器向系统探针模块发送获取系统负载的请求，系统探针模块向进程管理器发送获取系统负载的请求，进程管理器获取系统负载。在一种可选的实现方式中，也可以由OsEventDriver节点向进程管理器转发系统负载探针的获取系统负载的请求。

S13、调度引擎将调节策略表发送至BIOS。

可以理解，调度引擎可以通过WMI通道向BIOS发送调节策略表。

S14、BIOS将调节策略表发送至EC。

其中，BIOS可以通过I/O接口向EC发送上述调节策略表。

S15、EC按照固定时间间隔获取CPU温度。

这里可将每次获取的CPU温度记为CPU的当前温度。

S16、EC根据CPU的当前温度和上述确定的table，确定是否需要调节风扇转速。若是，执行S17；若否，执行S15。

S17、EC根据CPU的当前温度对应的风扇目标转速调节当前风扇转速。

具体地，S16步骤的具体实现过程可以为：EC根据CPU的当前温度，从table中查找到该当前温度对应的风扇目标转速；获取当前风扇转速，若当前风扇转速不等于风扇目标转速，或者当前风扇转速与风扇目标转速之间的差值大于预设差值(例如预设差值为50rpm)，则确定需要调节风扇转速。可选地，EC可以从一些应用程序中获取当前风扇转速，该应用程序具有风扇转速监测功能。

在一个实施例中，因场景识别引擎中的系统探针模块会实时接收下层事件，那么若场景识别引擎再次检测到电子设备所处的用户场景发生了变化，则继续从S11开始执行，以确定新的调节策略表。

在另一个实施例中，因电子设备在同一用户场景下，系统负载也可能会发生变化，那么若负载管理器接收到进程管理器上传的系统负载后，确定系统负载发生了变化，则可以再根据当前用户场景的场景标识和新的系统负载确定新的调节策略表。

本申请实施例中，电子设备通过确定用户场景是否发生变化，并在用户场景发生变化时，根据当前用户场景和系统负载确定对应的调节策略表，然后根据当前CPU温度确定不同用户场景下的风扇转速，以对风扇转速进行调节。由此可结合电子设备的用户场景对风扇转速进行调节，较大程度满足了电子设备的实际需求。

上述实施例是以表1的对应关系来确定当前用户场景及当前系统负载下的table，再根据表2的table内容确定当前CPU温度对应的风扇目标转速的过程，但本申请实施例并不限于只采用该方式来确定风扇目标转速，只要能将用户场景、系统负载、CPU温度以及风扇转速对应起来即可。

在一个实施例中，电子设备中可以存储有第一关联关系，该第一关联关系指示的是多个用户场景、多个CPU温度以及多个风扇转速之间的对应关系，那么电子设备通过当前CPU温度和当前用户场景，便可以确定当前CPU温度对应的风扇目标转速，进而可以根据该风扇目标转速调节风扇的当前转速。

示例性地，第一关联关系可以如表3所示：

表3

由表3可以看出，同一个用户场景下，在不同的CPU温度区间对应有不同的风扇转速。对于不同的用户场景，在相同的CPU温度区间对应有不同的风扇转速。例如，在社交场景下，当CPU温度处于[44℃，47℃]区间时，左风扇转速为2530rmp，右风扇转速为2330rpm；而在视频场景下，当CPU温度处于[44℃，47℃]区间时，左风扇转速为2730rmp，右风扇转速为2530rpm，这是因为视频场景产生的功耗通常大于社交场景产生的功耗，CPU温度可能会升高的较快，因此需要更大的风扇转速来降低CPU温度。

在另一个实施例中，电子设备中可以存储有第一关联关系，该第一关联关系指示的是多个用户场景、多个系统负载、多个CPU温度以及多个风扇转速之间的对应关系，那么电子设备通过当前CPU温度和当前用户场景，便可以确定当前CPU温度对应的风扇目标转速，进而可以根据该风扇目标转速调节风扇的当前转速。

示例性地，第一关联关系可以如表4所示；可以理解，该表4可以为上述表1和表2的结合。

由表4可知，同一个用户场景下，对于不同的系统负载，同一CPU温度区间对应有不同的风扇转速。例如，社交场景下，在轻负载时，当CPU温度处于[44℃，47℃]区间时，左风扇转速为2530rmp，右风扇转速为2330rpm；在中负载时，当CPU温度处于[44℃，47℃]区间时，左风扇转速为2630rmp，右风扇转速为2430rpm。这是因为系统负载越重时，所产生的功耗会越大，CPU温度可能会升高的较快，因此需要更大的风扇转速来降低CPU温度。

对于不同的用户场景，在相同负载情况下，相同的CPU温度区间也对应有不同的风扇转速，其具体原因可参见上述描述，在此不再赘述。

表4

需要说明的是，本申请实施例中上述第一关联关系的存储形式并不限于表3和表4的形式，对于其他可表征该关联关系的存储形式都可支持。

对于上述S11的过程，以电子设备从办公场景变换为视频场景为例，如图7所示，其确定电子设备所处的用户场景发生变化的流程如下：

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之间没有严格的先后顺序，其可以按照图7中所示的顺序依次执行，也可以同时执行，也可以按照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节点向系统探针模块上报进程创建事件。

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

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

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

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

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

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

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

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

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

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

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

表5

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

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

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

在本步骤中，通过第一进程所属的类型，可以确定电子设备所处的用户场景的类型。例如，若确定第一进程所属的类型为视频类，则可以确定电子设备处于视频场景；又例如，若确定第一进程所属的类型为游戏类，则可以确定电子设备处于游戏场景。并且，由于第一进程的名称和第二进程的名称不一致，则可以确定电子设备的用户场景发生了变化。

为了进一步分析用户需求，场景识别模块还可以进一步结合其他参数(例如，外设事件、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引擎，则执行S136；若第一进程的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。另外，场景识别引擎获取第一进程的类型的过程可以参阅图5中S101、S102、S105、S106～S114，场景识别引擎判断第一进程的GPU占用率是否大于0且第一进程的GPU引擎是否为GPU 3D引擎的过程参阅S124～S135。区别在于将视频应用更换为游戏应用，在此不再赘述。

综上，在执行上述过程后，电子设备可以确定用户场景已从办公场景变化为了视频场景，则可以执行后续确定对应的调节策略表的过程。

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

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

需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。

本实施例提供的电子设备，用于执行上述调节风扇转速的方法，因此可以达到与上述实现方法相同的效果。

在采用集成的单元的情况下，电子设备还可以包括处理模块、存储模块和通信模块。其中，处理模块可以用于对电子设备的动作进行控制管理。存储模块可以用于支持电子设备执行存储程序代码和数据等。通信模块，可以用于支持电子设备与其他设备的通信。

其中，处理模块可以是处理器或控制器。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理(digital signal processing，DSP)和微处理器的组合等等。存储模块可以是存储器。通信模块具体可以为射频电路、蓝牙芯片、Wi-Fi芯片等与其他电子设备交互的设备。

在一个实施例中，当处理模块为处理器，存储模块为存储器时，本实施例所涉及的电子设备可以为具有图1所示结构的设备。

本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质中存储了计算机程序，当计算机程序被处理器执行时，使得处理器执行上述任一实施例的调节风扇转速的方法。

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

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

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

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

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

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

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

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

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

Claims (12)

1.一种调节风扇转速的方法，其特征在于，所述方法由电子设备执行，所述电子设备包括风扇，所述方法包括：

在检测到所述电子设备处理的业务所对应的用户场景发生变化的情况下，基于获取到的所述电子设备的当前温度、当前用户场景和第一关联关系，确定所述电子设备的当前温度对应的风扇目标转速，所述第一关联关系指示多个第一信息、所述电子设备的多个温度与所述风扇的多个转速之间的对应关系，所述第一信息包括用户场景；

根据所述风扇目标转速，调节所述风扇的当前转速。

2.根据权利要求1所述的方法，其特征在于，所述根据所述风扇目标转速，调节所述风扇的当前转速，包括：

在获取到的所述风扇的当前转速和所述风扇目标转速之间的差值大于预设差值的情况下，根据所述风扇目标转速，调节所述风扇的当前转速。

3.根据权利要求1或2所述的方法，其特征在于，任意用户场景与所述多个温度中的部分温度、所述多个转速中的部分转速对应。

4.根据权利要求1至3中任一项所述的方法，其特征在于，所述第一信息还包括所述电子设备的系统负载，所述基于获取到的所述电子设备的当前温度、当前用户场景和第一关联关系，确定所述电子设备的当前温度对应的风扇目标转速，包括：

基于所述电子设备的当前温度、所述当前用户场景、所述电子设备的当前系统负载和所述第一关联关系，确定所述电子设备的当前温度对应的风扇目标转速。

5.根据权利要求4所述的方法，其特征在于，一个用户场景对应多个系统负载，每个系统负载与所述多个温度中的部分温度、所述多个转速中的部分转速对应。

6.根据权利要求1至5中任一项所述的方法，其特征在于，在所述基于获取到的所述电子设备的当前温度、当前用户场景和第一关联关系，确定所述电子设备的当前温度对应的风扇目标转速之前，所述方法还包括：

按照预设频率获取所述电子设备的温度，得到所述电子设备的当前温度。

7.根据权利要求1至6中任一项所述的方法，其特征在于，所述电子设备的当前温度为所述电子设备中CPU的当前温度。

8.根据权利要求1至7中任一项所述的方法，其特征在于，调节所述风扇的当前转速的方式为脉冲宽度调制PWM方式。

9.根据权利要求1至8中任一项所述的方法，其特征在于，所述检测到所述电子设备处理的业务所对应的用户场景发生变化，包括：

获取所述电子设备当前显示的第一窗口对应的第一进程的进程信息及第一信息，所述第一信息包括以下信息中的至少一种：所述第一进程的GPU占用信息、外设事件信息或电源模式信息；

根据所述第一进程的进程信息及所述第一信息确定所述当前用户场景的场景标识；

在所述当前用户场景的场景标识与上一用户场景的场景标识不同的情况下，确定所述用户场景发生变化。

10.根据权利要求1所述的方法，其特征在于，所述电子设备还包括场景识别引擎、调度引擎、基本输入输出系统BIOS和嵌入式控制器EC，所述方法包括：

所述场景识别引擎在检测到所述电子设备处理的业务所对应的用户场景发生变化的情况下，向所述调度引擎发送所述当前用户场景的场景标识；

所述调度引擎根据所述当前用户场景的场景标识、所述电子设备的当前系统负载以及第二关联关系，确定第一调节策略表，所述第二关联关系指示多个用户场景标识、多个系统负载与多个调节策略表之间的对应关系，所述第一调节策略表指示所述电子设备的多个温度与所述风扇的多个转速之间的对应关系；

所述调度引擎向所述BIOS发送所述第一调节策略表；

所述BIOS向所述EC发送所述第一调节策略表；

所述EC基于获取到的所述电子设备的当前温度和所述第一调节策略表，确定所述电子设备的当前温度对应的风扇目标转速；

在获取到的所述风扇的当前转速和所述风扇目标转速之间的差值大于预设差值的情况下，所述EC根据所述风扇目标转速调节所述风扇的当前转速。

11.一种电子设备，其特征在于，包括：

一个或多个处理器；

一个或多个存储器；

所述存储器存储有一个或多个程序，当所述一个或者多个程序被所述处理器执行时，使得所述电子设备执行如权利要求1至10中任一项所述的方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储了计算机程序，当所述计算机程序被处理器执行时，使得所述处理器执行权利要求1至10中任一项所述的方法。

Images