WO2025200014A1 - 散热控制方法和电子设备 - Google Patents

散热控制方法和电子设备

Info

Publication number
WO2025200014A1
WO2025200014A1 PCT/CN2024/085043 CN2024085043W WO2025200014A1 WO 2025200014 A1 WO2025200014 A1 WO 2025200014A1 CN 2024085043 W CN2024085043 W CN 2024085043W WO 2025200014 A1 WO2025200014 A1 WO 2025200014A1
Authority
WO
WIPO (PCT)
Prior art keywords
scenario
electronic device
fan
application
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2024/085043
Other languages
English (en)
French (fr)
Inventor
王安龙
马鹏飞
胡秀银
徐可
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202480041025.8A priority Critical patent/CN121488225A/zh
Priority to PCT/CN2024/085043 priority patent/WO2025200014A1/zh
Publication of WO2025200014A1 publication Critical patent/WO2025200014A1/zh
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • F—MECHANICAL ENGINEERING; LIGHTING; HEATING; WEAPONS; BLASTING
    • F04—POSITIVE - DISPLACEMENT MACHINES FOR LIQUIDS; PUMPS FOR LIQUIDS OR ELASTIC FLUIDS
    • F04D—NON-POSITIVE-DISPLACEMENT PUMPS
    • F04D27/00—Control, e.g. regulation, of pumps, pumping installations or pumping systems specially adapted for elastic fluids
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/16—Constructional details or arrangements
    • G06F1/20—Cooling means
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]

Definitions

  • the present application relates to the field of electronic technology, and in particular to a heat dissipation control method and electronic equipment.
  • cooling control strategies implemented in their systems. These strategies include, but are not limited to, power control, brightness control, and fan control. These strategies are used to control the operating frequency of components, screen brightness, and fan speed, respectively, to achieve heat dissipation.
  • the present application provides a heat dissipation control method and an electronic device, which can improve the heat dissipation control effect and enhance the user experience.
  • the present application provides a heat dissipation control method, which is executed by an electronic device, the electronic device including a fan and a keyboard, the method comprising: when a first application is running in the background, at a first moment, starting a second application and displaying a window of the second application, before the first moment, the fan speed is a first speed, and after the first moment, the window of the second application is a focus window; after the first moment, the fan speed is set to a second speed; after the fan speed is set to the second speed, within a first time period, when the first area or the second area of the keyboard is tapped, the fan speed remains unchanged; after the first time period, uninstalling the first application; after uninstalling the first application, within a second time period, when the first area of the keyboard is tapped, the fan speed is set to a third speed.
  • the first application is also the preset APP in the specific implementation.
  • the first application can be, for example, a PC manager, a computer manager, or a heat dissipation decision APP, and the first application can identify the user scenario of the electronic device based on information such as the focus window.
  • the second application is the application launched by the user in the actual application scenario.
  • the second application can be an office APP; in a game scenario, the second application can be a game APP; in a video scenario, the second application can be an APP for playing videos.
  • the fan speed is the first speed.
  • the window of the second application becomes the focus window.
  • the first application recognizes that the user scenario of the electronic device has changed to the user scenario corresponding to the second application.
  • the electronic device performs heat dissipation control based on the scene recognition result and adjusts the fan speed to the second speed.
  • the focus window changes and the fan speed changes.
  • the first application recognizes that the user context has not changed.
  • the fan speed does not change when the user taps the first or second area of the keyboard.
  • the fan speed remains unchanged when data is entered on the keyboard.
  • the first application After the first time period, the first application is uninstalled. After the first application is uninstalled, the first application cannot identify the user scenario, so the electronic device cannot perform heat dissipation control based on the user scenario identified by the first application. In this case, the electronic device can The user scenario is identified based on keyboard input data and the like during the second time period, and heat dissipation control is performed based on the identification result. Specifically, when the user taps the first area of the keyboard during the second time period, the user scenario is identified as a preset scenario based on the keyboard input data, and the fan speed is adjusted to a third speed corresponding to the preset scenario.
  • the preset scenario can be, for example, a gaming scenario.
  • keyboard input causes the fan speed to change.
  • the focus window may or may not change. Because the first application has been uninstalled, regardless of whether the focus window changes, the user context cannot be identified based on the first application.
  • the method also includes: within a first time period, in response to the first area or the second area of the keyboard being tapped, displaying first content in a window of a second application, the first content including content input by tapping the first area or the second area of the keyboard within the first time period.
  • the method further includes: in response to the first area of the keyboard being tapped within a second time period, displaying second content on the screen of the electronic device, the second content including content input by tapping the first area of the keyboard within the second time period.
  • the method further includes: after uninstalling the first application, setting the rotation speed of the fan to a fourth rotation speed based on a power change of a first component in the electronic device.
  • the rotational speed of the fan is set to a fourth rotational speed corresponding to the power range.
  • fan control strategies are determined not only based on user scenarios but also based on the electronic device's system operating mode. This further considers the user's actual usage needs, ensuring that the resulting fan control strategy better matches their needs, further improving the user experience.
  • each of the multiple temperature ranges corresponds to a level, the higher the temperature in the temperature range, the higher the level, the faster the fan speed, the temperature range to which the current temperature belongs corresponds to the first target level in the first strategy, and the minimum duration includes the first minimum duration and the second minimum duration; the method also includes: if the previous strategy is not the first strategy, then based on the first strategy, determining that the value of the first minimum duration corresponding to the first target level is the first target duration; the previous strategy refers to the strategy for controlling the fan speed before the current moment and closest to the current moment; if the previous strategy is the first strategy, and the fan speed was controlled by the second target level in the first strategy before the current moment, and the second target level is lower than the first target level, then based on the first strategy, determining that the value of the first minimum duration corresponding to the first target level is the first target duration; if the previous strategy is the first strategy, and the fan speed was controlled by the second target level in the first strategy before the current moment,
  • different minimum durations are selected in different situations, such as when a certain control strategy is newly entered, the level is increased, and the level is decreased. This can match the minimum duration that better matches the heat dissipation requirements, prevent the fan speed from being adjusted too frequently, and dissipate heat in time, thereby improving the heat dissipation control effect.
  • the flag bit is also called a status flag bit.
  • the first preset value may be, for example, false.
  • the flag bit may also have a second preset value, which may be, for example, true.
  • the value of the flag bit is the first preset value, indicating that the running state of the first application is abnormal, and autonomous heat dissipation control is performed; the value of the flag bit is the second preset value, indicating that the running state of the first application is normal, and passive heat dissipation control is performed.
  • the first application can provide comprehensive and accurate user scenario information to the user, and thus can accurately control heat dissipation based on the scenario information, improve the comprehensiveness and accuracy of heat dissipation control, and improve the heat dissipation effect.
  • the detection method by executing a heartbeat request operation on the first application, not only can the operating status of the first application itself be determined simply and quickly, but the detection results can also cover situations where the first application communicates abnormally with other modules (such as an embedded controller (EC)). In actual applications, abnormal communication between the preset APP and the EC can also result in an inability to provide recognized user scenarios. Therefore, this method performs autonomous heat dissipation control in this situation, which can improve the accuracy of heat dissipation control.
  • the detection method provided by this implementation sends M heartbeat requests in each round of heartbeat detection, and determines the operating status of the first application based on the responses to these M heartbeat requests. This can prevent the occasional normal heartbeat response when the operating status is abnormal from being mistakenly judged as normal, thereby improving the accuracy of operating status detection and, in turn, the accuracy of heat dissipation control.
  • This implementation method can simply, quickly and accurately determine whether there is a first heartbeat request among M heartbeat requests by looping through the timer, thereby improving the accuracy of heartbeat detection, thereby improving the accuracy of the flag bit value, and further improving the accuracy of heat dissipation control.
  • the first heartbeat request exists in the M heartbeat requests, including: taking the first preset duration as the periodic duration, periodically determining whether the first time difference is greater than the preset maximum detection duration; the first time difference is the time difference between the current moment and the time when the earliest heartbeat request is sent, the earliest heartbeat request is the earliest heartbeat request sent among the M heartbeat requests, and the first preset duration is less than the longest detection duration; if the first time difference is greater than the longest detection duration, it is determined that the first heartbeat request exists in the M heartbeat requests; if the time difference is less than or equal to the longest detection duration, then after receiving the second heartbeat response message, it is determined whether the second time difference exceeds the timing duration of the third timer; the second time difference is the time difference between the moment when the second heartbeat response message is received and the time when the third heartbeat request is sent.
  • the time difference is less than or equal to the longest detection duration, then after receiving the second heartbeat response message, it is determined whether the second time difference exceeds the timing duration of the third timer; if the M heartbeat response messages are traversed, it is determined that the first heartbeat request does not exist in the M heartbeat requests.
  • This implementation method can simply, quickly and accurately detect the heartbeat response message by looping through it within the longest detection time. Determining whether the first heartbeat request exists among the M heartbeat requests improves the accuracy of heartbeat detection, thereby improving the accuracy of the value of the flag bit, and further improving the accuracy of heat dissipation control.
  • the method further includes: after the second time period, in a fourth time period, while the second area of the keyboard is being tapped, the rotational speed of the fan is set to a sixth rotational speed.
  • the focus window may or may not change.
  • the first application is in an uninstalled state.
  • the first application After uninstalling the first application, the first application cannot recognize the user scenario, and thus the electronic device cannot perform heat dissipation control based on the user scenario recognized by the first application.
  • the user scenario when the user taps the second area of the keyboard within the fourth time period, the user scenario is recognized as a preset scenario based on the keyboard input data, and the fan speed is adjusted to a sixth speed corresponding to the preset scenario.
  • the preset scenario may be, for example, an office scene.
  • the method further includes: within a fourth time period, in response to the second area of the keyboard being tapped, displaying third content on the screen of the electronic device, the third content including content input by tapping the second area of the keyboard within the fourth time period.
  • the fan speed is set to a sixth speed, including: after uninstalling the first application, within a fourth time period, based on the second area of the keyboard being tapped, the fan speed is set to the sixth speed.
  • the electronic device detects that the second area of the keyboard is tapped, it identifies the user scenario according to the data input by tapping the second area, and sets the fan speed to the sixth speed based on the user scenario.
  • the fan speed is set to a sixth speed, including: within the fourth time period, in response to the second area of the keyboard being tapped, receiving a second key value through the keyboard; based on the first application being uninstalled, determining, according to the second key value, that the user scenario of the electronic device is the second scenario; determining a second strategy based on the scenario information of the second scenario; and adjusting the fan speed to the sixth speed based on the second strategy.
  • the second scene may be, for example, an office scene.
  • the second scenario can be identified based on the key value, and a fan control strategy (second strategy) matching the second scenario can be decided based on the second scenario. Even when the first application is uninstalled, refined heat dissipation control based on the scenario can be achieved to improve the heat dissipation control effect.
  • second strategy fan control strategy
  • determining that the user scenario of the electronic device is the second scenario includes: respectively counting the number of first-category key values, the number of second-category key values, and the number of third-category key values in the second key value; the first-category key values, the second-category key values, and the third-category key values corresponding to the fourth area of the keyboard, and the fourth area corresponding to the second area of the keyboard.
  • the second key value is the key value entered by tapping the first area of the keyboard during the fourth time period. Therefore, the number of first-category key values of the second key value is also the total number of times the user taps the first-category key value during the second time period.
  • the keys corresponding to the first-category key values, the second-category key values, and the third-category key values are keys that are most likely to be used by users in office scenarios.
  • the key values corresponding to some or all of the keys in the second area of the keyboard belong to the first-category key values, the second-category key values, or the third-category key values.
  • the predicted value is determined according to the number of each type of preset key value in the second key value, and according to the size of the predicted value, the second scene can be accurately identified, thereby improving the accuracy of user scene identification and further improving the accuracy of heat dissipation control.
  • determining that the user scenario of the electronic device is the second scenario includes: if the second result is that the predicted value is greater than the preset threshold, determining that the user scenario of the electronic device is the second scenario; or, if the second result is that the predicted value is greater than the preset threshold, and the total number of second key values is greater than the second preset number, determining that the user scenario of the electronic device is the second scenario.
  • a judgment condition for the total number of second key values is added, so that key values that are mostly first-class key values, second-class key values or third-class key values but have a small number of key presses that are not the second scenario can be excluded, thereby reducing misrecognition and improving the recognition accuracy of the second scenario.
  • determining the value of the first prediction factor based on the number of first-category key values includes: if the number of first-category key values is greater than a first numerical threshold, determining the value of the first prediction factor to be a first value; if the number of first-category key values is less than or equal to the first numerical threshold, determining the value of the first prediction factor to be a second value.
  • the first prediction factor may be, for example, the prediction factor a in the specific implementation.
  • the first number threshold may also be called the first number threshold, which may be the number threshold th1 in the specific implementation.
  • the first value may be, for example, 1, and the second value may be, for example, 0.
  • the first category of key values includes key values for indicating deletion of content and/or key values for indicating line breaks; the second category of key values includes key values corresponding to at least one shortcut key; and the third category of key values includes key values for indicating adjustment directions.
  • the fan speed remains unchanged, including: during the first time period, in response to the first area or the second area of the keyboard being tapped, receiving a third key value through the keyboard; based on the first application being run, determining the user scenario of the electronic device not based on the third key value.
  • the first application is in operation and can normally identify the user scenario.
  • the electronic device can perform passive heat dissipation control based on the user scenario identified by the first application. Therefore, in this scenario, keyboard tapping does not perform scenario recognition based on the input third key value.
  • the electronic device further includes an embedded controller (EC), and after a first moment, the fan speed is set to a second speed, including: based on the window of the second application being the focus window, the first application determines that the user scenario of the electronic device is a fifth scenario; the first application sends the scenario information of the fifth scenario to the EC; the EC determines a fifth strategy based on the scenario information of the fifth scenario based on the value of the flag bit being a second preset value; and the EC controls the fan speed to change to the second speed according to the fifth strategy.
  • EC embedded controller
  • passive heat dissipation control is performed by EC. It is understood that autonomous heat dissipation control can also be performed by EC EC is located in the firmware layer and runs at the bottom of the operating system. It is not affected by the upper layer of the operating system. Therefore, the heat dissipation control performed by EC is not easily affected by changes in the upper layer of the operating system, which improves the reliability and stability of heat dissipation control.
  • the present application provides a device, which is included in an electronic device and has the function of implementing the electronic device behavior described in the first aspect and possible implementations of the first aspect.
  • the function can be implemented through hardware or through hardware executing corresponding software implementations.
  • the hardware or software includes one or more modules or units corresponding to the above functions. For example, a receiving module or unit, a processing module or unit, etc.
  • the present application provides an electronic device, which includes: a processor, a memory, and an interface; the processor, the memory, and the interface cooperate with each other so that the electronic device executes any one of the methods in the technical solution of the first aspect.
  • the present application provides a chip system, comprising a processor, wherein the processor is configured to read and execute a computer program stored in a memory to perform the method of the first aspect and any possible implementation thereof.
  • the chip system also includes a memory, and the memory is connected to the processor via circuits or wires.
  • FIG1 is a schematic diagram of a heat dissipation control process provided by an embodiment of the present application.
  • FIG3 is a block diagram of the software and hardware structure of an electronic device 100 provided in an embodiment of the present application.
  • FIG4 is a block diagram of software and hardware structures of another electronic device 100 provided in an embodiment of the present application.
  • FIG6 is a schematic diagram of module interaction of another heat dissipation control method provided in an embodiment of the present application.
  • FIG10 is a flow chart of a heat dissipation control method according to an embodiment of the present application.
  • FIG15 is a schematic structural diagram of a chip system provided in an embodiment of the present application.
  • first,” “second,” and “third” are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the quantity of the technical features indicated. Therefore, a feature specified as “first,” “second,” or “third” may explicitly or implicitly include one or more of the features.
  • autonomous and “passive” in this specification are only used to distinguish different data sources, different modules, or different execution processes, and should not be understood as indicating or implying the execution method, execution subject, or execution result of an action, nor should they be understood as distinguishing the primary and secondary of modules, data, or processes.
  • “autonomous” can be replaced by “first”, and “passive” can be replaced by “second”; or, “autonomous” can be replaced by “second”, and “passive” can be replaced by "first”.
  • references to "one embodiment” or “some embodiments” in this specification mean that one or more embodiments of the present application include a particular feature, structure, or characteristic described in conjunction with that embodiment.
  • phrases such as “in one embodiment,” “in some embodiments,” “in other embodiments,” and “in other embodiments” appearing in different places in this specification do not necessarily refer to the same embodiment, but rather mean “one or more but not all embodiments,” unless otherwise specifically emphasized.
  • the terms “including,” “comprising,” “having,” and variations thereof all mean “including but not limited to,” unless otherwise specifically emphasized.
  • Heat dissipation control strategy refers to a set of solutions that can achieve heat dissipation control.
  • Power control strategy refers to a set of solutions that can adjust the power (also known as power consumption) of devices in electronic devices to control heat dissipation.
  • Brightness control refers to a set of solutions that can adjust the brightness of the screen (i.e., display) of an electronic device to control heat dissipation.
  • Fan control strategy refers to a set of solutions that can adjust the fan speed to control heat dissipation.
  • the focus window is the window that has focus.
  • the focus window is the only window that can receive keyboard input.
  • the determination of the focus window is related to the system's focus mode.
  • the topmost window of the focus window is called the active window. Only one window can be active at a time.
  • the focus window is most likely the window that the user is currently working on.
  • Focus mode can be used to determine how the mouse focuses on a window.
  • focus modes there are three focus modes:
  • Focus follows mouse.
  • the window under the mouse can be focused. That is, when the mouse moves into the range of a window that can be focused, the user can activate the window without clicking anywhere in the window and receive keyboard input, but the window is not necessarily placed in front of all other windows. When the mouse moves out of the range of the window, the window is no longer focused.
  • Sloppy focus This focus mode is similar to focus follow mouse: when the mouse moves into the range of a window that can be focused, the user does not need to click anywhere in the window to activate the window and receive keyboard input, but the window is not necessarily placed in the front of all windows. The difference is that when the mouse moves out of the window range, the focus does not change. The system focus will only change when the mouse moves to another window that can be focused.
  • Heat dissipation control plays a vital role in the performance of electronic devices.
  • Heat dissipation control strategies include frequency control strategy, brightness control strategy, and fan control strategy.
  • the abnormal operating status of the PC Manager APP includes but is not limited to the PC Manager APP not running (including the APP being uninstalled or not installed), the PC Manager APP process is stuck, frozen or suspended, etc.
  • the PC Manager app can identify user scenarios during the heat dissipation control process for electronic devices and adapt different heat dissipation strategies based on different user scenarios, so as to achieve thermal balance while taking into account user needs.
  • abnormal operation of the PC Manager app may result in the inability to identify user scenarios, and thus the inability to adapt the heat dissipation control strategy (at least one of the frequency control strategy, brightness control strategy, and fan control strategy) to the user scenario, resulting in poor heat dissipation control results.
  • FIG. 1 is a schematic diagram of a heat dissipation control process provided in an embodiment of the present application.
  • the electronic device may include a system-on-chip (SoC), an embedded controller (EC), and a fan.
  • SoC system-on-chip
  • EC embedded controller
  • the number of fans may be one or more.
  • fan 1 and fan 2 the example of two fans, represented by fan 1 and fan 2 is used for explanation.
  • Components such as CPU and GPU may be integrated in the SoC.
  • An operating system (OS) runs in the SoC, and the operating system includes a PC manager APP and an operating system kernel (kernel) (hereinafter referred to as the kernel).
  • OS operating system
  • kernel operating system kernel
  • the PC Manager app identifies the current user scenario of the electronic device and sends it to the EC through the kernel.
  • the EC matches the user scenario, generates a fan control policy, and executes the fan control policy to control the speed of Fan 1 and Fan 2.
  • the PC Manager app can also generate a cooling control policy based on the user scenario, including a fan control policy.
  • the PC Manager app sends the fan control policy to the EC through the kernel, and the EC executes the fan control policy to control the speed of Fan 1 and Fan 2.
  • the PC Manager APP is only used as an example.
  • the PC Manager APP can also be other APPs that can identify user scenarios and/or decide on heat dissipation control strategies (hereinafter referred to as preset APPs), and there is no limitation on this.
  • Both of the above two implementation methods can control the fan speed according to the user scenario, improve the effect of heat dissipation control, and meet the user's usage needs.
  • EC needs to rely on the output results of the PC Manager APP to control the fan speed.
  • the PC Manager APP is in an abnormal operating state, EC cannot obtain the fan control strategy, resulting in the inability to control the fan speed.
  • the default control strategy is a coarse-grained control of the fan speed.
  • the default control strategy is to set the fan speed to a fixed value, then the fan speed cannot change adaptively with the user scenario, resulting in the device being unable to achieve thermal balance, or problems such as high noise.
  • the default control strategy is used to control the fan to run at a fixed speed.
  • gaming scenarios electronic devices generate more heat, and the fan needs to be controlled to run at a higher speed to meet faster heat dissipation needs. Therefore, if the fan runs at a fixed speed in gaming scenarios, the heat dissipation is weak, and the heat dissipation is not timely, resulting in overheating of the device and affecting device performance.
  • the fan speed is a fixed value only as an example of the default control strategy. In actual applications, the default control strategy can also be other, such as coarse-grained control of the fan according to the CPU temperature.
  • abnormal operation of the PC Manager app may also cause other cooling control strategies to fail to execute as expected, leading to poor cooling control for electronic devices.
  • the PC Manager app when the PC Manager app is operating abnormally, it cannot match the corresponding power control strategy based on the user scenario. As a result, the electronic device cannot adjust the operating frequency of the central processing unit (CPU) or graphics processing unit (GPU) based on the scenario, resulting in poor cooling control.
  • the PC Manager app when the PC Manager app is operating abnormally, it cannot match the corresponding brightness control strategy based on the user scenario. As a result, the screen cannot adjust brightness based on the scenario, resulting in poor cooling control.
  • the present embodiment provides a heat dissipation control method that uses EC to identify user scenarios and monitor the operating status of a preset app. If the preset app's operating status is abnormal, the EC identifies the user scenario and generates a heat dissipation control strategy. This eliminates the need for the heat dissipation control strategy to rely on the preset app. Even if the preset app is operating abnormally, a refined heat dissipation control strategy can be generated based on the user scenario identified by the EC, improving the effectiveness of heat dissipation control, thereby enhancing the performance of the electronic device and the user experience.
  • the heat dissipation control method provided in the embodiments of the present application can be applied to electronic devices such as laptops, PCs, and ultra-mobile personal computers (UMPCs).
  • UMPCs ultra-mobile personal computers
  • the embodiments of the present application do not impose any restrictions on the specific types of electronic devices.
  • FIG2 is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of the present application.
  • the electronic device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, a wireless communication module 150, a display 160, a fan 170, an input device 180, a sensor 190, etc.
  • USB universal serial bus
  • the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 100.
  • the electronic device 100 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently.
  • the illustrated components may be implemented in hardware, software, or a combination of software and hardware.
  • the processor 110 may include one or more processing units.
  • the processor 110 may include an application processor (AP), a modem processor, a GPU, an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, an EC, and/or a neural-network processing unit (NPU).
  • the application processor (AP) may be integrated with a CPU.
  • the AP can also be directly replaced with a CPU.
  • different processing units can be independent devices or integrated into one or more processors.
  • processing units other than the EC such as the AP, GPU, and baseband processor, can be integrated into a processor chip to form the SoC described in the above embodiment.
  • the processor 110 may include an SoC and an EC.
  • the controller can be the nerve center and command center of the electronic device 100.
  • the controller can sequence signal, generates operation control signal, and completes the control of instruction fetching and execution.
  • Processor 110 may also include a memory for storing instructions and data.
  • the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.
  • the processor 110 may include one or more interfaces.
  • the interfaces may include an inter-integrated circuit (I2C) interface, a serial peripheral interface (SPI), an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver/transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input/output (GPIO) interface, a subscriber identity module (SIM) interface, and/or a USB interface.
  • I2C inter-integrated circuit
  • SPI serial peripheral interface
  • I2S inter-integrated circuit sound
  • PCM pulse code modulation
  • UART universal asynchronous receiver/transmitter
  • MIPI mobile industry processor interface
  • GPIO general-purpose input/output
  • SIM subscriber identity module
  • the interface connection relationship between the modules illustrated in this embodiment is merely an illustrative illustration and does not constitute a structural limitation on the electronic device 100.
  • the electronic device 100 may also adopt different interface connection methods from the above embodiments, or a combination of multiple interface connection methods.
  • the charging management module 140 is used to receive charging input from a charger.
  • the charger can be a wireless charger or a wired charger. While charging the battery 142, the charging management module 140 can also power the electronic device through the power management module 141.
  • the wireless communication module 150 can provide wireless communication solutions for the electronic device 100, including WLAN (such as Wi-Fi), Bluetooth, global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), and other wireless communication technologies.
  • WLAN such as Wi-Fi
  • GNSS global navigation satellite system
  • FM frequency modulation
  • NFC near field communication
  • IR infrared
  • the electronic device 100 can establish a Bluetooth connection with a terminal device (such as the wireless headset 100) through the wireless communication module 150.
  • the wireless communication module 150 can be one or more devices that integrate at least one communication processing module.
  • the wireless communication module 150 receives electromagnetic waves via an antenna, frequency-modulates and filters the electromagnetic wave signals, and transmits the processed signals to the processor 110.
  • the wireless communication module 150 can also receive signals to be transmitted from the processor 110, frequency-modulate them, amplify them, and convert them into electromagnetic waves for radiation via the antenna.
  • Electronic device 100 implements display functionality through a GPU, display screen 160, and an application processor.
  • a GPU is a microprocessor for image processing that connects display screen 160 and the application processor.
  • the GPU is used to perform mathematical and geometric calculations for graphics rendering.
  • Processor 110 may include one or more GPUs that execute program instructions to generate or modify display information.
  • the display screen 160 is used to display images, videos, etc.
  • the display screen 160 includes a display panel.
  • the fan 170 is used to dissipate heat for the electronic device.
  • the external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100.
  • the external memory card communicates with the processor 110 via the external memory interface 120 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.
  • the internal memory 121 can be used to store computer executable program code, which includes instructions.
  • the processor 110 executes various functional applications and data processing of the electronic device 100 by running the instructions stored in the internal memory 121.
  • the processor 110 can execute instructions stored in the internal memory 121, and the internal memory 121 can include a program storage area and a data storage area.
  • the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.
  • the data storage area can store data created during the use of the electronic device 100 (such as audio data), etc.
  • the internal memory 121 can include a random access memory and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc.
  • the random access memory can be, for example, a double data rate synchronous dynamic random access memory (DDR).
  • DDR double data rate synchronous dynamic random access memory
  • the flash memory device can be, for example, a solid state disk (SSD).
  • a user can input data into processor 110 via input device 180, which processes the data and responds.
  • input device 180 may include, but is not limited to, a touchpad 181, a mouse 182, and a keyboard 183.
  • Touchpad 181 and keyboard 183 can be connected to an electronic control (EC), respectively, and data inputted by the touchpad 181 and keyboard 183 can be received and processed by the EC.
  • Communication between the touchpad 181 and keyboard 183 and the EC can be achieved via an I2C interface or SPI.
  • Power sensor 192 is used to detect the operating power of devices, such as the SoC, SSD, DDR, wireless communication module 150, display 160, and audio power amplifier (PA).
  • power sensors 192 for multiple devices can be integrated into a power measurement integrated circuit (IC).
  • the power measurement IC can communicate with the EC via an I2C interface or SPI interface, transmitting the collected power to the EC.
  • the software operating system of the electronic device 100 can run on a processor, such as a SoC or EC.
  • the operating system can adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservices architecture, or a cloud architecture.
  • This embodiment of the present invention uses a Windows system with a layered architecture as an example to illustrate the software structure of the electronic device 100.
  • FIG3 is a block diagram of the software and hardware structure of the electronic device 100 of the embodiment of the present application.
  • the layered architecture divides the software into several layers, each layer has a clear role and division of labor.
  • the layers communicate with each other through software interfaces.
  • the Windows system is divided into user state and kernel state.
  • the user state includes the application layer and the subsystem Dynamic link library.
  • the kernel state is divided into the firmware layer, hardware abstraction layer (HAL), kernel and driver layer and executive body from bottom to top.
  • HAL hardware abstraction layer
  • FIG3 also shows the hardware layer of the electronic device 100.
  • the application layer includes applications such as music, video, games, office, and social networking.
  • the application layer also includes preset APPs, etc. Among them, only some applications are shown in the figure.
  • the application layer can also include other applications, such as shopping applications, browsers, etc., which are not limited in this application.
  • the preset APP can be, for example, a heat dissipation decision APP, a PC manager APP (or a computer manager APP, etc.).
  • the preset APP can include modules such as an environmental subsystem, a scene recognition engine, and a scheduling engine.
  • the scene recognition engine can identify the user scenario in which the electronic device 100 is located.
  • the scheduling engine can obtain information such as the load status and system operating mode of the electronic device 100 and send it to other modules of the electronic device, such as the EC.
  • the details of the environment subsystem, scene recognition engine, and scheduling engine will be discussed later and will not be described here.
  • the subsystem dynamic link library includes an API module, which includes the Windows API, the Windows native API, and so on. Both the Windows API and the Windows native API can provide system call entry points and internal function support for applications.
  • the difference is that the Windows native API is an API native to the Windows system.
  • the Windows API may include user.dll and kernel.dll
  • the Windows native API may include ntdll.dll.
  • User.dll is the Windows user interface interface that can be used to perform operations such as creating windows and sending messages.
  • Kernel.dll is used to provide applications with an interface to access the kernel.
  • ntdll.dll is an important Windows NT kernel-level file that describes the interface of the Windows native NTAPI. When Windows starts, ntdll.dll resides in a specific write-protected area in memory, preventing other programs from occupying this memory area.
  • the executive body includes the process manager, virtual memory manager, security reference monitor, I/O manager, Windows management instrumentation (WMI), power manager, operating system event driver (OsEventDriver) node, operating system to system on chip (OS2SOC) node, etc.
  • WMI Windows management instrumentation
  • OsEventDriver operating system event driver
  • OS2SOC operating system to system on chip
  • the process manager is used to create and terminate processes and threads.
  • the virtual memory manager implements "virtual memory".
  • the virtual memory manager also provides basic support for the cache manager.
  • the Security Reference Monitor enforces security policy on the local computer, protects operating system resources, and performs runtime object protection and monitoring.
  • the I/O manager performs device-independent input/output and further processes calls to appropriate device drivers.
  • the power manager manages power state changes for all devices that support power state changes.
  • the system event-driven node can interact with the kernel and driver layer, for example, interact with the graphics card driver, and after determining that a GPU video decoding event exists, report the GPU video decoding event to the scene recognition engine.
  • the system and chip driver nodes can be used by the scheduling engine to send adjustment information to the hardware device, such as sending information to adjust PL1 and PL2 to the CPU.
  • the kernel and driver layer include the kernel and device drivers.
  • Device drivers run in kernel mode and are the interface between the I/O system and the associated hardware. These may include graphics card drivers, Intel DTT drivers, mouse drivers, audio and video drivers, camera drivers, keyboard drivers, etc. For example, a graphics card driver can drive the GPU to run, and an Intel DTT driver can drive the CPU to run.
  • the HAL is a kernel-mode module that hides hardware-related details, such as I/O interfaces, interrupt controllers, and multi-processor communication mechanisms. It provides a unified service interface for different hardware platforms running Windows, enabling portability across multiple hardware platforms. It's important to note that to maintain Windows portability, Windows internal components and user-written device drivers don't access hardware directly. Instead, they call routines in the HAL.
  • the EC can receive data from the upper layer through the BIOS, process it, and then control the hardware layer devices. It can also receive data from the hardware layer, process it, and then send it to the BIOS, which then passes it to the upper layer. In addition, the EC can also communicate with the kernel through interfaces such as I2C or SPI.
  • the thermal noise balancing engine may include an autonomous identification module, an autonomous decision-making module, a passive decision-making module, a fan control module, and a status detection module.
  • the thermal noise balancing engine may be implemented via a thermal noise balancing process.
  • the thermal noise balancing process may be created when the operating system starts.
  • the autonomous recognition module is used to identify user scenarios based on data provided by the hardware layer.
  • the process of the autonomous recognition module identifying user scenarios based on data provided by the hardware layer is referred to as autonomous scenario recognition, and the user scenarios identified by the autonomous recognition module are referred to as autonomous user scenarios.
  • the process of the preset app identifying user scenarios is referred to as upper-layer scenario recognition, and the user scenarios identified by the preset app are referred to as upper-layer user scenarios.
  • the autonomous decision module is used to determine a heat dissipation control strategy (referred to as an autonomous heat dissipation strategy) based on autonomous user scenarios.
  • the autonomous heat dissipation strategy includes a fan control strategy. It is understood that the fan control strategy can be presented in the form of a table. Therefore, in the following embodiments of this application, the fan control strategy is also referred to as a table.
  • the fan control strategy determined based on the autonomous user scenario is referred to as an autonomous table.
  • the hardware layer may include hardware structures such as the GPU, CPU, keyboard, touchpad, mouse, power sensor (using a power measurement IC as an example), temperature sensor (using an NTC device as an example), and fan.
  • the GPU, CPU, and mouse can communicate with the SoC.
  • the keyboard, touchpad, power sensor, temperature sensor, and fan can communicate with the EC.
  • the simplified electronic device includes a preset APP in the application layer, a kernel and a kernel in the driver layer, a thermal noise balance engine in the firmware layer, and a keyboard, touchpad, power measurement IC, NTC and fan in the hardware layer.
  • the thermal noise balance engine includes an autonomous identification module, an autonomous decision-making module, a passive decision-making module, a fan control module and a status detection module.
  • FIG5 is a schematic diagram of module interaction of a heat dissipation control method provided in an embodiment of the present application. Please refer to FIG4 and FIG5 together. The method includes:
  • a status detection module in a thermal noise balancing engine assigns a value to a preset status flag bit according to whether the heartbeat of a preset APP meets a preset condition.
  • Preset conditions refer to pre-set conditions used to detect the operating status of a preset app.
  • the value of the status flag bit is used to indicate the operating status of the preset app.
  • the operating status of the preset app can include normal operating status and abnormal operating status. Among them, normal operating status means that the preset app itself is operating normally and the preset app and the EC can communicate normally. Abnormal operating status means that the preset app itself is operating abnormally and/or the preset app and the EC cannot communicate normally.
  • the value of the status flag bit can be true or false. If the value of the status flag bit is true, it indicates that the running status of the preset APP is normal; if the value of the status flag bit is false, it indicates that the running status of the preset APP is abnormal.
  • the value of the status flag bit can also be other, such as 1 or 0, yes or no, etc., which is not limited in this embodiment of the present application.
  • the status flag bit can be a global variable. Other modules in the thermal noise balance engine can obtain the value of the status flag bit at any time.
  • the status flag is assigned a value of true; if the heartbeat of the preset APP does not meet the preset conditions, indicating that the preset APP is running abnormally, the status flag is assigned a value of false.
  • determining whether the heartbeat satisfies the preset conditions and assigning a value to the status flag is only an exemplary implementation method for detecting the running status of the preset APP.
  • other detection methods can also be used to detect whether the running status of the preset APP is normal, which is not limited to this.
  • step S101 can be executed continuously to continuously monitor the running status of the preset APP.
  • “continuously” can be understood as multiple times that can be discontinuous in time.
  • step S101 can be executed once every preset time interval, or step S101 can be triggered to execute once each time a preset condition is met.
  • the process of executing step S101 once is also referred to as one round of heartbeat detection.
  • step S101 introduces the status detection process of the preset APP.
  • steps S102 to S108 introduce the identification of the status of the preset APP.
  • the process of determining the passive table based on the upper-layer user scenario and controlling the fan speed through the passive table is the implementation process of the heat dissipation control method when the EC operates in the passive decision-making heat dissipation mode.
  • the process described in steps S102 to S108 can also be called the passive heat dissipation control process.
  • the passive heat dissipation control process can be performed based on the value assigned to the status flag in step S101. It should be understood that the passive heat dissipation control process and the preset APP status detection process can be executed in parallel, and the two can be executed by two different threads respectively, without being restricted by the order of precedence. Specifically, when the status flag already has a value, steps S102 to S108 can be executed before or after a certain execution of step S101, or can be executed simultaneously with step S101.
  • the passive heat dissipation control process may include:
  • the preset APP identifies the user scenario of the electronic device and obtains the upper-level user scenario.
  • upper-level user scenarios may include, for example, game scenarios, meeting scenarios, office scenarios, video scenarios, social scenarios, browser scenarios, etc.
  • different upper-level user scenarios can be distinguished by scene information.
  • the scene information of an upper-level user scenario can include, for example, a scene number, a scene name, or other information that can identify a scene.
  • scene number V01 can indicate that the upper-level user scenario is a video scenario.
  • scene number V02 can indicate that the upper-level user scenario is a game scenario.
  • the preset APP can identify the upper-level user scene according to a preset period, and assign the scene information of the identified upper-level user scene to the preset upper-level user scene parameter.
  • the preset upper-level user scene parameter can be, for example, the parameter "current scene 1" (current scene 1).
  • the preset period can be, for example, 2 minutes (min).
  • the upper-level user scene identified by the preset APP is a video scene (scene number is V01), then the preset APP assigns "V01" to current scene 1.
  • the preset APP identifies the upper-level user scene again. Assuming that the identification result is a game scene (scene number is V02), the preset APP assigns "V02" to current scene 1.
  • Steps S109 through S115 describe how the EC identifies autonomous user scenarios, determines an autonomous table based on those scenarios, and controls fan speed using that table. This describes the implementation of the cooling control method when the EC operates in autonomous cooling mode. Steps S109 through S115 are also referred to as the autonomous cooling control process.
  • the keyboard, touch panel, NTC and power measurement IC of the hardware layer collect target data and send the collected target data to the autonomous identification module.
  • the autonomous identification module may determine whether the value of the status flag is false according to a preset period, where the preset period may be, for example, 2 minutes or 5 minutes.
  • autonomous user scenarios may include, for example, video scenarios, gaming scenarios, office scenarios, idle scenarios, light-load scenarios, and heavy-load scenarios.
  • a light-load scenario refers to a non-video, non-gaming, and non-office scenario with a relatively light load.
  • a light-load scenario may, for example, be an audio playback scenario.
  • a heavy-load scenario refers to a non-video, non-gaming, and non-office scenario with a relatively heavy load.
  • a heavy-load scenario may, for example, be an animation rendering scenario.
  • the scenario information for an autonomous user scenario can include, for example, a scenario number, a scenario name, or other information that identifies a scenario.
  • the representation rules for the scenario information for an autonomous user scenario and the scenario information for an upper-level user scenario can differ to facilitate distinguishing between the two scenarios.
  • scenario number S01 can be used to indicate that the autonomous user scenario is a gaming scenario.
  • scenario number S02 can be used to indicate that the autonomous user scenario is an office scenario.
  • the autonomous identification module is triggered to identify an autonomous user scene based on the target data.
  • the autonomous identification module can assign the scene information of the identified autonomous user scene to a preset autonomous user scene parameter.
  • the preset autonomous user scene parameter can be, for example, the parameter "current scene 2" (current scene2).
  • the autonomous identification module determines that the value of the status flag is false, triggering an autonomous user scene recognition. Assuming that the identified autonomous user scene is a game scene (scene number is S01), the autonomous identification module assigns "S01" to current scene 2.
  • the autonomous identification module again determines that the value of the status flag is false, triggering the autonomous identification module to recognize the autonomous user scene again. Assuming that the recognition result is an office scene (scene number is S02), the autonomous identification module assigns "S02" to current scene 2.
  • the autonomous recognition module sends scenario information of the changed autonomous user scenario to the autonomous decision module (the scenario information of the changed autonomous user scenario is hereinafter referred to as second scenario information).
  • the autonomous recognition module can determine whether the value of current scene 2 after the assignment is consistent with the value before the assignment, before, after, or simultaneously with each assignment to current scene 2. If the value of current scene 2 before and after the assignment is consistent, it is determined that the autonomous user scene has not changed; if the value of current scene 2 before and after the assignment is inconsistent, it is determined that the autonomous user scene has changed.
  • the autonomous recognition module sends the scene information of the changed autonomous user scene (i.e., S02) to the autonomous decision-making module.
  • the autonomous decision-making module determines an autonomous heat dissipation strategy based on the second scenario information.
  • the autonomous identification module sends the second scenario information to the autonomous decision module.
  • the autonomous decision module determines an autonomous cooling strategy that matches the changed autonomous user scenario based on the second scenario information.
  • the autonomous cooling strategy includes an autonomous table.
  • the autonomous decision module can determine the autonomous table that matches the changed autonomous user scenario based on the preset correspondence.
  • the correspondence between the scenario information of the autonomous user scenario and the autonomous table The relationship may be as shown in Table 4, for example.
  • the changed autonomous user scene is a video scene and the second scene information is S02, then according to Table 4, it can be determined that the autonomous table is table 2-3.
  • the autonomous decision-making module can also match the corresponding autonomous table based on the changed autonomous user scenario in combination with other information.
  • the autonomous table can be matched based on the electronic device's system operating mode.
  • System operating modes can be multiple operating modes pre-set by the electronic device's operating system. Different system operating modes vary the electronic device's power level (corresponding to battery life), heat dissipation, and noise level.
  • System operating modes may include, for example, quiet mode, performance mode, and mad mode. In quiet mode, the electronic device's operating noise is relatively low, such as fan noise. Users may generally choose quiet mode for scenarios such as working at night, working in a library, or studying in a classroom.
  • performance mode the electronic device achieves a near-balanced balance between battery life, heat dissipation, and noise.
  • Users may generally choose performance mode in office settings.
  • mad mode the electronic device's performance is optimized, with relatively high fan speeds. Users may generally choose mad mode for scenarios such as gaming or animation rendering.
  • the default system operating mode for an electronic device may be performance mode.
  • users can switch the system operating mode using shortcut keys.
  • shortcut keys For example, users can use the Fn+J shortcut key to switch the system operating mode to Quiet mode, the Fn+Q shortcut key to switch the system operating mode to Berserk mode, and the Fn+X shortcut key to switch the system operating mode to Performance mode.
  • the autonomous decision module may determine the autonomous table based on the corresponding relationship shown in Table 5.
  • the changed autonomous user scene is a video scene
  • the second scene information is S02
  • the current system operation mode is the performance mode
  • the preset app when it sends the upper-level user scenario to the thermal-noise balancing engine in the EC, it can also send the system operating mode.
  • the system operating mode can be sent to the autonomous decision module in the thermal-noise balancing engine.
  • the autonomous decision module can first obtain the system operating mode last sent by the preset app before the current moment. Based on this system operating mode, it matches the autonomous table with Table 5. However, if the electronic device has never run the preset app or the system data has been cleared, the autonomous decision module may not be able to obtain the system operating mode. In this case, the autonomous decision module can match the autonomous table with the default system operating mode (e.g., performance mode) based on Table 5.
  • the default system operating mode e.g., performance mode
  • the autonomous decision module obtains historical system operating modes sent by the preset app within a historical time period and selects the historical system operating mode with the closest issuance time to the current moment as the target system operating mode. The autonomous table is then matched against the target system operating mode. If no historical system operating mode exists, the default (i.e., preset) system operating mode is determined as the target system operating mode.
  • the autonomous decision module continuously acquires keyboard data and monitors whether the user has switched the system operating mode based on this data. If a user switches the system operating mode, the autonomous table is re-matched based on the user's switched operating mode. For example, if the monitored keyboard input includes the key value Fn+Q, the system operating mode is determined to be in berserk mode. Based on the berserk mode and the current autonomous user scenario, the autonomous table is re-matched based on Table 5.
  • the autonomous decision-making module determines other heat dissipation strategies, such as frequency control strategy, brightness control strategy, etc., based on the second scenario information. It can be based on a preset correspondence search or other methods. The embodiments of the present application do not impose any restrictions on this.
  • the autonomous decision module sends the autonomous table to the fan control module.
  • the autonomous decision module can write to a predefined object called an autonomous table.
  • This object is accessible to the fan control module and can read values from it. It is understood that the object used to write to the autonomous table can be the same object as the object used to write to the passive table, or different objects.
  • the autonomous decision-making module can also send other cooling strategies to corresponding modules, which will then execute the corresponding cooling strategies.
  • the autonomous decision-making module can send the determined frequency control strategy to the OS2SoC driver node in the execution body, which will adjust the CPU and/or GPU frequency according to the frequency control strategy.
  • the autonomous decision-making module can send the determined brightness control strategy to the display screen, which will then control and adjust the brightness according to the brightness control strategy.
  • the fan control module controls the fan speed according to the received autonomous table.
  • the fan control module can read an autonomous table from a preset object and control the fan speed according to the solution in the autonomous table.
  • an autonomous table 1-N may be as shown in Table 6 below, where NA is the abbreviation of not applicable, meaning not applicable, and is used to indicate that the corresponding parameter has no value or is not limited. The meaning of NA in subsequent embodiments is similar and will not be repeated.
  • the temperature of the virtual shell refers to the current temperature of the shell of the electronic device calculated and estimated based on the current temperatures of multiple components in the electronic device, for example, the shell problem of the electronic device is calculated and estimated based on the current temperature of the SoC, the current temperature of the battery, the current temperature of the charger, etc.
  • the passive table may include more or less information than Table 6.
  • the passive table may also include one or more of the battery temperature range, the ambient temperature range, or the charger temperature range.
  • the autonomous table allows for multiple control levels (referred to as levels). Different levels correspond to different device temperatures and fan speeds. Higher levels increase device temperatures and fan speeds.
  • the fan control module monitors the temperature of each device and, based on the current autonomous table, determines the level that matches the device temperature. It then controls the fan according to the corresponding fan speed and minimum duration.
  • minimum durations include minimum duration 1 and minimum duration 2.
  • minimum duration 1 for any level n indicates the minimum duration of fan operation at the speed corresponding to level n when the fan control strategy is switched from another table to level n in table 2-N.
  • minimum duration 1 for level n in table 2-N indicates the minimum duration of fan operation at the speed corresponding to level n when the fan control strategy is increased from a lower level (less than level n) in table 2-N to level n.
  • the fan control strategy switches from a level in table 2-X to level 1 in table 2-N.
  • the fan control module then controls the fans according to the fan speeds corresponding to level 1 in table 2-N (Fan 1 at 2600 rpm and Fan 2 at 2500 rpm).
  • the fans must operate at the fan speed corresponding to level 1 in table 2-N for at least 5 minutes, based on the minimum duration 1 (5 minutes) corresponding to level 1 in table 2-N, before they can be adjusted to another level. That is, Fan 1 must run at 2600 rpm and Fan 2 at 2500 rpm for at least 5 minutes before they can be adjusted to another speed.
  • the fan control module has not received a new table (i.e., the table has not been switched).
  • the level matched based on the current SoC temperature and virtual case temperature is Level 2 in Table 2-N. This means that the level needs to be increased from Level 1 in Table 2-N to Level 2 in Table 2-N.
  • the fan control module determines that the duration of Level 1 in Table 2-N exceeds 5 minutes, it controls the fans to operate at the fan speeds corresponding to Level 2 in Table 2-N (Fan 1 speed is 2900 rpm, Fan 2 speed is 2800 rpm). Furthermore, in this case, the level is increased from Level 1 in Table 2-N to Level 2.
  • the fans must operate at the fan speed corresponding to Level 2 in Table 2-N for at least 6 minutes before they can be adjusted to another level. That is, fan 1 is controlled to run at 2900 rpm and fan 2 is controlled to run at 2800 rpm for at least 6 minutes before they can be adjusted to other speeds.
  • the minimum duration 2 corresponding to any level n indicates the minimum duration of fan operation at the speed corresponding to level n when the fan control strategy is reduced from a high level (a level greater than n) in table 2-N to level n.
  • the fan control module has not received the new table, that is, table If the switch is not made, and according to Table 2-N in Table 6, the level matched based on the current SoC temperature and the virtual case temperature is Level 1 in Table 2-N, meaning the level needs to be lowered from Level 2 in Table 2-N to Level 1 in Table 2-N, then, if the fan control module determines that the duration of Level 2 in Table 2-N exceeds 6 minutes, it controls the fans according to the fan speeds corresponding to Level 1 in Table 2-N (Fan 1 speed is 2600 rpm, Fan 2 speed is 2500 rpm).
  • the fans since the level is lowered from Level 2 in Table 2-N to Level 1, the fans must operate at the fan speed corresponding to Level 1 in Table 2-N for at least 4 minutes, based on the minimum duration 2 (4 minutes) corresponding to Level 1 in Table 2-N, before they can be adjusted to another level. That is, Fan 1 must operate at 2600 rpm and Fan 2 at 2500 rpm for at least 4 minutes before they can be adjusted to another speed.
  • step S101 the preset APP status detection process (step S101), the passive heat dissipation control process (S102 to S108), and the autonomous heat dissipation control process (S109 to S115) can be executed in a certain order or simultaneously.
  • fan speed control is based on device temperature. High fan speeds are used at higher temperatures, while low speeds are used at lower temperatures. This allows for better and faster heat dissipation, helps the device reach thermal equilibrium, and improves the efficiency and accuracy of temperature control. Furthermore, fan speed control is implemented by limiting the minimum duration of level control. This prevents overly frequent fan speed adjustments, which could lead to unnecessary power loss and interruptions to the user, thereby improving the stability and reliability of fan control.
  • the preset APP provides the identified upper-level user scenario to the thermal noise balancing engine, and the thermal noise balancing engine generates a passive table based on the upper-level user scenario decision.
  • the preset APP can also generate a passive table based on the upper-level user scenario decision after identifying the upper-level user scenario, and send the passive table to the thermal noise balancing engine through the kernel.
  • the fan control module in the thermal noise balancing engine can control the fan speed according to the passive table sent by the upper layer when it determines that the value of the status flag bit is true.
  • the EC can operate in both a passive heat dissipation mode, performing passive heat dissipation control based on the upper-level user scenario output by a pre-set app, and an autonomous heat dissipation mode, performing autonomous heat dissipation control based on the autonomous user scenario identified by the EC. Furthermore, the EC can detect the operating status of the pre-set app and operate in different modes depending on the operating status. Specifically, when the pre-set app is operating normally, the EC operates in the passive heat dissipation mode, performing passive heat dissipation control.
  • the pre-set app can provide the EC with comprehensive and accurate user scenario information, enabling accurate heat dissipation control based on this scenario information, improving the comprehensiveness and accuracy of heat dissipation control and enhancing heat dissipation effectiveness.
  • the EC operates in the autonomous heat dissipation mode, performing autonomous heat dissipation control.
  • the EC can autonomously identify the user scenario and, based on this autonomously identified user scenario, perform fine-grained heat dissipation control, improving heat dissipation effectiveness.
  • any heartbeat request i (1 ⁇ i ⁇ M) as an example, the above process can be represented as FIG7 .
  • the timer corresponding to the heartbeat request i is represented as timer i
  • the heartbeat response message corresponding to the heartbeat request i is represented as heartbeat response message i.
  • the corresponding timer i is started and the timing begins.
  • S1015 includes:
  • the status detection module can execute S1051B once every period of time (less than the detection duration) to determine whether the execution duration of this round of heartbeat detection is greater than the longest detection duration.
  • this round of heartbeat detection process fails to exit through the following steps S1052B and S1053B, if the execution duration of this round of heartbeat detection is greater than the longest detection duration, it is determined that there is a heartbeat request with an abnormal reply in the M heartbeat requests, the preset APP state is abnormal, step S1016 is executed, false is assigned to the status flag bit, and step S1011 is returned to be executed, and M heartbeat requests are resent, that is, this round of heartbeat detection ends and enters the next round of heartbeat detection. If the execution duration of this round of heartbeat detection is less than or equal to the longest detection duration, it means that the upper limit of the duration of a round of heartbeat detection has not been reached, step S1052B is executed, and other heartbeat response messages are detected.
  • the status detection module determines whether the heartbeat response message i has timed out according to the timer i corresponding to the heartbeat response message i; if the heartbeat response message i has timed out, it is determined that the running status of the preset APP is abnormal, and step S1016 is executed; if the heartbeat response message i has not timed out, step S1053B is executed.
  • the status detection module determines whether all M heartbeat response messages have been traversed; if so, execute step S1017; if not, take the next received heartbeat response message as the heartbeat response message i, and return to execute step S1052B.
  • the heartbeat response message i can be marked as not timed out, indicating that the heartbeat response message i has not timed out.
  • the heartbeat request i can be marked with a normal reply flag, indicating that the heartbeat request i has a normal reply. This facilitates subsequent statistical analysis and improves algorithm efficiency.
  • the detection method of this embodiment sends M heartbeat requests and determines the pre-set app's operating status based on the responses to these M heartbeat requests. This prevents misjudging abnormal heartbeat responses during periods of abnormal operation as normal operation, thereby improving the accuracy of operation status detection and, consequently, the accuracy of heat dissipation control.
  • autonomous user scenarios may include game scenarios, office scenarios, video scenarios, idle scenarios, light-load scenarios, and heavy-load scenarios, etc.
  • FIG9 is a schematic diagram of the principle of autonomous user scene recognition provided by an embodiment of the present application
  • FIG10 This is a flow chart of a heat dissipation control method provided in an embodiment of the present application. Please refer to Figures 9 and 10 together.
  • the implementation process of the above step "S111, the autonomous identification module identifies the user scenario of the electronic device according to the target data to obtain the autonomous user scenario" includes:
  • the autonomous recognition module performs scene recognition based on input data obtained from at least one of a keyboard, a touchpad, and a mouse, and obtains a scene recognition result 1 .
  • Step S1111 is also called scene recognition based on user input behavior characteristics.
  • scene recognition based on user input behavior characteristics belongs to accurate recognition.
  • the data entered by a user through an input device can reflect the user's input behavior. Based on the user's input behavior, the current user scenario of the electronic device can be inferred.
  • the following uses the recognition of gaming and office scenarios as examples to illustrate.
  • this embodiment can identify the game scene by at least one of the key values provided by the keyboard, the data provided by the mouse (called mouse data), and the state of the touchpad.
  • the key value refers to The content (i.e., value) entered by the user using a keyboard key. For example, if the user presses the "A" key, the key value entered is "A”, and if the user presses the "Space” key, the key value entered is "Space”.
  • Mouse data refers to data entered by the user by pressing a mouse key or sliding the mouse wheel. For example, if the user clicks the left mouse button twice in succession, the input data is "double-click".
  • the touchpad state can be either on or off.
  • a game key value list can be predetermined based on the feature analysis shown in Table 7.
  • the game key value list includes key values used by various types of games. These key values can reflect the area where the keys operated by the user in the game scene are located.
  • the game key value list may include key values such as W, A, S, D, Q, E, Z, X, and C. These key values are key values corresponding to some keys in the left half of the keyboard, and users generally operate these keys with their left hand.
  • the game key value list may also include mouse data, such as double-clicking the left mouse button, right-clicking the mouse button, etc. The following mainly uses key values as an example for explanation. The matching process of mouse data is similar to that of key values and will not be elaborated on.
  • the autonomous recognition module can obtain the key values entered by the user from the keyboard in real time.
  • the autonomous recognition module counts the key values and determines the ratio of the total number of key values entered during a preset time period to the total number of key presses during that time period (called the target ratio).
  • the target key value refers to a key value that belongs to the game key value list.
  • the preset time period can be set as needed, for example, to 30 seconds. For example, within 30 seconds, the user enters a total of 13 key values. Of these 13 key values, W is entered 5 times, S is entered 3 times, D is entered 1 time, Y is entered 3 times, and O is entered 1 time.
  • the autonomous recognition module can determine whether the target ratio exceeds a preset ratio threshold. If so, the scene recognition result 1 is determined to be a game scene.
  • the above process can be repeated M times. After determining that the target ratio in each of the M time periods is greater than a preset ratio threshold, scene recognition result 1 is determined to be a game scene. M is an integer greater than or equal to 2. Repeated calculations can eliminate misidentifications caused by special scenarios and improve scene recognition accuracy.
  • the judgment condition of the game scene can also be added with the judgment condition of the total number of key presses in addition to the target ratio.
  • the total number of key presses within 30s needs to be greater than the preset number threshold.
  • the judgment condition of the total number of key presses is added, so that the non-game scenes with most of the key values being the target key values but the total number of key presses being few can be excluded, thereby reducing misidentification and improving the recognition accuracy of the game scene.
  • the results of multiple calculations and judgments can also be combined to identify the game scene and improve the accuracy of scene recognition.
  • the touchpad status can also be added to the judgment conditions of the game scene. For example, if the touchpad status is off and meets the above-mentioned target ratio conditions and the total number of key presses, the scene recognition result 1 is determined to be a game scene.
  • a game key value list is determined. Based on this list and the number of user inputs, it is possible to simply and accurately identify whether the user is in a gaming scenario, thereby improving scene recognition efficiency.
  • office key value list 1 is a delete line break key value list
  • office key value list 1 includes but is not limited to key values such as Delete (also recorded as Dle), Backspace, and Enter.
  • Office key value list 2 is a shortcut key value list, and office key value list 2 includes but is not limited to key values such as Ctrl+A, Ctrl+C, Ctrl+V, Ctrl+X, Ctrl+S, Ctrl+Y, Ctrl+Z, Ctrl+B, Ctrl+I, Ctrl+L, Ctrl+E, Ctrl+R, Alt+Tab, Ctrl+T, Ctrl+W, Ctrl+R, and Ctrl+F.
  • the office key value list 3 is a direction key value list, which includes but is not limited to the direction key values such as up, down, left, and right.
  • the autonomous recognition module determines that the scene recognition result 3 is a light load scenario.
  • the matching process for other scenarios is similar and will not be repeated here.
  • the rule for temperature-based fuzzy scene recognition can also be: (ambient temperature && SoC temperature && SSD temperature)
  • scene recognition result 3 is not any of the user scenarios in Table 10, NA can be used as scene recognition result 3.
  • Scene recognition result 3 being NA indicates that the temperature-based fuzzy scene recognition result does not belong to a preset scene, for example, it does not belong to an idle scene, a light load scene, or a heavy load scene.
  • the device temperature under different ambient temperatures can reflect the degree of device usage by the electronic device, and thus can reflect the user scenario.
  • the user scenario can be matched simply and quickly by using the ambient temperature and the device temperature, thereby improving the efficiency of scene recognition.
  • an average temperature may be used to improve the accuracy of scene recognition.
  • a calculation method which includes the following steps:
  • SoC_NTC reports the SoC sampling temperature to the autonomous identification module according to a preset time window (e.g., 2s).
  • the SoC_NTC reports the SoC sampled temperature to the autonomous identification module every 2 seconds.
  • the SoC_NTC can calculate the average of multiple SoC temperature values collected within 2 seconds and report this average as the current SoC sampled temperature to the autonomous identification module. This improves temperature acquisition accuracy.
  • the autonomous identification module calculates the average value of i SoC sampling temperatures reported by SoC_NTC i times in a row to obtain a reference average value; i can be set according to actual needs, for example, it can be an integer greater than or equal to 5.
  • the autonomous identification module eliminates the SoC sampling temperatures whose difference from the reference average value is greater than a preset difference (e.g., 1°C) from the i SoC sampling temperatures, and obtains j SoC standard temperatures; j is an integer less than or equal to i.
  • a preset difference e.g. 1°C
  • the autonomous identification module calculates the average value of the standard temperatures of j SoCs to obtain the average temperature of the SoC.
  • the above calculation process obtains a reference average value based on multiple sampled temperatures, and then eliminates abnormal values in the temperature based on the reference average value (that is, the sampled temperature whose difference from the reference average value is greater than the preset difference), preventing individual abnormal data from affecting the accuracy of the average temperature calculation, thereby improving the accuracy of scene recognition.
  • the autonomous recognition module determines the autonomous user scene according to scene recognition result 1 , scene recognition result 2 , and scene recognition result 3 .
  • the trust levels of the three scene recognition results can be pre-set, and the final autonomous user scenario can be determined from the three scene recognition results based on the trust levels.
  • the trust levels of the three scene recognition results can be sorted from high to low as follows: the trust level of scene recognition result 1 > the trust level of scene recognition result 2 > the trust level of scene recognition result 3.
  • the autonomous user scenario can be determined according to the process shown in Figure 11. As shown in Figure 11, first determine whether the scene recognition result 1 is NA.
  • the scene recognition result 1 is autonomously determined to be not NA, then use the scene recognition result 1 as the autonomous user scenario; if the scene recognition result 1 is NA, then determine whether the scene recognition result 2 is NA. If the scene recognition result 2 is not NA, then use the scene recognition result 2 as the autonomous user scenario; if the scene recognition result 2 is NA, then determine whether the scene recognition result 3 is NA. If the scene recognition result 3 is not NA, then use the scene recognition result 3 as the autonomous user scenario; if the scene recognition result 3 is NA, then use the preset user scenario (such as a light load scenario) as the user autonomous scenario.
  • the preset user scenario such as a light load scenario
  • the autonomous user scenario recognition process provided in this embodiment has three branches of user scenario recognition, namely, user scenario recognition based on user input behavior characteristics, fuzzy scenario recognition based on power, and fuzzy scenario recognition based on temperature.
  • the three branches predict user scenarios from different perspectives (user usage perspective, device characteristics perspective) and different recognition granularity (precise recognition, fuzzy recognition), and the results of the three branches are integrated to obtain the final autonomous user scenario.
  • the possible omissions or inaccuracies in the scene recognition predicted by each branch can be compensated by other branches, thereby improving the comprehensiveness and accuracy of scene recognition, thereby improving the accuracy and control effect of heat dissipation control.
  • This embodiment provides a heat dissipation control method, which is performed by an electronic device, the electronic device including a fan and a keyboard, and includes:
  • the fan speed is set to a third speed
  • the fan speed is set to a sixth speed.
  • the first application can be the aforementioned preset application.
  • the first application is the PC Manager application.
  • the second application can be an application opened by the user in an actual usage scenario.
  • the office application opened by the user in an office scenario i.e., the second application is an office application
  • the office application opened by the user in an office scenario is used as an example.
  • the electronic device starts the office application. That is to say, before starting the office software, the running state of the PC Butler is normal. After the user starts the office application, the window of the office application is displayed on the screen, and the window of the office application is used as the focus window. After the PC Butler APP recognizes the change of the focus window, it recognizes that the user scene of the electronic device has changed to an office scene. The PC Butler APP sends the scene information of the office scene to the EC.
  • the process of the PC Butler APP identifying the user scene can be referred to the above steps S102 to S104.
  • the EC can continuously determine the operating status of the PC Manager app through heartbeat detection and assign a value to the status flag based on the heartbeat detection result.
  • the specific implementation process can be found in steps S101 and S1011 to S1017 of the above embodiment and will not be repeated here.
  • process 1) the PC Manager app is running normally in the background, so the status flag is assigned a value of true.
  • the EC After the EC receives the scene information of the office scene sent by the PC Butler APP, it triggers the judgment of the status flag bit and determines that the value of the status flag bit is true. Therefore, the EC determines the fan control strategy, that is, the passive table, based on the scene information of the office scene sent by the PC Butler APP. After determining the passive table, the EC controls the fan according to the passive table. That is to say, in this scenario, the passive heat dissipation control process is executed, and the scene is identified by the PC Butler APP based on the focus window, etc.
  • At least some of the key values corresponding to the first area of the keyboard are in the aforementioned game key value list. That is, after the PC Manager app is uninstalled, the first area of the keyboard is tapped, and the electronic device recognizes that the user scene has changed to a game scene, and the fan speed is set to the third speed.
  • the EC detects that the heartbeat did not meet the preset conditions based on the heartbeat detection results, so Assigning false to the status flag. Assigning false to the status flag triggers the EC to enter autonomous decision-making cooling mode, identifying the user scenario based on data such as the keyboard and device power of the electronic device, and device temperature. After the user taps the first area of the keyboard and enters the first key value, the EC recognizes that the current scenario has changed to a game scenario, and thus determines the corresponding fan control strategy (i.e., the autonomous table) based on the game scenario, and adjusts the fan speed to the third speed based on the fan control strategy. For details, please refer to steps S109 to S115 and steps S1111 to S1114 in the above embodiment.
  • Figure 12 is a schematic diagram of the workflow of an upper-level user scene recognition provided in an embodiment of the present application.
  • the scene recognition engine of the preset APP includes a system probe module, a scene recognition module and a basic strategy matching manager.
  • the scene recognition module can interact with the system probe module and the basic strategy matching manager respectively.
  • the scene recognition module can send a request to the system probe module to obtain the probe status.
  • the system probe module can obtain the operating status of the electronic device 100.
  • the system probe module may include a power status probe, a peripheral status probe, a process load probe, an audio and video status probe, a system load probe and a system event probe, etc.
  • the power status probe can subscribe to power status events in kernel mode and determine the power status based on the callback function returned by kernel mode.
  • the power status includes information such as the remaining battery charge and power mode, which can include alternating current (AC) and direct current (DC).
  • AC alternating current
  • DC direct current
  • the power status probe can send a request to subscribe to power status events to the OsEventDriver node at the executive layer.
  • the OsEventDriver node forwards the request to the power manager at the executive layer.
  • the power manager can then return a callback function to the power status probe through the OsEventDriver node.
  • the process load probe may subscribe to the process load in the kernel state, and determine the load of the process (eg, the first process) according to a callback function fed back by the kernel state.
  • the system event probe can subscribe to system events in the kernel state and determine the system events based on the callback function fed back by the kernel state.
  • System events may include window change events, process creation events, thread creation events, etc.
  • the system event probe may send a request to subscribe to the process creation event to the OsEventDriver node of the executive layer, and the OsEventDriver node forwards the request to the process manager.
  • the process manager may feed back the callback function to the system event probe through the OsEventDriver node.
  • the system event probe also sends a subscription to the focus window change event to the API module.
  • the API module may monitor whether the focus window of the electronic device 100 has changed, and feed back the callback function to the system event probe when it detects that the focus window has changed.
  • the system probe module subscribes to various events of the electronic device 100 in the kernel state, and then determines the operating status of the electronic device 100 according to the callback function fed back by the kernel state, that is, obtains the probe state. After the system probe module obtains the probe state, it can feed back the probe state to the scene recognition module. After receiving the probe state, the scene recognition module can determine the user scene of the electronic device 100 according to the probe state, that is, determine the upper user scene. As mentioned above, the upper user scene may include idle scenes, video scenes, game scenes, office scenes and social scenes, etc. The user scene can reflect the user's current usage needs.
  • the scene recognition engine identifies that the focus window is a window of a video application, it determines that the electronic device 100 is in a state of being used.
  • the sub-device 100 is in a video scene, which means that the user needs to use a video application to watch and browse videos.
  • the scene recognition engine identifies that the focus window is a chat window of WeChat TM , it determines that the electronic device 100 is in a social scene.
  • the scene recognition module determines that the user scene of the electronic device has changed through the above-mentioned probe state (for example, a change in the probe state can be considered as a change in the user scene), it can determine the user scene in which the electronic device is currently located and obtain the upper-level user scene. After the scene recognition module determines the upper-level user scene, it can send the upper-level user scene to the thermal noise balancing engine.
  • the scene recognition engine includes a system probe module, which includes a system event probe.
  • the system event probe can send a request to subscribe to a process creation event to the OsEventDriver node at the executive layer.
  • the request to subscribe to a process creation event can also be referred to as a first request.
  • the request to subscribe to process creation events can include the process name.
  • the scene recognition engine can subscribe only to creation events for a specific process, reducing interference from creation events for irrelevant processes.
  • a specific process can be a video application, a gaming application, an office application, a social networking application, and so on.
  • the scene recognition engine may not impose restrictions on the process creation events it subscribes to.
  • the OsEventDriver node sends a request to the process manager to subscribe to a process creation event.
  • the request for the process creation event can refer to the description of S201 and will not be repeated here.
  • system event probe of the scene recognition engine can send a request to subscribe to the process creation event to the process manager through the OsEventDriver node.
  • S203 The system probe module sends a request to subscribe to GPU decoding events to the OsEventDriver node.
  • the system probe module also includes an audio and video status probe.
  • the audio and video status probe of the system probe module can send a request to subscribe to GPU decoding events to the OsEventDriver node.
  • the request to subscribe to GPU decoding events can also be called a third request.
  • the OsEventDriver node sends a request to subscribe to GPU decoding events to the graphics card driver.
  • the scene recognition engine's audio and video status probe can send a request to the graphics driver to subscribe to GPU decoding events through the OsEventDriver node.
  • the OsEventDriver node can register a callback with the graphics driver. This callback registers the GPU decoding event back to the OsEventDriver node when the graphics driver detects a GPU decoding operation.
  • the system probe module sends a request to subscribe to a focus window change event to the API module.
  • the API module may include a Windows user interface interface implemented by user32.dll, which can be used to create windows.
  • a system event probe of the system probe module may send a request to subscribe to a focus window change event to the Windows user interface interface of the API module.
  • the request to subscribe to the focus window change event may also be referred to as a second request.
  • the system event probe can register a callback with the API module.
  • the purpose of registering the callback is to return the focus window change event to the system event probe when the API module (Windows user interface interface) monitors the focus window change.
  • the focus window is the window with focus, which is most likely the window that the user currently needs to use. Therefore, by monitoring the focus window, the user's usage needs can be determined. For example, if the focus window is the window of a video application, it indicates that the user needs to browse and play videos. For another example, if the focus window is the window of a game application, it indicates that the user needs to play games. By monitoring whether the focus window changes, it can be determined whether the user's needs have changed. For example, if the focus window changes from the window of a video application to the window of a game application, it indicates that the user's current need has changed from watching videos to playing games. It can be understood that if the focus window changes, that is, the user's needs have changed, it can also be determined that the current user scenario has changed.
  • S201, S203, and S205 there is no strict order between S201, S203, and S205. They can be executed sequentially in the order shown in FIG13, or simultaneously, or sequentially in the order of S203, S201, and S205, or in the order of S203, S205, and S201, or in the order of S205, S201, and S203, or in the order of S205, S203, and S201.
  • S202, S204, and S206 As long as S202 is executed after S201, S204 is executed after S203, and S206 is executed after S205, no specific restrictions are imposed here.
  • the system probe module After the system probe module has subscribed to various event requests, when the user scene of the electronic device changes, the system probe module can monitor the change event.
  • the following describes an example where the user scene of the electronic device changes from an office scene to a video scene.
  • the video application can send a request to create a process to the process manager through the kernel32.dll interface and the Ntdll.dll interface of the API module (not shown).
  • S207 The process manager creates a video application process.
  • thread 1 of the video application process actively calls the Windows user interface interface of the API module to create window 1.
  • the electronic device can display window 101, which is an office interface.
  • the electronic device can receive an operation in which the user clicks on the icon 102 of the video application on the desktop.
  • the electronic device displays window 103 (i.e., window 1, also referred to as the first window).
  • window 1 also referred to as the first window.
  • the API module reports the focus window event to the system probe module.
  • the API module determines that the focus window has changed, and reports the focus window event to the system event probe of the system probe module.
  • the focus window change event includes the name of the first process (i.e., the focus process).
  • the first process is a video application process
  • the focus window change event carries the name of the video application process.
  • the electronic device does not need to execute S206 to S211.
  • the system probe module sends a request to the API module to subscribe to the focus window change event, if the user switches the focus window to the video application window, the API module can also detect the focus window change and report the focus window event to the system probe module.
  • S213 The system probe module sends a focus window event to the scene recognition module.
  • the scene recognition module determines that the type of the first process is a video type.
  • the scene recognition module can determine that the first process belongs to the video category. For another example, if the name of the first process is wechat.exe, the scene recognition module can determine that the first process belongs to the social category. It should be noted that the above Table 11 is only an example. In fact, Table 11 can also include the process names of more applications and their categories.
  • the user context of the electronic device can be determined based on the type of the first process. For example, if the first process is determined to be a video type, the electronic device can be determined to be in a video context; for another example, if the first process is determined to be a game type, the electronic device can be determined to be in a game context. Furthermore, since the names of the first and second processes are inconsistent, it can be determined that the user context of the electronic device has changed.
  • the API module reads the video file.
  • the API module can read the corresponding video file according to the cache address carried in the video playback instruction.
  • the API module sends a decoding instruction to the graphics card driver.
  • the graphics card driver sends a startup instruction to the GPU.
  • the GPU can decode the video file through the GPU video processing engine.
  • the GPU reports a decoding event to the graphics card driver.
  • the graphics card driver reports a decoding event to the OsEventDriver node.
  • the OsEventDriver node reports the decoding event to the system probe module.
  • the OsEventDriver node reports the decoding event to the audio and video status probe of the system probe module.
  • S223 The system probe module sends a decoding event to the scene recognition module.
  • the scene recognition module sends instruction 1 to the system probe module.
  • Instruction 1 instructs the system probe module to obtain the GPU occupancy rate of the first process.
  • the instruction 1 may carry the name of the first process.
  • the system probe module sends a request to the process manager to obtain the GPU occupancy rate of the first process.
  • the request for obtaining the GPU occupancy of the focus process may include the name of the first process.
  • the audio and video status probe of the system probe module may send a request for obtaining the GPU occupancy of the first process to the process manager.
  • S226 The process manager collects the GPU occupancy rate of the first process.
  • the system probe module sends the GPU occupancy rate of the first process to the scene recognition engine.
  • the scene recognition module determines whether the GPU occupancy rate of the first process is greater than 0.
  • step S230 is executed.
  • S230 The scene recognition module sends instruction 2 to the system probe module.
  • Instruction 2 instructs the system probe module to obtain the GPU engine of the first process.
  • the instruction 2 may carry the name of the first process.
  • S231 The system probe module sends a request to the process manager to obtain the GPU engine of the first process.
  • the process manager obtains the GPU engine of the first process.
  • the process manager can obtain the GPU engine of the first process through the graphics kernel interface of the graphics card driver.
  • the process manager sends message 1 to the system probe module.
  • Message 1 indicates that the GPU engine of the first process is a GPU video processing engine.
  • the process manager may send the message to the audio and video status probe of the system probe module, and then the audio and video status module forwards the message to the scene recognition module.
  • the system probe module sends message 1 to the scene recognition module.
  • the scene recognition module determines whether the GPU engine of the first process is a GPU video processing engine.
  • the GPU engine of the first process is a GPU video processing engine, then execute S236; if the GPU engine of the first process is a GPU video processing engine, then execute S236; If the GPU engine is not a GPU video processing engine, execute S230.
  • the scene recognition engine has determined that the type of the first process is video, that is, it can be determined that the electronic device is in a video scene.
  • the scene recognition engine can determine the specific operation performed by the first process through the GPU, and then determine the specific operation of the user using the video application. For example, if the GPU engine of the first process is a GPU video processing engine, it indicates that the first process is using the GPU for decoding operations, and it can be considered that the user is using the video application to play the video. For another example, if the GPU engine of the first process is not a GPU video processing engine, it indicates that the first process is not using the GPU for decoding operations, and the user is most likely browsing video resources on the video application and has not yet played the video.
  • the scene recognition module determines, based on the process information of the first process, that the upper-layer user scene is a video playback scene.
  • the process information of the first process includes information such as the name of the first process, the application type to which the first process belongs, the GPU occupancy rate of the first process, and the GPU engine used by the first process.
  • the type of the first process is video
  • the GPU occupancy of the first process is greater than 0
  • the GPU engine of the first process is a GPU video processing engine
  • the scene recognition engine determines that the type of the first process (focus process) belongs to the game category, the power mode of the CPU is changed to game mode (game mode), the GPU occupancy of the first process is greater than 0 and the GPU engine of the first process is a GPU 3D engine, it can be determined that the electronic device is in a game scene.
  • the power status probe of the system probe module can send a request to the power manager to subscribe to the power mode change event.
  • the power manager can report the power mode change event to the power status probe of the system probe module when the power module is switched to game mode.
  • the scene recognition engine can determine whether the power mode of the CPU is game mode through the power mode change event.
  • the process of the scene recognition engine obtaining the type of the first process can be referred to S201, S202, S205, S206 ⁇ S214 in Figure 5.
  • the process of the scene recognition engine determining whether the GPU occupancy rate of the first process is greater than 0 and whether the GPU engine of the first process is a GPU 3D engine can be referred to S224 ⁇ S235. The difference is that the video application is replaced with a game application, which will not be repeated here.
  • the preset APP can determine that the upper user scene has changed from the office scene to the video scene, and then it can execute the subsequent process to send the scene information of the current upper user scene (ie, the video scene) to the kernel.
  • the electronic device may also include a processing module, a storage module, and a communication module.
  • the processing module may be used to control and manage the operation of the electronic device.
  • the storage module may be used to support the execution of program code and data stored in the electronic device.
  • the communication module may be used to support communication between the electronic device and other devices.
  • the processing module may be a processor or a controller. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application.
  • the processor may also be a combination that implements computing functions, such as a combination of one or more microprocessors, a combination of a digital signal processor (DSP) and a microprocessor, and so on.
  • the storage module may be a memory.
  • the communication module may specifically be a device that interacts with other electronic devices, such as a radio frequency circuit, a Bluetooth chip, or a Wi-Fi chip.
  • the electronic device involved in this embodiment may be a device having the structure shown in FIG. 2 .
  • An embodiment of the present application also provides a chip system, as shown in Figure 15, which includes at least one processor 801 and at least one interface circuit 802.
  • the processor 801 and the interface circuit 802 can be interconnected via lines.
  • the interface circuit 802 can be used to receive signals from other devices (such as the memory of an electronic device).
  • the interface circuit 802 can be used to send signals to other devices (such as the processor 801).
  • the interface circuit 802 can read instructions stored in the memory and send the instructions to the processor 801.
  • the electronic device can perform the various steps in the above embodiments.
  • the chip system can also include other discrete devices, which is not specifically limited in the embodiment of the present application.
  • the chip system can include the above-mentioned SoC and/or EC.
  • An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored.
  • the computer program is executed by a processor, the processor executes the heat dissipation control method of any of the above embodiments.
  • the embodiment of the present application further provides a computer program product.
  • the computer program product When the computer program product is run on a computer, the computer is caused to execute the above-mentioned related steps to implement the heat dissipation control method in the above-mentioned embodiment.
  • an embodiment of the present application also provides a device, which can specifically be a chip, component or module, and the device may include a connected processor and memory; wherein the memory is used to store computer-executable instructions, and when the device is running, the processor can execute the computer-executable instructions stored in the memory to enable the chip to execute the heat dissipation control method in the above-mentioned method embodiments.
  • the electronic device, computer-readable storage medium, computer program product or chip provided in this embodiment are all used to execute the corresponding methods provided above. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Mechanical Engineering (AREA)
  • Input From Keyboards Or The Like (AREA)
  • Cooling Or The Like Of Electrical Apparatus (AREA)

Abstract

本申请涉及电子技术领域，提供了一种散热控制方法和电子设备，该方法包括：第一应用被运行在后台的情况下，在第一时刻，启动第二应用，显示第二应用的窗口，在第一时刻之前，风扇的转速为第一转速，在第一时刻之后，第二应用的窗口为焦点窗口；在第一时刻之后，风扇的转速被设置为第二转速；在风扇的转速被设置为第二转速后，在第一时间段内，当在键盘的第一区域或第二区域被敲击的过程中，风扇的转速不变；在第一时间段之后，卸载第一应用；卸载第一应用后，在第二时间段内，在键盘的第一区域被敲击的过程中，风扇的转速被设置为第三转速。该方法能够提高散热控制效果。

Description

散热控制方法和电子设备 技术领域
本申请涉及电子技术领域，具体涉及一种散热控制方法和电子设备。
背景技术
为了提高电子设备(如笔记本电脑、个人计算机(personal computer，PC)等)的性能，很多电子设备的系统均设置了散热控制策略。散热控制策略可以包括但不限于功率控制策略、亮度控制策略以及风扇控制策略等，分别用于控制电子设备中器件的工作频率、控制电子设备的屏幕亮度，以及控制电子设备中风扇的转速等，达到散热的目的。
实际应用中发现，电子设备在一些情况下，例如在电子设备中安装的PC管家应用程序(application，APP)卡死，或被卸载时，散热控制的效果较差，出现了设备无法及时散热或者不必要情况下风扇噪声较大等问题，用户体验较差。
发明内容
本申请提供了一种散热控制方法和电子设备，能够提高散热控制的效果，提高用户体验。
第一方面，本申请提供一种散热控制方法，该方法由电子设备执行，电子设备包括风扇和键盘，该方法包括：第一应用被运行在后台的情况下，在第一时刻，启动第二应用，显示第二应用的窗口，在第一时刻之前，风扇的转速为第一转速，在第一时刻之后，第二应用的窗口为焦点窗口；在第一时刻之后，风扇的转速被设置为第二转速；在风扇的转速被设置为第二转速后，在第一时间段内，当在键盘的第一区域或第二区域被敲击的过程中，风扇的转速不变；在第一时间段之后，卸载第一应用；卸载第一应用后，在第二时间段内，在键盘的第一区域被敲击的过程中，风扇的转速被设置为第三转速。
第一应用也即具体实施方式中的预设APP。可选的，第一应用例如可以为PC管家、电脑管家或散热决策APP等，第一应用能够根据焦点窗口等信息识别电子设备所处的用户场景。第二应用为用户在实际应用场景下启动的应用。例如，办公场景下，第二应用可以为办公APP；游戏场景下，第二应用可以为游戏APP；视频场景下，第二应用可以为用于播放视频的APP。
在第一时刻之前，风扇的转速为第一转速。第一时刻之后，第二应用的窗口变为焦点窗口，第一应用被运行在后台的情况下，第一应用识别到电子设备的用户场景变化为第二应用对应的用户场景。电子设备基于该场景识别结果进行散热控制，将风扇转速调整为第二转速。简而言之，第一应用被运行在后台的情况下，焦点窗口变化，风扇转速变化。
之后，在第一时间段内，在第一应用仍在运行，且保持焦点窗口不变，即焦点窗口仍为第二应用的窗口，第一应用识别到用户场景未发生变化。这种情况下，用户敲击键盘中的第一区域或第二区域，风扇转速不发生改变。也就是说，第一应用被运行在后台，且焦点窗口不变的情况下，键盘输入数据，风扇转速不变。
第一时间段之后，卸载第一应用。卸载第一应用后第一应用无法识别用户场景，因而电子设备无法根据第一应用识别的用户场景进行散热控制。这种情况下，电子设备可以基 于第二时间段内键盘的输入数据等进行用户场景识别，并基于该识别结果进行散热控制。具体的，当用户在第二时间段内敲击键盘的第一区域，基于键盘的输入数据识别到用户场景变化为预设场景，将风扇转速调整为该预设场景对应的第三转速。该预设场景例如可以为游戏场景。简而言之，第一应用被卸载后，键盘输入数据，风扇转速改变。
可以理解，第二时间段，只有键盘的第一区域被敲击，键盘的第二区域没有被敲击。另外，在第二时间段内，焦点窗口可以发生变化，也可以不发生变化。因为第一应用已被卸载，无论焦点窗口是否发生变化，均无法基于第一应用识别用户场景。
第一方面提供的散热控制方法，在第一应用被卸载之后，键盘的第一区域被敲击的情况下，能够根据键盘输入的数据确定与用户场景匹配的风扇转速，基于该风扇转速进行风扇控制，以对电子设备进行及时散热，且防止出现过度散热导致风扇噪声过大的情况。也就是说，该方法无需依赖第一应用，在第一应用异常的情况下，也能够实现精细化的散热控制，提高散热控制的效果。
结合第一方面，在第一方面的有些实现方式中，该方法还包括：在第一时间段内，响应于键盘的第一区域或第二区域被敲击，在第二应用的窗口中显示第一内容，第一内容包括在第一时间段内，敲击键盘的第一区域或第二区域输入的内容。
例如，用户敲击键盘的第一区域中的A、D、S、F键，则第二应用的窗口内显示“ADSF”或“adsf”。
一种可能的实现方式中，该方法还包括：在第二时间段内，响应于键盘的第一区域被敲击，在电子设备的屏幕中显示第二内容，第二内容包括在第二时间段内，敲击键盘的第一区域输入的内容。
一种可能的实现方式中，该方法还包括：卸载第一应用后，基于电子设备中的第一器件的功率变化，将风扇的转速设置为第四转速。
可选的，在第一器件的功率变化至某一功率范围内时，将风扇的转速设置为与该功率范围对应的第四转速。
可选的，功率越大，对应的风扇转速越大。
一种可能的实现方式中，可以基于某一时间段内第一器件功率的情况，调整风扇的转速。具体的，卸载第一应用后，基于电子设备中的第一器件的功率变化，将风扇的转速设置为第四转速，包括：卸载第一应用后，在第五时间段内，基于电子设备中的第一器件的功率变化，将风扇的转速设置为第四转速。根据一段时间内的功率情况，能够更准确地识别用户场景的变化，提高散热控制的准确性。
一种可能的实现方式中，基于电子设备中的第一器件的功率变化，将风扇的转速设置为第四转速，包括：检测到电子设备中的第一器件的功率变化为第一功率；根据第一功率，确定电子设备所处的用户场景为第三场景；根据第三场景的场景信息，确定第三策略；根据第三策略，调整风扇的转速为第四转速。
可选的，第三场景例如可以为本地视频场景或在线视频场景。
可以理解，不同用户场景下，电子设备中器件的功率大小不同。该实现方式中，从器件功率的角度对电子设备所处的用户场景进行识别，可以将识别结果作为基于键盘输入的数据识别结果的一种补充或再次确认，减少场景识别的遗漏或识别不准确，提高场景识别的全面性和准确性。
一种可能的实现方式中，第一器件包括系统级芯片(system on chip，SoC)、固态硬盘(solid state disk，简称SSD)、双倍速率同步动态随机存储器(doubledata rate，DDR)、屏幕、音频功率放大器(power amplifier，PA)和无线通信模块中的至少一者。
该实现方式中，基于多种器件的功率综合识别用户场景，提高用户场景识别的准确性，进而提高散热控制的效果。
一种可能的实现方式中，该方法还包括：卸载第一应用后，在第三时间段内，基于电子设备中的第二器件的温度变化，将风扇的转速设置为第五转速。
可选的，在第二器件的功率变化至某一温度范围的情况下，将风扇的转速设置为与该温度范围对应的第五转速。可选的，温度越高，对应的风扇转速越大。
一种可能的实现方式中，在第三时间段内，基于电子设备中的第二器件的温度变化，将风扇的转速设置为第五转速，包括：检测到电子设备中的第二器件的温度变化为第一温度；根据第一温度，确定电子设备所处的用户场景为第四场景；根据第四场景的场景信息，确定第四策略；根据第四策略，调整风扇的转速为第五转速。
第四场景例如可以为空闲(idle)场景、重载场景或轻载场景等。
可以理解，不同用户场景下，器件的发热程度不同，器件的温度不同。该实现方式中，从器件温度的角度对电子设备所处的用户场景进行识别，可以将识别结果作为其他方式识别得到的识别结果的一种补充或再次确认，减少场景识别的遗漏或识别不准确，提高场景识别的全面性和准确性。
一种可能的实现方式中，检测到电子设备中的第二器件的温度变化为第一温度，包括：获取第二器件在第三时间段内的i个采样温度，i为大于或等于1的整数；计算i个采样温度的平均值，得到参考平均值；剔除i个采样温度中，与参考平均值的差值大于预设差值的采样温度，得到j个标准温度；计算j个标准温度的平均值，得到第一温度。
该实现方式中，基于多个采样温度计算得到参考平均值，再基于参考平均值剔除温度中的异常值(即，与参考平均值的差值大于预设差值的采样温度)，之后基于剩下的采样温度计算第一温度。这样能够防止个别异常数据影响平均温度计算的准确性，进而提高了场景识别的准确性。
一种可能的实现方式中，卸载第一应用后，在第二时间段内，在键盘的第一区域被敲击的过程中，风扇的转速被设置为第三转速，包括：卸载第一应用后，在第二时间段内，基于键盘的第一区域被敲击，将风扇的转速设置为第三转速。
具体的，电子设备在检测到键盘的第一区域被敲击，根据敲击第一区域输入的数据，识别用户场景，并基于用户场景将风扇转速设置为第三转速。
一种可能的实现方式中，卸载第一应用后，在第二时间段内，基于键盘的第一区域被敲击，将风扇的转速设置为第三转速，包括：在第二时间段内，响应于键盘的第一区域被敲击，通过键盘接收第一键值；基于第一应用被卸载，根据第一键值，确定电子设备所处的用户场景为第一场景；根据第一场景的场景信息，确定第一策略；根据第一策略，调整风扇的转速为第三转速。
可选的，第一场景例如可以为游戏场景。
该实现方式中，可以基于键值，识别第一场景，并基于第一场景决策与第一场景匹配的风扇控制策略(第一策略)，在第一应用被卸载的情况下，也能够实现基于场景进行精 细化散热控制，提高散热控制效果。
一种可能的实现方式中，根据第一键值，确定电子设备所处的用户场景为第一场景，包括：根据第一键值，确定目标比例，目标比例为第一键值中，目标键值的总个数占第一键值总个数的比例，目标键值为属于目标列表的键值，目标列表中的键值在键盘形成第三区域，第三区域与键盘的第一区域至少部分重合；确定目标比例是否大于预设比例阈值，得到第一结果；根据第一结果，确定电子设备所处的用户场景为第一场景。
可以理解，第一键值为第二时间段内敲击键盘第一区域输入的键值，因而，第一键值的总个数也即第二时间段内用户按键(即敲击键盘中的键)的总次数(每个键被敲击一次统计为一个键值)，目标键值的总个数也即第二时间段内用户对目标键值对应的键的敲击次数。
目标键值列表也即具体实施例方式中的游戏键值列表。游戏键值列表中包含在游戏场景下，大概率被用户使用到的键对应的键值。第一区域中的部分或全部键对应的键值属于目标键值列表。
目标比例大于预设比例阈值，说明第一键值中属于目标键值列表的键值较多，则确定用户场景为第一场景(例如游戏场景)。
该实现方式中，通过计算第一键值中目标键值的占比，能够准确地识别第一场景，提高用户场景识别的准确性，进而提高散热控制的准确性。
一种可能的实现方式中，根据第一结果，确定电子设备所处的用户场景为第一场景，包括：若第一结果为目标比例大于预设比例阈值，则确定电子设备所处的用户场景为第一场景；或者，若第一结果为目标比例大于预设比例阈值，且第一键值的总个数大于第一预设数量，则确定电子设备所处的用户场景为第一场景。
该实现方式中，在目标比例的基础上，增加了第一键值总个数的判断条件，这样能够将键值多数为目标键值但是按键总次数少的非第一场景排除，减少误识别，提高了第一场景的识别准确性。
一种可能的实现方式中，根据第一场景的场景信息，确定第一策略，包括：根据第一场景的场景信息，以及电子设备当前的系统运行模式，确定第一策略。
系统运行模式可以为电子设备的操作系统预先设置的多种运行模式。不同的系统运行模式下，电子设备的功率大小、散热力度、噪声大小等不同。系统运行模式例如可以包括静谧模式、性能模式和狂战模式等。
该实现方式中，在决策风扇控制策略时，不仅考虑到基于用户场景，还基于电子设备的系统运行模式进行决策。这样，进一步考虑用户的实际使用需求，使决策得到的风扇控制策略与用户需求更匹配，进一步提高用户体验。
一种可能的实现方式中，第一策略中包括电子设备中第三器件的多个温度范围与风扇的多个转速的对应关系，其中，多个转速中包括第三转速；根据第一策略，调整风扇的转速为第三转速，包括：获取第三器件的当前温度；基于第一策略，确定当前温度所属的温度范围与第三转速对应；调整风扇的转速为第三转速。
该实现方式中，在基于风扇控制策略调整风扇转速时，结合器件温度进行调整。具体的，器件温度较高时，风扇转速可以较大，器件温度较低时，风扇转速可以较低。这样，使电子设备能够趋于热平衡，提高散热控制效果，进而提高电子设备的性能。
一种可能的实现方式中，第一策略中还包括多个温度范围与多个最小持续时长的对应关系，多个最小持续时长中包括第一目标时长，该方法还包括：基于第一策略，确定当前温度所属的温度范围与第一目标时长对应；风扇在第三转速下运转的时长大于第一目标时长。
该实现方式中，在控制风扇转速时，设置最小持续时长，这样防止风扇转速调整过于频繁，防止造成不必要的功率损耗，也防止给用户造成过多打扰，提高风扇控制的稳定性和可靠性。
一种可能的实现方式中，第一策略中，多个温度范围中的每个对应一个等级，温度范围中的温度越高等级越高，风扇转速越大，当前温度所属的温度范围对应于第一策略中的第一目标等级，最小持续时长包括第一最小持续时长和第二最小持续时长；该方法还包括：若上一策略不为第一策略，则基于第一策略，确定第一目标等级对应的第一最小持续时长的值为第一目标时长；上一策略是指当前时刻之前且距离当前时刻最近的，用于控制风扇转速的策略；若上一策略为第一策略，且当前时刻之前通过第一策略中的第二目标等级控制风扇转速，且第二目标等级低于第一目标等级，则基于第一策略，确定第一目标等级对应的第一最小持续时长的值为第一目标时长；若上一策略为第一策略，且当前时刻之前通过第一策略中的第二目标等级控制风扇转速，且第二目标等级高于第一目标等级，则基于第一策略，确定第一目标等级对应的第二最小持续时长的值为第一目标时长。
该实现方式中，新切入某一控制策略、等级升高以及等级降低等不同情况下，选用不同的最小持续时长，这样能够匹配到与散热需求更匹配的最小持续时长，防止风扇转速调整过于频繁的同时，也能够及时散热，提高散热控制效果。
一种可能的实现方式中，基于第一应用被卸载，根据第一键值，确定电子设备所处的用户场景为第一场景，包括：确定标记位的值；基于标记位的值是第一预设值，根据第一键值，确定电子设备所处的用户场景为第一场景。
标记位也称为状态标记位。第一预设值例如可以为false。标记位还可以具有第二预设值，第二预设值例如可以为true。
该实现方式中，基于标记位的值为第一预设值，确定第一应用运行状态异常，进而通过键值识别用户场景。也就是说，根据标记位的值确定是进行自主散热控制，还是被动散热控制。自主散热控制是指通过键盘的数据、功率或温度等进行自主场景识别，基于自主场景识别的结果进行散热控制。被动散热控制是指基于第一应用识别的用户场景(也称为上层用户场景)进行散热控制。这样，在第一应用被卸载等情况下，也能够进行细粒度的散热控制，提高散热控制效果。标记位的值为第一预设值，说明第一应用的运行状态异常，进行自主散热控制；标记位的值为第二预设值，说明第一应用的运行状态正常，进行被动散热控制，这样第一应用能够向提供全面、准确的用户场景信息，因而能够基于该场景信息准确地控制散热，提高散热控制的全面性和准确性，提高散热效果。
一种可能的实现方式中，确定标记位的值，包括：向第一应用发送M个心跳请求，并在发送每个心跳请求时启动一个与心跳请求对应的定时器，M为大于或等于1的整数；根据第一应用回复的与心跳请求对应的心跳响应消息，以及定时器，确定M个心跳请求中是否存在第一心跳请求，第一心跳请求是指，未在对应的定时器超时之前接收到对应心跳响应消息的心跳请求；若M个心跳请求中存在第一心跳请求，则确定标记位的值为第一预设 值；若M个心跳请求中不存在第一心跳请求，则确定标记位的值为第二预设值。
第一心跳请求也称为回复异常的心跳请求。
该实现方式中，通过对第一应用执行心跳请求操作，不仅能够简单、快速地确定第一应用本身的运行状态是否异常，而且检测结果能够覆盖第一应用与其他模块(例如嵌入式控制器(embedded controller，EC))通信异常的情况，而实际应用中，预设APP与EC通信异常也会导致无法提供识别的用户场景，因而该方法在这种情况下进行自主散热控制，能够提高散热控制的准确性。另外，本实现方式提供的检测方法，每轮心跳检测中，发送M个心跳请求，根据这M个心跳请求的回复情况判断第一应用的运行状态，这样能够防止将运行状态异常时偶尔有心跳正常回复的情况误判断为运行状态正常，提高运行状态检测的准确性，进而提高散热控制的准确性。
一种可能的实现方式中，根据第一应用回复的与心跳请求对应的心跳响应消息，以及定时器，确定M个心跳请求中是否存在第一心跳请求，包括：在第一定时器到达其定时时长时，确定是否存在第一心跳响应消息，第一定时器为最早心跳请求对应的定时器，第一心跳响应消息为最早心跳请求对应的心跳响应消息，最早心跳请求为M个心跳请求中发送最早的心跳请求；若不存在第一心跳响应消息，则确定M个心跳请求中存在第一心跳请求；若存在第一心跳响应消息，则确定M个心跳请求对应的M个定时器是否被遍历；若M个定时器未被遍历，则将第二定时器作为第一定时器，返回执行在第一定时器到达其定时时长时，确定是否存在第一心跳响应消息；第二定时器为第二心跳请求对应的定时器，第二心跳请求为第一心跳请求之后发送的，与第一心跳请求相邻的心跳请求；若所有M个定时器被遍历，则确定M个心跳请求中不存在第一心跳请求。
该实现方式通过循环遍历定时器，能够简单、快速、准确地确定M个心跳请求中是否存在第一心跳请求，提高心跳检测的准确性，从而提高标记位的值的准确性，进而提高散热控制的准确性。
一种可能的实现方式中，根据第一应用回复的与心跳请求对应的心跳响应消息，以及定时器，确定M个心跳请求中是否存在第一心跳请求，包括：以第一预设时长为周期时长，周期性确定第一时间差是否大于预设的最长检测时长；第一时间差为当前时刻与最早心跳请求的发送时刻的时间差，最早心跳请求为M个心跳请求中发送最早的心跳请求，第一预设时长小于最长检测时长；若第一时间差大于最长检测时长，则确定M个心跳请求中存在第一心跳请求；若时间差小于或等于最长检测时长，则在接收到第二心跳响应消息后，确定第二时间差是否超过第三定时器的定时时长；第二时间差为接收第二心跳响应消息的时刻与发送第三心跳请求的时刻的时间差，第二心跳响应消息为接收到的任意一个心跳响应消息，第三心跳请求为第三心跳响应消息对应的心跳请求，第三定时器为第三心跳请求对应的定时器；若第二时间差大于第三定时器的定时时长，则确定M个心跳请求中存在第一心跳请求；若第二时间差小于或等于第三定时器的定时时长，则判断是否遍历M个心跳请求对应的M个心跳响应消息；若未遍历M个心跳响应消息，则将下一个接收到心跳响应消息作为第二心跳响应消息，返回执行若时间差小于或等于最长检测时长，则在接收到第二心跳响应消息后，确定第二时间差是否超过第三定时器的定时时长；若遍历M个心跳响应消息，则确定M个心跳请求中不存在第一心跳请求。
该实现方式通过在最长检测时长内循环遍历心跳响应消息，能够简单、快速、准确地 确定M个心跳请求中是否存在第一心跳请求，提高心跳检测的准确性，从而提高标记位的值的准确性，进而提高散热控制的准确性。
一种可能的实现方式中，该方法还包括：在第二时间段后，在第四时间段内，在键盘的第二区域被敲击的过程中，风扇的转速被设置为第六转速。
可以理解，在第四时间段内，只有键盘的第二区域被敲击，键盘的第一区域没有被敲击。在第四时间段内，焦点窗口可以发生变化，也可以不发生变化。第四时间段内，第一应用处于被卸载状态。
卸载第一应用后第一应用无法识别用户场景，因而电子设备无法根据第一应用识别的用户场景进行散热控制。这种情况下，当用户在第四时间段内敲击键盘的第二区域，基于键盘的输入数据识别到用户场景变化为预设场景，将风扇转速调整为该预设场景对应的第六转速。该预设场景例如可以为办公场景。
该实现方式中，在第一应用被卸载之后，键盘的第二区域被敲击的情况下，能够根据键盘输入的数据识别用户场景，基于用户场景，确定与用户场景匹配的风扇转速，基于该风扇转速进行风扇控制，以对电子设备进行及时散热且防止不必要情况下出现风扇噪声过大的情况。也就是说，该方法无需依赖第一应用，在第一应用异常的情况下，也能够实现精细化的散热控制，提高散热控制的效果。而且，不依赖第一应用的情况下，该方法可以识别多种用户场景，将风扇转速调整为多种转速(例如第三转速和第六转速)。
一种可能的实现方式中，该方法还包括：在第四时间段内，响应于键盘的第二区域被敲击，在电子设备的屏幕中显示第三内容，第三内容包括在第四时间段内，敲击键盘的第二区域输入的内容。
例如，用户选中某一应用中的内容“x”，并敲击键盘的第二区域中的Ctrl、C、Ctrl、V键，则屏幕中显示内容“x”。
一种可能的实现方式中，卸载第一应用后，在第四时间段内，在键盘的第二区域被敲击的过程中，风扇的转速被设置为第六转速，包括：卸载第一应用后，在第四时间段内，基于键盘的第二区域被敲击，将风扇的转速设置为第六转速。
具体的，电子设备在检测到键盘的第二区域被敲击，根据敲击第二区域输入的数据，识别用户场景，并基于用户场景将风扇转速设置为第六转速。
一种可能的实现方式中，在第二时间段后，在第四时间段内，在键盘的第二区域被敲击的过程中，风扇的转速被设置为第六转速，包括：在第四时间段内，响应于键盘的第二区域被敲击，通过键盘接收第二键值；基于第一应用被卸载，根据第二键值，确定电子设备所处的用户场景为第二场景；根据第二场景的场景信息，确定第二策略；根据第二策略，调整风扇的转速为第六转速。
第二场景例如可以为办公场景。
该实现方式中，可以基于键值，识别第二场景，并基于第二场景决策与第二场景匹配的风扇控制策略(第二策略)，在第一应用被卸载的情况下，也能够实现基于场景进行精细化散热控制，提高散热控制效果。
一种可能的实现方式中，根据第二键值，确定电子设备所处的用户场景为第二场景，包括：分别统计第二键值中，第一类键值的个数、第二类键值的个数和第三类键值的个数；第一类键值、第二类键值和第三类键值对应键盘的第四区域，第四区域与键盘的第二区域 至少部分重合；根据第一类键值的个数确定第一预测因子的值；根据第二类键值的个数确定第二预测因子的值；根据第三类键值的个数确定第三预测因子的值；对第一预测因子的值、第二预测因子的值和第三预测因子的值进行加权求和，得到预测值；确定预测值是否大于预设阈值，得到第二结果；根据第二结果，确定电子设备所处的用户场景为第二场景。
可以理解，第二键值为第四时间段内敲击键盘第一区域输入的键值，因而，第二键值的第一类键值的个数也即第二时间段内用户对第一类键值的敲击总次数。第一类键值、第二类键值和第三类键值对应的键为用户在办公场景下大概率被使用到的键。键盘的第二区域中的部分或全部键对应的键值属于第一类键值、第二类键值或第三类键值。
该实现方式中，根据第二键值中各类预设键值的个数确定预测值，并根据预测值的大小，能够准确地识别第二场景，提高用户场景识别的准确性，进而提高散热控制的准确性。
一种可能的实现方式中，根据第二结果，确定电子设备所处的用户场景为第二场景，包括：若第二结果为预测值大于预设阈值，则确定电子设备所处的用户场景为第二场景；或者，若第二结果为预测值大于预设阈值，且第二键值的总个数大于第二预设数量，则确定电子设备所处的用户场景为第二场景。
该实现方式中，在预测值的基础上，增加了第二键值总个数的判断条件，这样能够将键值多数为第一类键值、第二类键值或第三类键值，但是按键次数少的非第二场景排除，减少误识别，提高了第二场景的识别准确性。
一种可能的实现方式中，根据第一类键值的个数确定第一预测因子的值，包括：若第一类键值的个数大于第一个数阈值，则确定第一预测因子的值为第一值；若第一类键值的个数小于或等于第一个数阈值，则确定第一预测因子的值为第二值。
第一预测因子例如可以为具体实施方式中的预测因子a。第一个数阈值也可以称为第一次数阈值，可以为具体实施方式中的次数阈值th1。
第一值例如可以为1，第二值例如可以为0。
一种可能的实现方式中，第一类键值中包括用于指示删除内容的键值，和/或，用于指示换行的键值；第二类键值中包括至少一个快捷键对应的键值；第三类键值中包括用于指示调整方向的键值。
一种可能的实现方式中，在第一时间段内，当在键盘的第一区域或第二区域被敲击的过程中，风扇的转速不变，包括：在第一时间段内，响应于键盘的第一区域或第二区域被敲击，通过键盘接收第三键值；基于第一应用被运行，不根据第三键值确定电子设备所处的用户场景。
在第一时间段内，第一应用处于运行状态，第一应用能够正常识别用户场景。电子设备可以基于第一应用识别的用户场景进行被动散热控制。因而，该场景下，敲击键盘，不基于输入的第三键值进行场景识别。
一种可能的实现方式中，电子设备还包括嵌入式控制器(embedded controller，EC)，在第一时刻之后，风扇的转速被设置为第二转速，包括：基于第二应用的窗口为焦点窗口，第一应用确定电子设备所处的用户场景为第五场景；第一应用将第五场景的场景信息下发至EC；EC基于标记位的值是第二预设值，根据第五场景的场景信息，确定第五策略；EC根据第五策略控制风扇的转速变化为第二转速。
该实现方式中，通过EC执行被动散热控制。可以理解，自主散热控制也可以由EC 执行。EC位于固件层，运行于操作系统的底层，不受操作系统上层的影响，因而，由EC进行散热控制，不易受到操作系统上层变化的影响，提高散热控制的可靠性和稳定性。
第二方面，本申请提供一种装置，该装置包含在电子设备中，该装置具有实现上述第一方面及上述第一方面的可能实现方式中电子设备行为的功能。功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。硬件或软件包括一个或多个与上述功能相对应的模块或单元。例如，接收模块或单元、处理模块或单元等。
第三方面，本申请提供一种电子设备，电子设备包括：处理器、存储器和接口；处理器、存储器和接口相互配合，使得电子设备执行第一方面的技术方案中任意一种方法。
第四方面，本申请提供一种芯片系统，包括处理器。处理器用于读取并执行存储器中存储的计算机程序，以执行第一方面及其任意可能的实现方式中的方法。
可选的，芯片系统还包括存储器，存储器与处理器通过电路或电线连接。
进一步可选的，芯片还包括通信接口。
第五方面，本申请提供一种计算机可读存储介质，计算机可读存储介质中存储了计算机程序，当计算机程序被处理器执行时，使得该处理器执行第一方面的技术方案中任意一种方法。
第六方面，本申请提供一种计算机程序产品，计算机程序产品包括：计算机程序代码，当计算机程序代码在电子设备上运行时，使得该电子设备执行第一方面的技术方案中任意一种方法。
附图说明
图1是本申请实施例提供的一例散热控制过程示意图；
图2是本申请实施例提供的一例电子设备100的结构示意图；
图3是本申请实施例提供的一例电子设备100的软件和硬件结构框图；
图4是本申请实施例提供的另一例电子设备100的软件和硬件结构框图；
图5是本申请实施例提供的一例散热控制方法的模块交互示意图；
图6是本申请实施例提供的另一例散热控制方法的模块交互示意图；
图7是本申请实施例提供的一例状态检测的流程示意图；
图8是本申请实施例提供的另一例状态检测的流程示意图；
图9是本申请实施例提供的一例自主用户场景识别的原理示意图；
图10是本申请实施例提供的一例散热控制方法的流程示意图；
图11是本申请实施例提供的一例自主用户场景的识别流程示意图；
图12是本申请实施例提供的一例上层用户场景识别的工作流程示意图；
图13是本申请实施例提供的一例上层用户场景识别的模块交互示意图；
图14是本申请实施例提供的一例界面示意图；
图15是本申请实施例提供的一例芯片系统的结构示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本 申请实施例的描述中，“多个”是指两个或多于两个。
以下，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”、“第三”的特征可以明示或者隐含地包括一个或者更多个该特征。
另外，本申请说明书中的“自主”和“被动”，仅用于区分不同的数据来源、不同的模块或不同的执行过程等，而不能理解为用于指示或暗示动作的执行方式、执行主体或者动作的执行结果，也不能理解为用于区分模块、数据或过程的主次等。本申请中，“自主”也可以替换为“第一”，“被动”也可以替换为“第二”；或者，“自主”也可以替换为“第二”，“被动”也可以替换为“第一”。
在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本申请说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
为更好地理解本申请实施例，以下对实施例中可能涉及的术语或概念进行解释说明。
策略，是指能够实现目标的方案的集合。本申请实施例中涉及散热控制策略、功率控制策略、亮度控制策略和风扇控制策略等。散热控制策略是指能够实现散热控制的方案的集合。功率控制策略是指能够实现对电子设备中器件功率(也称为功耗)的调节，以控制散热的方案的集合。亮度控制是指能够实现对电子设备屏幕(即显示屏)亮度的调节，以控制散热的方案集合。风扇控制策略是指能够实现对风扇转速的调节，以控制散热的方案集合。
焦点窗口(focus window)，指拥有焦点的窗口。焦点窗口是唯一可以接收键盘输入的窗口。焦点窗口的确定方式与系统的焦点模式(focus mode)关联。焦点窗口的顶层窗口被称为活动窗口(active window)。同一时间只有一个窗口可以是活动窗口。焦点窗口大概率为用户当前需要使用的窗口。
焦点模式，可用于决定鼠标如何使一个窗口获得焦点。一般地，焦点模式可包括三种，分别为：
(1)点击聚焦(click to focus)，在这种模式下，鼠标点击的窗口即可被作为焦点。即当鼠标点击一个可以被作为焦点的窗口的任意位置，即可激活该窗口，该窗口便被置于所有窗口的最前面，并接收键盘输入。当鼠标点击其他窗口时，该窗口不再被作为焦点。
(2)焦点跟随鼠标(focus follow mouse)，在这种模式下，鼠标下的窗口可以被作为焦点。即当鼠标移到一个可以被作为焦点的窗口的范围内，用户不需要点击窗口的某个地方就可以激活这个窗口，接收键盘输入，但该窗口不一定被置于所有窗口的最前面。当鼠标移出这个窗口的范围时，这个窗口也不再被作为焦点。
(3)草率聚焦(sloppy focus)，这种焦点模式与focus follow mouse比较类似：当鼠标移到一个可以被作为焦点的窗口的范围内，用户不需要点击窗口的某个地方就可以激活这个窗口，接收键盘输入，但该窗口不一定被置于所有窗口的最前面。与focus follow mouse 不同的是，当鼠标移出这个窗口范围时，焦点并不会随之改变，只有当鼠标移动到别的可以被作为焦点的窗口时，系统焦点才改变。
下面对本申请的技术问题进行说明。
散热控制的效果对于电子设备的性能起着举足轻重的作用。散热控制策略包括频率控制策略、亮度控制策略，以及风扇控制策略等。使用过程中发现，在电子设备中安装的PC管家APP(或电脑管家APP等)的运行状态异常时，电子设备的散热控制效果不佳。PC管家APP的运行状态异常包括但不限于PC管家APP未运行(包括该APP被卸载或未安装)，PC管家APP的进程卡死、被冻结或被挂起等。
对此现象分析原因发现，电子设备的散热控制过程，可以由PC管家APP识别用户场景，并基于不同的用户场景，适配不同的散热策略，以使电子设备趋于热平衡的同时，考虑用户的使用需求。而PC管家APP运行状态异常，可能导致用户场景无法识别，进而导致无法根据用户场景适配散热控制策略(频率控制策略、亮度控制策略和风扇控制策略中的至少一种)，导致散热控制的效果不佳。
以下结合电子设备的结构，以风扇控制策略为例，对散热控制过程进行说明。示例性，图1为本申请实施例提供的一例散热控制过程示意图。如图1所示，电子设备可以包括系统级芯片(system on chip，SoC)、嵌入式控制器(embedded controller，EC)和风扇(fan)。其中，风扇的数量可以为一个，也可以为多个。本申请实施例中，以风扇数量为两个，表示为风扇1和风扇2为例进行说明。SoC中可以集成有CPU、GPU等器件。SoC中运行有操作系统(operating system，OS)，操作系统中包括PC管家APP和操作系统内核(kernel)(下简称为内核)。
如图1所示，一种实现方式中，PC管家APP识别电子设备当前的用户场景，并将用户场景通过内核发送至EC。EC进行用户场景匹配，生成风扇控制策略，并执行风扇控制策略，以控制风扇1和风扇2的转速。
在另一些图1未示出的实现方式中，PC管家APP也可以根据用户场景生成散热控制策略，散热控制策略中包括风扇控制策略。PC管家APP将风扇控制策略通过内核发送至EC，由EC执行风扇控制策略，以控制风扇1和风扇2的转速。
可以理解，本申请实施例中，PC管家APP仅作为一种示例，实际应用中，PC管家APP也可以为其他能够识别用户场景，和/或，决策散热控制策略的其他APP(以下称为预设APP)，对此不做任何限定。
上述两种实现方式都能够根据用户场景控制风扇的转速，提高散热控制的效果，满足用户的使用需求。然而，无论是上述哪一种实现方式，EC控制风扇转速需要依赖PC管家APP的输出结果。那么，在PC管家APP运行状态异常的情况下，EC无法获得风扇控制策略，导致无法对风扇转速进行控制。如图1所示，作为一种可能的实现方式，EC在无法接收到PC管家APP发送的用户场景或风扇控制策略时，可以选择默认的控制策略对风扇1和风扇1进行控制。但是，默认的控制策略对于风扇转速的控制为粗粒度控制。例如默认的控制策略为设置风扇转速为固定值，则风扇转速不能跟随用户场景适应性变化，导致设备无法达到热平衡，或者噪声大等问题。举例来说，PC管家APP运行状态异常的情况下，无论是游戏场景，还是办公场景，均通过默认的控制策略，控制风扇以固定转速运 转。但是，对于游戏场景来说，电子设备产生热量较多，需要控制风扇以较高的转速运转，以满足更快的散热需求。所以，若游戏场景下风扇以固定转速运转，散热力度较小，散热不及时，导致设备过热，影响设备性能。而对于办公场景来说，电子设备产生热量较少，散热需求小，且用户可能希望环境尽可能的安静，这时就需要风扇以较低的转速运转。所以，若办公场景下风扇以固定转速运转，风扇噪声较大，用户体验较差。可以理解，风扇转速为固定值仅作为默认控制策略的一种举例，实际应用中，默认控制策略也可以为其他，例如为根据CPU温度对风扇进行粗粒度的控制等。
需要说明的是，PC管家APP运行状态异常还可能导致其他散热控制策略无法按照预期执行，进而导致电子设备散热控制效果不佳。例如，PC管家APP运行状态异常时，不能根据用户场景匹配对应的功率控制策略，电子设备不能跟随场景调整中央处理器(central processing unit，CPU)或图形处理器(graphics processing unit，GPU)的工作频率，导致散热控制效果不佳。再例如，PC管家APP运行状态异常时，不能根据用户场景匹配对应的亮度控制策略，屏幕不能跟随场景调整亮度，导致散热控制效果不佳。
基于上述分析，本申请实施例提供一种散热控制方法，通过EC识别用户场景，并通过EC监测预设APP的运行状态。在预设APP运行状态异常的情况下，通过EC识别得到用户场景生成散热控制策略。这样，散热控制策略无需依赖预设APP，即使预设APP运行异常，也能够根据EC识别到的用户场景生成精细化的散热控制策略，提高散热控制的效果，进而提高电子设备的性能，提高用户的体验。
本申请实施例提供的散热控制方法可以应用于笔记本电脑、PC、超级移动个人计算机(ultra-mobile personal computer，UMPC)等电子设备上，本申请实施例对电子设备的具体类型不作任何限制。
示例性地，图2为本申请实施例提供的电子设备100的结构示意图。如图2所示，电子设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，无线通信模块150，显示屏160，风扇170，输入设备180，传感器190等。
可以理解的是，本实施例示意的结构并不构成对电子设备100的具体限定。在另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，GPU，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，EC，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，应用处理器(application processor，AP)中可以集成有CPU。当然，AP也可以直接替换为CPU。应理解，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。例如，AP、GPU以及基带处理器等除EC之外的处理单元可以集成在一个处理器芯片中，形成上述实施中所述的SoC。换句话说，处理器110可以包括SoC和EC等。
控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时 序信号，产生操作控制信号，完成取指令和执行指令的控制。
处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括：内置集成电路(inter-integrated circuit，I2C)接口，串行外围设备接口(serial peripheral interface，SPI)，集成电路内置音频(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)，调频(frequency modulation，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用于为电子设备散热。
外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。
内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行电子设备100的各种功能应用以及数据处理。例如，在本申请实施例中，处理器110可以通过执行存储在内部存储器121中的指令，内部存储器121可以包括存储程序区和存储数据区。
其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据)等。此外，内部存储器121可以包括随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universalflash storage，UFS)等。可选的，随机存取存储器例如可以为双倍速率同步动态随机存储器(doubledata rate，DDR)。闪存器件例如可以为固态硬盘(solid state disk，简称SSD)。
用户可以通过输入设备180向处理器110输入数据，由处理器110对数据处理后进行响应。可选的，输入设备180可以包括但不限于触摸板181、鼠标182和键盘183等。其中，触摸板181和键盘183可以分别与EC连接，触摸板181和键盘183输入的数据可以由EC进行接收和处理。触摸板181和键盘183与EC之间可以通过I2C接口或SPI等通信。
传感器190可以包括温度传感器191、功率传感器192和指纹传感器193等。
温度传感器191用于检测温度。可选的，本申请实施例中，温度传感器191可以包括环境温度传感器、SoC温度传感器、SSD温度传感器、DDR温度传感器、充电器温度传感器和电池温度传感器等。环境温度传感器用于采集环境温度。SoC温度传感器可以部署在SoC上或者SoC周围，用于采集SoC的温度。SDD温度传感器可以部署在SSD上或者SSD周围，用于采集SDD的温度。DDR温度传感器可以部署在DDR上或者DDR周围，用于采集DDR的温度。充电器温度传感器可以部署在充电管理模块140上或者充电管理模块140周围，用于采集充电管理模块140的温度。电池温度传感器可以部署在电池142上或者电池142周围，用于采集电池142的温度。可选的，温度传感器191可以为负的温度系数(negative temperature coefficient，NTC)器件。各个温度传感器191可以与EC通过I2C接口或SPI等通信，将采集的温度传输至EC。
功率传感器192用于检测器件的运行功率，例如检测SoC、SSD、DDR、无线通信模块150、显示屏160、音频功率放大器(power amplifier，PA)等器件的运行功率。可选的，检测多个器件的功率传感器192可以集成为功率测量集成电路(integrated circuit，IC)。功率测量IC可以与EC通过I2C接口或SPI等通信，将采集的功率传输至EC。
指纹传感器193用于采集指纹。电子设备100可以利用采集的指纹特性实现指纹解锁，访问应用锁等。
上述电子设备100的软件操作系统可以运行于处理器，例如可以运行于SoC和EC。可选的，操作系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。本发明实施例以分层架构的Windows系统为例，示例性说明电子设备100的软件结构。
示例性地，图3为本申请实施例的电子设备100的软件和硬件结构框图。分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Windows系统分为用户态和内核态。其中，用户态包括应用层以及子系统 动态链接库。内核态自下而上分为固件层、硬件抽象层(hardware abstraction layer，HAL)、内核和驱动层及执行体。为了便于说明，图3中还示出了电子设备100的硬件层。
如图3所示，应用层包括音乐、视频、游戏、办公、社交等应用程序。应用层还包括预设APP等。其中，图中仅示出部分应用程序，应用层还可以包括其他应用程序，例如购物应用、浏览器等，本申请不做限定。在一个实施例中，预设APP例如可以为散热决策APP、PC管家APP(或称为电脑管家APP等)。预设APP可以包括环境子系统、场景识别引擎以及调度引擎等模块。
环境子系统可以将基本的执行体系统服务的某些子集以特定的形态展示给应用程序，为应用程序提供执行环境。
场景识别引擎可以识别电子设备100所处的用户场景。调度引擎可以获取电子设备100的负载情况、系统运行模式等，并发送至电子设备的其他模块，例如发送至EC。其中，关于环境子系统、场景识别引擎和调度引擎的具体内容见后文，在此暂不描述。
子系统动态链接库包括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)节点、系统与芯片驱动(operating system 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发送指令。可选地，固件层还可以包括热噪音平衡引擎。热噪音平衡引擎用于控制电子设备的散热，以使电子设备趋于热平衡，且减少风扇产生的噪音。
可以理解，上述软件架构中，应用层、子系统动态链接库、执行体、内核和驱动层，以及固件层中的BIOS可以运行于SoC中，热噪音平衡引擎可以运行于EC中。
EC可以通过BIOS接收上层传递的数据，处理后控制硬件层的设备，还可以接收硬件层传递的数据，并进行相应处理后发送至BIOS，由BIOS再向上层传递。另外，EC还可以通过I2C或SPI接口等与内核通信。
本申请实施例中，热噪音平衡引擎可以包括自主识别模块、自主决策模块、被动决策模块、风扇控制模块和状态检测模块。热噪音平衡引擎可以通过热噪音平衡进程实现。可选的，热噪音平衡进程可以在操作系统启动时创建。
其中，自主识别模块用于根据硬件层提供的数据，识别用户场景。为了便于区分，以下实施例中，将自主识别模块根据硬件层提供的数据识别用户场景的过程称为自主场景识别，自主识别模块识别得到的用户场景称为自主用户场景。将预设APP识别用户场景的过程称为上层场景识别，预设APP识别得到的用户场景称为上层用户场景。
自主决策模块用于根据自主用户场景，确定散热控制策略(称为自主散热策略)，自主散热策略中包括风扇控制策略。可以理解，风扇控制策略可以以表格(table)的形式呈现，因而本申请以下实施例中，也将风扇控制策略称为table，其中，基于自主用户场景确定的风扇控制策略称为自主table。
被动决策模块用于基于上层传递的上层用户场景确定风扇控制策略(称为被动table)。风扇控制模块可以根据被动table或自主table确定风扇转速，并相应的调节风扇转速。
为了便于区分，将识别自主用户场景，并根据自主用户场景确定自主散热策略，且根据自主散热策略控制散热的模式称为自主决策散热模式。将根据上层用户场景确定被动table，并根据被动table控制散热的模式称为被动决策散热模式。也就是说，EC的散热模式可以包括自主决策散热模式和被动决策散热模式，EC可以工作于自主决策散热模式，也可以工作于被动决策散热模式。
状态检测模块用于检测预设APP的运行状态，并基于运行状态向预设的状态标记位赋值。
硬件层可以包括GPU、CPU、键盘、触摸板、鼠标、功率传感器(以功率测量IC为例)、温度传感器(以NTC器件为例)、风扇等硬件结构。其中，GPU、CPU和鼠标等可以与SoC通信连接。键盘、触摸板、功率传感器、温度传感器和风扇等可以与EC通信连接。
需要说明的是，本申请实施例仅以Windows系统举例来说明，在其他操作系统中(例如安卓系统，IOS系统等)，只要各个功能模块实现的功能和本申请的实施例类似也能实现本申请的方案。
为了便于理解，本申请以下实施例将以具有图2和图3所示结构的电子设备为例，结合附图和应用场景，对本申请实施例提供的散热控制方法进行具体阐述。
为了方便了解本申请实施例提供的散热控制方法，先结合上述图3简化本申请实施例涉及的软件和硬件结构。如图4所示，简化后电子设备包括应用层的预设APP，内核和驱动层的内核，固件层的热噪音平衡引擎，以及硬件层的键盘、触摸板、功率测量IC、NTC和风扇。其中，热噪音平衡引擎包括自主识别模块、自主决策模块、被动决策模块、风扇控制模块和状态检测模块。
图5是本申请实施例提供的一例散热控制方法的模块交互示意图，请一并参见图4和图5，该方法包括：
S101、热噪音平衡引擎中的状态检测模块根据预设APP的心跳是否满足预设条件，向预设的状态标记位赋值。
预设条件是指预先设置的，用于检测预设APP运行状态的条件。状态标记位的值用于表征预设APP的运行状态。预设APP的运行状态可以包括运行状态正常和运行状态异常。其中，运行状态正常是指预设APP本身运行正常，且预设APP与EC之间能够正常通信。运行状态异常是指预设APP本身运行异常，和/或，预设APP与EC之间无法正常通信。
状态标记位的值可以为true或false。状态标记位的值为true，表示预设APP的运行状态正常；状态标记位的值为false，表示预设APP的运行状态异常。当然，在一些其他的实施例中，状态标记位的值也可以为其他，例如1或0、是或否等，本申请实施例对此不做限定。可选的，状态标记位可以为全局变量。热噪音平衡引擎中的其他模块可以随时获取状态标记位的值。
具体的，若预设APP的心跳满足预设条件，说明预设APP的运行状态正常，则向状态标记位赋值true；若预设APP的心跳不满足预设条件，说明预设APP的运行状态异常，则向状态标记位赋值false。具体过程参见后续实施例。
可以理解，确定心跳是否满足预设条件，并向状态标记位赋值，只是检测预设APP的运行状态的一种示例性的实现方式。可选的，还可以通过其他检测方式检测预设APP的运行状态是否正常，对此不做限定。
应理解，步骤S101可以持续执行，以持续监控预设APP的运行状态。其中，“持续”可以理解为在时间上可以间断的多次。例如，每间隔预设时长执行一次步骤S101，或者，在每次满足预先设置的条件时触发执行一次步骤S101等。本实施例中，执行一次步骤S101的过程也称为一轮心跳检测。
上述步骤S101介绍了预设APP的状态检测过程。下面步骤S102至S108介绍识别上 层用户场景，以及基于上层用户场景确定被动table，并通过被动table控制风扇转速的过程，即EC工作于被动决策散热模式时，散热控制方法的实现过程。步骤S102至S108所述的过程也可以称为被动散热控制过程。
被动散热控制过程中，可以基于步骤S101中向状态标记位所赋的值进行。应理解，被动散热控制过程与预设APP的状态检测过程可以并行执行，二者可以由两个不同的线程分别执行，而不受先后顺序的限定。具体来说，在状态标记位已存在值的情况下，步骤S102至S108可以在某一次执行步骤S101之前执行，也可以在之后执行，还可以与步骤S101同时执行。
请参见图5，被动散热控制过程可以包括：
S102、预设APP识别电子设备所处的用户场景，得到上层用户场景。
可选的，上层用户场景例如可以包括游戏场景、会议场景、办公场景、视频场景、社交场景、浏览器场景等。
可选的，可以通过场景信息区分不同的上层用户场景。上层用户场景的场景信息例如可以为场景号、场景名称等可以标识一个场景的信息。例如，可以通过场景号V01表示上层用户场景为视频场景。又例如，可以通过场景号V02表示上层用户场景为游戏场景。
可选的，预设APP可以按照预设的周期，识别上层用户场景，并将识别到的上层用户场景的场景信息赋值给预设的上层用户场景参数。预设的上层用户场景参数例如可以为参数“当前场景1”(current scene 1)。示例性的，预设周期例如可以为2分钟(min)，在时刻t1，预设APP识别到的上层用户场景为视频场景(场景号为V01)，则预设APP向current scene 1赋值“V01”。在2min之后，即在时刻t1+2min，预设APP再次识别上层用户场景，假设识别结果为游戏场景(场景号为V02)，则预设APP向current scene 1赋值“V02”。
识别上层用户场景的过程详见后续实施例。
S103、预设APP在上层用户场景发生变化的情况下，向内核发送变化后的上层用户场景的场景信息(变化后的上层用户场景的场景信息下称为第一场景信息)。
可选的，预设APP可以在每次向current scene 1赋值之前、之后或赋值的同时，判断current scene 1赋值后的值与赋值前的值是否一致。若赋值前后current scene 1的值一致，则确定上层用户场景未发生变化；若赋值前后，current scene 1的值不一致，则确定上层用户场景发生变化。继续上述例子，在时刻t1+2min，向current scene 1赋值“V02”之前，current scene 1的值为“V01”，向current scene 1赋值“V02”后，current scene 1的值为“V02”，“V01”与“V02”不一致，因而上层用户场景发生变化，预设APP将变化后的上层用户场景的场景信息(即V02)发送至内核。
可选的，预设APP可以通过执行体中的WMI插件将第一场景信息发送至内核。
S104、内核将第一场景信息发送至热噪音平衡引擎中的被动决策模块。
可选的，内核可以先将第一场景信息发送至BIOS，再由BIOS将该信息发送至热噪音平衡引擎中的被动决策模块。
S105、被动决策模块在接收到第一场景信息后，判断状态标记位的值是否为true；若是，则执行步骤S106；若否，则不执行任何操作。
如上述步骤S104，内核向被动决策模块发送第一场景信息。被动决策模块在接收到第 一场景信息后，触发对状态标记位的值的判断，即判断状态标记位的值是否为true。若状态标记位的值为true，说明预设APP的运行状态正常，则根据第一场景信息，确定与变化后的上层用户场景匹配的被动table，并根据被动table控制风扇转速，也即EC进入被动决策散热模式。若状态标记位的值为false，说明预设APP的运行状态异常，则不进入被动决策散热模式。
S106、被动决策模块根据第一场景信息确定被动table。
作为一种可能的实现方式，被动决策模块可以根据预设的对应关系，确定与变化后的上层用户场景匹配的被动table。示例性的，上层用户场景的场景信息与被动table的对应关系可以如表1所示。
表1
例如，若变化后的上层用户场景为游戏场景，第一场景信息为V02，则根据表1，可以确定被动table为table 1-2。
可以理解，表1中的内容仅作为示例，用于说明上层用户场景与被动table的对应关系，不代表实际数据，也不造成对本申请技术方案的任何限定。本申请实施例中其他的表格、附图及文字举例等也是如此，不再赘述。
作为另一种可能的实现方式，被动决策模块也可以根据变化后的上层用户场景，结合其他的信息，例如当前系统负载等，确定匹配的被动table。其中，当前系统负载可以由预设APP或者上层的其他模块检测后发送至被动决策模块。示例性的，被动决策模块可以基于表2所示的对应关系，确定被动table。
表2
例如，若变化后的上层用户场景为游戏场景，第一场景信息为V02，当前系统负载为“中”，则根据表2，可以确定被动table为table 1-5。
可选的，在一些其他的实施例中，被动决策模块在确定被动table时，也可以结合其他信息，例如系统运行模式等进行决策，此处只是示例性说明。
S107、被动决策模块将被动table发送至风扇控制模块。
可选的，被动决策模块可以向预设的对象中写入被动table。该对象为风扇控制模块可以访问并可以从中读取值的对象。
S108、风扇控制模块根据接收到的被动table控制风扇的转速。
示例性的，某一被动table 1-N可以如下表3所示：
表3被动table 1-N
具体的，风扇控制模块在接收到被动table 1-N后，获取当前SoC温度。之后，风扇控制模块可以查询当前SoC温度在被动table 1-N中所属的范围，并确定该温度范围对应的风扇转速(称为目标转速)。然后，调整风扇转速至目标转速。其中，SoC温度可以从部署在SoC上或者SoC周围的NTC(称为SoC_NTC)处获取。例如，当前SoC温度为45℃时，根据表3，该温度落入温度范围[44，46)，因而风扇控制模块控制风扇1的转速为2530转/min，并控制风扇2的转速为2330转/min。
需要说明的是，上述表3仅作为被动table的一种示例，不用于限定。实际应用中，被动table中可以包括比表3更多或更少的内容，例如，被动table中还可以包括SSD的温度范围、环境温度范围等。
下面的步骤S109至S115介绍EC识别自主用户场景，以及基于自主用户场景确定自主table，并通过自主table控制风扇转速的过程，即EC工作于自主决策散热模式时，散热控制方法的实现过程。步骤S109至S115也称为自主散热控制过程。
自主散热控制过程中，可以基于步骤S101中向状态标记位所赋的值进行。但是，自主散热控制过程与预设APP的状态检测过程可以并行执行。同时，自主散热控制过程与被动散热控制过程也可以并行执行。总而言之，预设APP的状态检测过程、自主散热控制过程和被动散热控制过程，这三个过程可以并行，可以由三个不同的线程分别执行，而不受先后顺序的限定。请继续参见图5，自主散热控制过程包括：
S109、硬件层的键盘、触摸板、NTC和功率测量IC采集目标数据，并将采集到的目标数据发送至自主识别模块。
S110、自主识别模块周期性判断状态标记位的值是否为false；若是，则执行步骤S111；若否，则不执行任何操作。
可选的，自主识别模块可以按照预设的周期，判断状态标记位的值是否为false。预设的周期时长例如可以为2min、5min等。
S111、自主识别模块根据目标数据识别电子设备所处的用户场景，得到自主用户场景。
可选的，自主用户场景例如可以包括视频场景、游戏场景、办公场景、空闲(idle)场景、轻载场景、重载场景等。其中，轻载场景是指非视频场景、非游戏场景且非办公场景的负载较轻的场景。轻载场景例如可以为音频播放场景。重载场景是指非视频场景、非游戏场景且非办公场景的负载较重的场景。重载场景例如可以为动画渲染场景。
可选的，可以通过场景信息区分不同的自主用户场景。自主用户场景的场景信息例如可以为场景号、场景名称等可以标识一个场景的信息。自主用户场景的场景信息与上层用户场景的场景信息的表示规则可以不同，以便于对两种场景进行区分。例如，可以通过场景号S01表示自主用户场景为游戏场景。又例如，可以通过场景号S02表示自主用户场景为办公场景。
可选的，每一次确定状态标记位的值为false，触发自主识别模块基于目标数据识别一次自主用户场景。自主识别模块可以将识别得到的自主用户场景的场景信息赋值给预设的自主用户场景参数。预设的自主用户场景参数例如可以为参数“当前场景2”(current scene2)。例如，时刻t3，自主识别模块确定状态标记位的值为false，触发一次自主用户场景识别，假设识别到的自主用户场景为游戏场景(场景号为S01)，则自主识别模块向current scene 2赋值“S01”。在3min之后，即在时刻t3+3min，自主识别模块再次确定状态标记位的值为false，再次触发自主识别模块识别自主用户场景，假设识别结果为办公场景(场景号为S02)，则自主识别模块向current scene 2赋值“S02”。
自主识别模块识别自主用户场景的过程详见后续实施例。
S112、自主识别模块在自主用户场景发生变化的情况下，向自主决策模块发送变化后的自主用户场景的场景信息(变化后的自主用户场景的场景信息下称为第二场景信息)。
可选的，自主识别模块可以在每次向current scene 2赋值之前、之后或赋值的同时，判断current scene 2赋值后的值与赋值前的值是否一致。若赋值前后current scene 2的值一致，则确定自主用户场景未发生变化；若赋值前后，current scene 2的值不一致，则确定自主用户场景发生变化。继续上述例子，在时刻t3+3min，向current scene 2赋值“S02”之前，current scene 2的值为“S01”，向current scene 2赋值“S02”后，current scene 2的值为“S02”，“S01”与“S02”不一致，因而自主用户场景发生变化，自主识别模块将变化后的自主用户场景的场景信息(即S02)发送至自主决策模块。
S113、自主决策模块根据第二场景信息，确定自主散热策略。
自主散热策略中包括自主table。
如上述步骤S112，自主识别模块向自主决策模块发送第二场景信息。自主决策模块在接收到第二场景信息后，根据第二场景信息，确定与变化后的自主用户场景匹配的自主散热策略，自主散热策略中包括自主table。
作为一种可能的实现方式，自主决策模块可以根据预设的对应关系，确定与变化后的自主用户场景匹配的自主table。示例性的，自主用户场景的场景信息与自主table的对应 关系例如可以如表4。
表4
例如，若变化后的自主用户场景为视频场景，第二场景信息为S02，则根据表4，可以确定自主table为table 2-3。
作为另一种可能的实现方式，自主决策模块也可以根据变化后的自主用户场景，结合其他的信息匹配对应的自主table。例如可以结合电子设备的系统运行模式匹配对应的自主table。系统运行模式可以为电子设备的操作系统预先设置的多种运行模式。不同的系统运行模式下，电子设备的功率大小(对应于续航时间的长短)、散热力度、噪声大小等不同。系统运行模式例如可以包括静谧模式、性能模式和狂战模式等。静谧模式下，电子设备的运行噪音相对较小，例如风扇噪音较小。一般的，用户在夜间办公、图书馆或教室办公或学习等场景下可能会选择静谧模式。性能模式下，电子设备的续航、散热和噪声等几方面接近平衡。一般的，用户在办公场景下可能会选择性能模式。狂战模式下，电子设备性能趋于最优，风扇转速相对较快。一般的，用户在游戏、动画渲染等场景下可能会选择狂战模式。电子设备默认的系统运行模式可以为性能模式。
可选的，用户可以通过快捷键切换系统运行模式。例如，用户可以通过Fn+J快捷键将系统运行模式切换为静谧模式，通过Fn+Q快捷键将系统运行模式切换为狂战模式，通过Fn+X快捷键将系统运行模式切换为性能模式。
示例性的，自主决策模块可以基于表5所示的对应关系，确定自主table。
表5
例如，若变化后的自主用户场景为视频场景，第二场景信息为S02，当前系统运行模式为性能模式，则根据表5，可以确定自主table为table 2-11。
可以理解，预设APP在向EC中的热噪音平衡引擎下发上层用户场景的同时，也可以下发系统运行模式。可选的，系统运行模式可以下发给热噪音平衡引擎中的自主决策模块。自主决策模块在决策自主table时，可以先获取当前时刻之前，预设APP最后一次下发的系统运行模式，根据该系统运行模式，基于表5匹配自主table。然而，在电子设备没有运行过预设APP，或者系统数据被清除等情况下，自主决策模块可能无法获取到系统运行模式。对于这种情况，自主决策模块可以根据默认的系统运行模式(例如性能模式)，基于表5匹配自主table。简而言之，在自主决策散热模式下，自主决策模块获取历史时间段内预设APP下发的历史系统运行模式，并将历史系统运行模式中，下发时刻距离当前时刻最近的一个作为目标系统运行模式，基于目标系统运行模式匹配自主table。若不存在历史系统运行模式，则将默认的(即预设的)系统运行模式确定为目标系统运行模式。
在自主决策散热模式下，自主决策模块可以持续获取键盘的数据，根据键盘的数据监控用户是否切换系统运行模式。若监控到用户切换系统运行模式，则基于用户切换后的运行模式，重新匹配自主table。例如，若监控到键盘输入的键值包括Fn+Q，则确定系统运行模式被切换为狂战模式，根据狂战模式和当前的自主用户场景，基于表5，重新匹配自主table。
自主决策模块根据第二场景信息确定其他散热策略，例如频率控制策略、亮度控制策略等的方式，可以为基于预设对应关系查找，也可以为其他，本申请实施例对此不做任何限定。
S114、自主决策模块将自主table发送至风扇控制模块。
可选的，自主决策模块可以向预设的对象写入自主table。该对象为风扇控制模块可以访问并可以从中读取值的对象。可以理解，用于写入自主table的对象，与用于写入被动table的对象可以为同一对象，也可以为不同对象。
另外，自主决策模块也可以将确定的其他散热策略发送至对应的模块，由这些模块执行对应的散热策略。例如，自主决策模块可以将确定的频率控制策略发送至执行体中的OS2SoC驱动节点，由OS2SoC驱动节点根据频率控制策略调整CPU和/或GPU的频率。再例如，自主决策模块可以将确定的亮度控制策略发送至显示屏，由显示屏根据亮度控制策略控制调整亮度。
S115、风扇控制模块根据接收到的自主table控制风扇的转速。
可选的，风扇控制模块可以从预设对象中读取自主table，并根据自主table中的方案控制风扇转速。
示例性的，某一自主table1-N可以如下表6所示，其中，NA为not applicable的缩写，意为不适用，用于表征对应的参数无值或不限定，后续实施例中NA的含义也是类似，不再赘述。
表6自主table 2-N

虚拟壳体的温度是指根据电子设备中多个器件的当前温度，计算推测电子设备的壳体的当前温度，例如根据SoC的当前温度、电池的当前温度、充电器的当前温度等计算推测电子设备的壳体问题。
需要说明的是，上述表6仅作为被动table的一种示例，不用于限定。实际应用中，被动table中可以包括比表6更多或更少的内容，例如，被动table中还可以包括电池的温度范围、环境温度范围或者充电器的温度范围等中的一种或多种。
由表6可以看出，自主table中可以设置多个控制等级(简称等级)，不同的等级，对应的器件温度不同，风扇转速不同。等级越高，器件温度越高，风扇转速越高。风扇控制模块监控各器件温度，并根据当前的自主table，确定与各器件温度匹配的等级，按照等级对应的风扇转速和最小持续时长控制风扇。
其中，最小持续时长包括最小持续时长1和最小持续时长2。某一table 2-N中，任一等级n对应的最小持续时长1用于指示，在风扇控制策略由其他table切换至table 2-N的等级n的情况下，以等级n对应的转速控制风扇运转所持续的最小时长。或者，table 2-N中等级n对应的最小持续时长1用于指示，在风扇控制策略由table 2-N中的低等级(指小于n的等级)上升至等级n的情况下，以等级n对应的转速控制风扇运转所持续的最小时长。
例如，时刻T1，风扇控制策略从table 2-X中的某一等级切换到table 2-N中的等级1，则风扇控制模块按照table 2-N中的等级1对应的风扇转速(风扇1转速为2600转/min，风扇2转速为2500转/min)控制风扇运转。而且，这种情况属于风扇控制策略由其他table切换至table 2-N中的等级1的情况，因而，需要根据table 2-N中的等级1对应的最小持续时长1(5min)，控制风扇以table 2-N的等级1对应的风扇转速运转最少5min，才可以调整为其他等级。即控制风扇1以2600转/min的转速，风扇2以2500转/min的转速运转至少5min，才可以调整至其他转速。
继续该例子，时刻T2，风扇控制模块未接收到新的table，即table未切换，且根据表6所示的table 2-N，基于当前SoC温度和虚拟壳体温度匹配到的等级为table 2-N中的等级2，也即，等级需要从table 2-N中的等级1升高至table 2-N中的等级2，则风扇控制模块在确定table 2-N的等级1持续时长超过5min的情况下，按照table 2-N中的等级2对应的风扇转速(风扇1转速为2900转/min，风扇2转速为2800转/min)，控制风扇运转。而且，这种情况下，等级从table 2-N中的等级1升高至等级2，因而，需要根据table 2-N的等级2对应的最小持续时长1(6min)，控制风扇以table 2-N的等级2对应的风扇转速运转最少6min，才可以调整为其他等级。即控制风扇1以2900转/min的转速，风扇2以2800转/min的转速运转至少6min，才可以调整至其他转速。
某一table 2-N中，任一等级n对应的最小持续时长2用于指示，在风扇控制策略由table 2-N中的高等级(指大于n的等级)下降至等级n的情况下，以等级n对应的转速控制风扇运转所持续的最小时长。
继续上述例子，T2时刻之后的时刻T3，风扇控制模块未接收到新的table，即table 未切换，且根据表6所示的table 2-N，基于当前SoC温度和虚拟壳体温度匹配到的等级为table 2-N的等级1，也即，等级需要从table 2-N中的等级2降低至table 2-N中的等级1，则风扇控制模块在确定table 2-N的等级2持续时长超过6min的情况下，按照table 2-N的等级1对应的风扇转速(风扇1转速为2600转/min，风扇2转速为2500转/min)控制风扇运转。而且，这种情况下等级从table 2-N中的等级2降低至等级1，因而，需要根据table 2-N的等级1对应的最小持续时长2(4min)，控制风扇以table 2-N的等级1对应的风扇转速运转最少4min，才可以调整为其他等级。即风扇1以2600转/min的转速，风扇2以2500转/min的转速运转至少4min，才可以调整至其他转速。
需要说明的是，上述步骤的执行顺序不做任何限定。例如，预设APP的状态检测过程(步骤S101)、被动散热控制过程(S102至S108)，以及自主散热控制过程(S109至S115)三者，可以存在运行的先后顺序，也可以同时执行。
本实施例中，在控制风扇转速时，一方面结合器件的温度进行调整，高温下风扇以较高转速工作，低温下风扇以较低转速工作，这样能够更好、更快地散热，使设备趋于热平衡，提高温度控制的效率和精确度。另一方面，控制风扇转速时限制等级控制的最小持续时间，这样防止风扇转速调整过于频繁，防止造成不必要的功率损耗，也防止给用户造成过多打扰，提高风扇控制的稳定性和可靠性。
以上实施例中，以预设APP向热噪音平衡引擎提供识别得到的上层用户场景，由热噪音平衡引擎根据上层用户场景决策，生成被动table。作为另一种实现方式，也可以由预设APP在识别得到上层用户场景后，进一步根据上层用户场景决策生成被动table，并将被动table通过内核发送给热噪音平衡引擎。这种情况下，热噪音平衡引擎中的风扇控制模块可以在确定状态标记位的值为true的情况下，根据上层发送的被动table控制风扇转速。
本实施例提供的散热控制方法，EC既能够工作于被动决策散热模式，基于预设APP输出的上层用户场景进行被动散热控制，也能够工作于自主决策散热模式，基于EC识别得到的自主用户场景进行自主散热控制。而且，EC能够检测预设APP的运行状态，在不同的运行状态下，工作于不同的模式。具体的，在预设APP的运行状态正常时，EC工作于被动决策散热模式，进行被动散热控制。被动决策散热模式下，预设APP能够向EC提供全面、准确的用户场景信息，因而能够基于场景信息准确地控制散热，提高散热控制的全面性和准确性，提高散热效果。在预设APP的运行状态异常时，EC工作于自主决策散热模式，进行自主散热控制。自主决策散热模式下，EC能够自主地识别用户场景，基于自主识别的用户场景也能够进行细粒度的散热控制，提高散热控制效果。也就是说，无论预设APP能否正常工作，该方法均可以基于用户场景进行细粒度的散热控制，而无需依赖预设APP的运行状态，提高了散热控制的效果和可靠性，进而提高用户体验。
作为一种可能的实现方式，上述步骤S101至S108也可以不执行，仅执行S109至S115。也就是说，也可以不对预设APP进行状态检测，也不进行被动散热控制，仅进行自主散热控制。这样，EC能够完全自主地基于用户场景进行细粒度的散热控制，无需依赖预设APP，也不受预设APP的影响，提高散热控制的效果和可靠性，进而提高用户体验。而且，EC位于固件层，运行于操作系统的底层，不受操作系统上层的影响，因而，由EC进行自主用户场景识别和自主散热控制，不易受到操作系统变化(例如，重装、更新等)的影响，提高散热控制的可靠性和稳定性。
下面对自主散热控制过程进行进一步说明。
首先，对预设APP运行状态的检测过程进行说明。
示例性的，图6为本申请实施例提供的另一例散热控制方法的模块交互示意图，请参见图6，在一个实施例中，上述步骤“S101、热噪音平衡引擎中的状态检测模块根据预设APP的心跳是否满足预设条件，向预设的状态标记位赋值”的实现过程，包括：
S1011、热噪音平衡引擎中的状态检测模块向内核发送M个心跳请求。
M为大于或等于1的整数。例如，M可以为10。
可选的，状态检测模块可以按照预设的时间间隔(例如2s)，依次向内核发送M个心跳请求。为了便于区分，可以对M个心跳请求进行标记，例如，可以按照发送顺序，向M个心跳请求中的第1个心跳请求标记tag 1；向M个心跳请求中的第2个心跳请求标记tag 2；……；向M个心跳请求中的第M个心跳请求标记tag M。应理解，此标记方式仅作为一种示例，实际应用中也可以根据需求选择其他的标记方式，例如，用英文字母标记、用数字标记，或者用字母与英文的组合标记等等。
可选的，可以在发送每个心跳请求之前、之后或发送该心跳请求的同时，启动与心跳请求对应的定时器。定时器的定时时长可以根据需求设置，例如可以为30秒(s)。定时器用于定时，以检测心跳请求是否在定时时长内得到响应。可选的，各个心跳请求对应的定时器的定时时长可以相等，也可以不相等。且定时器的定时时长与发送心跳请求的时间间隔可以相等也可以不等。一个可能的实施例中，发送心跳请求的时间间隔小于各个定时器的定时时长。
可选的，可以根据对应的心跳请求的标记，对定时器进行标记。可选的，定时器与对应的心跳请求的标记可以相同，也可以不同。定时器与对应的心跳请求的标记不同时，可以建立定时器的标记与心跳请求标记的对应关系。
S1012、内核将M个心跳请求转发至预设APP。
S1013、在运行正常的情况下，预设APP接收到每个心跳请求后，向内核回复对应的心跳响应消息。
预设APP在回复心跳响应消息时，也可以根据对应的心跳请求的标记，对心跳响应消息进行标记。可选的，心跳响应消息与对应的心跳请求的标记可以相同。例如，标记为tag1的心跳请求对应的心跳响应消息的标记也为tag1。换句话说，若心跳响应消息的标记为tag1，则说明该心跳响应消息是标记为tag1的心跳请求的响应消息。
可以理解，在预设APP运行异常的情况下，预设APP无法向内核回复心跳响应消息，或者无法在定时器的定时时长内回复心跳响应消息。
本实施例中，预设APP运行正常是指预设APP本身运行正常。预设APP运行异常是指预设APP本身运行异常。预设APP本身运行异常可以包括但不限于预设APP未运行，或者，预设APP的进程卡死、被冻结、被挂起等。
S1014、内核将心跳响应消息转发至热噪音平衡引擎中的状态检测模块。
S1015、状态检测模块确定M个心跳请求中是否存在回复异常的心跳请求；若存在回复异常的心跳请求，则执行步骤S1016；若不存在回复异常的心跳请求，则执行步骤S1017。
S1016、状态检测模块向状态标记位赋值false，并返回执行步骤S1011。
S1017、状态检测模块向状态标记位赋值true，并返回执行步骤S1011。
如上述步骤S1011，发送心跳请求时，状态检测模块可以启动与心跳请求对应的定时器。应理解，M个心跳请求与M个定时器一一对应，M个心跳请求与M个心跳响应消息一一对应，因而，M个定时器与M个心跳响应消息也一一对应。
上述步骤S101中的“预设条件”，在本实施例中可以理解为“M个心跳请求中不存在回复异常的心跳请求”。也就是说，若M个心跳请求中不存在回复异常的心跳请求，则满足预设条件，向状态标记位赋值ture。若M个心跳请求中存在回复异常的心跳请求，则不满足预设条件，向状态标记位赋值false。
可选的，对于某一心跳请求而言，回复异常包括未被回复和回复超时两种。其中，未被回复是指，未接收到该心跳请求对应的心跳响应消息。回复超时是指接收到该心跳请求对应的心跳响应消息，但是该心跳响应消息是在对应的定时器超时后接收到的。也就是说，未被回复或者回复超时的心跳请求称为回复异常的心跳请求。对应的，被回复且回复超时的心跳请求可以称为回复正常的心跳请求。
作为一种可能的实现方式，状态检测模块可以在每个心跳请求对应的定时器达到定时时长时，检测该心跳请求是否为回复异常的心跳请求。若在某一心跳请求对应的定时器达到定时时长时，未接收到该心跳请求对应的心跳响应消息，说明该心跳请求为回复异常的心跳请求，说明预设APP的运行状态异常，则向状态标记位赋值false，并返回执行步骤S1011，重新发送M个心跳请求，也即本轮心跳检测结束，进入下一轮心跳检测。若在某一心跳请求对应的定时器达到定时时长时，确定已接收到该心跳请求对应的心跳响应消息，说明该心跳请求为回复正常的心跳请求，则在下一个定时器达到定时时长时，检测对应的心跳响应消息是否为回复异常的心跳请求。如此循环，直至M个定时器被遍历，则确定M个心跳请求中不存在回复异常的心跳请求，说明预设APP的运行状态正常，向状态标记为赋值true，并返回执行步骤S1011，重新发送M个心跳请求，也即本轮心跳检测结束，进入下一轮心跳检测。
可选的，在步骤S1016和步骤S1017中，“返回执行步骤S1011”进入下一轮心跳检测之前，可以先将本轮心跳请求的标记、接收到的心跳响应消息等信息清除，再返回执行步骤S1011，使下一轮心跳检测更加准确。
示例性的，参见图7，以任意一个心跳请求i(1≤i≤M)为例，上述过程可以表示如图7。其中，心跳请求i对应的定时器表示为定时器i，心跳请求i对应的心跳响应消息表示为心跳响应消息i，心跳请求i被发送后，启动对应的定时器i，开始计时。如图7所示，S1015包括：
S1051A、状态检测模块在定时器i达到其定时时长时，判断是否存在心跳响应消息i；若不存在心跳响应消息i，则执行步骤S1016；若存在心跳响应消息i，则执行步骤S1052A。
S1052A、状态检测模块判断i是否等于M，若是，则执行步骤S1017；若否，则令i＝i+1，返回执行步骤S1051A。
可选的，在确定存在心跳响应消息i的情况下，可以向该心跳响应消息i标记未超时标记，表示该心跳响应消息i未超时。或者，可以向心跳请求i标记回复正常标记，表示该心跳请求i为回复正常的心跳请求。这样便于后续统计判断，提高算法运行效率。
作为另一种可能的实现方式，状态检测模块也可以在每次接收到心跳响应消息后，判 断该心跳响应消息对应的定时器是否超过定时时长(即判断心跳响应消息是否超时)。该实现方式中，可以预设一最长检测时长，该最长检测时长可以作为一轮心跳检测时长的上限。可选的，最长检测时长≥定时时长M+发送时长Q。其中，定时时长M表示M个心跳请求中最后一个发送的心跳请求对应的定时器的定时时长。发送时长Q表示从发送M个心跳请求中的第一个心跳请求至发送最后一个心跳请求的总时长，也即M个心跳请求全部被发送出去所需的总时长。
参见图8，以心跳响应消息i为例，执行下述过程：
S1051B、状态检测模块周期性判断当前时刻与发送第1个心跳请求的时刻的时间差是否大于最长检测时长；若是，则执行步骤S1016；若否，则执行步骤S1052B。
发送第一个心跳请求的时刻可以理解为本轮心跳检测的起始时刻，当前时刻与发送第一个心跳请求的时刻的时间差可以理解为本轮心跳检测的执行时长。
可选的，状态检测模块可以每间隔一段时间(小于检测时长)，执行一次S1051B，以确定本轮心跳检测的执行时长是否大于最长检测时长。在本轮心跳检测流程未能通过下述步骤S1052B和S1053B退出的情况下，如果本轮心跳检测的执行时长大于最长检测时长，则确定M个心跳请求中存在回复异常的心跳请求，预设APP状态异常，执行步骤S1016，向状态标记位赋值false，并返回执行步骤S1011，重新发送M个心跳请求，也即本轮心跳检测结束，进入下一轮心跳检测。若本轮心跳检测的执行时长小于或等于最长检测时长，说明未达到一轮心跳检测时长上限，执行步骤S1052B，对其他心跳响应消息进行检测。
S1052B、状态检测模块在接收到心跳响应消息i后，根据心跳响应消息i对应的定时器i，判断该心跳响应消息i是否超时；若心跳响应消息i超时，则确定预设APP的运行状态异常，执行步骤S1016；若心跳响应消息i未超时，则执行步骤S1053B。
S1053B、状态检测模块判断是否M个心跳响应消息均遍历；若是，则执行步骤S1017；若否，则将下一个接收到的心跳响应消息作为心跳响应消息i，返回执行步骤S1052B。
类似的，该实现方式中，在确定心跳响应消息i未超时的情况下，可以对该心跳响应消息i进行未超时标记，表征该心跳响应消息i未超时。或者，可以向心跳请求i标记回复正常标记，表示该心跳请求i为回复正常的心跳请求。这样便于后续统计判断，提高算法运行效率。
本实施例中，通过对预设APP执行心跳请求操作，不仅能够简单、快速地确定预设APP本身的运行状态是否异常，而且检测结果能够覆盖预设APP与EC通信异常的情况，而实际应用中，预设APP与EC通信异常也会导致无法向EC提供上层用户场景，因而该方法在这种情况下由EC进行自主散热控制，能够提高散热控制的准确性。另外，本实施例的检测方法，每轮心跳检测中，发送M个心跳请求，根据这M个心跳请求的回复情况判断预设APP的运行状态，这样能够防止将运行状态异常时偶尔有心跳正常回复的情况误判断为运行状态正常，提高运行状态检测的准确性，进而提高散热控制的准确性。
接下来，对EC识别自主用户场景的具体过程进行说明。
如上述实施例所述，自主用户场景可以包括游戏场景、办公场景、视频场景、idle场景、轻载场景和重载场景等。
示例性的，图9为本申请实施例提供的一例自主用户场景识别的原理示意图，图10 是本申请实施例提供的一例散热控制方法的流程示意图，请一并参见图9和图10，在一个实施例中，上述步骤“S111、自主识别模块根据目标数据识别电子设备所处的用户场景，得到自主用户场景”的实现过程，包括：
S1111、自主识别模块根据从键盘、触摸板和鼠标中的至少一者获取的输入数据进行场景识别，得到场景识别结果1。
步骤S1111也称为基于用户输入行为特征的场景识别。比较而言，基于用户输入行为特征的场景识别属于精准识别。
可以理解，用户通过输入设备(例如键盘、鼠标、触摸板)输入的数据，能够体现用户的输入行为。根据用户的输入行为，能够推测电子设备当前所处的用户场景。下面以游戏场景和办公场景的识别为例进行说明。
(1)游戏场景的识别
首先，结合表7，对用户在一些游戏场景下的输入行为的特征进行分析。
表7
从表7可以看出，在游戏场景下，用户使用的键所在的区域相对比较集中，且多种类型的游戏使用的键相同或相近。游戏场景下，对于鼠标的使用方式类似。而且，用户在游戏场景下，可能会关闭触摸板。基于此，本实施例可以通过键盘提供的键值、鼠标提供的数据(称为鼠标数据)和触摸板的状态等中的至少一种，识别游戏场景。其中，键值是指 用户通过键盘的键输入的内容(即值)，例如用户按下键“A”，则输入的键值为“A”，用户按下键“空格”，则输入的键值为“空格”。鼠标数据是指用户通过按下鼠标的键或通过滑动鼠标的滚轮输入的数据，例如用户连续点击鼠标左键两次，则输入的数据为“鼠标左键双击”。触摸板的状态可以包括开启状态和关闭状态。
在一个具体的实施例中，可以基于表7所示的特征分析，预先确定游戏键值列表，游戏键值列表中包括被多类游戏使用到的键值，这些键值能够反映用户在游戏场景下操作的键所在的区域。例如，游戏键值列表中可以包括W、A、S、D、Q、E、Z、X、C等键值，这些键值为键盘中左半边区域中的部分键对应的键值，用户一般通过左手操作这些键。当然，游戏键值列表中也可以包括鼠标数据，例如，鼠标左键双击、鼠标右键单击等。以下主要以键值为例进行说明，鼠标数据的匹配过程与键值类似，不做赘述。
热噪音平衡进程创建后，自主识别模块可以实时从键盘获取用户输入的键值。自主识别模块对键值进行统计，确定预设时长的时间段内输入的键值中，目标键值的输入总次数占该时间段内按键总次数的比例(称为目标比例)。其中，目标键值是指属于游戏键值列表的键值。预设时长可以根据需求设置，例如可以为30s。举例来说，30s内用户共输入13次键值，这13次的键值中，W共输入5次，S共输入3次，D共输入1次，Y共输入3次，O共输入1次。由于键值W、S和D属于上述游戏键值列表，因而为目标键值。目标键值的输入总次数＝5+3+1＝9次。那么，这30s内，目标键值输入总次数与占按键总次数的比例(即目标比例)为：9/13≈0.6923。
确定目标比例后，自主识别模块可以判断目标比值是否超过预设比例阈值，若是，则确定场景识别结果1为游戏场景。
作为一种可能的实现方式，可以按照上述过程进行M次计算，确定M个时间段内的目标比例均大于预设比例阈值后，确定场景识别结果1为游戏场景。其中M为大于或等于2的整数。多次计算能够排除特殊场景造成的误识别，提高场景识别的准确性。
作为另一种可能的实现方式，游戏场景的判断条件除了目标比例外，还可以加入按键总次数的判断条件，例如，30s内的按键总次数需大于预设次数阈值。也就是说，30s内按键总次数大于预设次数阈值，且目标比例大于预设比例阈值，则确定场景识别结果1为游戏场景。该实现方式中，在目标比例的基础上，增加了按键总次数的判断条件，这样能够将键值多数为目标键值但是按键总次数少的非游戏场景排除，减少误识别，提高了游戏场景的识别准确性。另外，与上一实现方式类似，该实现方式中，也可以结合多次计算和判断的结果，识别游戏场景，提高场景识别的准确性。
在又一些实施例中，在游戏场景的判断条件中也可以加入触摸板状态，例如，若触摸板状态为关闭状态，且满足上述目标比例条件和按键总次数的条件，则确定场景识别结果1为游戏场景。
游戏场景下，用户通过键盘、触摸板和鼠标等输入设备输入的数据具有较显著的特征。本实施例中，基于对游戏场景下用户输入数据的特征分析结果，确定游戏键值列表，基于该列表以及用户的输入次数等，能够简单、准确地识别用户是否处于游戏场景，提高场景识别效率。
(2)办公场景的识别
结合表8，对用户在一些办公场景下的输入行为的特征进行分析。
表8

从表8可以看出，在办公场景下，用户会频繁操作一些办公软件(PPT、Word、浏览器等)相关的键，且键的分布具有随机性。基于此，本实施例可以通过键盘提供的键值，识别办公场景。
在一个具体的实施例中，可以基于例如表8所示的办公场景下的输入分析，预先确定出用户在办公场景下可能会频繁操作的三类办公键值，分别为：删除换行类键值、快捷类键值和方向类键值。为了便于统计，可以将三类办公键值记入办公键值列表1、办公键值列表2和办公键值列表3中。其中，办公键值列表1为删除换行类键值列表，办公键值列表1中包括但不限于Delete(也记为Dle)、Backspace、Enter等键值。办公键值列表2为快捷类键值列表，办公键值列表2中包括但不限于Ctrl+A、Ctrl+C、Ctrl+V、Ctrl+X、Ctrl+S、Ctrl+Y、Ctrl+Z、Ctrl+B、Ctrl+I、Ctrl+L、Ctrl+E、Ctrl+R、Alt+Tab、Ctrl+Tab、Ctrl+T、Ctrl+W、Ctrl+R、Ctrl+F等键值。办公键值列表3为方向类键值列表，办公键值列表3中包括但不限于方向键上、下、左、右等键值。
热噪音平衡进程创建后，自主识别模块可以实时从键盘获取用户输入的键值，并按照下述过程识别办公场景：
A、分别统计预设时长的时间段内输入的键值中，三类办公键值的输入次数。
也即，确定预设时长(例如60s)的时间段内输入的键值中，属于办公键值列表1的键值的输入次数，属于办公键值列表2的键值的输入次数，以及属于办公键值列表3的键值的输入次数。例如，根据统计，最近60s内输入的键值中，属于办公键值类列表1中的键值的输入的次数为n1，即删除换行类键值的输入次数为n1；最近60s内输入的键值中，属于办公键值类表列表2中的键值的输入的次数为n2，即快捷类键值的输入次数为n2；最近60s内输入的键值中，属于办公键值类表列表3中的键值的输入的次数为n3，即方向 类键值的输入次数为n3。
B、根据输入次数为三类办公键值对应的预测因子赋值。
具体的，每类办公键值可以对应有一个预测因子，预测因子的值根据办公键值的输入次数确定。删除换行类键值对应的预测因子记为a，快捷类键值对应的预测因子记为b，方向类键值对应的预测因子记为c。
可选的，自主识别模块可以分别确定三类办公键值的输入次数是否超过各自对应的次数阈值，若是，则为对应的预测因子赋值1，若否，则为对应的预测因子赋值0。删除换行类键值对应的次数阈值记为th1，快捷类键值对应的次数阈值记为th2，方向类键值对应的次数阈值记为th3。那么，判断n1是否大于th1，若是，则为预测因子a赋值1；若否，则为预测因子a赋值0。同理，判断n2是否大于th2，若是，则为预测因子b赋值1；若否，则为预测因子b赋值0。判断n3是否大于th3，若是，则为预测因子c赋值1；若否，则为预测因子c赋值0。
C、根据三类办公键值对应的预测因子和对应的预设权重，计算预测值。
可选的，可以按照下述公式计算预测值：
其中，f表示预测值，ω1表示删除换行类键值对应的权重，ω2表示快捷类键值对应的权重，ω2表示方向类键值对应的权重。可选的，ω1、ω2和ω3可以根据需求预先设置。
D、根据预测值确定场景识别结果1是否为办公场景。
可选的，可以确定预测值是否大于预设阈值，若是，则确定场景识别结果1为办公场景；若否，则确定场景识别结果1不为办公场景。预设阈值可以根据实际情况设置，例如可以为0.8。
作为一种可能的实现方式，可以按照上述过程进行X次计算，确定X个时间段内的预测值均大于预设阈值后，确定场景识别结果1为办公场景。其中X为大于或等于2的整数。多次计算能够排除特殊场景造成的误识别，提高场景识别的准确性。
作为另一种可能的实现方式，还可以对一段时间内的键值进行统计分析，确定该段时间内各个键值出现的次数，从而确定该段时间内的键值分布的随机性程度。若键值分布随机性程度较高，且根据上述步骤A至D确定的预测值大于预设阈值，则确定场景识别结果1为办公场景。这样，进一步提高办公场景识别的准确性。关于随机性程度的确定方法，本申请实施例不做任何限定。
办公场景下，用户输入的键值具有较显著的特征，本实施例中，基于对办公场景下用户输入键值的特征分析结果，确定三类办公键值，基于这三类办公键值的输入次数，能够简单、准确地识别用户是否处于办公场景，提高场景识别效率。
可以理解，若自主识别按照上述过程，确定场景识别结果1不为游戏场景，也不为办公场景，则可以将NA作为场景识别结果1。场景识别结果1为NA表示基于用户输入行为特征的场景识别结果不属于预设场景，例如不属于游戏场景也不属于办公场景。
S1112、自主识别模块根据从功率测量IC获取的器件功率数据进行模糊场景识别，得到场景识别结果2。
步骤S1112也称为基于功率的模糊场景识别。
基于功率的模糊场景识别，可以用于识别视频场景等。可选的，视频场景可以进一步 细分为本地视频场景和在线视频场景。
可以理解，不同场景下，电子设备中器件的功率大小可能不同。视频场景下，电子设备中一些器件的功率具有较显著的特征。另外，在线视频场景和本地视频场景下，无线通信模块的功率不同。本实施例中，结合SoC功率、SSD功率、DDR功率、屏幕功率、音频PA功率、无线通信模块(例如WLAN)功率，进行模糊场景识别，确定当前用户场景是否为本地视频场景或在线视频场景。
作为一种示例，可以基于器件功率数据，按照表9所示的对应关系进行模糊场景识别。其中，功率的单位可以为毫瓦(mW)。
表9
具体的，若SoC功率、SSD功率、DDR功率、屏幕功率、音频PA功率和WLAN功率与表9中某一用户场景对应的各个温度范围一一对应匹配，则自主识别模块确定场景识别结果1为该用户场景。例如，SoC功率、SSD功率、DDR功率、屏幕功率、音频PA功率和WLAN功率依次为1854mW、56mW、220mW、2777mW、902mW和0mW，与本地视频场景下的SoC功率范围、SSD功率范围、DDR功率范围、屏幕功率范围、音频PA功率范围和WLAN功率范围一一对应匹配，则可以确定场景识别结果1为本地视频场景。
可以理解，若自主识别模块按照上述过程，确定场景识别结果1不为表9中的任一种用户场景，则可以将NA作为场景识别结果2。场景识别结果2为NA表示基于功率的模糊场景识别结果不属于预设场景，例如不属于本地视频场景也不属于在线视频场景。
S1113、自主识别模块根据从NTC获取的温度数据，进行模糊场景识别，得到场景识别结果3。
步骤S1113也称为基于温度的模糊场景识别。
基于温度的模糊场景识别，可以用于识别idle场景、轻载场景和重载场景等。
可以理解，不同用户场景下，器件的发热程度不同。另外，不同的环境温度下，器件的发热程度也不同。本实施例中，可以基于环境的温度、SoC的温度、SSD的温度和DDR的温度，进行模糊场景识别，确定当前用户场景是否为识别idle场景、轻载场景、重载场景等中的一种。
作为一种示例，可以基于环境或器件的温度数据，按照表10所示的对应关系进行模糊场景识别。其中，温度的单位可以为摄氏度(℃)。
表10

作为一种可能的实现方式，基于温度的模糊场景识别的规则可以为：(环境温度&&SoC温度&&SSD温度&&DDR温度)。也就是说，环境温度、SoC温度、SSD温度和DDR温度分别与表10中某一横行中各个温度范围一一对应匹配时，确定场景识别结果3为该横行所对应的用户场景。例如，若当前环境温度为20℃、SoC温度为48℃，SSD温度为42℃，DDR温度为44℃，这些温度与表10中轻载场景下的环境温度范围、SoC温度范围、SSD温度范围和DDR温度范围一一对应匹配，则自主识别模块确定场景识别结果3为轻载场景。其他场景的匹配过程与此类似，不再赘述。
在另一种可能的实现方式中，基于温度的模糊场景识别的规则也可以为：(环境温度&&SoC温度&&SSD温度)||(环境温度&&SoC温度&&DDR温度)。也就是说，在环境温度、SoC温度分别与表10中某一横行的环境温度范围、SoC温度范围对应匹配的情况下，SSD温度、DDR温度中的至少一者与该横行的SSD温度范围、DDR温度范围对应匹配，即可确定场景识别结果3为该横行所对应的用户场景。例如，若当前环境温度为20℃、SoC温度为48℃，这两个温度与表10中常温环境对应的轻载场景的环境温度范围([10,30])和SoC温度范围([45,55])分别对应匹配，因而，若当前SSD温度与常温环境对应的轻载场景的SSD温度范围([40,50])匹配，或者，当前DDR温度与常温环境对应的轻载场景的DDR温度范围([40,50])匹配，即可确定场景识别结果3为轻载场景。如，当前SSD温度为38℃，DDR温度为42℃，则可确定场景识别结果3为轻载场景。
应理解，实际应用中，存在一些场景，SSD和DDR的工作量差异较明显，因而二者温度差异较明显。一些场景(例如本地音频播放)下电子设备主要由SSD工作，而DDR工作量很小。这种场景下，SSD温度较高，DDR温度较低；而另一些场景(例如网络音频播放)下，SSD几乎不需要工作，仅需要DDR工作。这种场景下，SSD温度较低，DDR温度较高。该实现方式中，将环境温度和SoC温度作为场景识别的必要条件，将SSD温度和DDR温度作为辅助条件，在SSD温度和DDR温度中的一者满足对应的温度范围，即可确定场景识别结果3。这样能够覆盖上述SSD和DDR工作量存在差异的场景，提高场景识别的准确性。
可选的，若自主识别模块按照上述过程确定场景识别结果3不为表10中的任一种用户场景，则可以将NA作为场景识别结果3。场景识别结果3为NA表示基于温度的模糊场景识别结果不属于预设场景，例如不属于idle场景、不属于轻载场景，也不属于重载场景。
不同环境温度下的器件温度能够反映电子设备对器件的使用程度，因而能够反映用户场景。本实施例中，通过环境温度和器件温度能够简单、快速地匹配出用户场景，提高场景识别效率。
可选的，关于环境及各器件的温度，可以采用平均温度，以提高场景识别的准确性。 在此，以计算SoC的平均温度为例，介绍一种计算方法，包括下述步骤：
A、SoC_NTC按照预设时长的时间窗(例如2s)，向自主识别模块上报SoC采样温度。
也就是说，SoC_NTC每间隔2s，向自主识别模块上报一次SoC采样温度。可选的，SoC_NTC可以计算2s内采集到的多个SoC温度值的平均值，并将多个SoC温度值的平均值作为本次SoC采样温度上报至自主识别模块。这样，能够提高温度采集的准确性。
B、自主识别模块计算SoC_NTC连续i次上报的i个SoC采样温度的平均值，得到参考平均值；i可以根据实际需求设置，例如可以为大于或等于5的整数。
C、自主识别模块剔除i个SoC采样温度中，与参考平均值的差值大于预设差值(例如1℃)的SoC采样温度，得到j个SoC标准温度；j为小于或等于i的整数。
D、自主识别模块计算j个SoC标准温度的平均值，得到SoC的平均温度。
上述计算过程，基于多个采样温度计算得到参考平均值，再基于参考平均值剔除温度中的异常值(即，与参考平均值的差值大于预设差值的采样温度)，防止个别异常数据影响平均温度计算的准确性，进而提高了场景识别的准确性。
S1114、自主识别模块根据场景识别结果1、场景识别结果2和场景识别结果3，确定自主用户场景。
根据场景识别结果1、场景识别结果2和场景识别结果3确定自主用户场景的方法可以有多种。在一个具体的实施例中，可以预先设置三种场景识别结果的可信级别，根据可信级别从三种场景识别结果中确定最终的自主用户场景。例如，三种场景识别结果的可信级别由高到低排序可以为：场景识别结果1的可信级别＞场景识别结果2的可信级别＞场景识别结果3的可信级别。这种情况下，可以按照图11所示的过程确定自主用户场景。如图11所示，首先确定场景识别结果1是否为NA，若自主确定场景识别结果1不为NA，则将场景识别结果1作为自主用户场景；若场景识别结果1为NA，则确定场景识别结果2是否为NA，若场景识别结果2不为NA，则将场景识别结果2作为自主用户场景；若场景识别结果2为NA，则确定场景识别结果3是否为NA，若场景识别结果3不为NA，则将场景识别结果3作为自主用户场景；若场景识别结果3为NA，则将预设的用户场景(例如轻载场景)作为用户自主场景。
本实施例提供的自主用户场景识别过程，有三个用户场景识别的分支，分别为基于用户输入行为特征识别用户场景，基于功率的模糊场景识别和基于温度的模糊场景识别。三个分支从不同的角度(用户使用角度、器件特性角度)、不同的识别粒度(精准识别、模糊识别)预测用户场景，并将三个分支的结果进行融合，得到最终的自主用户场景。如此，每个分支预测场景识别可能存在的场景遗漏或识别不准确，可以由其他分支进行弥补，提高了场景识别的全面性和准确性，进而提高散热控制的准确性和控制效果。
下面结合具体场景对上述描述的散热控制方法进行进一步说明。
本实施例提供一种散热控制方法，该方法由电子设备执行，电子设备包括风扇和键盘，方法包括：
1)第一应用被运行在后台的情况下，在第一时刻，启动第二应用，显示第二应用的窗口，在第一时刻之前，风扇的转速为第一转速，在第一时刻之后，第二应用的窗口为焦 点窗口；在第一时刻之后，风扇的转速被设置为第二转速；
2)在风扇的转速被设置为第二转速后，在第一时间段内，当在键盘的第一区域或第二区域被敲击的过程中，风扇的转速不变；
3)在第一时间段之后，卸载第一应用；
4)卸载第一应用后，在第二时间段内，在键盘的第一区域被敲击的过程中，风扇的转速被设置为第三转速；
5)卸载第一应用后，在所述第二时间段后，在第四时间段内，在键盘的第二区域被敲击的过程中，风扇的转速被设置为第六转速。
具体的，第一应用可以为上述预设APP，在此以第一应用为PC管家APP为例说明。第二应用可以为用户在实际使用场景下打开的某一应用。在此以办公场景下，用户打开的办公应用(即第二应用为办公应用)为例说明。
首先结合场景，对上述过程1)进行说明：
当PC管家APP在后台运行时，在第一时刻，响应于用户的启动操作，电子设备启动办公应用。也就是说，启动办公软件之前，PC管家的运行状态正常。用户启动办公应用后，办公应用的窗口显示于屏幕，且办公应用的窗口被作为焦点窗口。PC管家APP识别到焦点窗口变化后，识别到电子设备所处的用户场景变化为办公场景。PC管家APP将该办公场景的场景信息发送至EC。这里，PC管家APP识别用户场景的过程可以参见上述步骤S102至S104。
如上述实施例所述，EC可以持续通过心跳检测确定PC管家APP的运行状态，并根据心跳检测结果向状态标记位赋值。具体的实现过程可以参见上述实施例中的步骤S101及S1011至S1017等，在此不做赘述。过程1)中，PC管家APP在后台正常运行，因而状态标志位的被赋值为true。
下面对上述过程2)进行说明：
EC接收到PC管家APP发送的办公场景的场景信息后，触发对状态标记位的判断，确定状态标记位的值为true，所以，EC根据PC管家APP发送的办公场景的场景信息确定风扇控制策略，即被动table。确定被动table后，EC根据被动table对风扇进行控制。也就是说，这种场景下，执行被动散热控制过程，识别场景是由PC管家APP根据焦点窗口等识别，因此在这种场景下，在焦点窗口仍为办公应用的情况下，用户敲击键盘的第一区域或第二区域，PC管家APP识别到场景不变化，所以风扇转速保持不变。该过程可以参见上述实施例中的步骤S105至S108。
下面对上述过程3)和4)进行说明：
可选的，键盘的第一区域对应的键值中至少部分键值位于上述游戏键值列表中。也就是说，PC管家APP被卸载后，键盘的第一区域被敲击，电子设备识别到用户场景变化为游戏场景，风扇的转速被设置为第三转速。
具体的，当PC管家APP被卸载后，假设用户启动游戏应用，进入游戏场景。此时，虽然焦点窗口变化为游戏应用的窗口，但是PC管家APP无法识别上层用户场景，无法基于上层用户场景进行被动散热控制。这种情况下，用户在游戏场景下敲击键盘的第一区域，输入第一键值，第一键值中的部分或全部属于游戏键值列表。
而由于用户卸载PC管家，EC根据心跳检测结果，检测到心跳不满足预设条件，因而 向状态标记位赋值false。状态标记位赋值false触发EC进入自主决策散热模式，根据键盘、电子设备的器件功率、器件温度等数据识别用户场景。用户敲击键盘的第一区域，输入第一键值后，EC识别到当前场景变化为游戏场景，因而根据游戏场景确定对应的风扇控制策略(也即自主table)，并根据该风扇控制策略调整风扇转速为第三转速。具体的，可以参见上述实施例中的步骤S109至S115，以及步骤S1111至S1114等。
可选的，在一些场景下，用户未启动游戏应用(第二应用)，仍保持办公应用的窗口显示于屏幕。也即，焦点窗口未变化，仍然为办公应用的窗口。这种情况下，电子设备在按照上述过程控制风扇的转速调整为第三转速之外，响应于用户敲击键盘的第一区域，第一内容被显示于屏幕(即显示屏)。第一内容为敲击键盘的第一区域所输入的内容。
下面对上述过程5)进行说明：
可选的，键盘的第二区域对应的键值中至少部分键值位于上述办公键值类表列表1、办公键值类表列表2和办公键值类表列表3。键盘的第二区域被敲击，电子设备识别到用户场景变化为办公场景，风扇的转速被设置为第六转速。
具体的，继续上述例子，用户关闭游戏应用，并再次启动办公应用。这种情况下，PC管家APP被卸载后，虽然焦点窗口变化为办公应用的窗口，但是PC管家APP无法识别上层用户场景，无法基于上层用户场景进行被动散热控制。用户启动办公应用后，用户在游戏场景下敲击键盘的第二区域，输入第二键值，第二键值中的部分或全部属于办公键值类表列表1、办公键值类表列表2或办公键值类表列表3中。
此时，PC管家APP仍处于被卸载状态，状态标记位的值仍为false，EC仍处于自主决策散热模式。因而，用户敲击键盘的第二区域，输入第二键值后，一方面，屏幕中显示第三内容。第三内容为敲击键盘的第二区域所输入的内容。另一方面，EC识别到当前场景变化为办公场景，因而根据办公场景确定对应的风扇控制策略，并根据该风扇控制策略调整风扇转速为第六转速。具体的，可以参见上述实施例中的步骤S109至S115，以及步骤S1111至S1114等。
可选的，在一些场景下，用户未启动办公应用，仍保持游戏应用的窗口显示于屏幕。这种情况下，电子设备也在按照上述过程控制风扇的转速调整为第六转速，但是，屏幕中可以不显示第二内容。
另外，在另一些实施例中，卸载所述第一应用后，基于所述电子设备中的第一器件的功率变化，将所述风扇的转速设置为第四转速。或者，卸载所述第一应用后，在第三时间段内，基于所述电子设备中的第二器件的温度变化，将所述风扇的转速设置为第五转速。
具体的，PC管家APP被卸载后，EC检测心跳仍异常，因而，状态标记位持续保持false。EC继续根据键盘、电子设备的器件功率、器件温度等数据识别用户场景。当用户场景变化，例如用户打开视频软件，场景变化为本地视频场景或在线视频场景时，EC识别到相关器件的功率发生变化，因而确定当前场景变化为本地视频场景或在线视频场景，根据本地视频场景或在线视频场景确定对应的自主table，并根据该自主table调整风扇转速为第四转速。
再例如，用户打开动画渲染软件，场景变化重载场景，EC识别到相关器件的温度发生变化，因而确定当前场景变化为重载场景，根据重载场景确定对应的自主table，并根据该自主table调整风扇转速为第六转速。
接下来，对被动散热控制过程进行进一步说明。
首先，对预设APP识别上层用户场景的过程进行说明。
示例性的，图12为本申请实施例提供的一例上层用户场景识别的工作流程示意图。如图12所示，预设APP的场景识别引擎包括系统探针模块、场景识别模块及基础策略匹配管理器。场景识别模块可分别与系统探针模块及基础策略匹配管理器进行交互。场景识别模块可以向系统探针模块发送获取探针状态的请求。系统探针模块可以获取电子设备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所处的用户场景，即确定上层用户场景。如上所述，上层用户场景可包括idle场景、视频场景、游戏场景、办公场景及社交场景等。用户场景可以反映用户当前的使用需求。例如，场景识别引擎在识别出焦点窗口为视频应用的窗口时，确定出电 子设备100处于视频场景，这说明用户需要使用视频应用观看、浏览视频。又例如，场景识别引擎在识别出焦点窗口为微信TM的聊天窗口时，确定电子设备100处于社交场景。通常情况下，场景识别模块通过上述探针状态确定到电子设备的用户场景发生变化时(例如探针状态发生变化可认为用户场景发生变化)，可以确定电子设备当前所处的用户场景，得到上层用户场景。场景识别模块确定上层用户场景后，可以将上层用户场景发送至热噪音平衡引擎。
如图12所示，调度引擎包括负载管控器。负载管控器可以从系统探针模块获取系统负载，并将系统负载发送至热噪音平衡引擎。
具体的，场景识别模块和负载管控器可以将上层用户场景和系统负载经由WMI插件发送至BIOS，再由BIOS发送至EC中的热噪音平衡引擎。热噪音平衡引擎根据上层用户场景和系统负载等信息进行散热控制，具体过程参见上述实施例，不再赘述。
下面以电子设备从办公场景变换为视频场景为例，结合图12和图13，对上述步骤“S102、预设APP识别电子设备所处的用户场景，得到上层用户场景”的实现过程进行说明。需要说明的是，图12和图13涉及的主要为上层用户场景的识别，在实施例描述中，上层用户场景也可以简单描述为用户场景。如图12和图13所示，S102包括：
S201、系统探针模块向OsEventDriver节点发送订阅进程创建事件的请求。
如图12所示，场景识别引擎包括系统探针模块，系统探针模块包括系统事件探针。在本申请实施例中，可以由系统事件探针向位于执行体层的OsEventDriver节点发送订阅进程创建事件的请求。其中，订阅进程创建事件的请求也可以称为第一请求。
在一种可选的实施方式中，订阅进程创建事件的请求可以携带有进程名称。即场景识别引擎可以仅订阅指定进程的创建事件，减少不相干进程的创建事件的干扰。例如，指定进程可以为视频应用的进程、游戏应用的进程、办公应用的进程、社交应用的进程等等。当然，在其他实施方式中，场景识别引擎也可以不对订阅的进程创建事件做出限制。
S202、OsEventDriver节点向进程管理器发送订阅进程创建事件的请求。
进程创建事件的请求可以参考S201的描述，在此不做赘述。
也就是说，场景识别引擎的系统事件探针可以通过OsEventDriver节点向进程管理器发送订阅进程创建事件的请求。
可以理解地，OsEventDriver节点会向进程管理器注册一个回调，注册该回调的作用是当进程管理器创建进程后，可以向OsEventDriver节点返回该进程创建事件。
S203、系统探针模块向OsEventDriver节点发送订阅GPU解码事件的请求。
仍然如图12所示，系统探针模块还包括音视频状态探针。在本申请实施例中，可以由系统探针模块的音视频状态探针向OsEventDriver节点发送订阅GPU解码事件的请求。其中，订阅GPU解码事件的请求也可以称为第三请求。
S204、OsEventDriver节点向显卡驱动发送订阅GPU解码事件的请求。
也就是说，场景识别引擎的音视频状态探针可以通过OsEventDriver节点向显卡驱动发送订阅GPU解码事件的请求。同样地，OsEventDriver节点可向显卡驱动注册一个回调，注册该回调的作用是当显卡驱动监控到GPU进行解码操作后，可以向OsEventDriver节点返回该GPU解码事件。
S205、系统探针模块向API模块发送订阅焦点窗口变化事件的请求。
API模块可包括由user32.dll实现的Windows用户界面接口，该接口可用于创建窗口。在一种可选的实施方式中，可以由系统探针模块的系统事件探针向API模块的Windows用户界面接口发送订阅焦点窗口变化事件的请求。其中，订阅焦点窗口变化事件的请求也可以称为第二请求。
同样地，该系统事件探针可向API模块注册一个回调，注册该回调的作用是当API模块(的Windows用户界面接口)监控到焦点窗口发生变化时，可以向系统事件探针返回该焦点窗口变化事件。
焦点窗口为拥有焦点的窗口，大概率为用户当前需要使用的窗口。因此，通过监控焦点窗口，可以确定用户的使用需求。例如，焦点窗口为视频应用的窗口，则表明用户需求浏览、播放视频。又例如，焦点窗口为游戏应用的窗口，则表明用户需求打游戏。通过监控焦点窗口是否发生变化，可以确定用户需求是否发生改变。例如，焦点窗口由视频应用的窗口变为游戏应用的窗口，则表明用户当前的需求由看视频变成了打游戏。可以理解，若焦点窗口发生了变化，即用户需求发生了变化，也可确定是当前的用户场景发生了变化。
需要说明的是，上述S201、S203及S205之间没有严格的先后顺序，其可以按照图13中所示的顺序依次执行，也可以同时执行，也可以按照S203、S201、S205的顺序依次执行、按照S203、S205、S201的顺序依次执行、按照S205、S201、S203的顺序依次执行或者按照S205、S203、S201的顺序依次执行。相应地，S202、S204及S206之间也没有严格的先后顺序，只要满足S202在S201之后执行、S204在S203之后执行以及S206在S205之后执行即可，在此不做具体限制。
上述系统探针模块已经订阅了各种事件的请求后，在电子设备的用户场景发生变化时，系统探针模块便可以监听到该变化事件。下面以电子设备的用户场景从办公场景变化为视频场景为例进行描述。
S206、响应于接收到用户开启视频应用的操作，视频应用向进程管理器发送创建进程请求。
其中，创建进程请求包括视频应用程序的存储地址。
视频应用可以通过API模块的kernel32.dll接口及Ntdll.dll接口向进程管理器发送创建进程的请求(图未示)。
S207、进程管理器创建视频应用进程。
具体的，进程管理器可以通过该存储地址查询到视频应用程序的二进制文件。通过加载视频应用程序的二进制文件，可以创建进程运行的环境，启动视频应用进程。
其中，Windows操作系统将一个应用程序的一次运行定义为一个进程。一个进程可以拥有多个线程。窗口是窗口结构的实例，是一种图形用户界面(graphical user interface，GUI)资源，窗口是由线程创建的，线程可以拥有它所创建的所有窗口。在本申请实施例中，电子设备运行视频应用，则进程管理器需创建该视频应用的进程，即视频应用进程(即第一进程)。视频应用进程包括多个线程，多个线程包括线程1，线程1可用于创建视频应用的主窗口，主窗口为集成有视频应用全部功能按键的窗口。
S208、进程管理器向OsEventDriver节点上报进程创建事件。
其中，进程创建事件可包括进程管理器所创建的进程的名称。在本申请实施例中，该 进程的名称为视频应用进程的名称。当然，若进程管理器创建的是其他应用的进程，该进程的名称也对应为其他应用进程的名称。
前文已经说明，OsEventDriver节点向进程管理器发送了订阅进程创建事件的请求，且注册了回调。因此，进程管理器在创建视频应用进程后可向OsEventDriver节点上报进程创建事件。
S209、OsEventDriver节点向系统探针模块上报进程创建事件。
其中，关于进程创建事件的描述见S208，在此不再赘述。
在本申请实施例中，该OsEventDriver节点可向系统探针模块的系统事件探针上报该进程创建事件。
S210、系统探针模块向场景识别模块发送进程创建事件。
S211、响应于线程1的调用请求，API模块创建窗口1。
进程管理器创建视频应用进程后，视频应用进程的线程1主动调用API模块的Windows用户界面接口创建窗口1。示例性的，如图14中(a)所示，电子设备可以显示窗口101，该窗口101为办公界面。电子设备可以接收用户点击桌面上视频应用的图标102的操作，响应于该操作，如图14中的(b)所示，电子设备显示窗口103(即窗口1，也可以称为第一窗口)。在上述过程中，焦点窗口由原本的窗口101变为窗口103。
S212、API模块向系统探针模块上报焦点窗口事件。
在本申请实施例中，API模块的Windows用户界面接口创建窗口1后，可以获取第一进程(即焦点进程)的名称及第二进程的名称，第一进程为当前的焦点窗口(即窗口1)对应的进程，第二进程为上一个焦点窗口(例如窗口2)对应的进程。示例性的，窗口1对应的进程为视频应用进程(第一进程)，该进程的名称例如为hlive.exe，窗口2对应的进程为办公应用进程(第二进程)，该进程的名称例如为word.exe。由于第一进程的名称与第二进程的名称不一致，API模块确定焦点窗口发生变化，向系统探针模块的系统事件探针上报焦点窗口事件。其中，焦点窗口变化事件包括第一进程(即焦点进程)的名称。示例性的，第一进程为视频应用进程，焦点窗口变化事件携带有视频应用进程的名称。
需要说明的是，在电子设备已经启动视频应用的情况下，电子设备可以不用执行S206～S211。在系统探针模块向API模块发送订阅焦点窗口变化事件的请求后，若用户将焦点窗口切换为视频应用的窗口，API模块同样可以检测到焦点窗口发生变化，并向系统探针模块上报焦点窗口事件。
S213、系统探针模块向场景识别模块发送焦点窗口事件。
S214、场景识别模块确定第一进程所属的类型为视频类。
电子设备可以预先配置有应用名单，场景识别模块可以查询应用名单中是否包括第一进程。若应用名单中包括第一进程，场景识别模块可以确定第一进程所属的类型。其中，应用名单包括每个应用的进程名称及应用所属的类型。示例性的，应用名单可以如表11所示：
表11

例如，第一进程的名称为hlive.exe，则场景识别模块可以确定第一进程所属的类型为视频类。又例如，第一进程的名称为wechat.exe，则场景识别模块可以确定第一进程所属的类型为社交类。需要说明的是，上述表11仅作为示例，实际上表11还可包括更多应用的进程名称及其所属的类型。
需要说明的是，此步骤的目的在于初步判断电子设备所处的用户场景，即初步判断上层用户场景。上层用户场景可以包括视频场景、游戏场景、社交场景、办公场景、浏览器场景等等。其中，视频场景进一步可包括视频播放场景、视频浏览场景。社交场景进一步可包括文字聊天场景、语音聊天场景、视频聊天场景等。办公场景进一步可包括文档编辑场景、文档浏览场景、视频会议场景等。浏览器场景可包括浏览网页场景及播放视频场景等。
在本步骤中，通过第一进程所属的类型，可以确定电子设备所处的用户场景。例如，若确定第一进程所属的类型为视频类，则可以确定电子设备处于视频场景；又例如，若确定第一进程所属的类型为游戏类，则可以确定电子设备处于游戏场景。并且，由于第一进程的名称和第二进程的名称不一致，则可以确定电子设备的用户场景发生了变化。
为了进一步分析用户需求，场景识别模块还可以进一步结合其他参数(例如，外设事件、GPU运行状态等)来分析电子设备所处的具体场景，以达到分析结果更加准确的效果，继续以视频场景为例，其具体过程可以包括：
S215、响应于接收到用户播放视频的操作，视频应用向API模块发送视频播放指令。
具体的，视频应用可向API模块的DirectX API发送该视频播放指令。该视频播放指令可包括视频的缓存地址。
S216、API模块读取视频文件。
API模块可根据视频播放指令中携带的缓存地址，读取对应的视频文件。
S217、API模块向显卡驱动发送解码指令。
S218、显卡驱动向GPU发送启动指令。
S219、GPU进行解码。
具体的，GPU可通过GPU视频处理(video processing)引擎对该视频文件进行解码操作。
S220、GPU向显卡驱动上报解码事件。
S221、显卡驱动向OsEventDriver节点上报解码事件。
S222、OsEventDriver节点向系统探针模块上报解码事件。
具体的，OsEventDriver节点向系统探针模块的音视频状态探针上报该解码事件。
S223、系统探针模块向场景识别模块发送解码事件。
S224、场景识别模块向系统探针模块发送指令1。
其中，指令1指示系统探针模块获取第一进程的GPU占用率。该指令1可携带有第一进程的名称。
S225、系统探针模块向进程管理器发送获取第一进程的GPU占用率的请求。
其中，该获取焦点进程的GPU占用率的请求可以包括第一进程的名称。
在一种可选的实施方式中，可以由系统探针模块的音视频状态探针向进程管理器发送获取第一进程的GPU占用率的请求。
S226、进程管理器采集第一进程的GPU占用率。
具体的，进程管理器可以通过显卡驱动的图像核心(graphics kernel)接口采集第一进程的GPU占用率。
S227、进程管理器向系统探针模块发送第一进程的GPU占用率。
进程管理器可向系统探针模块的音视频状态探针发送第一进程的GPU占用率。
S228、系统探针模块向场景识别引擎发送第一进程的GPU占用率。
S229、场景识别模块判断第一进程的GPU占用率是否大于0。
其中，若第一进程的GPU占用率大于0，则执行S230。
通过第一进程的GPU占用率，可以确定第一进程在运行过程中是否使用GPU，若第一进程的GPU占用率大于0，则可以认为第一进程在运行过程中使用了GPU；若第一进程的GPU占用率为0，则表明第一进程在运行过程中未使用GPU。
S230、场景识别模块向系统探针模块发送指令2。
其中，指令2指示系统探针模块获取第一进程的GPU引擎。该指令2可携带有第一进程的名称。
S231、系统探针模块向进程管理器发送获取第一进程的GPU引擎的请求。
其中，可以由系统探针模块的音视频状态探针向进程管理器发送获取第一进程的GPU引擎的请求。获取第一进程的GPU引擎的请求包括第一进程的名称。
GPU引擎包括GPU 3D引擎、GPU copy引擎、GPU video encode引擎、GPU video processing引擎。其中，GPU 3D引擎主要负责处理2D或者3D图形。GPU copy引擎主要用于传输数据。GPU video encode引擎主要用于进行编码操作。GPU video processing引擎主要进行解码操作。在一些实施例中，GPU video processing引擎也可以由GPU video decode引擎代替。
S232、进程管理器获取第一进程的GPU引擎。
具体的，进程管理器可以通过显卡驱动的graphics kernel接口获取第一进程的GPU引擎。
S233、进程管理器向系统探针模块发送消息1，消息1指示第一进程的GPU引擎为GPU视频处理(video processing)引擎。
具体的，进程管理器可向系统探针模块的音视频状态探针发送该消息，再由音视频状态将该消息转发给场景识别模块。
S234、系统探针模块向场景识别模块发送消息1。
S235、场景识别模块判断第一进程的GPU引擎是否为GPU视频处理(video processing)引擎。
若第一进程的GPU引擎为GPU video processing引擎，则执行S236；若第一进程的 GPU引擎不为GPU video processing引擎，则执行S230。
在S214步骤中，场景识别引擎已经确定第一进程所属的类型为视频类，即可以确定电子设备处于视频场景。通过步骤S235，场景识别引擎可以确定第一进程通过GPU执行的具体操作，进而确定用户在使用视频应用的具体操作。例如，若第一进程的GPU引擎为GPU video processing引擎，则表明第一进程在使用GPU进行解码操作，可以认为用户在使用视频应用播放视频。又例如，第一进程的GPU引擎不为GPU video processing引擎，则表明第一进程没有在使用GPU进行解码操作，那么用户大概率在视频应用上浏览视频资源，还未播放视频。
S236、场景识别模块根据第一进程的进程信息确定上层用户场景为视频播放场景。
其中，第一进程的进程信息包括第一进程的名称、第一进程所属的应用类型、第一进程的GPU占用率及第一进程使用的GPU引擎等信息。
综合上述内容可知，若第一进程(焦点进程)的类型为视频类、第一进程的GPU占用率大于0且第一进程的GPU引擎为GPU video processing引擎，则可以确定电子设备处于视频播放场景。
需要说明的是，上述S201～S236仅以电子设备处于视频场景下的视频播放场景为例进行说明。实际上，电子设备还可以处于其他用户场景(例如，游戏场景、办公场景、社交场景、视频浏览场景等)。
在一种可选的实施方式中，若场景识别引擎确定第一进程(焦点进程)的类型属于游戏类、CPU的电源模式变为游戏模式(game mode)、第一进程的GPU占用率大于0且第一进程的GPU引擎为GPU 3D引擎，则可以确定电子设备处于游戏场景。
其中，系统探针模块的电源状态探针可以向电源管理器发送订阅电源模式变化事件的请求。电源管理器可以在电源模块转换为游戏模式(game mode)时，向系统探针模块的电源状态探针上报该电源模式变化事件。如此，场景识别引擎可通过电源模式变化事件确定CPU的电源模式是否为game mode。另外，场景识别引擎获取第一进程的类型的过程可以参阅图5中S201、S202、S205、S206～S214，场景识别引擎判断第一进程的GPU占用率是否大于0且第一进程的GPU引擎是否为GPU 3D引擎的过程参阅S224～S235。区别在于将视频应用更换为游戏应用，在此不再赘述。
综上，在执行上述过程后，预设APP可以确定上层用户场景已从办公场景变化为了视频场景，则可以执行后续过程，向内核发送当前上层用户场景(即视频场景)的场景信息。
上文详细介绍了本申请实施例提供的散热控制方法的示例。可以理解的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请实施例可以根据上述方法示例对电子设备进行功能模块的划分，例如，可以对应各个功能划分为各个功能模块，例如检测单元、处理单元、显示单元等，也可以将两个 或两个以上的功能集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。需要说明的是，本申请实施例中对模块的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
需要说明的是，上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述，在此不再赘述。
本实施例提供的电子设备，用于执行上述散热控制方法，因此可以达到与上述实现方法相同的效果。
在采用集成的单元的情况下，电子设备还可以包括处理模块、存储模块和通信模块。其中，处理模块可以用于对电子设备的动作进行控制管理。存储模块可以用于支持电子设备执行存储程序代码和数据等。通信模块，可以用于支持电子设备与其他设备的通信。
其中，处理模块可以是处理器或控制器。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，数字信号处理(digital signal processor，DSP)和微处理器的组合等等。存储模块可以是存储器。通信模块具体可以为射频电路、蓝牙芯片、Wi-Fi芯片等与其他电子设备交互的设备。
在一个实施例中，当处理模块为处理器，存储模块为存储器时，本实施例所涉及的电子设备可以为具有图2所示结构的设备。
本申请实施例还提供一种芯片系统，如图15所示，该芯片系统包括至少一个处理器801和至少一个接口电路802。处理器801和接口电路802可通过线路互联。例如，接口电路802可用于从其它装置(例如电子设备的存储器)接收信号。又例如，接口电路802可用于向其它装置(例如处理器801)发送信号。示例性的，接口电路802可读取存储器中存储的指令，并将该指令发送给处理器801。当所述指令被处理器801执行时，可使得电子设备执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。可选的，该芯片系统可以包括上述SoC和/或EC。
本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质中存储了计算机程序，当计算机程序被处理器执行时，使得处理器执行上述任一实施例的散热控制方法。
本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得计算机执行上述相关步骤，以实现上述实施例中的散热控制方法。
另外，本申请的实施例还提供一种装置，这个装置具体可以是芯片，组件或模块，该装置可包括相连的处理器和存储器；其中，存储器用于存储计算机执行指令，当装置运行时，处理器可执行存储器存储的计算机执行指令，以使芯片执行上述各方法实施例中的散热控制方法。
其中，本实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
通过以上实施方式的描述，所属领域的技术人员可以了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。

Claims (20)

  1. 一种散热控制方法，所述方法由电子设备执行，其特征在于，所述电子设备包括风扇和键盘，所述方法包括：
    第一应用被运行在后台的情况下，在第一时刻，启动第二应用，显示第二应用的窗口，在所述第一时刻之前，风扇的转速为第一转速，在所述第一时刻之后，所述第二应用的窗口为焦点窗口；
    在所述第一时刻之后，所述风扇的转速被设置为第二转速；
    在所述风扇的转速被设置为所述第二转速后，在第一时间段内，当在所述键盘的第一区域或第二区域被敲击的过程中，所述风扇的转速不变；
    在所述第一时间段之后，卸载所述第一应用；
    卸载所述第一应用后，在第二时间段内，在所述键盘的第一区域被敲击的过程中，所述风扇的转速被设置为第三转速。
  2. 根据权利要求1所述的方法，其特征在于，所述方法还包括：
    卸载所述第一应用后，基于所述电子设备中的第一器件的功率变化，将所述风扇的转速设置为第四转速。
  3. 根据权利要求1或2所述的方法，其特征在于，所述方法还包括：
    卸载所述第一应用后，在第三时间段内，基于所述电子设备中的第二器件的温度变化，将所述风扇的转速设置为第五转速。
  4. 根据权利要求1至3中任一项所述的方法，其特征在于，所述卸载所述第一应用后，在第二时间段内，在所述键盘的第一区域被敲击的过程中，所述风扇的转速被设置为第三转速，包括：
    卸载所述第一应用后，在所述第二时间段内，基于所述键盘的第一区域被敲击，将所述风扇的转速设置为所述第三转速。
  5. 根据权利要求4所述的方法，其特征在于，所述卸载所述第一应用后，在所述第二时间段内，基于所述键盘的第一区域被敲击，将所述风扇的转速设置为所述第三转速，包括：
    在所述第二时间段内，响应于所述键盘的第一区域被敲击，通过所述键盘接收第一键值；
    基于所述第一应用被卸载，根据所述第一键值，确定所述电子设备所处的用户场景为第一场景；
    根据所述第一场景的场景信息，确定第一策略；
    根据所述第一策略，调整所述风扇的转速为所述第三转速。
  6. 根据权利要求5所述的方法，其特征在于，所述根据所述第一键值，确定所述电子设备所处的用户场景为第一场景，包括：
    根据所述第一键值，确定目标比例，所述目标比例为所述第一键值中，目标键值的总个数占所述第一键值总个数的比例，所述目标键值为属于目标列表的键值，所述目标列表中的键值在所述键盘形成第三区域，所述第三区域与所述键盘的第一区域至少部分重合；
    确定所述目标比例是否大于预设比例阈值，得到第一结果；
    根据所述第一结果，确定所述电子设备所处的用户场景为所述第一场景。
  7. 根据权利要求6所述的方法，其特征在于，所述根据所述第一结果，确定所述电子设备所处的用户场景为所述第一场景，包括：
    若所述第一结果为所述目标比例大于所述预设比例阈值，则确定所述电子设备所处的用户场景为所述第一场景；
    或者，
    若所述第一结果为所述目标比例大于所述预设比例阈值，且所述第一键值的总个数大于第一预设数量，则确定所述电子设备所处的用户场景为所述第一场景。
  8. 根据权利要求5至7中任一项所述的方法，其特征在于，所述第一策略中包括所述电子设备中第三器件的多个温度范围与所述风扇的多个转速的对应关系，其中，所述多个转速中包括所述第三转速；
    所述根据所述第一策略，调整所述风扇的转速为所述第三转速，包括：
    获取所述第三器件的当前温度；
    基于所述第一策略，确定所述当前温度所属的温度范围与所述第三转速对应；
    调整所述风扇的转速为所述第三转速。
  9. 根据权利要求8所述的方法，其特征在于，所述第一策略中还包括所述多个温度范围与多个最小持续时长的对应关系，所述多个最小持续时长中包括第一目标时长，所述方法还包括：
    基于所述第一策略，确定所述当前温度所属的温度范围与所述第一目标时长对应；
    所述风扇在所述第三转速下运转的时长大于所述第一目标时长。
  10. 根据权利要求5至9中任一项所述的方法，其特征在于，所述基于所述第一应用被卸载，根据所述第一键值，确定所述电子设备所处的用户场景为第一场景，包括：
    确定标记位的值；
    基于所述标记位的值是第一预设值，根据所述第一键值，确定所述电子设备所处的用户场景为第一场景。
  11. 根据权利要求10所述的方法，其特征在于，所述确定标记位的值，包括：
    向所述第一应用发送M个心跳请求，并在发送每个心跳请求时启动一个与心跳请求对应的定时器，M为大于或等于1的整数；
    根据所述第一应用回复的与心跳请求对应的心跳响应消息，以及所述定时器，确定所述M个心跳请求中是否存在第一心跳请求，第一心跳请求是指，未在对应的定时器超时之前接收到对应心跳响应消息的心跳请求；
    若所述M个心跳请求中存在所述第一心跳请求，则确定所述标记位的值为所述第一预设值；
    若所述M个心跳请求中不存在所述第一心跳请求，则确定所述标记位的值为第二预设值。
  12. 根据权利要求1至11中任一项所述的方法，其特征在于，所述方法还包括：
    在所述第二时间段后，在第四时间段内，在所述键盘的第二区域被敲击的过程中，所述风扇的转速被设置为第六转速。
  13. 根据权利要求12所述的方法，其特征在于，所述在所述第二时间段后，在第四时间段内，在所述键盘的第二区域被敲击的过程中，所述风扇的转速被设置为第六转速，包 括：
    在所述第四时间段内，响应于所述键盘的第二区域被敲击，通过所述键盘接收第二键值；
    基于所述第一应用被卸载，根据所述第二键值，确定所述电子设备所处的用户场景为第二场景；
    根据所述第二场景的场景信息，确定第二策略；
    根据所述第二策略，调整所述风扇的转速为所述第六转速。
  14. 根据权利要求13所述的方法，其特征在于，所述根据所述第二键值，确定所述电子设备所处的用户场景为第二场景，包括：
    分别统计所述第二键值中，第一类键值的个数、第二类键值的个数和第三类键值的个数；所述第一类键值、所述第二类键值和所述第三类键值对应所述键盘的第四区域，所述第四区域与所述键盘的第二区域至少部分重合；
    根据所述第一类键值的个数确定第一预测因子的值；
    根据所述第二类键值的个数确定第二预测因子的值；
    根据所述第三类键值的个数确定第三预测因子的值；
    对所述第一预测因子的值、所述第二预测因子的值和所述第三预测因子的值进行加权求和，得到预测值；
    确定所述预测值是否大于预设阈值，得到第二结果；
    根据所述第二结果，确定所述电子设备所处的用户场景为第二场景。
  15. 根据权利要求14所述的方法，其特征在于，
    所述第一类键值中包括用于指示删除内容的键值，和/或，用于指示换行的键值；
    所述第二类键值中包括至少一个快捷键对应的键值；
    所述第三类键值中包括用于指示调整方向的键值。
  16. 根据权利要求1至15中任一项所述的方法，其特征在于，所述在第一时间段内，当在所述键盘的第一区域或第二区域被敲击的过程中，所述风扇的转速不变，包括：
    在所述第一时间段内，响应于所述键盘的第一区域或第二区域被敲击，通过所述键盘接收第三键值；
    基于所述第一应用被运行，不根据所述第三键值确定所述电子设备所处的用户场景。
  17. 根据权利要求1至16中任一项所述的方法，其特征在于，所述电子设备还包括嵌入式控制器EC，所述在所述第一时刻之后，所述风扇的转速被设置为第二转速，包括：
    基于所述第二应用的窗口为焦点窗口，所述第一应用确定所述电子设备所处的用户场景为第五场景；
    所述第一应用将所述第五场景的场景信息下发至所述EC；
    所述EC基于标记位的值是第二预设值，根据所述第五场景的场景信息，确定第五策略；
    所述EC根据所述第五策略控制所述风扇的转速变化为所述第二转速。
  18. 一种电子设备，其特征在于，所述电子设备包括：一个或多个处理器，以及存储器；
    所述存储器与所述一个或多个处理器耦合，所述存储器用于存储计算机程序代码，所 述计算机程序代码包括计算机指令，所述一个或多个处理器调用所述计算机指令以使得所述电子设备执行如权利要求1至17中任一项所述的方法。
  19. 一种芯片系统，其特征在于，所述芯片系统应用于电子设备，所述芯片系统包括一个或多个处理器，所述一个或多个处理器用于调用计算机指令以使得所述电子设备执行如权利要求1至17中任一项所述的方法。
  20. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括指令，当所述指令在电子设备上运行时，使得所述电子设备执行如权利要求1至17中任一项所述的方法。
PCT/CN2024/085043 2024-03-29 2024-03-29 散热控制方法和电子设备 Pending WO2025200014A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202480041025.8A CN121488225A (zh) 2024-03-29 2024-03-29 散热控制方法和电子设备
PCT/CN2024/085043 WO2025200014A1 (zh) 2024-03-29 2024-03-29 散热控制方法和电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2024/085043 WO2025200014A1 (zh) 2024-03-29 2024-03-29 散热控制方法和电子设备

Publications (1)

Publication Number Publication Date
WO2025200014A1 true WO2025200014A1 (zh) 2025-10-02

Family

ID=97218462

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2024/085043 Pending WO2025200014A1 (zh) 2024-03-29 2024-03-29 散热控制方法和电子设备

Country Status (2)

Country Link
CN (1) CN121488225A (zh)
WO (1) WO2025200014A1 (zh)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150268710A1 (en) * 2014-03-19 2015-09-24 International Business Machines Corporation Power management for multi-core processing systems
US20170277545A1 (en) * 2016-03-28 2017-09-28 Dell Products, L.P. System and Method to Remotely Detect and Report Bootable Physical Disk Location
CN112445276A (zh) * 2019-08-30 2021-03-05 华为技术有限公司 一种折叠屏显示应用方法及电子设备
CN113050776A (zh) * 2021-03-30 2021-06-29 联想(北京)有限公司 一种控制方法及装置
CN116025580A (zh) * 2022-05-16 2023-04-28 荣耀终端有限公司 调节风扇转速的方法和电子设备
CN117130772A (zh) * 2023-04-10 2023-11-28 荣耀终端有限公司 资源调度方法、电子设备及存储介质
CN117270670A (zh) * 2023-11-22 2023-12-22 荣耀终端有限公司 一种功耗控制方法及电子设备
CN117331418A (zh) * 2023-10-25 2024-01-02 成都数字狗科技有限公司 一种基于场景识别的散热方法、系统及终端设备

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150268710A1 (en) * 2014-03-19 2015-09-24 International Business Machines Corporation Power management for multi-core processing systems
US20170277545A1 (en) * 2016-03-28 2017-09-28 Dell Products, L.P. System and Method to Remotely Detect and Report Bootable Physical Disk Location
CN112445276A (zh) * 2019-08-30 2021-03-05 华为技术有限公司 一种折叠屏显示应用方法及电子设备
CN113050776A (zh) * 2021-03-30 2021-06-29 联想(北京)有限公司 一种控制方法及装置
CN116025580A (zh) * 2022-05-16 2023-04-28 荣耀终端有限公司 调节风扇转速的方法和电子设备
CN117130772A (zh) * 2023-04-10 2023-11-28 荣耀终端有限公司 资源调度方法、电子设备及存储介质
CN117331418A (zh) * 2023-10-25 2024-01-02 成都数字狗科技有限公司 一种基于场景识别的散热方法、系统及终端设备
CN117270670A (zh) * 2023-11-22 2023-12-22 荣耀终端有限公司 一种功耗控制方法及电子设备

Also Published As

Publication number Publication date
CN121488225A (zh) 2026-02-06

Similar Documents

Publication Publication Date Title
CN115599513B (zh) 资源调度方法及电子设备
US8065540B2 (en) Power control for information handling system having shared resources
CN116027880B (zh) 资源调度方法和电子设备
US20170185457A1 (en) Technologies for offloading and on-loading data for processor/coprocessor arrangements
US20100292854A1 (en) Integrating energy budgets for power management
CN116028205B (zh) 资源调度方法和电子设备
EP3452954A1 (en) Dynamic classifier selection based on class skew
CN116028210B (zh) 资源调度方法、电子设备及存储介质
CN110032267B (zh) 信息处理方法、装置、移动终端及计算机可读存储介质
KR102326945B1 (ko) 태스크 마이그레이션 방법 및 장치
CN116027879B (zh) 确定参数的方法、电子设备和计算机可读存储介质
CN110032321B (zh) 应用程序处理方法和装置、电子设备、计算机可读存储介质
CN110008008A (zh) 应用程序处理方法和装置、电子设备、计算机可读存储介质
US20200004304A1 (en) Dynamic power source selection, charging, and discharging
CN109992376B (zh) 应用冻结方法、装置、终端及计算机可读存储介质
CN116025580B (zh) 调节风扇转速的方法和电子设备
JP2020513603A (ja) 動的な外部電力資源選択
CN110032429B (zh) 信息处理方法、装置、移动终端及计算机可读存储介质
CN109992369B (zh) 应用程序处理方法和装置、电子设备、计算机可读存储介质
CN116028209B (zh) 资源调度方法、电子设备及存储介质
CN116028005B (zh) 音频会话获取方法、装置、设备和存储介质
CN116028314B (zh) 温度参数读取方法、电子设备和计算机可读存储介质
CN116700816B (zh) 一种资源管理方法及电子设备
CN121488225A (zh) 散热控制方法和电子设备
CN114764353B (zh) 用于信息处置系统(ihs)全系统优化的ml到ml的编排系统和方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24932017

Country of ref document: EP

Kind code of ref document: A1