Heat dissipation control method and electronic device

Abstract

The present application relates to the technical field of electronics, and provides a heat dissipation control method and an electronic device. The method comprises: when a first application runs at the background, starting a second application and displaying a window of the second application at a first moment, wherein the rotating speed of a fan is a first rotating speed before the first moment, and the window of the second application is a focus window after the first moment; setting the rotating speed of the fan to be a second rotating speed after the first moment; after the rotating speed of the fan is set to be the second rotating speed, in the process of a first area or a second area of a keyboard being knocked, staying the rotating speed of the fan unchanged in a first time period; unloading the first application after the first time period; and after the first application is unloaded, in the process of the first area of the keyboard being knocked, setting the rotating speed of the fan to be a third rotating speed in a second time period. The method can improve the heat dissipation control effect.

Description

Heat dissipation control method and electronic equipment Technical Field

[0001] The present application relates to the field of electronic technology, and in particular to a heat dissipation control method and electronic equipment. Background Art

[0002] To improve the performance of electronic devices (such as laptops and personal computers (PCs)), many electronic devices have 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.

[0003] In actual applications, it is found that in some cases, for example, when the PC manager application (APP) installed in the electronic device is stuck or uninstalled, the heat dissipation control effect of the electronic device is poor, resulting in problems such as the device being unable to dissipate heat in time or unnecessary fan noise, resulting in a poor user experience.

[0004] Summary of the Invention

[0005] 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.

[0006] In a first aspect, 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.

[0007] The first application is also the preset APP in the specific implementation. Optionally, 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. For example, in an office 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.

[0008] Before the first moment, the fan speed is the first speed. After the first moment, the window of the second application becomes the focus window. When the first application is running in the background, 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. In short, when the first application is running in the background, the focus window changes and the fan speed changes.

[0009] Afterwards, during the first time period, while the first application is still running and the focus window remains unchanged (i.e., the focus window remains the window of the second application), the first application recognizes that the user context has not changed. In this case, the fan speed does not change when the user taps the first or second area of ​​the keyboard. In other words, while the first application is running in the background and the focus window remains unchanged, the fan speed remains unchanged when data is entered on the keyboard.

[0010] After the first time period, the first application is uninstalled. After the first application is uninstalled, the first application cannot recognize the user scenario, and thus the electronic device cannot perform heat dissipation control according to the user scenario recognized by the first application. In this case, the electronic device can identify the user scenario based on the input data of the keyboard in the second time period, and perform heat dissipation control based on the recognition result. Specifically, when the user taps the first area of ​​the keyboard in the second time period, the user scenario is recognized as a preset scenario based on the input data of the keyboard, and the fan speed is adjusted to a third speed corresponding to the preset scenario. The preset scene can be, for example, a game scene. In short, after the first application is uninstalled, the keyboard inputs data and the fan speed changes.

[0011] It is understood that during the second time period, only the first area of ​​the keyboard is tapped, and the second area of ​​the keyboard is not tapped. In addition, during the second time period, 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.

[0012] The heat dissipation control method provided in the first aspect can, after the first application is uninstalled, determine a fan speed that matches the user scenario based on keyboard input data when the first area of ​​the keyboard is tapped, and perform fan control based on the fan speed to promptly dissipate heat from the electronic device and prevent excessive fan noise caused by excessive heat dissipation. In other words, this method does not rely on the first application and can achieve refined heat dissipation control even when the first application is abnormal, thereby improving the effectiveness of heat dissipation control.

[0013] In combination with the first aspect, in some implementations of the first aspect, 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.

[0014] For example, when the user presses the A, D, S, or F keys in the first area of ​​the keyboard, “ADSF” or “adsf” is displayed in the window of the second application.

[0015] In one possible implementation, 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.

[0016] In a possible implementation, 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.

[0017] Optionally, when the power of the first device changes to within a certain power range, the rotational speed of the fan is set to a fourth rotational speed corresponding to the power range.

[0018] Optionally, the greater the power, the greater the corresponding fan speed.

[0019] In one possible implementation, the fan speed can be adjusted based on the power status of the first device within a certain time period. Specifically, after uninstalling the first application, the fan speed is set to a fourth speed based on the power change of the first device in the electronic device, including: after uninstalling the first application, within a fifth time period, the fan speed is set to the fourth speed based on the power change of the first device in the electronic device. Based on the power status over a period of time, changes in user scenarios can be more accurately identified, improving the accuracy of heat dissipation control.

[0020] In one possible implementation, the fan speed is set to a fourth speed based on a power change of a first component in the electronic device, including: detecting that the power change of the first component in the electronic device is a first power; determining, based on the first power, that the user scenario in which the electronic device is located is a third scenario; determining a third strategy based on scenario information of the third scenario; and adjusting the fan speed to a fourth speed based on the third strategy.

[0021] Optionally, the third scene may be, for example, a local video scene or an online video scene.

[0022] It is understood that the power consumption of electronic devices varies in different user scenarios. In this implementation, the user scenario of the electronic device is identified from the perspective of device power. The identification result can be used to supplement or reconfirm the recognition result based on keyboard input data, reducing omissions or inaccuracies in scene recognition and improving the comprehensiveness and accuracy of scene recognition.

[0023] In one possible implementation, the first device includes at least one of a system on chip (SoC), a solid state disk (SSD), a double data rate synchronous dynamic random access memory (DDR), a screen, an audio power amplifier (PA), and a wireless communication module.

[0024] In this implementation, user scenarios are comprehensively identified based on the power of multiple devices, thereby improving the accuracy of user scenario identification and further improving the effect of heat dissipation control.

[0025] In a possible implementation, the method further includes: after uninstalling the first application, within a third time period, based on a temperature change of a second component in the electronic device, setting the rotation speed of the fan to a fifth rotation speed.

[0026] Optionally, when the power of the second device changes to a certain temperature range, the speed of the fan is set to a fifth speed corresponding to the temperature range. Optionally, the higher the temperature, the higher the corresponding fan speed.

[0027] In one possible implementation, within a third time period, based on the temperature change of a second component in the electronic device, the fan speed is set to a fifth speed, including: detecting that the temperature change of the second component in the electronic device is a first temperature; determining, based on the first temperature, that the user scenario of the electronic device is a fourth scenario; determining a fourth strategy based on the scenario information of the fourth scenario; and adjusting the fan speed to a fifth speed based on the fourth strategy.

[0028] The fourth scenario may be, for example, an idle scenario, a heavy-load scenario, or a light-load scenario.

[0029] It is understandable that different user scenarios can generate different levels of heat and temperatures. This implementation identifies the user scenario of the electronic device based on device temperature, and the identification results can be used to supplement or reconfirm the identification results obtained by other methods, reducing omissions or inaccuracies in scene recognition and improving the comprehensiveness and accuracy of scene recognition.

[0030] In one possible implementation, detecting that the temperature change of a second device in an electronic device is a first temperature includes: obtaining i sampled temperatures of the second device within a third time period, where i is an integer greater than or equal to 1; calculating an average of the i sampled temperatures to obtain a reference average; eliminating, from the i sampled temperatures, sampled temperatures whose difference from the reference average is greater than a preset difference to obtain j standard temperatures; and calculating the average of the j standard temperatures to obtain the first temperature.

[0031] In this implementation, a reference average is calculated based on multiple sampled temperatures. Outliers (i.e., sampled temperatures with a difference from the reference average greater than a preset difference) are then removed from the reference average. The first temperature is then calculated based on the remaining sampled temperatures. This prevents individual outliers from affecting the accuracy of the average temperature calculation, thereby improving the accuracy of scene recognition.

[0032] In one possible implementation, after uninstalling the first application, within a second time period, while the first area of ​​the keyboard is tapped, the fan speed is set to a third speed, including: after uninstalling the first application, within a second time period, based on the first area of ​​the keyboard being tapped, the fan speed is set to the third speed.

[0033] Specifically, when the electronic device detects that the first area of ​​the keyboard is tapped, it identifies the user scenario according to the data input by tapping the first area, and sets the fan speed to the third speed based on the user scenario.

[0034] In one possible implementation, after the first application is uninstalled, within a second time period, based on the first area of ​​the keyboard being tapped, the fan speed is set to a third speed, including: within the second time period, in response to the first area of ​​the keyboard being tapped, receiving a first key value through the keyboard; based on the first application being uninstalled, determining that the user scenario of the electronic device is a first scenario according to the first key value; determining a first strategy according to the scenario information of the first scenario; and adjusting the fan speed to the third speed according to the first strategy.

[0035] Optionally, the first scene may be, for example, a game scene.

[0036] In this implementation, the first scenario can be identified based on the key value, and a fan control strategy (first strategy) that matches the first scenario can be decided based on the first 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.

[0037] In one possible implementation, based on the first key value, determining that the user scenario of the electronic device is the first scenario includes: determining a target ratio based on the first key value, the target ratio being the ratio of the total number of target key values ​​in the first key value to the total number of first key values, the target key value being a key value belonging to a target list, the key values ​​in the target list forming a third area on the keyboard, and the third area at least partially overlapping with the first area of ​​the keyboard; determining whether the target ratio is greater than a preset ratio threshold to obtain a first result; and determining that the user scenario of the electronic device is the first scenario based on the first result.

[0038] It can be understood that the first key value is the key value input by tapping the first area of ​​the keyboard during the second time period. Therefore, the total number of first key values ​​is also the total number of times the user presses the key (i.e., taps the key in the keyboard) during the second time period (each key tapped once is counted as a key value), and the total number of target key values ​​is also the number of times the user taps the key corresponding to the target key value during the second time period.

[0039] The target key value list is also the game key value list in the specific embodiment. The game key value list contains key values ​​corresponding to keys that are likely to be used by the user in the game scene. The key values ​​corresponding to some or all keys in the first area belong to the target key value list.

[0040] If the target ratio is greater than the preset ratio threshold, it means that there are more key values ​​in the first key value that belong to the target key value list, and the user scene is determined to be the first scene (for example, a game scene).

[0041] In this implementation, by calculating the proportion of the target key value in the first key value, the first scene can be accurately identified, thereby improving the accuracy of user scene identification and further improving the accuracy of heat dissipation control.

[0042] In one possible implementation, based on the first result, determining that the user scenario of the electronic device is the first scenario includes: if the first result is that the target ratio is greater than the preset ratio threshold, determining that the user scenario of the electronic device is the first scenario; or, if the first result is that the target ratio is greater than the preset ratio threshold, and the total number of first key values ​​is greater than the first preset number, determining that the user scenario of the electronic device is the first scenario.

[0043] In this implementation, based on the target ratio, a judgment condition of the total number of first key values ​​is added. This can exclude non-first scenarios where most of the key values ​​are target key values ​​but the total number of key presses is small, reduce misrecognition, and improve the recognition accuracy of the first scenario.

[0044] In a possible implementation, determining the first strategy according to the scenario information of the first scenario includes: determining the first strategy according to the scenario information of the first scenario and a current system operation mode of the electronic device.

[0045] System operating modes can be pre-set by the operating system of an electronic device. Different system operating modes can result in different power consumption, heat dissipation, and noise levels. Examples of system operating modes include quiet mode, performance mode, and aggressive mode.

[0046] In this implementation, 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.

[0047] In one possible implementation, the first strategy includes a correspondence between multiple temperature ranges of a third component in the electronic device and multiple speeds of the fan, wherein the multiple speeds include the third speed; according to the first strategy, adjusting the speed of the fan to the third speed includes: obtaining the current temperature of the third component; based on the first strategy, determining that the temperature range to which the current temperature belongs corresponds to the third speed; and adjusting the speed of the fan to the third speed.

[0048] In this implementation, the fan speed is adjusted based on the fan control strategy, taking into account device temperature. Specifically, when the device temperature is high, the fan speed can be higher, and when the device temperature is low, the fan speed can be lower. This allows the electronic device to approach thermal equilibrium, improves heat dissipation control, and thus enhances the performance of the electronic device.

[0049] In one possible implementation, the first strategy also includes a correspondence between multiple temperature ranges and multiple minimum durations, and the multiple minimum durations include a first target duration. The method also includes: based on the first strategy, determining that the temperature range to which the current temperature belongs corresponds to the first target duration; the time for the fan to operate at the third speed is greater than the first target duration.

[0050] In this implementation, when controlling the fan speed, a minimum duration is set to prevent the fan speed from being adjusted too frequently, thereby preventing unnecessary power loss and excessive disturbance to the user, and improving the stability and reliability of fan control.

[0051] In one possible implementation, in the first strategy, 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, and the second target level is higher than the first target level, then based on the first strategy, determining that the value of the second minimum duration corresponding to the first target level is the first target duration.

[0052] In this implementation, 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.

[0053] In one possible implementation, based on the first application being uninstalled, according to the first key value, determining that the user scenario of the electronic device is the first scenario includes: determining the value of the mark bit; based on the value of the mark bit being the first preset value, determining that the user scenario of the electronic device is the first scenario according to the first key value.

[0054] 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.

[0055] In this implementation, based on the value of the flag bit being the first preset value, it is determined that the running state of the first application is abnormal, and then the user scenario is identified through the key value. That is, whether autonomous heat dissipation control or passive heat dissipation control is performed is determined based on the value of the flag bit. Autonomous heat dissipation control refers to autonomous scene recognition through keyboard data, power or temperature, and heat dissipation control is performed based on the result of autonomous scene recognition. Passive heat dissipation control refers to heat dissipation control based on the user scenario (also called upper-level user scenario) identified by the first application. In this way, even in cases where the first application is uninstalled, fine-grained heat dissipation control can be performed to improve the heat dissipation control effect. 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. In this way, 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.

[0056] In one possible implementation, determining the value of the mark bit includes: sending M heartbeat requests to the first application, and starting a timer corresponding to the heartbeat request when sending each heartbeat request, where M is an integer greater than or equal to 1; determining whether there is a first heartbeat request in the M heartbeat requests based on a heartbeat response message corresponding to the heartbeat request replied by the first application, and the timer, the first heartbeat request refers to a heartbeat request for which no corresponding heartbeat response message is received before the corresponding timer times out; if there is a first heartbeat request in the M heartbeat requests, determining that the value of the mark bit is a first preset value; if there is no first heartbeat request in the M heartbeat requests, determining that the value of the mark bit is a second preset value.

[0057] The first heartbeat request is also called a heartbeat request in response to an abnormality.

[0058] In this implementation, 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 has communication anomalies 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, in this case, the method performs autonomous heat dissipation control, which can improve the accuracy of heat dissipation control. In addition, 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.

[0059] In a possible implementation, based on the heartbeat response message corresponding to the heartbeat request replied by the first application and the timer, determining whether there is a first heartbeat request in M ​​heartbeat requests includes: when the first timer reaches its timing duration, determining whether there is a first heartbeat response message, the first timer is the timer corresponding to the earliest heartbeat request, the first heartbeat response message is the heartbeat response message corresponding to the earliest heartbeat request, and the earliest heartbeat request is the heartbeat request sent earliest among the M heartbeat requests; if there is no first heartbeat response message, determining whether the first heartbeat request exists in the M heartbeat requests; if there is a first heartbeat response message, determining whether the M timers corresponding to the M heartbeat requests are traversed; if the M timers are not traversed, using the second timer as the first timer, returning to execute when the first timer reaches its timing duration, determining whether there is a first heartbeat response message; the second timer is the timer corresponding to the second heartbeat request, the second heartbeat request is the heartbeat request sent after the first heartbeat request and adjacent to the first heartbeat request; if all M timers are traversed, determining that the first heartbeat request does not exist in the M heartbeat requests.

[0060] 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.

[0061] In a possible implementation, based on the heartbeat response message corresponding to the heartbeat request replied by the first application and the timer, it is determined whether 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 between the first and second heartbeat response messages is the time difference between the first and second heartbeat response messages received, the third heartbeat request is the heartbeat request corresponding to the third heartbeat response message, and the third timer is the timer corresponding to the third heartbeat request; if the second time difference is greater than the timing duration of the third timer, it is determined that the first heartbeat request exists in the M heartbeat requests; if the second time difference is less than or equal to the timing duration of the third timer, it is determined whether the M heartbeat response messages corresponding to the M heartbeat requests are traversed; if the M heartbeat response messages are not traversed, the next received heartbeat response message is taken as the second heartbeat response message, and execution is returned. 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; if the M heartbeat response messages are traversed, it is determined that the first heartbeat request does not exist in the M heartbeat requests.

[0062] This implementation method can simply, quickly and accurately determine whether there is a first heartbeat request among M heartbeat requests by looping through the heartbeat response messages within the maximum detection time, thereby improving the accuracy of heartbeat detection, thereby improving the accuracy of the mark bit value, and further improving the accuracy of heat dissipation control.

[0063] In a possible implementation, 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.

[0064] It is understood that, during the fourth time period, only the second area of ​​the keyboard is tapped, and the first area of ​​the keyboard is not tapped. During the fourth time period, the focus window may or may not change. During the fourth time period, the first application is in an uninstalled state.

[0065] 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. In this case, 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.

[0066] In this implementation, after the first application is uninstalled, when the second area of ​​the keyboard is tapped, the user scenario can be identified based on the data inputted on the keyboard, and based on the user scenario, the fan speed that matches the user scenario is determined, and the fan is controlled based on the fan speed to dissipate heat for the electronic device in a timely manner and prevent the fan from being too noisy when it is not necessary. In other words, this method does not need to rely on the first application, and even when the first application is abnormal, it can still achieve refined heat dissipation control and improve the effect of heat dissipation control. Moreover, without relying on the first application, this method can identify multiple user scenarios and adjust the fan speed to multiple speeds (such as the third speed and the sixth speed).

[0067] In one possible implementation, 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.

[0068] For example, if a user selects content "x" in an application and presses the Ctrl, C, Ctrl, and V keys in the second area of ​​the keyboard, the content "x" will be displayed on the screen.

[0069] In one possible implementation, after uninstalling the first application, within a fourth time period, while the second area of ​​the keyboard is tapped, 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.

[0070] Specifically, when 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.

[0071] In one possible implementation, after the second time period, within a fourth time period, while the second area of ​​the keyboard is tapped, 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.

[0072] The second scene may be, for example, an office scene.

[0073] In this implementation, 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.

[0074] In one possible implementation, based on the second key value, determining that the user scenario of the electronic device is the second scenario includes: separately 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 ​​correspond to the fourth area of ​​the keyboard, and the fourth area at least partially overlaps with the second area of ​​the keyboard; determining the value of a first prediction factor based on the number of first-category key values; determining the value of a second prediction factor based on the number of second-category key values; determining the value of a third prediction factor based on the number of third-category key values; performing weighted summation on the values ​​of the first prediction factor, the second prediction factor, and the third prediction factor to obtain a prediction value; determining whether the prediction value is greater than a preset threshold to obtain a second result; and determining that the user scenario of the electronic device is the second scenario based on the second result.

[0075] It can be understood that 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.

[0076] In this implementation, 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.

[0077] In one possible implementation, based on the second result, 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.

[0078] In this implementation, based on the predicted value, 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.

[0079] In one possible implementation, 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.

[0080] 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.

[0081] The first value may be, for example, 1, and the second value may be, for example, 0.

[0082] In one possible implementation, 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.

[0083] In one possible implementation, during a first time period, when the first area or the second area of ​​the keyboard is tapped, 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.

[0084] During the first time period, 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.

[0085] In one possible implementation, the electronic device further includes an embedded controller (EC), and after the 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 scene information of the fifth scenario to the EC; the EC determines a fifth strategy based on the scene 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.

[0086] In this implementation, passive cooling control is performed by the EC. It is understood that autonomous cooling control can also be performed by the EC. The EC is located in the firmware layer, running at the bottom of the operating system and is not affected by the upper operating system layers. Therefore, cooling control performed by the EC is less susceptible to changes in the upper operating system layers, improving the reliability and stability of cooling control.

[0087] In a second aspect, 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.

[0088] In a third aspect, 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.

[0089] In a fourth 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.

[0090] Optionally, the chip system also includes a memory, and the memory is connected to the processor via circuits or wires.

[0091] Further optionally, the chip also includes a communication interface.

[0092] In a fifth aspect, the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the processor executes any one of the methods in the technical solution of the first aspect.

[0093] In a sixth aspect, the present application provides a computer program product, which includes: a computer program code, which, when the computer program code runs on an electronic device, enables the electronic device to execute any one of the methods in the technical solution of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0094] FIG1 is a schematic diagram of a heat dissipation control process provided by an embodiment of the present application;

[0095] FIG2 is a schematic structural diagram of an electronic device 100 provided in an embodiment of the present application;

[0096] FIG3 is a block diagram of the software and hardware structure of an electronic device 100 provided in an embodiment of the present application;

[0097] FIG4 is a block diagram of software and hardware structures of another electronic device 100 provided in an embodiment of the present application;

[0098] FIG5 is a schematic diagram of module interaction of a heat dissipation control method provided in an embodiment of the present application;

[0099] FIG6 is a schematic diagram of module interaction of another heat dissipation control method provided in an embodiment of the present application;

[0100] FIG7 is a schematic diagram of a state detection process according to an embodiment of the present application;

[0101] FIG8 is a flowchart of another example of status detection provided in an embodiment of the present application;

[0102] FIG9 is a schematic diagram showing the principle of autonomous user scene recognition according to an embodiment of the present application;

[0103] FIG10 is a flow chart of a heat dissipation control method according to an embodiment of the present application;

[0104] FIG11 is a schematic diagram of an example of an autonomous user scenario recognition process provided by an embodiment of the present application;

[0105] FIG12 is a schematic diagram of a workflow for upper-layer user scenario recognition according to an embodiment of the present application;

[0106] FIG13 is a schematic diagram of module interaction for upper-layer user scenario recognition according to an embodiment of the present application;

[0107] FIG14 is a schematic diagram of an interface provided in an embodiment of the present application;

[0108] FIG15 is a schematic structural diagram of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0109] The technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings in the embodiments of the present application. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships can exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, "multiple" means two or more than two.

[0110] In the following, the terms "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.

[0111] In addition, the terms "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. In this application, "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".

[0112] 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. Thus, 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.

[0113] To better understand the embodiments of the present application, the terms or concepts that may be involved in the embodiments are explained below.

[0114] Strategy refers to a set of solutions that can achieve the goal. The embodiments of the present application involve heat dissipation control strategies, power control strategies, brightness control strategies and fan control strategies, etc. 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.

[0115] 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 with.

[0116] Focus mode can be used to determine how the mouse focuses on a window. Generally, there are three focus modes:

[0117] (1) Click to focus. In this mode, the window clicked by the mouse becomes the focus. That is, when the mouse clicks anywhere on a window that can be the focus, the window is activated, and the window is placed on the front of all windows and receives keyboard input. When the mouse clicks on another window, the window is no longer the focus.

[0118] (2) Focus follows mouse. In this mode, 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 windows. When the mouse moves out of the range of the window, the window is no longer focused.

[0119] (3) 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 can activate the window without clicking anywhere in the window and receive keyboard input, but the window is not necessarily brought to the front of all windows. Unlike focus follow mouse, the focus does not change when the mouse moves out of the window range. The system focus only changes when the mouse moves to another window that can be focused.

[0120] The technical issues of this application are explained below.

[0121] The effect of 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. During use, it was found that when the operating status of the PC Manager APP (or Computer Manager APP, etc.) installed in the electronic device is abnormal, the heat dissipation control effect of the electronic device is not good. 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.

[0122] Analysis of the cause of this phenomenon revealed that 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. However, 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.

[0123] The following describes the heat dissipation control process by taking the fan control strategy as an example in combination with the structure of the electronic device. For example, Figure 1 is a schematic diagram of a heat dissipation control process provided in an embodiment of the present application. As shown in Figure 1, the electronic device may include a system on chip (SoC), an embedded controller (EC) and a fan. The number of fans may be one or more. In the embodiment of the present application, the number of fans is two, represented by fan 1 and fan 2, for example. Components such as a CPU and a 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).

[0124] As shown in Figure 1, in one implementation, 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.

[0125] In other implementations not shown in Figure 1, 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.

[0126] It can be understood that in the embodiment of the present application, the PC Manager APP is only used as an example. In actual applications, 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.

[0127] Both of the aforementioned implementations can control fan speed based on user scenarios, improving cooling control and meeting user needs. However, regardless of which implementation is used, the EC's fan speed control relies on output from the PC Manager app. Therefore, if the PC Manager app is operating abnormally, the EC cannot obtain the fan control policy, resulting in an inability to control fan speed. As shown in Figure 1, as one possible implementation, when the EC cannot receive user scenarios or fan control policies from the PC Manager app, it can select the default control policy to control Fan 1 and Fan 2. However, the default control policy provides coarse-grained control of fan speed. For example, if the default control policy sets the fan speed to a fixed value, the fan speed cannot adapt to user scenarios, resulting in thermal equilibrium failure or excessive noise. For example, if the PC Manager app is operating abnormally, the default control policy will control the fan to a fixed speed in both gaming and office scenarios. However, in gaming scenarios, electronic devices generate more heat, requiring the fan to run at a higher speed to meet faster cooling requirements. Therefore, if the fan runs at a fixed speed in a gaming scenario, the heat dissipation is weak and untimely, resulting in overheating of the device and affecting device performance. In office scenarios, electronic equipment generates less heat and has a small heat dissipation demand, and users may want the environment to be as quiet as possible. In this case, the fan needs to run at a lower speed. Therefore, if the fan runs at a fixed speed in an office scenario, the fan noise is louder and the user experience is poor. It can be understood that 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 based on the CPU temperature.

[0128] It should be noted that the abnormal running state of the PC Butler APP may also cause other heat dissipation control strategies to fail to execute as expected, thereby resulting in poor heat dissipation control of electronic devices. For example, when the PC Butler APP is running abnormally, it cannot match the corresponding power control strategy according to the user scenario, and the electronic device cannot adjust the operating frequency of the central processing unit (CPU) or graphics processing unit (GPU) according to the scenario, resulting in poor heat dissipation control. For another example, when the PC Butler APP is running abnormally, it cannot match the corresponding brightness control strategy according to the user scenario, and the screen cannot adjust the brightness according to the scenario, resulting in poor heat dissipation control.

[0129] Based on the above analysis, 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.

[0130] The heat dissipation control method provided in the embodiment of the present application can be applied to electronic devices such as notebook computers, PCs, and ultra-mobile personal computers (UMPCs). The embodiment of the present application does not impose any restrictions on the specific type of electronic devices.

[0131] For example, Figure 2 is a schematic diagram of the structure of an electronic device 100 provided in an embodiment of the present application. As shown in Figure 2, 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.

[0132] It should be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device 100. In other embodiments, 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.

[0133] The processor 110 may include one or more processing units, for example: 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), etc. Among them, the application processor (AP) may be integrated with a CPU. Of course, the AP can also be directly replaced with a CPU. It should be understood that different processing units can be independent devices or integrated into one or more processors. For example, 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. In other words, the processor 110 may include an SoC and an EC, etc.

[0134] The controller may be the nerve center and command center of the electronic device 100. The controller may generate an operation control signal according to the instruction operation code and the timing signal to complete the control of fetching and executing instructions.

[0135] Processor 110 may also include a memory for storing instructions and data. In some embodiments, 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.

[0136] In some embodiments, 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.

[0137] It is understood that 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. In other embodiments, the electronic device 100 may also adopt different interface connection methods from the above embodiments, or a combination of multiple interface connection methods.

[0138] 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.

[0139] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 and provides power to the processor 110, the internal memory 121, the external memory, the display 160, and the wireless communication module 150. In some embodiments, the power management module 141 and the charging management module 140 can also be provided in the same device.

[0140] 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), etc. For example, in an embodiment of the present application, the electronic device 100 can establish a Bluetooth connection with a terminal device (such as a wireless headset 100) through the wireless communication module 150.

[0141] 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.

[0142] 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.

[0143] 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.

[0144] 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.

[0145] 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. For example, in an embodiment of the present application, 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.

[0146] Among them, 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. In addition, the internal memory 121 may include a random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. Optionally, the random access memory may be, for example, a double data rate synchronous dynamic random access memory (DDR). The flash memory device may be, for example, a solid state disk (SSD).

[0147] A user can input data into processor 110 via input device 180, which processes the data and responds. Optionally, 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.

[0148] The sensor 190 may include a temperature sensor 191 , a power sensor 192 , a fingerprint sensor 193 , and the like.

[0149] The temperature sensor 191 is used to detect temperature. Optionally, in embodiments of the present application, the temperature sensor 191 may include an ambient temperature sensor, an SoC temperature sensor, an SSD temperature sensor, a DDR temperature sensor, a charger temperature sensor, and a battery temperature sensor. The ambient temperature sensor is used to collect ambient temperature. The SoC temperature sensor can be deployed on or near the SoC to collect the SoC temperature. The SDD temperature sensor can be deployed on or near the SSD to collect the SDD temperature. The DDR temperature sensor can be deployed on or near the DDR to collect the DDR temperature. The charger temperature sensor can be deployed on or near the charging management module 140 to collect the charging management module 140 temperature. The battery temperature sensor can be deployed on or near the battery 142 to collect the battery 142 temperature. Optionally, the temperature sensor 191 may be a negative temperature coefficient (NTC) device. Each temperature sensor 191 can communicate with the EC via an I2C interface or SPI, for example, to transmit the collected temperature to the EC.

[0150] Power sensor 192 is used to detect the operating power of devices, such as an SoC, SSD, DDR, wireless communication module 150, display 160, and audio power amplifier (PA). Optionally, 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, transmitting the collected power to the EC.

[0151] The fingerprint sensor 193 is used to collect fingerprints. The electronic device 100 can use the collected fingerprint characteristics to implement fingerprint unlocking, access application locks, etc.

[0152] The software operating system of the electronic device 100 can run on a processor, such as a SoC or EC. Alternatively, 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.

[0153] For example, FIG3 is a block diagram of the software and hardware structure of the electronic device 100 according to an embodiment of the present application. The layered architecture divides the software into several layers, each with a clear role and division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Windows system is divided into user state and kernel state. Among them, the user state includes the application layer and the subsystem dynamic link library. The kernel state is divided from bottom to top into the firmware layer, the hardware abstraction layer (HAL), the kernel and the driver layer, and the executive body. For ease of explanation, FIG3 also shows the hardware layer of the electronic device 100.

[0154] As shown in Figure 3, 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. In one embodiment, 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.

[0155] The environment subsystem can present certain subsets of basic executive system services to applications in a specific form, providing an execution environment for the applications.

[0156] 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.

[0157] The subsystem dynamic link library includes an API module, which includes the Windows API, the Windows native API, etc. Among them, the Windows API and the Windows native API can both 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. For example, the Windows API may include user.dll and kernel.dll, and the Windows native API may include ntdll.dll. Among them, user.dll is the Windows user interface interface, which 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 the memory, preventing other programs from occupying this memory area.

[0158] 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.

[0159] The process manager is used to create and terminate processes and threads.

[0160] The virtual memory manager implements "virtual memory". The virtual memory manager also provides basic support for the cache manager.

[0161] The Security Reference Monitor enforces security policy on the local computer, protects operating system resources, and performs runtime object protection and monitoring.

[0162] The I / O manager performs device-independent input / output and further processes calls to appropriate device drivers.

[0163] The power manager manages power state changes for all devices that support power state changes.

[0164] 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.

[0165] 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.

[0166] The kernel and driver layer include the kernel and device drivers.

[0167] The kernel is an abstraction of the processor architecture, isolating the executive from differences in processor architecture to ensure system portability. The kernel can perform thread scheduling and scheduling, trap handling and exception scheduling, interrupt handling and scheduling, etc.

[0168] Device drivers run in kernel mode and serve as the interface between the I / O system and the associated hardware. These drivers can include graphics drivers, Intel DTT drivers, mouse drivers, audio and video drivers, camera drivers, and keyboard drivers. For example, a graphics driver drives the GPU, while an Intel DTT driver drives the CPU.

[0169] 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.

[0170] The firmware layer may include a basic input and output system (BIOS), which is a set of programs solidified into a read-only memory (ROM) chip on the computer motherboard. It stores the computer's most important basic input and output programs, self-test programs after power-on, and system self-startup programs. It can read and write specific information about system settings from a complementary metal oxide semiconductor (CMOS). Its main function is to provide the computer with the lowest-level and most direct hardware settings and control. For example, the Intel DTT driver can send instructions to the CPU through the BIOS. Optionally, the firmware layer may also include a thermal noise balancing engine. The thermal noise balancing engine is used to control the heat dissipation of electronic devices so that the electronic devices tend to thermal balance and reduce the noise generated by the fan.

[0171] It can be understood that in the above software architecture, the application layer, subsystem dynamic link library, executive body, kernel and driver layer, as well as the BIOS in the firmware layer can run in the SoC, and the thermal noise balance engine can run in the EC.

[0172] 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.

[0173] In an embodiment of the present application, 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. Optionally, the thermal noise balancing process may be created when the operating system starts.

[0174] The autonomous recognition module is used to identify user scenarios based on data provided by the hardware layer. For ease of distinction, in the following embodiments, 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.

[0175] 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.

[0176] The passive decision module is used to determine the fan control strategy (called the passive table) based on the upper-layer user scenario transmitted from the upper layer. The fan control module can determine the fan speed based on the passive table or the autonomous table and adjust the fan speed accordingly.

[0177] For ease of distinction, the mode in which autonomous user scenarios are identified, autonomous cooling strategies are determined based on these scenarios, and cooling is controlled according to these strategies is referred to as autonomous cooling mode. The mode in which a passive table is determined based on upper-layer user scenarios and cooling is controlled according to these passive tables is referred to as passive cooling mode. In other words, EC cooling modes can include both autonomous and passive cooling modes, and ECs can operate in both autonomous and passive cooling modes.

[0178] The status detection module is used to detect the running status of the preset APP and assign a value to the preset status flag based on the running status.

[0179] 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.

[0180] It should be noted that the embodiments of the present application are only illustrated using the Windows system as an example. In other operating systems (such as the Android system, the IOS system, etc.), as long as the functions implemented by each functional module are similar to those of the embodiments of the present application, the solutions of the present application can also be implemented.

[0181] For ease of understanding, the following embodiments of the present application will take an electronic device having the structure shown in Figures 2 and 3 as an example, and combine the accompanying drawings and application scenarios to specifically explain the heat dissipation control method provided in the embodiments of the present application.

[0182] In order to facilitate understanding of the heat dissipation control method provided in the embodiment of the present application, the software and hardware structures involved in the embodiment of the present application are simplified in combination with the above-mentioned Figure 3. As shown in Figure 4, 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. Among them, 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.

[0183] 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:

[0184] S101. 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.

[0185] 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.

[0186] 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. Of course, in some other embodiments, 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. Optionally, 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.

[0187] Specifically, if the heartbeat of the preset APP meets the preset conditions, indicating that the preset APP is running normally, 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. The specific process is described in the subsequent embodiments.

[0188] It is understandable that 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. Optionally, 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.

[0189] It should be understood that step S101 can be executed continuously to continuously monitor the running status of the preset APP. Here, "continuously" can be understood as multiple times that can be discontinuous in time. For example, 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. In this embodiment, the process of executing step S101 once is also referred to as one round of heartbeat detection.

[0190] Step S101 above describes the process of detecting the status of a preset app. Steps S102 through S108 below describe the process of identifying the upper-level user scenario, determining the passive table based on the upper-level user scenario, and controlling the fan speed using the passive table. This is the implementation of the heat dissipation control method when the EC operates in passive decision-making cooling mode. The process described in steps S102 through S108 can also be referred to as the passive cooling control process.

[0191] 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.

[0192] Referring to Figure 5, the passive heat dissipation control process may include:

[0193] S102: The preset APP identifies the user scenario of the electronic device and obtains the upper-level user scenario.

[0194] Optionally, upper-level user scenarios may include, for example, game scenarios, meeting scenarios, office scenarios, video scenarios, social scenarios, browser scenarios, etc.

[0195] Optionally, 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. For example, scene number V01 can indicate that the upper-level user scenario is a video scenario. For another example, scene number V02 can indicate that the upper-level user scenario is a game scenario.

[0196] Optionally, 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). Exemplarily, the preset period can be, for example, 2 minutes (min). At time t1, 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. After 2 minutes, that is, at time t1+2 minutes, the preset APP identifies the upper-level user scene again. Assuming that the recognition result is a game scene (scene number is V02), the preset APP assigns "V02" to current scene 1.

[0197] The process of identifying the upper-level user scenario is detailed in the subsequent embodiments.

[0198] S103. When the upper user scene changes, the preset APP sends scene information of the changed upper user scene to the kernel (the scene information of the changed upper user scene is hereinafter referred to as first scene information).

[0199] Optionally, the preset APP can determine whether the value of current scene 1 after assignment is consistent with the value before assignment each time before, after, or while assigning a value to current scene 1. If the value of current scene 1 is consistent before and after assignment, it is determined that the upper-level user scene has not changed; if the value of current scene 1 is inconsistent before and after assignment, it is determined that the upper-level user scene has changed. Continuing with the above example, at time t1+2min, before assigning "V02" to current scene 1, the value of current scene 1 is "V01", and after assigning "V02" to current scene 1, the value of current scene 1 is "V02". "V01" and "V02" are inconsistent, so the upper-level user scene has changed, and the preset APP sends the scene information of the changed upper-level user scene (i.e., V02) to the kernel.

[0200] Optionally, the preset APP may send the first scene information to the kernel via a WMI plug-in in the executable body.

[0201] S104: The core sends the first scene information to the passive decision module in the thermal noise balancing engine.

[0202] Optionally, the kernel may first send the first scenario information to the BIOS, and then the BIOS sends the information to the passive decision module in the thermal noise balancing engine.

[0203] S105. After receiving the first scenario information, the passive decision module determines whether the value of the status flag is true; if so, execute step S106; if not, do not perform any operation.

[0204] As described in step S104 above, the kernel sends the first scenario information to the passive decision module. Upon receiving the first scenario information, the passive decision module triggers a check on the status flag value, specifically, whether the status flag value is true. If the status flag value is true, indicating that the pre-set app is operating normally, the kernel determines the passive table that matches the changed upper-level user scenario based on the first scenario information and controls the fan speed based on the passive table, effectively entering the passive decision cooling mode. If the status flag value is false, indicating that the pre-set app is operating abnormally, the EC does not enter the passive decision cooling mode.

[0205] S106. The passive decision module determines a passive table according to the first scenario information.

[0206] As a possible implementation, the passive decision module can determine the passive table that matches the changed upper-layer user scenario based on a preset correspondence. For example, the correspondence between the scenario information of the upper-layer user scenario and the passive table can be shown in Table 1.

[0207] Table 1

[0208] For example, if the changed upper user scene is a game scene and the first scene information is V02, then according to Table 1, it can be determined that the passive table is table 1-2.

[0209] It is understood that the content in Table 1 is only an example used to illustrate the correspondence between upper-level user scenarios and passive tables. It does not represent actual data and does not constitute any limitation on the technical solution of this application. The same applies to other tables, figures, and text examples in the embodiments of this application, which will not be repeated here.

[0210] As another possible implementation, the passive decision module can also determine a matching passive table based on the changed upper-layer user scenario and other information, such as the current system load. The current system load can be detected by a pre-set app or other upper-layer module and then sent to the passive decision module. For example, the passive decision module can determine the passive table based on the corresponding relationships shown in Table 2.

[0211] Table 2

[0212] For example, if the changed upper user scene is a game scene, the first scene information is V02, and the current system load is "medium", then according to Table 2, it can be determined that the passive table is table 1-5.

[0213] Optionally, in some other embodiments, the passive decision module may also make decisions based on other information, such as the system operation mode, when determining the passive table. This is just an exemplary description.

[0214] S107 : The passive decision module sends the passive table to the fan control module.

[0215] Optionally, the passive decision module may write a passive table into a preset object that the fan control module can access and read values ​​from.

[0216] S108 : The fan control module controls the fan speed according to the received passive table.

[0217] For example, a passive table 1-N may be shown in Table 3 below:

[0218] Table 3 Passive table 1-N

[0219] Specifically, after receiving the passive table 1-N, the fan control module obtains the current SoC temperature. Afterwards, the fan control module can query the range of the current SoC temperature in the passive table 1-N and determine the fan speed corresponding to the temperature range (called the target speed). Then, the fan speed is adjusted to the target speed. Among them, the SoC temperature can be obtained from the NTC (called SoC_NTC) deployed on or around the SoC. For example, when the current SoC temperature is 45°C, according to Table 3, the temperature falls within the temperature range [44, 46), so the fan control module controls the speed of fan 1 to 2530 rpm and controls the speed of fan 2 to 2330 rpm.

[0220] It should be noted that Table 3 is only an example of a passive table and is not intended to be limiting. In actual applications, the passive table may include more or less content than Table 3. For example, the passive table may also include the SSD temperature range, the ambient temperature range, etc.

[0221] The following 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.

[0222] During the autonomous heat dissipation control process, it can be performed based on the value assigned to the status flag bit in step S101. However, the autonomous heat dissipation control process and the status detection process of the preset APP can be executed in parallel. At the same time, the autonomous heat dissipation control process and the passive heat dissipation control process can also be executed in parallel. In short, the status detection process of the preset APP, the autonomous heat dissipation control process and the passive heat dissipation control process, these three processes can be executed in parallel and can be executed separately by three different threads without being limited by the order. Please continue to refer to Figure 5, the autonomous heat dissipation control process includes:

[0223] S109 , 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.

[0224] S110 , the autonomous identification module periodically determines whether the value of the status flag is false; if so, executes step S111 ; if not, does not perform any operation.

[0225] Optionally, 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.

[0226] S111 . An autonomous identification module identifies a user scenario of the electronic device according to target data to obtain an autonomous user scenario.

[0227] Optionally, 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.

[0228] Optionally, different autonomous user scenarios can be distinguished by scenario information. 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. For example, scenario number S01 can be used to indicate that the autonomous user scenario is a gaming scenario. For another example, scenario number S02 can be used to indicate that the autonomous user scenario is an office scenario.

[0229] Optionally, each time the value of the status flag is determined to be false, 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). For example, at time t3, 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. After 3 minutes, that is, at time t3+3 minutes, the autonomous identification module again determines that the value of the status flag is false, and again triggers the autonomous identification module to identify the autonomous user scene. Assuming that the recognition result is an office scene (scene number is S02), the autonomous identification module assigns "S02" to current scene 2.

[0230] The process of the autonomous identification module identifying the autonomous user scenario is detailed in the subsequent embodiments.

[0231] S112. When the autonomous user scenario changes, 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).

[0232] Optionally, the autonomous recognition module can determine whether the value of current scene 2 after assignment is consistent with the value before assignment each time before, after, or while assigning a value to current scene 2. If the value of current scene 2 is consistent before and after assignment, it is determined that the autonomous user scene has not changed; if the value of current scene 2 is inconsistent before and after assignment, it is determined that the autonomous user scene has changed. Continuing with the above example, at time t3+3min, before assigning the value "S02" to current scene 2, the value of current scene 2 is "S01", and after assigning the value "S02" to current scene 2, the value of current scene 2 is "S02". "S01" and "S02" are inconsistent, so 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.

[0233] S113. The autonomous decision-making module determines an autonomous heat dissipation strategy based on the second scenario information.

[0234] The autonomous cooling strategy includes autonomous tables.

[0235] As in step S112 above, the autonomous identification module sends the second scenario information to the autonomous decision module. After receiving the second scenario information, 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.

[0236] As a possible implementation, the autonomous decision module can determine the autonomous table that matches the changed autonomous user scenario based on a preset correspondence. For example, the correspondence between the scenario information of the autonomous user scenario and the autonomous table can be as shown in Table 4.

[0237] Table 4

[0238] For example, if 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.

[0239] As another possible implementation, the autonomous decision-making module can also match the corresponding autonomous table based on the changed autonomous user scenario in combination with other information. For example, 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. In 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. In 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.

[0240] Optionally, users can switch the system operating mode using 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.

[0241] Exemplarily, the autonomous decision module may determine the autonomous table based on the corresponding relationship shown in Table 5.

[0242] Table 5

[0243] For example, if the changed autonomous user scene is a video scene, the second scene information is S02, and the current system operation mode is the performance mode, then according to Table 5, it can be determined that the autonomous table is table 2-11.

[0244] It is understood that when the preset app sends the upper-level user scenario to the thermal-noise balancing engine in the EC, it can also send the system operating mode. Optionally, the system operating mode can be sent to the autonomous decision module in the thermal-noise balancing engine. When determining the autonomous table, 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. In short, in the autonomous cooling 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.

[0245] In autonomous cooling 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.

[0246] 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.

[0247] S114 , the autonomous decision module sends the autonomous table to the fan control module.

[0248] Optionally, 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.

[0249] In addition, the autonomous decision-making module can also send other cooling strategies to corresponding modules, which will then execute the corresponding cooling strategies. For example, 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. For another example, 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.

[0250] S115 : The fan control module controls the fan speed according to the received autonomous table.

[0251] Optionally, 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.

[0252] For example, a certain autonomous table 1-N can be shown in Table 6 below, where NA is the abbreviation of not applicable, which means not applicable and is used to characterize 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.

[0253] Table 6 Autonomous table 2-N

[0254] 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.

[0255] It should be noted that Table 6 above is only an example of a passive table and is not intended to be limiting. In actual applications, the passive table may include more or less information than Table 6. For example, the passive table may also include one or more of the battery temperature range, the ambient temperature range, or the charger temperature range.

[0256] As shown in Table 6, 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.

[0257] The minimum duration includes minimum duration 1 and minimum duration 2. In a table 2-N, the minimum duration 1 corresponding to any level n indicates the minimum duration of fan operation controlled at the speed corresponding to level n when the fan control strategy is switched from another table to level n in table 2-N. Alternatively, the minimum duration 1 corresponding to level n in table 2-N indicates the minimum duration of fan operation controlled at the speed corresponding to level n when the fan control strategy is increased from a lower level (a level less than n) in table 2-N to level n.

[0258] For example, at time T1, the fan control strategy switches from a certain level in table 2-X to level 1 in table 2-N. The fan control module then controls the fan operation according to the fan speeds corresponding to level 1 in table 2-N (Fan 1 at 2600 rpm and Fan 2 at 2500 rpm). Furthermore, this situation involves the fan control strategy switching from another table to level 1 in table 2-N. Therefore, based on the minimum duration 1 (5 minutes) corresponding to level 1 in table 2-N, the fans must be controlled to operate at the fan speed corresponding to level 1 in table 2-N for at least 5 minutes before they can be adjusted to other levels. That is, Fan 1 must be controlled to operate at 2600 rpm and Fan 2 at 2500 rpm for at least 5 minutes before they can be adjusted to other speeds.

[0259] Continuing with this example, at time T2, the fan control module has not received a new table, meaning the table has not been switched. According to Table 2-N shown in Table 6, the level matched based on the current SoC temperature and the virtual case temperature is Level 2 in Table 2-N. This means the level needs to be increased from Level 1 in Table 2-N to Level 2 in Table 2-N. Upon determining that the duration of Level 1 in Table 2-N exceeds 5 minutes, the fan control module 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. Therefore, based on the minimum duration 1 (6 minutes) corresponding to Level 2 in Table 2-N, the fans need to be controlled to 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.

[0260] In a table 2-N, 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.

[0261] Continuing with the above example, at time T3 after time T2, the fan control module has not received a new table, meaning the table has not been switched. According to Table 2-N shown in Table 6, the level matched based on the current SoC temperature and the virtual case temperature is Level 1 in Table 2-N. This means the level needs to be lowered from Level 2 in Table 2-N to Level 1 in Table 2-N. If the fan control module determines that the duration of Level 2 in Table 2-N has exceeded 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). Furthermore, in this case, since the level has been lowered from Level 2 in Table 2-N to Level 1, the fan control module must control the fans to 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 adjusting to another level. That is, fan 1 runs at 2600 rpm and fan 2 runs at 2500 rpm for at least 4 minutes before they can be adjusted to other speeds.

[0262] It should be noted that the execution order of the above steps is not limited. For example, 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.

[0263] In this embodiment, 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.

[0264] In the above embodiment, 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. As another implementation method, 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. In this case, 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.

[0265] In the heat dissipation control method provided in this embodiment, 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. In this passive heat dissipation mode, 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. When the pre-set app is operating abnormally, the EC operates in the autonomous heat dissipation mode, performing autonomous heat dissipation control. In this autonomous heat dissipation mode, 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. In other words, regardless of whether the pre-set app is operating normally, this method can perform fine-grained heat dissipation control based on the user scenario, without relying on the pre-set app's operating status. This improves the effectiveness and reliability of heat dissipation control, thereby enhancing the user experience.

[0266] As a possible implementation method, the above steps S101 to S108 may not be executed, and only S109 to S115 may be executed. In other words, it is also possible not to perform status detection on the preset APP, nor to perform passive heat dissipation control, but only to perform autonomous heat dissipation control. In this way, the EC can perform fine-grained heat dissipation control based on user scenarios completely autonomously, without relying on the preset APP, and without being affected by the preset APP, thereby improving the effect and reliability of heat dissipation control, and thus improving user experience. Moreover, the EC is located in the firmware layer, running at the bottom layer of the operating system, and is not affected by the upper layer of the operating system. Therefore, the autonomous user scenario recognition and autonomous heat dissipation control performed by the EC are not easily affected by changes in the operating system (for example, reinstallation, updating, etc.), thereby improving the reliability and stability of heat dissipation control.

[0267] The autonomous heat dissipation control process is further explained below.

[0268] First, the detection process of the preset APP running status is explained.

[0269] For example, FIG6 is a schematic diagram of module interaction of another heat dissipation control method provided in an embodiment of the present application. Referring to FIG6, in one embodiment, the implementation process of the above step "S101, the status detection module in the thermal noise balance engine assigns a value to a preset status flag bit based on whether the heartbeat of a preset APP meets a preset condition" includes:

[0270] S1011. The status detection module in the thermal noise balancing engine sends M heartbeat requests to the kernel.

[0271] M is an integer greater than or equal to 1. For example, M may be 10.

[0272] Optionally, the status detection module may send M heartbeat requests to the kernel in sequence at a preset time interval (e.g., 2 seconds). To facilitate differentiation, the M heartbeat requests may be labeled. For example, the first heartbeat request among the M heartbeat requests may be labeled with tag 1, the second heartbeat request among the M heartbeat requests may be labeled with tag 2, and so on, and the Mth heartbeat request among the M heartbeat requests may be labeled with tag M. It should be understood that this labeling method is merely an example, and in actual applications, other labeling methods may be selected as needed, for example, labeling with English letters, labeling with numbers, or labeling with a combination of letters and English letters, etc.

[0273] Optionally, a timer corresponding to the heartbeat request can be started before, after, or while sending each heartbeat request. The timer's timing duration can be set as needed, for example, it can be 30 seconds (s). The timer is used for timing to detect whether the heartbeat request is responded to within the timing duration. Optionally, the timing durations of the timers corresponding to the various heartbeat requests can be equal or unequal. And the timing duration of the timer can be equal or unequal to the time interval for sending the heartbeat request. In a possible embodiment, the time interval for sending the heartbeat request is less than the timing duration of each timer.

[0274] Optionally, the timer may be marked according to the mark of the corresponding heartbeat request. Optionally, the mark of the timer and the mark of the corresponding heartbeat request may be the same or different. If the mark of the timer and the mark of the corresponding heartbeat request are different, a corresponding relationship between the mark of the timer and the mark of the heartbeat request may be established.

[0275] S1012: The kernel forwards M heartbeat requests to a preset APP.

[0276] S1013. Under normal operation, after receiving each heartbeat request, the preset APP replies with a corresponding heartbeat response message to the kernel.

[0277] When replying to a heartbeat response message, the preset APP may also tag the heartbeat response message according to the tag of the corresponding heartbeat request. Optionally, the tag of the heartbeat response message and the corresponding heartbeat request may be the same. For example, the tag of the heartbeat response message corresponding to the heartbeat request tagged with tag1 is also tag1. In other words, if the tag of the heartbeat response message is tag1, it means that the heartbeat response message is a response message to the heartbeat request tagged with tag1.

[0278] It is understandable that when the preset APP runs abnormally, the preset APP cannot reply the heartbeat response message to the kernel, or cannot reply the heartbeat response message within the timing length of the timer.

[0279] In this embodiment, "normal operation of the preset app" means that the preset app itself is running normally. "Abnormal operation of the preset app" means that the preset app itself is running abnormally. Abnormal operation of the preset app itself may include, but is not limited to, the preset app not running, or the preset app process being stuck, frozen, or suspended.

[0280] S1014. The kernel forwards the heartbeat response message to the status detection module in the thermal noise balancing engine.

[0281] S1015. The status detection module determines whether there is a heartbeat request with an abnormal reply among the M heartbeat requests; if there is a heartbeat request with an abnormal reply, execute step S1016; if there is no heartbeat request with an abnormal reply, execute step S1017.

[0282] S1016. The status detection module assigns a value of false to the status flag bit and returns to execute step S1011.

[0283] S1017: The status detection module assigns a value of true to the status flag bit and returns to execute step S1011.

[0284] As in step S1011 above, when a heartbeat request is sent, the status detection module may start a timer corresponding to the heartbeat request. It should be understood that there is a one-to-one correspondence between M heartbeat requests and M timers, and a one-to-one correspondence between M heartbeat requests and M heartbeat response messages. Therefore, there is also a one-to-one correspondence between M timers and M heartbeat response messages.

[0285] The "preset condition" in step S101 above can be understood in this embodiment as "no heartbeat request with an abnormal reply exists among the M heartbeat requests." That is, if no heartbeat request with an abnormal reply exists among the M heartbeat requests, the pre-set condition is satisfied, and the status flag is assigned a value of true. If no heartbeat request with an abnormal reply exists among the M heartbeat requests, the pre-set condition is not satisfied, and the status flag is assigned a value of false.

[0286] Optionally, for a heartbeat request, abnormal responses include no response and response timeout. No response means that the heartbeat response message corresponding to the heartbeat request has not been received. A response timeout means that the heartbeat response message corresponding to the heartbeat request has been received, but the response message was received after the corresponding timer has timed out. In other words, a heartbeat request that is not responded to or whose response times out is called a heartbeat request with an abnormal response. Conversely, a heartbeat request that is responded to and whose response times out is called a heartbeat request with a normal response.

[0287] As a possible implementation, the state detection module can detect whether the heartbeat request is a heartbeat request that replies to an abnormality when the timer corresponding to each heartbeat request reaches the timing duration. If the heartbeat response message corresponding to a certain heartbeat request is not received when the timer corresponding to the heartbeat request reaches the timing duration, it indicates that the heartbeat request is a heartbeat request that replies to an abnormality, indicating that the running state of the preset APP is abnormal, then the state flag is assigned a value of false, and the execution of step S1011 is returned to resend M heartbeat requests, that is, this round of heartbeat detection ends, and enters the next round of heartbeat detection. If the heartbeat response message corresponding to the heartbeat request is determined to have been received when the timer corresponding to the heartbeat request reaches the timing duration, indicating that the heartbeat request is a heartbeat request that replies to normal, then when the next timer reaches the timing duration, the corresponding heartbeat response message is detected to indicate whether it is a heartbeat request that replies to an abnormality. This cycle is repeated until M timers are traversed. It is determined that there is no heartbeat request with an abnormal reply among the M heartbeat requests, indicating that the running status of the preset APP is normal. The status mark is assigned a value of true, and the process returns to step S1011 to resend M heartbeat requests. This means that this round of heartbeat detection ends and the next round of heartbeat detection begins.

[0288] Optionally, in step S1016 and step S1017, before "returning to execute step S1011" to enter the next round of heartbeat detection, the mark of this round of heartbeat request, the received heartbeat response message and other information can be cleared first, and then returning to execute step S1011 to make the next round of heartbeat detection more accurate.

[0289] For example, referring to FIG7 , taking any heartbeat request i (1≤i≤M) as an example, the above process can be represented as FIG7 . Among them, the timer corresponding to the heartbeat request i is represented as timer i, and the heartbeat response message corresponding to the heartbeat request i is represented as heartbeat response message i. After the heartbeat request i is sent, the corresponding timer i is started and the timing begins. As shown in FIG7 , S1015 includes:

[0290] S1051A, when timer i reaches its timing duration, the status detection module determines whether there is a heartbeat response message i; if there is no heartbeat response message i, execute step S1016; if there is a heartbeat response message i, execute step S1052A.

[0291] S1052A, the status detection module determines whether i is equal to M. If so, execute step S1017; if not, set i=i+1 and return to execute step S1051A.

[0292] Optionally, if a heartbeat response message i is determined to exist, the heartbeat response message i can be marked with a non-timeout flag, indicating that the heartbeat response message i has not timed out. Alternatively, 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 the efficiency of the algorithm.

[0293] As another possible implementation, the state detection module can also determine whether the timer corresponding to the heartbeat response message exceeds the timing duration (i.e., determine whether the heartbeat response message has timed out) after receiving the heartbeat response message each time. In this implementation, a maximum detection duration can be preset, and this maximum detection duration can be used as the upper limit of a round of heartbeat detection duration. Optionally, the maximum detection duration ≥ timing duration M + sending duration Q. Wherein, the timing duration M represents the timing duration of the timer corresponding to the last heartbeat request sent among the M heartbeat requests. The sending duration Q represents the total duration from sending the first heartbeat request among the M heartbeat requests to sending the last heartbeat request, that is, the total duration required for all M heartbeat requests to be sent out.

[0294] Referring to FIG8 , taking the heartbeat response message i as an example, the following process is performed:

[0295] S1051B, the status detection module periodically determines whether the time difference between the current moment and the moment of sending the first heartbeat request is greater than the maximum detection duration; if so, execute step S1016; if not, execute step S1052B.

[0296] The time when the first heartbeat request is sent can be understood as the starting time of this round of heartbeat detection, and the time difference between the current time and the time when the first heartbeat request is sent can be understood as the execution duration of this round of heartbeat detection.

[0297] Optionally, 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. In the case that 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.

[0298] S1052B, after receiving the heartbeat response message i, 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.

[0299] S1053B, 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.

[0300] Similarly, in this implementation, if it is determined that heartbeat response message i has not timed out, the heartbeat response message i can be marked as not timed out, indicating that the heartbeat response message i has not timed out. Alternatively, 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.

[0301] In this embodiment, by executing a heartbeat request on a pre-set app, not only can the pre-set app's own operating status be quickly and easily determined to be abnormal, but the detection results also cover situations where the pre-set app experiences communication anomalies with the EC. In actual applications, communication anomalies between the pre-set app and the EC can also result in an inability to provide upper-layer user scenarios to the EC. Therefore, in this case, the EC performs autonomous heat dissipation control, thereby improving the accuracy of heat dissipation control. Furthermore, in each round of heartbeat detection, 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.

[0302] Next, the specific process of EC identifying autonomous user scenarios is explained.

[0303] As described in the above embodiments, autonomous user scenarios may include game scenarios, office scenarios, video scenarios, idle scenarios, light-load scenarios, and heavy-load scenarios, etc.

[0304] For example, FIG9 is a schematic diagram of the principle of autonomous user scene recognition provided in an embodiment of the present application, and FIG10 is a flow chart of a heat dissipation control method provided in an embodiment of the present application. Please refer to FIG9 and FIG10 together. In one embodiment, the implementation process of the above step "S111, the autonomous recognition module identifies the user scene of the electronic device according to the target data to obtain the autonomous user scene" includes:

[0305] S1111 . 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 .

[0306] Step S1111 is also called scene recognition based on user input behavior characteristics. In comparison, scene recognition based on user input behavior characteristics belongs to accurate recognition.

[0307] It is understood that the data entered by a user through an input device (such as a keyboard, mouse, or touchpad) 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.

[0308] (1) Identification of game scenes

[0309] First, based on Table 7, we analyze the characteristics of users’ input behaviors in some game scenarios.

[0310] Table 7

[0311] As can be seen from Table 7, in the game scenario, the area where the keys used by the user are located is relatively concentrated, and the keys used by various types of games are the same or similar. In the game scenario, the way of using the mouse is similar. Moreover, the user may turn off the touchpad in the game scenario. Based on this, this embodiment can identify the game scenario through at least one of the key value provided by the keyboard, the data provided by the mouse (referred to as mouse data), and the state of the touchpad. Among them, the key value refers to the content (i.e., value) entered by the user through the keyboard key. For example, if the user presses the key "A", the key value entered is "A", and if the user presses the key "space", the key value entered is "space". Mouse data refers to the data entered by the user by pressing the mouse key or by sliding the mouse wheel. For example, if the user clicks the left mouse button twice in succession, the input data is "double-click the left mouse button". The state of the touchpad can include an on state and an off state.

[0312] In a specific embodiment, 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. For example, 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. Of course, 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.

[0313] After the thermal noise balancing process is established, 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. Since key values ​​W, S, and D belong to the aforementioned game key value list, they are the target key values. The total number of target key value entries = 5 + 3 + 1 = 9. Therefore, the ratio of the total number of target key value entries to the total number of key presses during this 30-second period (i.e., the target ratio) is: 9 / 13 ≈ 0.6923.

[0314] After determining the target ratio, 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.

[0315] As a possible implementation, 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.

[0316] As another possible implementation, 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. For example, the total number of key presses within 30s needs to be greater than the preset number threshold. In other words, if the total number of key presses within 30s is greater than the preset number threshold, and the target ratio is greater than the preset ratio threshold, it is determined that scene recognition result 1 is a game scene. In this implementation, on the basis of the target ratio, 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. In addition, similar to the previous implementation, in this implementation, the results of multiple calculations and judgments can also be combined to identify the game scene and improve the accuracy of scene recognition.

[0317] In some other embodiments, 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.

[0318] In gaming scenarios, data input by users through input devices such as keyboards, touchpads, and mice has distinct characteristics. In this embodiment, based on the characteristic analysis results of user input data in gaming scenarios, 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.

[0319] (2) Identification of office scenes

[0320] Combined with Table 8, the characteristics of user input behavior in some office scenarios are analyzed.

[0321] Table 8

[0322] As can be seen from Table 8, in office scenarios, users frequently operate some office software (PPT, Word, The key values ​​provided by the keyboard can be used to identify office scenes.

[0323] In a specific embodiment, based on the input analysis in an office scenario as shown in Table 8, three types of office key values ​​that users may frequently operate in an office scenario can be pre-determined, namely: delete line break key values, shortcut key values, and direction key values. For the convenience of statistics, the three types of office key values ​​can be recorded in office key value list 1, office key value list 2, and office key value list 3. Among them, office key value list 1 is a delete line break key value list, and 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.

[0324] After the thermal noise balance process is established, the autonomous recognition module can obtain the key values ​​entered by the user from the keyboard in real time and identify the office scene according to the following process:

[0325] A. Count the number of times three types of office key values ​​are entered within a preset time period.

[0326] That is, the number of key values ​​input within a preset time period (e.g., 60 seconds) is determined, including the number of key values ​​input from office key value list 1, the number of key values ​​input from office key value list 2, and the number of key values ​​input from office key value list 3. For example, according to statistics, among the key values ​​input within the last 60 seconds, the number of key values ​​input from office key value list 1 is n1, i.e., the number of key values ​​input from the delete and line break category is n1; among the key values ​​input within the last 60 seconds, the number of key values ​​input from office key value list 2 is n2, i.e., the number of key values ​​input from the shortcut category is n2; and among the key values ​​input within the last 60 seconds, the number of key values ​​input from office key value list 3 is n3, i.e., the number of key values ​​input from the direction category is n3.

[0327] B. Assign prediction factors corresponding to the three types of office key values ​​based on the number of inputs.

[0328] Specifically, each office key can have a corresponding prediction factor, and the value of the prediction factor is determined by the number of times the office key is entered. The prediction factor corresponding to the delete line key is denoted as a, the prediction factor corresponding to the shortcut key is denoted as b, and the prediction factor corresponding to the direction key is denoted as c.

[0329] Optionally, the autonomous identification module can separately determine whether the number of inputs of the three types of office key values ​​exceeds their respective corresponding number thresholds. If so, the corresponding prediction factor is assigned a value of 1; if not, the corresponding prediction factor is assigned a value of 0. The number threshold corresponding to the delete line key value is recorded as th1, the number threshold corresponding to the shortcut key value is recorded as th2, and the number threshold corresponding to the direction key value is recorded as th3. Then, determine whether n1 is greater than th1. If so, assign 1 to the prediction factor a; if not, assign 0 to the prediction factor a. Similarly, determine whether n2 is greater than th2. If so, assign 1 to the prediction factor b; if not, assign 0 to the prediction factor b. Determine whether n3 is greater than th3. If so, assign 1 to the prediction factor c; if not, assign 0 to the prediction factor c.

[0330] C. Calculate the predicted value based on the prediction factors corresponding to the three types of office key values ​​and the corresponding preset weights.

[0331] Optionally, the predicted value can be calculated according to the following formula:

[0332] Where f represents the predicted value, ω1 represents the weight corresponding to the line break key, ω2 represents the weight corresponding to the shortcut key, and ω3 represents the weight corresponding to the direction key. Optionally, ω1, ω2, and ω3 can be pre-set as needed.

[0333] D. Determine whether scene recognition result 1 is an office scene based on the predicted value.

[0334] Optionally, it can be determined whether the predicted value is greater than a preset threshold. If so, the scene recognition result 1 is determined to be an office scene; if not, the scene recognition result 1 is determined not to be an office scene. The preset threshold can be set according to actual conditions, for example, 0.8.

[0335] As a possible implementation, the above process can be repeated X times. After confirming that the predicted values ​​in each of the X time periods are greater than a preset threshold, scene recognition result 1 is determined to be an office scene. X is an integer greater than or equal to 2. Repeated calculations can eliminate misidentifications caused by special scenarios and improve scene recognition accuracy.

[0336] As another possible implementation method, a statistical analysis can be performed on the key values ​​within a period of time to determine the number of times each key value appears within the period, thereby determining the degree of randomness of the key value distribution within the period. If the degree of randomness of the key value distribution is high, and the predicted value determined according to steps A to D above is greater than a preset threshold, then the scene recognition result 1 is determined to be an office scene. In this way, the accuracy of office scene recognition is further improved. The embodiments of this application do not impose any restrictions on the method for determining the degree of randomness.

[0337] In the office scene, the key values ​​input by the user have more obvious characteristics. In this embodiment, based on the characteristic analysis results of the key values ​​input by the user in the office scene, three types of office key values ​​are determined. Based on the number of inputs of these three types of office key values, it is possible to simply and accurately identify whether the user is in the office scene, thereby improving the efficiency of scene recognition.

[0338] It is understood that if autonomous recognition, according to the above process, determines that scene recognition result 1 is neither a gaming scene nor an office scene, then NA can be used as scene recognition result 1. Scene recognition result 1 being NA indicates that the scene recognition result based on the user input behavior characteristics does not belong to a preset scene, for example, neither a gaming scene nor an office scene.

[0339] S1112 : The autonomous recognition module performs fuzzy scene recognition based on the device power data obtained from the power measurement IC to obtain scene recognition result 2.

[0340] Step S1112 is also referred to as power-based fuzzy scene recognition.

[0341] Power-based fuzzy scene recognition can be used to identify video scenes, etc. Optionally, video scenes can be further subdivided into local video scenes and online video scenes.

[0342] It is understandable that the power of devices in electronic devices may be different in different scenarios. In video scenarios, the power of some devices in electronic devices has more significant characteristics. In addition, the power of wireless communication modules is different in online video scenarios and local video scenarios. In this embodiment, fuzzy scene recognition is performed in combination with SoC power, SSD power, DDR power, screen power, audio PA power, and wireless communication module (e.g., WLAN) power to determine whether the current user scenario is a local video scenario or an online video scenario.

[0343] As an example, fuzzy scene recognition may be performed based on device power data according to the corresponding relationship shown in Table 9. The unit of power may be milliwatt (mW).

[0344] Table 9

[0345] Specifically, if the SoC power, SSD power, DDR power, screen power, audio PA power, and WLAN power match the temperature ranges corresponding to a user scenario in Table 9, the autonomous identification module determines that scene identification result 1 is the user scenario. For example, if the SoC power, SSD power, DDR power, screen power, audio PA power, and WLAN power are 1854mW, 56mW, 220mW, 2777mW, 902mW, and 0mW, respectively, and match the SoC power ranges, SSD power ranges, DDR power ranges, screen power ranges, audio PA power ranges, and WLAN power ranges in the local video scenario, scene identification result 1 can be determined to be the local video scenario.

[0346] It is understood that if the autonomous recognition module determines, according to the above process, that scene recognition result 1 is not any of the user scenarios in Table 9, then NA can be used as scene recognition result 2. Scene recognition result 2 being NA indicates that the power-based fuzzy scene recognition result does not belong to a preset scene, for example, neither a local video scene nor an online video scene.

[0347] S1113. The autonomous recognition module performs fuzzy scene recognition based on the temperature data obtained from the NTC to obtain scene recognition result 3.

[0348] Step S1113 is also referred to as temperature-based fuzzy scene recognition.

[0349] Temperature-based fuzzy scene recognition can be used to identify idle scenes, light-load scenes, and heavy-load scenes, etc.

[0350] It is understandable that the degree of device heat generation varies in different user scenarios. Furthermore, the degree of device heat generation also varies under different ambient temperatures. In this embodiment, fuzzy scene recognition can be performed based on the ambient temperature, SoC temperature, SSD temperature, and DDR temperature to determine whether the current user scenario is an idle scenario, a lightly loaded scenario, a heavily loaded scenario, or the like.

[0351] As an example, fuzzy scene recognition may be performed based on the temperature data of the environment or device according to the corresponding relationship shown in Table 10. The unit of temperature may be Celsius (°C).

[0352] Table 10

[0353] As a possible implementation method, the rule for temperature-based fuzzy scene recognition can be: (ambient temperature && SoC temperature && SSD temperature && DDR temperature). That is to say, when the ambient temperature, SoC temperature, SSD temperature and DDR temperature are matched one-to-one with each temperature range in a row in Table 10, the scene recognition result 3 is determined to be the user scene corresponding to the row. For example, if the current ambient temperature is 20°C, the SoC temperature is 48°C, the SSD temperature is 42°C, and the DDR temperature is 44°C, these temperatures are matched one-to-one with the ambient temperature range, SoC temperature range, SSD temperature range and DDR temperature range under the light load scenario in Table 10, then 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.

[0354] In another possible implementation, the rule for temperature-based fuzzy scene recognition can also be: (ambient temperature && SoC temperature && SSD temperature) || (ambient temperature && SoC temperature && DDR temperature). That is, if the ambient temperature and SoC temperature respectively match the ambient temperature range and SoC temperature range of a row in Table 10, and at least one of the SSD temperature and DDR temperature matches the SSD temperature range and DDR temperature range of that row, scene recognition result 3 can be determined to be the user scene corresponding to that row. For example, if the current ambient temperature is 20°C and the SoC temperature is 48°C, these two temperatures respectively match the ambient temperature range ([10, 30]) and SoC temperature range ([45, 55]) for the light-load scene corresponding to the normal temperature environment in Table 10. Therefore, if the current SSD temperature matches the SSD temperature range ([40, 50]) for the light-load scene corresponding to the normal temperature environment, or if the current DDR temperature matches the DDR temperature range ([40, 50]) for the light-load scene corresponding to the normal temperature environment, scene recognition result 3 can be determined to be the light-load scene. For example, if the current SSD temperature is 38°C and the DDR temperature is 42°C, it can be determined that scene recognition result 3 is a light load scene.

[0355] It should be understood that in actual applications, there are some scenarios where the workload difference between SSD and DDR is quite obvious, and therefore the temperature difference between the two is quite obvious. In some scenarios (such as local audio playback), the electronic device is mainly operated by SSD, while the workload of DDR is very small. In this scenario, the SSD temperature is higher and the DDR temperature is lower; while in other scenarios (such as network audio playback), the SSD hardly needs to work and only the DDR needs to work. In this scenario, the SSD temperature is lower and the DDR temperature is higher. In this implementation, the ambient temperature and SoC temperature are used as necessary conditions for scene recognition, and the SSD temperature and DDR temperature are used as auxiliary conditions. When one of the SSD temperature and the DDR temperature meets the corresponding temperature range, the scene recognition result 3 can be determined. This can cover the above-mentioned scenarios where there are differences in the workload of SSD and DDR, and improve the accuracy of scene recognition.

[0356] Optionally, if the autonomous recognition module determines according to the above process that 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.

[0357] 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. In this embodiment, 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.

[0358] Optionally, an average temperature can be used to measure the temperature of the environment and each component to improve the accuracy of scene recognition. Here, taking the calculation of the average temperature of the SoC as an example, a calculation method is introduced, which includes the following steps:

[0359] A. SoC_NTC reports the SoC sampling temperature to the autonomous identification module according to a preset time window (e.g., 2s).

[0360] In other words, the SoC_NTC reports the SoC sampled temperature to the autonomous identification module every 2 seconds. Optionally, 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.

[0361] B. The autonomous identification module calculates the average value of i SoC sampling temperatures reported consecutively by SoC_NTC i times 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.

[0362] C. 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.

[0363] D. The autonomous identification module calculates the average value of the standard temperatures of j SoCs to obtain the average temperature of the SoC.

[0364] 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.

[0365] S1114 . The autonomous recognition module determines the autonomous user scene according to scene recognition result 1 , scene recognition result 2 , and scene recognition result 3 .

[0366] There are many methods for determining the autonomous user scenario based on scene recognition result 1, scene recognition result 2, and scene recognition result 3. In a specific embodiment, 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. For example, 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. In this case, 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. If 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.

[0367] 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. In this way, 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.

[0368] The heat dissipation control method described above is further explained below with reference to specific scenarios.

[0369] 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:

[0370] 1) When a first application is running in the background, at a first moment, a second application is started and a window of the second application is displayed. Before the first moment, the fan speed is a first speed. After the first moment, the window of the second application is the focus window. After the first moment, the fan speed is set to a second speed.

[0371] 2) After the fan speed is set to the second speed, during the first time period, when the first area or the second area of ​​the keyboard is being tapped, the fan speed remains unchanged;

[0372] 3) After the first time period, uninstall the first application;

[0373] 4) After uninstalling the first application, during a second time period, while the first area of ​​the keyboard is being tapped, the fan speed is set to a third speed;

[0374] 5) After uninstalling the first application, after the second time period, in a fourth time period, while the second area of ​​the keyboard is being tapped, the fan speed is set to a sixth speed.

[0375] Specifically, the first application can be the aforementioned preset application. Here, the first application is the PC Manager application. The second application can be an application opened by the user in an actual usage scenario. Here, the office application opened by the user in an office scenario (i.e., the second application is an office application) is used as an example.

[0376] First, let's explain the above process 1) based on the scenario:

[0377] When the PC Butler APP is running in the background, at the first moment, in response to the user's startup operation, 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. Here, the process of the PC Butler APP identifying the user scene can be referred to the above steps S102 to S104.

[0378] As described in the above embodiment, 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. In process 1), the PC Manager app is running normally in the background, so the status flag is assigned a value of true.

[0379] The above process 2) is described below:

[0380] 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. Therefore, in this scenario, when the focus window is still the office application, the user taps the first area or the second area of ​​the keyboard, and the PC Butler APP recognizes that the scene has not changed, so the fan speed remains unchanged. This process can be seen in steps S105 to S108 in the above embodiment.

[0381] The above processes 3) and 4) are explained below:

[0382] Optionally, 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.

[0383] Specifically, after the PC Manager app is uninstalled, suppose the user launches a game application and enters the game scene. At this time, although the focus window changes to the game application window, the PC Manager app cannot recognize the upper user scene and cannot perform passive cooling control based on the upper user scene. In this case, the user taps the first area of ​​the keyboard in the game scene and enters the first key value, part or all of which belongs to the game key value list.

[0384] However, since the user uninstalled PC Manager, the EC detected that the heartbeat did not meet the preset conditions based on the heartbeat detection results, and thus assigned a false value to the status flag. The false value assigned to the status flag triggers the EC to enter the autonomous decision-making cooling mode, and identifies the user scenario based on data such as the keyboard and the device power and device temperature of the electronic device. After the user taps the first area of ​​the keyboard and enters the first key value, the EC recognizes that the current scene has changed to a game scene, and thus determines the corresponding fan control strategy (i.e., the autonomous table) based on the game scene, and adjusts the fan speed to the third speed according to the fan control strategy. For details, please refer to steps S109 to S115, and steps S1111 to S1114, etc. in the above embodiment.

[0385] Optionally, in some scenarios, the user does not start the game application (the second application), but the office application window remains displayed on the screen. That is, the focus window does not change and remains the office application window. In this case, in addition to controlling the fan speed to adjust to the third speed according to the above process, the electronic device displays the first content on the screen (i.e., the display screen) in response to the user tapping the first area of ​​the keyboard. The first content is the content entered by tapping the first area of ​​the keyboard.

[0386] The above process 5) is described below:

[0387] Optionally, at least some of the key values ​​corresponding to the second area of ​​the keyboard are located in office key value category list 1, office key value category list 2, and office key value category list 3. When the second area of ​​the keyboard is tapped, the electronic device recognizes that the user scene has changed to an office scene, and the fan speed is set to a sixth speed.

[0388] Specifically, continuing with the above example, the user closes the gaming application and restarts the office application. In this case, after the PC Manager app is uninstalled, although the focus window changes to the office application window, the PC Manager app cannot recognize the upper-level user scenario and cannot perform passive cooling control based on the upper-level user scenario. After the user starts the office application, the user taps the second area of ​​the keyboard in the gaming scenario and enters a second key value. Part or all of the second key value belongs to Office Key Value Class List 1, Office Key Value Class List 2, or Office Key Value Class List 3.

[0389] At this point, the PC Manager APP is still uninstalled, the status flag is still false, and the EC is still in autonomous cooling mode. Therefore, when the user taps the second area of ​​the keyboard and enters the second key value, on the one hand, a third content is displayed on the screen. The third content is the content entered by tapping the second area of ​​the keyboard. On the other hand, the EC recognizes that the current scene has changed to an office scene, and thus determines the corresponding fan control strategy based on the office scene, and adjusts the fan speed to the sixth speed based on the fan control strategy. For details, please refer to steps S109 to S115, and steps S1111 to S1114, etc. in the above embodiment.

[0390] Optionally, in some scenarios, the user does not start the office application, but keeps the game application window displayed on the screen. In this case, the electronic device also controls the fan speed to the sixth speed according to the above process, but the second content may not be displayed on the screen.

[0391] In some other embodiments, after uninstalling the first application, the fan speed is set to a fourth speed based on a power change of a first component in the electronic device. Alternatively, after uninstalling the first application, the fan speed is set to a fifth speed based on a temperature change of a second component in the electronic device within a third time period.

[0392] Specifically, after the PC Manager app is uninstalled, the EC still detects an abnormal heartbeat, and therefore the status flag remains false. The EC continues to identify the user scenario based on data such as the keyboard and electronic device power and temperature. When the user scenario changes, for example, when the user opens video software and the scenario changes to a local video scenario or an online video scenario, the EC recognizes the power change of the relevant components and determines that the current scenario has changed to a local video scenario or an online video scenario. Based on the local video scenario or the online video scenario, the EC determines the corresponding autonomous table and adjusts the fan speed to the fourth speed according to the autonomous table.

[0393] For another example, when a user opens animation rendering software and the scene changes to an overload scene, the EC recognizes that the temperature of related components has changed, and therefore determines that the current scene change is an overload scene. It determines the corresponding autonomous table based on the overload scene, and adjusts the fan speed to the sixth speed based on the autonomous table.

[0394] Next, the passive heat dissipation control process is further explained.

[0395] First, the process of the preset APP identifying the upper-level user scenario is explained.

[0396] Exemplarily, Figure 12 is a schematic diagram of the workflow of an upper-level user scene recognition provided in an embodiment of the present application. As shown in Figure 12, 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. For example, 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.

[0397] The power status probe can subscribe to power status events in kernel mode and determine the power status based on the callback function fed back by kernel mode. The power status includes battery (remaining) power, power mode, etc., and the power mode can include alternating current (AC) and direct current (DC). For example, 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 feed back the callback function to the power status probe through the OsEventDriver node.

[0398] The peripheral status probe can subscribe to peripheral events in kernel state and determine the peripheral events based on the callback function fed back by kernel state. Peripheral events include mouse wheel sliding events, mouse click events, keyboard input events, microphone input events, camera input events, etc.

[0399] 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.

[0400] The system load probe can subscribe to the system load in the kernel state and determine the system load based on the callback function fed back by the kernel state.

[0401] The audio and video status probe can subscribe to audio and video events in the kernel state and determine the current audio and video events of the electronic device 100 based on the callback function fed back by the kernel state. Audio and video events may include GPU decoding events, etc. For example, the audio and video status probe can send a request to subscribe to GPU decoding events to the OsEventDriver node in the executive layer, and the OsEventDriver node forwards the request to the graphics card driver in the kernel and driver layer. The graphics card driver can monitor the status of the GPU and, after detecting that the GPU is performing a decoding operation, feed back a callback function to the audio and video status probe through the OsEventDriver node.

[0402] 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. For example, 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. After creating the process, the process manager may feed back the callback function to the system event probe through the OsEventDriver node. For another example, 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.

[0403] It can be seen that the system probe module subscribes to various events of the electronic device 100 in the kernel state, and then determines the operating state of the electronic device 100 according to the callback function fed back by the kernel state, that is, obtains the probe state. After obtaining the probe state, the system probe module 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 in which the electronic device 100 is located according to the probe state, that is, determine the upper-level user scene. As mentioned above, the upper-level 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. For example, when 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 video scene, which means that the user needs to use a video application to watch and browse videos. For another example, when the scene recognition engine identifies that the focus window is a window of a WeChat app, it determines that the electronic device 100 is in a video scene, which means that the user needs to use a video application to watch and browse videos. TM When the chat window of the electronic device 100 is displayed, it is determined that the electronic device 100 is in a social scene. Generally, when 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 a change in the user scene), it can determine the user scene currently in which the electronic device is 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.

[0404] As shown in Figure 12, the scheduling engine includes a load controller, which can obtain the system load from the system probe module and send the system load to the thermal noise balancing engine.

[0405] Specifically, the scenario recognition module and load controller can send the upper-level user scenario and system load to the BIOS via the WMI plug-in, which then sends it to the thermal noise balancing engine in the EC. The thermal noise balancing engine performs heat dissipation control based on the upper-level user scenario and system load information. The specific process is described in the above embodiment and is not repeated here.

[0406] The following uses the example of an electronic device changing from an office scene to a video scene, and in conjunction with Figures 12 and 13, to illustrate the implementation process of the above step "S102, presetting the APP to identify the user scene in which the electronic device is located and obtain the upper-level user scene". It should be noted that Figures 12 and 13 mainly involve the identification of the upper-level user scene. In the description of the embodiment, the upper-level user scene can also be simply described as the user scene. As shown in Figures 12 and 13, S102 includes:

[0407] S201: The system probe module sends a request to subscribe to a process creation event to the OsEventDriver node.

[0408] As shown in Figure 12, the scene recognition engine includes a system probe module, which includes a system event probe. In an embodiment of the present application, 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.

[0409] In one optional implementation, the request to subscribe to process creation events can include the process name. This means the scene recognition engine can subscribe only to creation events for a specific process, reducing interference from creation events for irrelevant processes. For example, a specific process can be a video application, a gaming application, an office application, a social networking application, and so on. Of course, in other implementations, the scene recognition engine may not impose restrictions on the process creation events it subscribes to.

[0410] S202: The OsEventDriver node sends a request to the process manager to subscribe to a process creation event.

[0411] The request for the process creation event can refer to the description of S201 and will not be repeated here.

[0412] That is, the 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.

[0413] It can be understood that the OsEventDriver node will register a callback with the process manager. The purpose of registering the callback is to return the process creation event to the OsEventDriver node after the process manager creates a process.

[0414] S203: The system probe module sends a request to subscribe to GPU decoding events to the OsEventDriver node.

[0415] Still as shown in Figure 12, the system probe module also includes an audio and video status probe. In this embodiment of the present application, 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.

[0416] S204. The OsEventDriver node sends a request to subscribe to GPU decoding events to the graphics card driver.

[0417] In other words, 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. Similarly, 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.

[0418] S205: The system probe module sends a request to subscribe to a focus window change event to the API module.

[0419] The API module may include a Windows user interface interface implemented by user32.dll, which can be used to create windows. In an optional embodiment, 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.

[0420] Similarly, 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.

[0421] 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.

[0422] It should be noted that 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. Correspondingly, there is no strict order between 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.

[0423] 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.

[0424] S206 : In response to receiving the user's operation of starting the video application, the video application sends a process creation request to the process manager.

[0425] The process creation request includes the storage address of the video application.

[0426] 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).

[0427] S207: The process manager creates a video application process.

[0428] Specifically, the process manager can query the binary file of the video application through the storage address. By loading the binary file of the video application, an environment for process operation can be created and the video application process can be started.

[0429] Among them, the Windows operating system defines one run of an application as a process. A process can have multiple threads. A window is an instance of a window structure and is a graphical user interface (GUI) resource. A window is created by a thread, and a thread can own all windows it creates. In an embodiment of the present application, an electronic device runs a video application, and the process manager needs to create a process for the video application, that is, a video application process (that is, a first process). The video application process includes multiple threads, and the multiple threads include thread 1. Thread 1 can be used to create the main window of the video application. The main window is a window that integrates all the function buttons of the video application.

[0430] S208: The process manager reports the process creation event to the OsEventDriver node.

[0431] Among them, the process creation event may include the name of the process created by the process manager. In the embodiment of the present application, the name of the process is the name of the video application process. Of course, if the process manager creates a process of another application, the name of the process also corresponds to the name of the other application process.

[0432] As previously explained, the OsEventDriver node sends a request to the process manager to subscribe to the process creation event and registers a callback. Therefore, after creating the video application process, the process manager can report the process creation event to the OsEventDriver node.

[0433] S209. The OsEventDriver node reports the process creation event to the system probe module.

[0434] The description of the process creation event is described in S208 and will not be repeated here.

[0435] In the embodiment of the present application, the OsEventDriver node may report the process creation event to the system event probe of the system probe module.

[0436] S210: The system probe module sends a process creation event to the scene recognition module.

[0437] S211 . In response to the call request of thread 1 , the API module creates window 1 .

[0438] After the process manager creates the 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. For example, as shown in (a) in Figure 14, 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. In response to this operation, as shown in (b) in Figure 14, the electronic device displays window 103 (i.e., window 1, also referred to as the first window). In the above process, the focus window changes from the original window 101 to window 103.

[0439] S212. The API module reports the focus window event to the system probe module.

[0440] In an embodiment of the present application, after the Windows user interface interface of the API module creates window 1, it can obtain the name of the first process (i.e., the focus process) and the name of the second process. The first process is the process corresponding to the current focus window (i.e., window 1), and the second process is the process corresponding to the previous focus window (e.g., window 2). Exemplarily, the process corresponding to window 1 is a video application process (first process), and the name of this process is, for example, hlive.exe. The process corresponding to window 2 is an office application process (second process), and the name of this process is, for example, word.exe. Since the name of the first process is inconsistent with the name of the second process, 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. Among them, the focus window change event includes the name of the first process (i.e., the focus process). Exemplarily, the first process is a video application process, and the focus window change event carries the name of the video application process.

[0441] It should be noted that if the electronic device has already started the video application, the electronic device does not need to execute S206 to S211. After 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.

[0442] S213: The system probe module sends a focus window event to the scene recognition module.

[0443] S214: The scene recognition module determines that the type of the first process is a video type.

[0444] The electronic device may be pre-configured with an application list, and the scene recognition module may query whether the application list includes the first process. If the application list includes the first process, the scene recognition module may determine the type of the first process. The application list includes the process name and type of each application. For example, the application list may be as shown in Table 11:

[0445] Table 11

[0446] For example, if the name of the first process is hlive.exe, 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.

[0447] It should be noted that the purpose of this step is to preliminarily determine the user scenario of the electronic device, that is, to preliminarily determine the upper-level user scenario. Upper-level user scenarios can include video scenarios, gaming scenarios, social scenarios, office scenarios, browser scenarios, and so on. Among them, video scenarios can further include video playback scenarios and video browsing scenarios. Social scenarios can further include text chat scenarios, voice chat scenarios, video chat scenarios, and so on. Office scenarios can further include document editing scenarios, document browsing scenarios, video conferencing scenarios, and so on. Browser scenarios can include web browsing scenarios and video playback scenarios, and so on.

[0448] In this step, 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.

[0449] To further analyze user needs, the scene recognition module can further combine other parameters (e.g., peripheral events, GPU operating status, etc.) to analyze the specific scene in which the electronic device is located, so as to achieve more accurate analysis results. Continuing with the video scene as an example, the specific process may include:

[0450] S215 . In response to receiving the user's operation of playing the video, the video application sends a video playing instruction to the API module.

[0451] Specifically, the video application may send the video play instruction to the DirectX API of the API module. The video play instruction may include the cache address of the video.

[0452] S216. The API module reads the video file.

[0453] The API module can read the corresponding video file according to the cache address carried in the video playback instruction.

[0454] S217. The API module sends a decoding instruction to the graphics card driver.

[0455] S218: The graphics card driver sends a startup instruction to the GPU.

[0456] S219: GPU performs decoding.

[0457] Specifically, the GPU may perform a decoding operation on the video file through a GPU video processing engine.

[0458] S220. The GPU reports a decoding event to the graphics card driver.

[0459] S221. The graphics card driver reports a decoding event to the OsEventDriver node.

[0460] S222. The OsEventDriver node reports the decoding event to the system probe module.

[0461] Specifically, the OsEventDriver node reports the decoding event to the audio and video status probe of the system probe module.

[0462] S223: The system probe module sends a decoding event to the scene recognition module.

[0463] S224. The scene recognition module sends instruction 1 to the system probe module.

[0464] 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.

[0465] S225. The system probe module sends a request to the process manager to obtain the GPU occupancy rate of the first process.

[0466] The request for obtaining the GPU occupancy of the focus process may include the name of the first process.

[0467] In an optional implementation, 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.

[0468] S226: The process manager collects the GPU occupancy rate of the first process.

[0469] Specifically, the process manager may collect the GPU occupancy rate of the first process through a graphics kernel interface of a graphics card driver.

[0470] S227: The process manager sends the GPU occupancy of the first process to the system probe module.

[0471] The process manager may send the GPU occupancy of the first process to the audio and video status probe of the system probe module.

[0472] S228. The system probe module sends the GPU occupancy rate of the first process to the scene recognition engine.

[0473] S229: The scene recognition module determines whether the GPU occupancy rate of the first process is greater than 0.

[0474] If the GPU occupancy of the first process is greater than 0, step S230 is executed.

[0475] The GPU occupancy rate of the first process can be used to determine whether the first process uses the GPU during operation. If the GPU occupancy rate of the first process is greater than 0, it can be considered that the first process uses the GPU during operation; if the GPU occupancy rate of the first process is 0, it indicates that the first process does not use the GPU during operation.

[0476] S230: The scene recognition module sends instruction 2 to the system probe module.

[0477] 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.

[0478] S231: The system probe module sends a request to the process manager to obtain the GPU engine of the first process.

[0479] The audio and video status probe of the system probe module may send a request to the process manager to obtain the GPU engine of the first process. The request to obtain the GPU engine of the first process includes the name of the first process.

[0480] The GPU engine includes a GPU 3D engine, a GPU copy engine, a GPU video encoding engine, and a GPU video processing engine. The GPU 3D engine is primarily responsible for processing 2D or 3D graphics. The GPU copy engine is primarily used for data transmission. The GPU video encoding engine is primarily used for encoding operations. The GPU video processing engine primarily performs decoding operations. In some embodiments, the GPU video processing engine can also be replaced by a GPU video decoding engine.

[0481] S232: The process manager obtains the GPU engine of the first process.

[0482] Specifically, the process manager may obtain the GPU engine of the first process through the graphics kernel interface of the graphics card driver.

[0483] S233: The process manager sends a message 1 to the system probe module. The message 1 indicates that the GPU engine of the first process is a GPU video processing engine.

[0484] Specifically, 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.

[0485] S234. The system probe module sends message 1 to the scene recognition module.

[0486] S235: The scene recognition module determines whether the GPU engine of the first process is a GPU video processing engine.

[0487] If the GPU engine of the first process is a GPU video processing engine, execute S236 ; if the GPU engine of the first process is not a GPU video processing engine, execute S230 .

[0488] In step S214, the scene recognition engine has determined that the type of the first process is a video class, that is, it can be determined that the electronic device is in a video scene. Through step S235, 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 a 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, then the user is most likely browsing video resources on the video application and has not yet played the video.

[0489] S236: 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.

[0490] 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.

[0491] Based on the above content, it can be seen that if the type of the first process (focus process) is video, the GPU occupancy of the first process is greater than 0, and the GPU engine of the first process is a GPU video processing engine, it can be determined that the electronic device is in a video playback scene.

[0492] It should be noted that the above S201 to S236 are only described by taking the electronic device in the video playing scene as an example. In fact, the electronic device can also be in other user scenes (for example, game scene, office scene, social scene, video browsing scene, etc.).

[0493] In an optional embodiment, if the scene recognition engine determines that the type of the first process (focus process) belongs to the game category, the CPU power mode is changed to 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.

[0494] Among them, 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 converted to game mode. In this way, the scene recognition engine can determine whether the power mode of the CPU is game mode through the power mode change event. In addition, the process of the scene recognition engine obtaining the type of the first process can be found in S201, S202, S205, S206~S214 in Figure 5, and 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 found in S224~S235. The difference is that the video application is replaced with a game application, which will not be repeated here.

[0495] In summary, after executing the above process, 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.

[0496] The above describes in detail an example of the heat dissipation control method provided by the embodiment of the present application. It is understandable that, in order to implement the above functions, the electronic device includes hardware and / or software modules corresponding to the execution of each function. Those skilled in the art should easily realize that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software driven hardware manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application in combination with the embodiments, but such implementation should not be considered to be beyond the scope of the present application.

[0497] The embodiment of the present application can divide the functional modules of the electronic device according to the above method example. For example, each function can be divided into various functional modules, such as a detection unit, a processing unit, a display unit, etc., or two or more functions can be integrated into one module. The above-mentioned integrated module can be implemented in the form of hardware or in the form of a software functional module. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical function division. There may be other division methods in actual implementation.

[0498] It should be noted that all relevant contents of each step involved in the above method embodiment can be referred to the functional description of the corresponding functional module and will not be repeated here.

[0499] The electronic device provided in this embodiment is used to execute the above-mentioned heat dissipation control method, and thus can achieve the same effect as the above-mentioned implementation method.

[0500] When integrated, 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.

[0501] 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.

[0502] In one embodiment, when the processing module is a processor and the storage module is a memory, the electronic device involved in this embodiment may be a device having the structure shown in FIG. 2 .

[0503] 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. For example, the interface circuit 802 can be used to receive signals from other devices (such as the memory of an electronic device). For another example, the interface circuit 802 can be used to send signals to other devices (such as the processor 801). Exemplarily, the interface circuit 802 can read instructions stored in the memory and send the instructions to the processor 801. When the instructions are executed by the processor 801, the electronic device can perform the various steps in the above embodiments. Of course, the chip system can also include other discrete devices, which is not specifically limited in the embodiment of the present application. Optionally, the chip system can include the above-mentioned SoC and / or EC.

[0504] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the processor executes the heat dissipation control method of any of the above embodiments.

[0505] The embodiment of the present application further provides a 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.

[0506] In addition, 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.

[0507] Among them, 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.

[0508] Through the description of the above implementation methods, technical personnel in the relevant field can understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0509] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0510] Units described as separate components may or may not be physically separate, and components shown as units may be one physical unit or multiple physical units, that is, they may be located in one place or distributed in multiple places. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0511] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0512] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0513] The above content is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A heat dissipation control method, the method being executed by an electronic device, characterized in that: The electronic device includes a fan and a keyboard, and the method includes: When the first application is running in the background, at a first moment, a second application is started and a window of the second application is displayed. Before the first moment, the fan speed is a first speed. After the first moment, the window of the second application is a focused window. After the first moment, the rotational speed of the fan is set to a second rotational speed; After the rotation speed of the fan is set to the second rotation speed, during a first time period, when the first area or the second area of ​​the keyboard is tapped, the rotation speed of the fan remains unchanged; After the first time period, uninstalling the first application; After uninstalling the first application, within a second time period, while the first area of ​​the keyboard is being tapped, the rotational speed of the fan is set to a third rotational speed.

2. The method according to claim 1, characterized in that The method further comprises: After uninstalling the first application, the rotation speed of the fan is set to a fourth rotation speed based on a power change of the first component in the electronic device.

3. The method according to claim 1 or 2, characterized in that The method further comprises: After uninstalling the first application, within a third time period, based on a temperature change of a second component in the electronic device, the rotation speed of the fan is set to a fifth rotation speed.

4. The method according to any one of claims 1 to 3, characterized in that After uninstalling the first application, during a second time period, while the first area of ​​the keyboard is being tapped, the fan speed is set to a third speed, including: After uninstalling the first application, within the second time period, based on the first area of ​​the keyboard being tapped, the rotational speed of the fan is set to the third rotational speed.

5. The method according to claim 4, characterized in that After uninstalling the first application, within the second time period, based on the first area of ​​the keyboard being tapped, setting the fan speed to the third speed includes: In response to a first area of ​​the keyboard being tapped during the second time period, receiving a first key value via the keyboard; Based on the fact that the first application is uninstalled, determining, according to the first key value, that the user scenario of the electronic device is a first scenario; Determining a first strategy based on the scenario information of the first scenario; According to the first strategy, the rotation speed of the fan is adjusted to the third rotation speed.

6. The method according to claim 5, characterized in that The determining, according to the first key value, that the user scenario of the electronic device is the first scenario includes: determining a target ratio based on the first key value, the target ratio being the ratio of the total number of target key values ​​in the first key value to the total number of the first key values, the target key values ​​being key values ​​belonging to a target list, the key values ​​in the target list forming a third area on the keyboard, the third area at least partially overlapping with the first area of ​​the keyboard; Determining whether the target ratio is greater than a preset ratio threshold to obtain a first result; According to the first result, it is determined that the user scenario in which the electronic device is located is the first scenario.

7. The method according to claim 6, characterized in that The determining, according to the first result, that the user scenario of the electronic device is the first scenario includes: If the first result is that the target ratio is greater than the preset ratio threshold, determining that the user scenario of the electronic device is the first scenario; or, If the first result is that the target ratio is greater than the preset ratio threshold, and the total number of the first key values ​​is greater than a first preset number, it is determined that the user scenario of the electronic device is the first scenario.

8. The method according to any one of claims 5 to 7, characterized in that The first strategy includes a correspondence between multiple temperature ranges of a third component in the electronic device and multiple rotational speeds of the fan, wherein the multiple rotational speeds include the third rotational speed; The adjusting the fan speed to the third speed according to the first strategy includes: Acquiring the current temperature of the third device; Based on the first strategy, determining that the temperature range to which the current temperature belongs corresponds to the third speed; The fan speed is adjusted to the third speed.

9. The method according to claim 8, characterized in that The first strategy further includes a correspondence between the multiple temperature ranges and multiple minimum durations, the multiple minimum durations including a first target duration, and the method further includes: Based on the first strategy, determining that the temperature range to which the current temperature belongs corresponds to the first target duration; The duration for which the fan operates at the third speed is greater than the first target duration.

10. The method according to any one of claims 5 to 9, characterized in that The step of determining, based on the first key value, that the user scenario of the electronic device is a first scenario based on the first application being uninstalled includes: Determine the value of the flag bit; Based on the fact that the value of the flag bit is a first preset value, and according to the first key value, it is determined that the user scenario of the electronic device is a first scenario.

11. The method according to claim 10, characterized in that Determining the value of the flag bit includes: Sending M heartbeat requests to the first application, and starting a timer corresponding to the heartbeat request when sending each heartbeat request, where M is an integer greater than or equal to 1; Determining, based on a heartbeat response message corresponding to the heartbeat request replied by the first application and the timer, whether there is a first heartbeat request among the M heartbeat requests, where the first heartbeat request refers to a heartbeat request for which no corresponding heartbeat response message is received before the corresponding timer expires; If the first heartbeat request exists in the M heartbeat requests, determining that the value of the flag bit is the first preset value; If the first heartbeat request does not exist in the M heartbeat requests, the value of the flag bit is determined to be a second preset value.

12. The method according to any one of claims 1 to 11, characterized in that The method further comprises: 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.

13. The method according to claim 12, characterized in that After the second time period, in a fourth time period, while the second area of ​​the keyboard is being tapped, the fan speed is set to a sixth speed, comprising: In response to a second area of ​​the keyboard being tapped during the fourth time period, receiving a second key value via the keyboard; Based on the fact that the first application is uninstalled, determining, according to the second key value, that the user scenario of the electronic device is a second scenario; determining a second strategy based on the scenario information of the second scenario; According to the second strategy, the rotational speed of the fan is adjusted to the sixth rotational speed.

14. The method according to claim 13, characterized in that The determining, according to the second key value, that the user scenario of the electronic device is the second scenario includes: 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 values ​​respectively; the first-category key values, the second-category key values, and the third-category key values ​​correspond to a fourth area of ​​the keyboard, and the fourth area at least partially overlaps with the second area of ​​the keyboard; determining a value of a first prediction factor according to the number of the first type of key values; determining a value of a second prediction factor according to the number of the second type of key values; Determining a value of a third prediction factor according to the number of the third type key values; Performing a weighted summation on the value of the first prediction factor, the value of the second prediction factor, and the value of the third prediction factor to obtain a prediction value; Determining whether the predicted value is greater than a preset threshold to obtain a second result; According to the second result, it is determined that the user scenario in which the electronic device is located is the second scenario.

15. The method according to claim 14, characterized in that The first type of key values ​​includes key values ​​for indicating content deletion and / or key values ​​for indicating line break; The second type of key values ​​includes at least one key value corresponding to a shortcut key; The third type of key values ​​includes key values ​​for indicating adjustment directions.

16. The method according to any one of claims 1 to 15, characterized in that The fan rotation speed remains unchanged during the first time period when the first area or the second area of ​​the keyboard is tapped, including: In response to a tap on the first area or the second area of ​​the keyboard during the first time period, receiving a third key value via the keyboard; Based on the first application being executed, the user scenario of the electronic device is determined not based on the third key value.

17. The method according to any one of claims 1 to 16, characterized in that The electronic device further includes an embedded controller EC, and after the first moment, the rotation speed of the fan is set to a second rotation speed, including: Based on the second application window 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 scene information of the fifth scene to the EC; The EC determines a fifth strategy based on the value of the flag bit being the second preset value and according to the scenario information of the fifth scenario; The EC controls the rotation speed of the fan to change to the second rotation speed according to the fifth strategy.

18. An electronic device, characterized in that: The electronic device includes: one or more processors, and a memory; The memory is coupled to the one or more processors, and is used to store computer program code. The computer program code includes computer instructions, and the one or more processors call the computer instructions to enable the electronic device to perform the method according to any one of claims 1 to 17.

19. A chip system, characterized in that: The chip system is applied to an electronic device, and the chip system includes one or more processors, and the one or more processors are used to call computer instructions so that the electronic device executes the method as described in any one of claims 1 to 17.

20. A computer-readable storage medium, characterized in that The computer-readable storage medium comprises instructions, which, when executed on an electronic device, cause the electronic device to perform the method according to any one of claims 1 to 17.

Images