Resource scheduling method and device

Abstract

The embodiment of the invention provides a resource scheduling method and device, and relates to the technical field of terminals, and the method comprises the steps that terminal equipment is started, and the limit power value of the terminal equipment is a first power consumption value; at the first moment, the terminal equipment turns off the screen; at the second moment, the terminal equipment locks the screen; at the third moment, the terminal equipment enters the sleep state, the limit power value of the terminal equipment is a second power consumption value between the first moment and the third moment, and the second power consumption value is larger than the first power consumption value; and at the fourth moment, the terminal equipment is on. Therefore, the terminal equipment can be in the high-power-consumption mode before entering the sleep state so as to quickly enter the sleep state, and can also be in the high-power-consumption mode before exiting the sleep state so as to quickly make a wake-up response.

Description

Resource scheduling method and device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on April 20, 2023, with application number 202310459952.9 and application name “Resource Scheduling Method and Device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of terminal technology, and in particular to a resource scheduling method and device. Background Art

[0003] Modern standby (MS) is an idle function of a terminal device. In the MS state, the terminal device can enter a sleep state to save energy and battery life.

[0004] In one implementation, when the terminal device enters the sleep state, the terminal device can perform a series of program suspension operations to save the process context; when the terminal device exits the sleep state, the terminal device can load the process context to restore the state of the terminal device before sleep.

[0005] However, the process of entering the sleep state and / or exiting the sleep state takes a long time, which affects the user's experience of using the sleep state.

[0006] Summary of the Invention

[0007] Embodiments of the present application provide a resource scheduling method and apparatus for reducing the time consumed by a terminal device entering and exiting a sleep state.

[0008] In a first aspect, an embodiment of the present application provides a resource scheduling method, comprising: starting a terminal device, wherein the terminal device's limit power value is a first power consumption value; at a first moment, the terminal device turns off the screen; at a second moment, the terminal device locks the screen; at a third moment, the terminal device enters a sleep state, and between the first moment and the second moment and between the second moment and the third moment, the terminal device's limit power value is a second power consumption value, the second power consumption value being greater than the first power consumption value; and at a fourth moment, the terminal device turns on the screen. In this way, the terminal device can be in a high power consumption mode before entering the sleep state, so as to quickly enter the sleep state, and can also be in a high power consumption mode before exiting the sleep state, so as to quickly respond to wake-up.

[0009] Among them, the first moment can be the first time point or the fourth time point described in the embodiment of the present application, the second moment can be the fifth time point described in the embodiment of the present application, the third moment can be the second time point or the sixth time point described in the embodiment of the present application, and the fourth moment can be the third time point or the seventh time point described in the embodiment of the present application.

[0010] In one possible implementation, after the terminal device locks its screen, the method further includes: the terminal device, based on the screen being locked and the first flag being the first value, not setting the terminal device's power limit value to the first power consumption value, wherein the first flag being the first value is used to indicate that the terminal device is in the screen-off state. In this way, the terminal device can determine whether the screen is in the screen-off state based on the first flag, and will not enter the low-power mode upon detecting that the screen is locked and is currently in the screen-off state, thereby avoiding the situation where the terminal device is in the low-power mode before sleep.

[0011] Among them, the first flag bit can be screenoff, and the first value is true.

[0012] In one possible implementation, after the terminal device turns off the screen, the method further includes: the terminal device setting the terminal device's power limit value to the second power consumption value based on the screen being turned off. In this way, the terminal device can be set to a high power consumption mode when the screen is detected to be off, so that the terminal device can enter a sleep mode in the high power consumption mode, thereby reducing the time spent in entering the sleep mode.

[0013] In one possible implementation, the terminal device includes: a system probe module and a scene recognition module, and the terminal device does not set the terminal device's limit power value to the first power consumption value based on the lock screen and the first flag bit being the first value, including: the system probe module does not report the lock screen event to the scene recognition module and does not set the terminal device's limit power value to the first power consumption value based on the lock screen and the first flag bit being the first value. In this way, the system probe module can determine not to report the lock screen event to the scene recognition module based on the first flag bit being the first value and the lock screen, thereby avoiding the terminal device being set to low power consumption mode based on the lock screen event.

[0014] In one possible implementation, the method further includes: the system probe module not reporting the screen-on event to the scene recognition module based on the screen being on and the second flag being the second value, wherein the second flag being the second value is used to indicate that the terminal device is in a locked screen state. In this way, the terminal device can determine whether the screen is locked based on the second flag, and not enter low-power mode when the locked screen is detected and the screen is currently on, thereby avoiding being in low-power mode before waking up.

[0015] Among them, the second flag is islocked, and the second value is true.

[0016] In one possible implementation, the method further includes: the terminal device runs the first application, the terminal device's limit power value is the second power consumption value; at a fifth moment, the terminal device locks the screen; at a sixth moment, the terminal device turns off the screen, and between the fifth and sixth moments, the terminal device's limit power value is the first power consumption value; at a seventh moment, the terminal device enters a sleep state; between the sixth and seventh moments, the terminal device's limit power value is the second power consumption value; and at an eighth moment, the terminal device turns on the screen. In this way, the terminal device can be in a high power consumption mode before entering the sleep state, so as to quickly enter the sleep state, and can also be in a high power consumption mode before exiting the sleep state, so as to quickly respond to a wake-up.

[0017] Among them, the fifth moment can be the eighth time point described in the embodiment of the present application, the sixth moment can be the ninth time point described in the embodiment of the present application, the seventh moment can be the tenth time point described in the embodiment of the present application, and the eighth moment can be the eleventh time point described in the embodiment of the present application.

[0018] In one possible implementation, after the terminal device locks the screen, the method further includes: the terminal device sets the terminal device's power limit value to the first power consumption value based on the screen being locked and the first flag being a third value, and the first flag being the third value is used to indicate that the terminal device is not in the screen-off state. The terminal device can determine whether it is in the screen-off state through the first flag, and enter a low-power consumption mode upon detecting that the screen is locked and is not currently in the screen-off state, thereby maintaining low-power operation of the terminal device.

[0019] In a second aspect, embodiments of the present application provide a resource scheduling apparatus, comprising units for executing the method described in the first aspect. The apparatus may be configured to execute the method described in the first aspect. For a description of the units in the apparatus, refer to the description of the first aspect above and are omitted for brevity.

[0020] The method described in the first aspect above can be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above functions. For example, a processing module or unit, a display module or unit, etc.

[0021] In a third aspect, the present application provides a terminal device comprising a memory and one or more processors; wherein the memory is used to store computer program code, and the computer program code comprises computer instructions; when the computer instructions are executed by the processor, the terminal device executes any one of the methods in the first aspect.

[0022] In a fourth aspect, the present application provides a computer-readable storage medium comprising computer instructions. When the computer instructions are executed on a terminal device (such as a computer), the terminal device executes the method of the first aspect and any possible design thereof.

[0023] In a fifth aspect, the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the method according to the first aspect and any possible design thereof.

[0024] In a sixth aspect, the present application provides a chip system comprising one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via a circuit. The chip system can be applied to a terminal device comprising a communication module and a memory. The interface circuit is configured to receive a signal from the memory of the terminal device and send the received signal to the processor, the signal comprising a computer instruction stored in the memory. When the processor executes the computer instruction, the terminal device can perform the method of the first aspect and any possible design thereof.

[0025] It can be understood that the beneficial effects that can be achieved by the resource scheduling device of the second aspect, the terminal equipment of the third aspect, the computer-readable storage medium of the fourth aspect, the computer program product of the fifth aspect and the chip system of the sixth aspect provided above can be referred to the beneficial effects in the first aspect and any possible design method thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] FIG1 is a schematic diagram of the hardware structure of a terminal device provided in an embodiment of the present application;

[0027] FIG2 is a schematic diagram of a software architecture of a terminal device provided in an embodiment of the present application;

[0028] FIG3 is a schematic diagram of a software and hardware workflow when a terminal device schedules resources according to an embodiment of the present application;

[0029] FIG4 is a schematic diagram of an interface for controlling the sleep setting time and the screen off setting time provided in an embodiment of the present application;

[0030] FIG5 is a schematic diagram of a lock screen interface provided in an embodiment of the present application;

[0031] FIG6 is a schematic diagram of an interface for controlling the lock screen setting duration provided in an embodiment of the present application;

[0032] FIG7 is a schematic diagram of a flow chart of a resource scheduling method provided in an embodiment of the present application;

[0033] FIG8 is a flow chart of another resource scheduling method provided in an embodiment of the present application;

[0034] FIG9 is a flow chart of another resource scheduling method provided in an embodiment of the present application;

[0035] FIG10 is a flow chart of another resource scheduling method provided in an embodiment of the present application;

[0036] FIG11 is a schematic diagram of the structure of a resource scheduling device provided in an embodiment of the present application;

[0037] FIG12 is a schematic diagram of the hardware structure of another terminal device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0038] In order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, words such as "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. For example, the first value and the second value are merely used to distinguish different values ​​and do not limit their order. Those skilled in the art will understand that words such as "first" and "second" do not limit the quantity and execution order, and words such as "first" and "second" do not necessarily limit different values.

[0039] It should be noted that, in this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described in this application as "exemplary" or "for example" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0040] In this application, "at least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, a and b, a and c, b and c, or a, b and c, where a, b, c can be single or multiple.

[0041] In one implementation, when a terminal device enters a sleep state, the terminal device may perform one or more of the following steps and save the process context. For example, the steps may include: suspending an application, suspending a driver, controlling hardware to enter low power consumption, suspending an operating system and a central processing unit (CPU), instructing a random access memory (RAM) to suspend read and write processes, or setting a CPU interrupt response. When the terminal device exits the sleep state (or can also be understood as waking up), the terminal device may load the process context to restore the state of the terminal device before the sleep state.

[0042] It is understandable that when entering the sleep state, the terminal device requires higher power consumption for processes such as saving the process context. When the terminal device enters the sleep state in low-power mode, the CPU performance in low-power mode is weak, and it may take a long time to enter the sleep state or be unable to enter the sleep state. In addition, when exiting the sleep state, the terminal device will enter the pre-sleep mode, that is, the low-power mode, which has weak performance and processes such as loading the process context also take a long time. When the terminal device exits the sleep state in low-power mode, it may also take a long time to exit the sleep state.

[0043] In view of this, an embodiment of the present application provides a resource scheduling method, whereby the terminal device can be in a high power consumption mode before entering the sleep state so as to quickly enter the sleep state, and can also be in a high power consumption mode before exiting the sleep state so as to quickly make a wake-up response, thereby enabling the terminal device to quickly enter and exit the MS state.

[0044] The above-mentioned terminal devices can be referred to as terminals, user equipment (UE), mobile stations (MS), mobile terminals (MT), etc. For example, the terminal devices can be mobile phones, smart TVs, wearable devices, tablet computers (Pad), computers with wireless transceiver functions, virtual reality (VR) terminal devices, augmented reality (AR) terminal devices, wireless terminals in industrial control, wireless terminals in self-driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, etc. The embodiments of the present application do not limit the specific technologies and specific device forms adopted by the terminal devices.

[0045] In order to better understand the embodiment of the present application, the structure of the terminal device of the embodiment of the present application is introduced below. For example, Figure 1 is a schematic diagram of the hardware structure of a terminal device provided in the embodiment of the present application.

[0046] As shown in Figure 1, the terminal device 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, an antenna 2, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, an indicator 192, a camera 193, and a display screen 194, etc.

[0047] The sensor module 180 may include one or more of the following, for example: a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, or a bone conduction sensor.

[0048] It is understood that the structures illustrated in the embodiments of the present application do not constitute specific limitations on the terminal device. In other embodiments of the present application, the terminal device 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.

[0049] The processor 110 may include one or more processing units. The different processing units may be independent devices or integrated into one or more processors. The processor 110 may also be provided with a memory for storing instructions and data.

[0050] The USB interface 130 is an interface that complies with USB standards and specifications, and may be a Mini USB interface, a Micro USB interface, a USB Type-C interface, or the like. The USB interface 130 can be used to connect a charger to charge the terminal device, or to transfer data between the terminal device and peripheral devices. It can also be used to connect headphones to play audio. The interface can also be used to connect other devices, such as AR devices.

[0051] 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. The power management module 141 is used to connect the charging management module 140 to the processor 110.

[0052] The wireless communication function of the terminal device can be implemented through the antenna 2, the wireless communication module 160 and the baseband processor.

[0053] Antenna 2 is used to transmit and receive electromagnetic wave signals. The antenna in the terminal device can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization.

[0054] The wireless communication module 160 can provide wireless communication solutions applied to terminal devices, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), etc.

[0055] The modem may include a modulator and a demodulator. The modulator is used to modulate the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After being processed by the baseband processor, the low-frequency baseband signal is passed to the application processor. The application processor outputs a sound signal through an audio device (not limited to a speaker, a receiver, etc.) or displays an image or video through the display screen 194. In some embodiments, the modem may be an independent device. In other embodiments, the modem may be independent of the processor 110.

[0056] The terminal device implements display functions through a GPU, display screen 194, and an application processor. The GPU is a microprocessor for image processing that connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering.

[0057] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. In some embodiments, the terminal device may include 1 or N display screens 194, where N is a positive integer greater than 1.

[0058] The terminal device can realize the shooting function through the ISP, camera 193, video codec, GPU, display 194 and application processor.

[0059] The camera 193 is used to capture static images or videos. In some embodiments, the terminal device may include 1 or N cameras 193, where N is a positive integer greater than 1.

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

[0061] The internal memory 121 can be used to store computer executable program codes, which include instructions. The internal memory 121 can include a program storage area and a data storage area.

[0062] The terminal device can implement audio functions such as music playback and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, the headphone jack 170D, and the application processor.

[0063] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The speaker 170A, also known as the "speaker", is used to convert audio electrical signals into sound signals. The terminal device can listen to music or listen to hands-free calls through the speaker 170A. The receiver 170B, also known as the "earpiece", is used to convert audio electrical signals into sound signals. When the terminal device answers a call or voice message, the voice can be heard by placing the receiver 170B close to the human ear. The headphone jack 170D is used to connect a wired headset. The microphone 170C, also known as the "microphone" or "microphone", is used to convert sound signals into electrical signals. In an embodiment of the present application, the terminal device may have a microphone 170C.

[0064] Keys 190 include a power button, a volume button, and other buttons. Keys 190 can be mechanical or touch-sensitive. The terminal device can receive key inputs and generate key signal inputs related to user settings and function control of the terminal device. Indicator 192 can be an indicator light that can be used to indicate charging status, battery level changes, messages, missed calls, notifications, and the like.

[0065] In addition, the device also runs an operating system on top of the above components, such as the iOS operating system, the Android operating system, or the Windows operating system. Applications can be installed and run on the operating system.

[0066] The software system of the terminal device can adopt a layered architecture, event-driven architecture, micro-kernel architecture, microservice architecture, or cloud architecture, etc., which will not be described here.

[0067] For example, FIG2 is a schematic diagram of a software architecture of a terminal device provided in an embodiment of the present application.

[0068] Before introducing the software architecture used in the embodiment of the present application, the parameters used in the resource scheduling method can be introduced:

[0069] Long-term turbo power consumption (power limit 1, PL1), or it can also be called the maximum power value, refers to the power consumption of the CPU under normal load, which is equivalent to the thermal design power consumption. The CPU's operating power consumption does not exceed PL1 most of the time.

[0070] Short-term turbo power consumption (power limit 2, PL2) refers to the highest power consumption mode that the CPU can reach for a short period of time, which has a duration limit. Generally, PL2 is greater than PL1.

[0071] The CPU energy performance preference (EPP) reflects the CPU's scheduling tendency and ranges from 0 to 255. A smaller EPP indicates a high-performance CPU; a higher EPP indicates a low-power CPU.

[0072] A layered architecture divides software into several layers, each with distinct roles and responsibilities. Layers communicate with each other via software interfaces. In some embodiments, the Windows system is divided into user mode and kernel mode. User mode includes the application layer, while kernel mode includes the OS layer.

[0073] As shown in Figure 2, the application layer includes applications such as music, video, games, office, social, and environment subsystems, as well as a computer manager. The computer manager may include a scene recognition engine and a scheduling engine. The scene recognition engine may include a system probe module, etc. The specific name of the computer manager application is not limited in this embodiment of the application.

[0074] The figure only shows some applications. The application layer can also include other applications, such as shopping applications, browsers, etc., which are not limited in this application.

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

[0076] The scenario recognition engine identifies the user scenario of the terminal device and determines a basic scheduling policy that matches that user scenario. The scheduling engine obtains the load of the terminal device and, based on the load and the basic scheduling policy, determines a specific scheduling policy that matches the actual operating conditions of the terminal device. Details on the scenario recognition engine and scheduling engine are provided below and are not described here.

[0077] The user state also includes the application programming interface (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 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. When Windows starts, ntdll.dll resides in a specific write-protected area in the memory, preventing other programs from occupying this memory area.

[0078] User state can also include: 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.

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

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

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

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

[0083] The power manager can manage the power state changes of all devices that support power state changes, and can also detect and report the sleep state, wake-up state, lock screen state, unlock state, screen off state, and screen on state of terminal devices.

[0084] The system event-driven node can interact with the kernel and drivers. For example, it can interact with the graphics card driver and, upon determining a GPU video decoding event, report the event to the scene recognition engine. Alternatively, the system event-driven node can interact with the power manager and report device status to the system probe module.

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

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

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

[0088] The hardware layer may include hardware such as a GPU, a CPU, a microphone, a camera, and a keyboard, or the hardware layer may also include a mouse (not shown in FIG. 2 ).

[0089] In a possible implementation, the terminal device may also include a hardware abstraction layer (HAL), not shown in Figure 2. The HAL can be a kernel-mode module that hides various 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 should be noted that to maintain Windows portability, Windows internal components and user-written device drivers do not directly access hardware, but instead call routines in the HAL.

[0090] In a possible implementation, the terminal device may also include a firmware layer, not shown in Figure 2. The firmware layer may include a basic input and output system (BIOS). The BIOS is a set of programs embedded in 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 startup programs. It can read and write specific system setting information from the complementary metal oxide semiconductor (CMOS). Its main function is to provide the lowest-level and most direct hardware settings and control for the computer. The Intel DTT driver can send instructions to the CPU through the BIOS.

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

[0092] For example, FIG3 is a schematic diagram of the software and hardware workflow when a terminal device schedules resources according to an embodiment of the present application.

[0093] As shown in Figure 3, the application layer's scene recognition engine includes a system probe module, a scene recognition module, and a basic policy matching manager. The scene recognition module can interact with the system probe module and the basic policy matching manager, respectively. The scene recognition module can send a request to the system probe module to obtain probe status. The system probe module can obtain the operating status of the terminal device. 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.

[0094] 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 information such as the remaining battery charge and the power mode, which 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.

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

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

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

[0098] The audio and video status probe can subscribe to audio and video events in kernel mode and determine the current audio and video events on the terminal device based on the callback function returned by kernel mode. Audio and video events can include GPU decoding events, for example. 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, which then forwards the request to the graphics driver. The graphics driver can monitor the GPU status and, upon detecting that the GPU is performing decoding operations, send a callback function back to the audio and video status probe through the OsEventDriver node.

[0099] The system event probe can subscribe to system events in kernel mode and determine system events based on the callback function fed back by kernel mode. System events can include one or more of the following, such as device status events, window change events, process creation events, thread creation events, etc. Device status events can include screen off events, screen on events, screen lock events, unlock events, sleep events, wake-up events, etc. The meaning of each of the above device status events can be found in the descriptions of the embodiments corresponding to Figures 4-6.

[0100] For example, a system event probe can send a request to subscribe to a process creation event to the OsEventDriver node, which then forwards the request to the process manager. After creating a process, the process manager can use the OsEventDriver node to send a callback function back to the system event probe. For another example, the system event probe can also send a request to subscribe to a focus window change event to the API module. The API module can monitor whether the focus window on the terminal device has changed and, if so, send a callback function back to the system event probe.

[0101] In the embodiment of the present application, the system event probe may also send a request to subscribe to device status events through the OsEventDriver node. The OsEventDriver node forwards the request to subscribe to device status events to the power manager. For example, the power manager may use the OsEventDriver node. When the power manager detects a change in the system status, it may send a callback function back to the system event probe through the OsEventDriver node to notify the system status.

[0102] As can be seen, the system probe module subscribes to various terminal device events in kernel mode and then determines the terminal device's operating status based on the callback function fed back by kernel mode, thus obtaining the probe status. After obtaining the probe status, the system probe module can feed it back to the scene recognition module. After receiving the probe status, the scene recognition module can use it to determine the user scenario of the terminal device.

[0103] For example, when the system probe module detects a lock screen event and feeds back to the scene recognition module that the current state is lock screen, the scene recognition module can identify an idle scene that can currently be in the user scene based on the lock screen state.

[0104] User scenarios reflect current user needs. For example, user scenarios can be categorized by power consumption: low-power mode scenarios and high-power mode scenarios. Low-power mode scenarios include idle scenarios, browser scenarios, video scenarios, office scenarios, and social scenarios. High-power mode scenarios include gaming scenarios, compilation scenarios, meeting scenarios, and default scenarios.

[0105] For example, when the scene recognition module recognizes that the terminal device is off or locked, it determines that the terminal device can be in an idle scene to reduce the power consumption of the terminal device. For another example, when the scene recognition module recognizes that the focus window is a window of a video application, it determines that the terminal device is in a video scene, which means that the user needs to use the video application to watch and browse videos. For another example, when the scene recognition module recognizes that the focus window is a WeChat window, it determines that the terminal device is in a video scene. TM When a chat window is displayed, it is determined that the terminal device is in a social scene.

[0106] Furthermore, the scenario recognition module may also send the user scenario to the basic policy matching manager. The basic policy matching manager may determine a basic scheduling policy based on the user scenario. The basic policy matching manager may feedback the basic scheduling policy to the scenario recognition module. The scenario recognition module may send the basic scheduling policy and user scenario to the scheduling engine of the application layer.

[0107] As shown in Figure 3, the scheduling engine includes a load controller, a chip policy integrator, and a scheduling executor. The load controller can receive the basic scheduling policy and user scenario sent by the scenario recognition module. The load controller can also obtain the system load from the system probe module and adjust the basic scheduling policy based on the system load and user scenario to obtain the actual scheduling policy. The actual scheduling policy includes the OS scheduling policy and the first CPU power consumption scheduling policy (also referred to as the first sub-policy). The load controller can send the OS scheduling policy to the scheduling executor, which then performs scheduling based on the OS scheduling policy. The OS scheduling policy is used to adjust the process priority and I / O priority of the focus process. For example, the scheduling executor can send an instruction to the process manager to adjust the process priority of the focus process. In response to this instruction, the process manager adjusts the process priority of the focus process. For another example, the scheduling executor can send an instruction to the I / O manager to adjust the I / O priority of the focus process. In response to this instruction, the I / O manager adjusts the I / O priority of the focus process.

[0108] The load controller can also send a first CPU power consumption scheduling policy to the chip policy fusion device. The chip policy fusion device can obtain a second CPU power consumption scheduling policy (also called a second sub-policy) based on the CPU chip platform type and the first CPU power consumption scheduling policy.

[0109] There are two main types of CPU chip platforms: Advanced Micro Devices (Advanced Micro Devices, AMD) CPU, or also referred to as the first type; and, The CPU of the second type can also be called the second type. These two types of CPUs have different ways of adjusting CPU power consumption and need to be distinguished.

[0110] If the CPU chip platform type is type 1, the scheduler executor may send an EPP adjustment instruction to the power manager to adjust the CPU's EPP. Additionally, the scheduler executor may send PL1 and PL2 adjustment instructions to the OS2SOC driver node to adjust the CPU's PL1 and PL2.

[0111] If the chip platform type of the CPU is the second type, the scheduling executor can send the second CPU power consumption scheduling policy to the Intel DTT driver through the WMI plug-in. The second CPU power consumption scheduling policy may include the minimum value of PL1, the maximum value of PL1, PL2, the duration of PL2 and EPP. Intel DTT drives the CPU to run based on the second CPU power consumption scheduling policy.

[0112] The following specific embodiments are used to describe in detail the technical solution of the present application and how the technical solution of the present application solves the above technical problems. The following specific embodiments can be implemented independently or in combination with each other. For the same or similar concepts or processes, some embodiments may not be described in detail.

[0113] To facilitate understanding of the embodiments of the present application, the various types of device states involved in the embodiments of the present application may be explained.

[0114] 1. Sleep and wake-up

[0115] Sleep can be understood as a state in which the device remains powered on while reducing power consumption. In sleep mode, the device retains process context within the process, powering only the memory and powering off other components, thereby reducing power consumption. While in sleep mode, the device requires power. If the device loses power or runs out of power, the data in its memory will be lost, and even if it is powered on, it will not be able to resume its previous operating state.

[0116] Wake-up can be understood as the return of a terminal device from sleep to active state. During the wake-up process, the terminal device can restore device power and load the process context stored in memory, allowing the terminal device to return to its pre-sleep state after wake-up.

[0117] For example, when the terminal device detects that the user clicks the sleep button or the terminal device does not detect the user's operation within the set sleep time, the terminal device can control the display screen to turn off, then instruct the system to enter the sleep state, and save the process context. When the terminal device is in the sleep state, when the terminal device detects the user's wake-up operation, the terminal device can control the display screen to turn on, wake up the system, load the process context, and the wake-up operation may include, for example, clicking the mouse, moving the mouse, tapping the keyboard, etc. Among them, the set sleep time can be understood as the time from the time when the user has no operation to the time when the terminal device enters the sleep state.

[0118] Among them, when a process is executing, the values ​​in all CPU registers, the process status, and the contents in the stack can be called the process context.

[0119] For example, the user can control the sleep setting duration through operation. Figure 4 is a schematic diagram of an interface for controlling the sleep setting duration and the screen off setting duration provided in an embodiment of the present application. The interface described in the embodiment of the present application will be illustrated using a computer as an example terminal device, and this example does not constitute a limitation on the embodiment of the present application.

[0120] When the terminal device detects that the user right-clicks on the desktop and opens the display settings function, the terminal device can display an interface as shown in Figure 4a, which can display a settings window. The settings window is used to set the functions of the terminal device, such as display, sound, notification and operation, power and sleep functions. The settings window can display multiple buttons for modifying system settings (such as the buttons within the dotted box 401). For example, the settings window can display: power and sleep buttons 402.

[0121] In the interface shown in a of FIG4 , when the terminal device detects a user clicking the power and sleep button 402, the terminal device may display the interface shown in b of FIG4 . In the interface shown in b of FIG4 , the settings window in the interface may display content for controlling the sleep setting duration and the screen off setting duration. For example, the settings window may display an option box 403 for controlling the sleep setting duration.

[0122] The user can control the sleep setting time by clicking option box 403. For example, when the words "5 minutes" are displayed in option box 403, it can be understood that the terminal device can enter sleep if no user operation is detected within 5 minutes, and the sleep setting time can be 5 minutes.

[0123] 2. Turn off the screen and turn on the screen

[0124] "Screen off" means the terminal device's display screen is powered off. When the screen is off, the brightness of the terminal device's display screen is lower than the preset brightness. "Screen on" means the terminal device's display screen is powered on. When the screen is on, the brightness of the terminal device's display screen is higher than the preset brightness. "Power on" means the current is greater than the preset current value, and "power off" means the current is less than the preset current value.

[0125] For example, when the terminal device detects that the user clicks the sleep button or the terminal device does not detect any user operation within the screen-off time setting, the terminal device can control the display screen to turn off. When the terminal device is in the screen-off state, when the terminal device detects a user operation with a mouse or keyboard, etc., the terminal device can control the display screen to turn on.

[0126] For example, users can also control the duration of the terminal device entering the screen-off state by setting a setting. As shown in the interface in Figure 4(b), the settings window of the interface may also display an option box 404 for controlling the screen-off setting duration. The screen-off setting duration can be the time from the time when the user has no operation until the terminal device enters the screen-off state.

[0127] The user can control the screen off time by clicking option box 404. For example, when the words "3 minutes" are displayed in option box 404, it can be understood that the terminal device can turn off the screen if no user operation is detected within 3 minutes, and the screen off time can be set to 3 minutes.

[0128] In one implementation, the terminal device can turn off the screen before entering the sleep state, or it can be understood that the screen-off event can occur before the sleep event, that is, the sleep setting duration can be greater than the screen-off setting duration.

[0129] 3. Lock and unlock the screen

[0130] The lock screen can be understood as the state in which the terminal device displays the lock screen interface. In the lock screen state, the programs in the terminal device remain running. Among them, the display of the lock screen interface can ensure the data security of the terminal device. The lock screen interface can be the interface shown in Figure 5 a. For example, Figure 5 is a schematic diagram of a lock screen interface provided in an embodiment of the present application. As shown in Figure 5 a, the lock screen interface can display content such as time and date.

[0131] Unlocking means releasing the lock on the terminal device's display screen. For example, in the interface shown in Figure 5(a), when the terminal device receives an operation such as pressing the Enter button on the user's keyboard or sliding the mouse upward, the terminal device can be unlocked and restored to the interface displayed before the lock screen, such as the interface shown in Figure 5(b).

[0132] Alternatively, as shown in the interface a in FIG5 , when the terminal device receives an operation such as the user inputting the enter button on the keyboard or sliding the mouse upward, and the terminal device determines that a lock screen password has been set, the terminal device can display an unlock interface as shown in FIG5 c, and the interface shown in FIG5 c can display one or more of the following, for example: an account name (such as user 500), a text box for inputting a lock screen password, a power button, or a button for indicating the network status, etc. Further, the terminal device can release the lock screen and display the interface as shown in FIG5 b when it detects that the user enters a password in the text box and triggers an operation such as enter.

[0133] For example, when the terminal device does not detect user operation within the lock screen setting time, or detects that the user enters win+L on the keyboard, the terminal device can control the display screen to lock the screen and display the lock screen interface. When the terminal device is in the lock screen, when the terminal device detects the lock screen operation, the terminal device can unlock the display screen so that the display screen returns to the interface displayed before the lock screen. Among them, the unlocking operation can be: the user enters the enter button on the keyboard, or slides the mouse up, etc., or it can also be an operation such as the user entering a password in the unlock interface. Among them, the lock screen setting time can be understood as the time from the time when the user has no operation to the time when the terminal device enters the lock screen state.

[0134] For example, the user can also control the lock screen setting time of the terminal device through operation. Figure 6 is a schematic diagram of an interface for controlling the lock screen setting time provided in an embodiment of the present application.

[0135] When a terminal device detects the user inputting the win+R key on the keyboard, the terminal device may display the interface shown in Figure 6a. This interface may include a run window, which is used to open the corresponding program, folder, document, or network resource based on the input name. The run window may also display the "regedit" command, which is used to open the registry on the terminal device. Alternatively, if the run window does not display the user command, the user can enter "regedit" in the text box of the run window.

[0136] In the interface shown in a of Figure 6, when the word "regedit" is displayed in the run window and the terminal device detects that the user clicks the OK button, the terminal device can display the interface shown in b of Figure 6. The interface shown in b of Figure 6 can display a registry editor window, which is used to view or edit the registry. For example, various types of registries can be displayed in the registry editor window, such as registry directory 1, registry directory 2, and registry 1 and registry 2 under registry directory 1, etc.

[0137] As shown in the interface in FIG6 b, when the terminal device detects that the user has entered "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" in the path text box, the terminal device queries the path entered by the user and displays the interface shown in FIG6 c. As shown in FIG6 c, the registry editor window of this interface may display a registry 601, which is used to control the lock screen setting duration. This registry 601 may display the words "InactivityTimeoutSecs".

[0138] As shown in the interface c in Figure 6, when the terminal device detects that the user double-clicks the registration form 601, the terminal device can display the interface shown in Figure 6 d. The interface shown in Figure 6 d can display: a lock screen setting duration control window, which is used to control the lock screen setting duration. The lock screen setting duration control window may include: a text box 602, which is used to enter the lock screen setting duration. Further, when the terminal device detects that the user enters the lock screen setting duration such as "120" in the text box 602 and clicks the confirmation button, the terminal device can record the lock screen setting duration as 120 seconds, and the lock screen setting duration can take effect after restarting the system.

[0139] In a possible implementation, when there is no registry 601 in the interface shown in c in Figure 6, the user can also create a new registry by right-clicking, for example, creating a registry named InactivityTimeoutSecs with a lock screen setting duration of 120 seconds to modify the lock screen setting duration.

[0140] Based on the description of different device states above, in one implementation, the terminal device can turn off the screen before entering the sleep state, that is, the lock screen setting duration is less than the sleep setting duration. However, locking the screen does not necessarily cause the terminal device to enter the sleep state, and turning off the screen does not cause the terminal device to enter the sleep state.

[0141] A terminal device with the screen off or locked can enter an idle scenario. The idle scenario can be a scenario where no user operation is detected for a duration that exceeds the set screen off duration or screen lock duration. For example, if no user use of the mouse or keyboard is detected for a duration that exceeds the set screen off duration or screen lock duration, the device can enter low power mode in the idle scenario.

[0142] A terminal device with the screen on and / or unlocked can enter scene recognition. For example, the terminal device detects the scene it is in based on the windows, applications or running processes currently opened on the device. The scene recognition method can be found in the description of the embodiment corresponding to Figure 3 and will not be repeated here.

[0143] In conjunction with the description of different device states above, in order to solve the problem of a long time spent by a terminal device entering and exiting a sleep state in a low-power mode, an embodiment of the present application provides a resource scheduling method so that the terminal device meets the following conditions:

[0144] Condition 1: The terminal device is in high power consumption mode when the screen is off.

[0145] In one implementation, the terminal device can send a command set to an idle scene when the screen is turned off, so that the terminal device is in a low-power mode. When the terminal device enters a sleep state in a low-power mode, it may take a longer time to enter sleep.

[0146] In another implementation, when the terminal device is in low-power mode, the terminal device can switch from low-power mode to high-power mode when the screen is off. Alternatively, when the terminal device is in high-power mode, the terminal device can remain in high-power mode when the screen is off, thereby ensuring that the terminal device enters a sleep state in high-power mode and reducing the time it takes to enter the sleep state. For the specific process, please refer to the embodiment corresponding to any of Scenario 1 to Scenario 4.

[0147] Among them, the power consumption set in high power consumption mode is greater than the preset power consumption, for example, the maximum power consumption in high power consumption mode is greater than the preset power consumption; the power consumption set in low power consumption mode is less than the preset power consumption, for example, the maximum power consumption in low power consumption mode is less than the preset power consumption.

[0148] Condition 2: If the terminal device detects that the screen is locked and is currently off, it does not report the lock screen event.

[0149] In one implementation, when a terminal device detects a lock screen and is currently off, it reports the lock screen event. Based on the lock screen event, the terminal device issues a command set to the idle scenario, putting the terminal device into low-power mode. This can result in a longer sleep time when the terminal device enters sleep mode in low-power mode. Reporting can be understood as one module in the terminal device sending data to another module.

[0150] In another implementation, when a terminal device enters sleep mode in the order of screen off and screen lock, the terminal device can be in high power consumption mode when the screen is off. If the screen lock is detected and the device is currently in the screen off state, the lock screen event is not reported, so that the terminal device remains in high power consumption mode. For the specific process, please refer to the embodiment corresponding to scenario 2.

[0151] Condition 3: When the terminal device detects that the screen is on and is currently locked, it does not report the screen-on event with the locked screen status.

[0152] In one implementation, when the terminal device detects that the screen is on and is currently in the locked state, the terminal device will report a screen-on event with the locked screen status. Based on the locked screen status, the terminal device will issue a command set to the idle scene, so that the terminal device is in low-power mode. When the terminal device enters the sleep state in the low-power mode, it may take a longer time to enter sleep.

[0153] In another implementation, when a terminal device switches from a locked screen to a bright screen, the terminal device may determine that the screen is currently locked upon detecting the bright screen. The terminal device may not report the bright screen event that carries the locked screen status, thereby maintaining the terminal device in a high power consumption mode. For the specific process, please refer to the embodiments corresponding to Scenario 2 or Scenario 3.

[0154] In combination with the various device states described above, embodiments of the present application provide three device state changes when entering and exiting the sleep state (see scenarios 1 to 3), and one device state change without entering the sleep state (see scenario 4).

[0155] In the embodiments corresponding to scenarios 1 to 4, the low power consumption mode is used as the first mode and the high power consumption mode is used as the second mode for example. In the first mode, the limit power value of the terminal device is the first power consumption value, and in the second mode, the limit power value of the terminal device is the second power consumption value, and the first power consumption value is less than the second power consumption value. In addition, the chip platform type of the CPU is the first type for example. For example, the computer manager can send an instruction to adjust the EPP to the power manager to adjust the EPP of the CPU. The computer manager can also send instructions to adjust PL1 and PL2 to the system and chip driver node to adjust the PL1 and PL2 of the CPU, which is not limited in the embodiments of the present application. Among them, the first power consumption value or the second power consumption value is PL1.

[0156] Scenario 1: Screen off -> Sleep -> Screen on -> Wake up

[0157] In an embodiment of the present application, the terminal device can enter the screen-off mode in the first mode, and switch from the first mode to the second mode when the screen is off, and then enter the sleep state; when the terminal device detects a wake-up operation, it controls the display screen to light up, and performs scene recognition after waking up the terminal device.

[0158] It is understandable that the time interval between waking up and turning on the screen is very small, or that waking up and turning on the screen can occur simultaneously. Therefore, the embodiments of the present application do not specifically limit the order of waking up and turning on the screen. For example, the terminal device can wake up first and then turn on the screen, or turn on the screen first and then wake up, or turn on the screen and wake up simultaneously. Scenarios 1 to 3 in the embodiments of the present application are illustrated by first turning on the screen and then waking up.

[0159] At this time, scenario one can be: first mode -> screen off -> switch to second mode -> sleep -> screen on -> wake up

[0160] For scenario one, the terminal device can turn off the screen after the user has not operated for a period of time equal to the screen-off setting time, and can sleep after the user has not operated for a period of time equal to the sleep setting time.

[0161] For example, FIG7 is a flow chart illustrating a resource scheduling method according to an embodiment of the present application. In the embodiment corresponding to FIG7 , the terminal device may be provided with modules such as a process manager, a power manager, a system event driver node, a computer manager, and a system and chip driver node. The modules included in the computer manager can be found in the embodiment corresponding to FIG3 and will not be described in detail here.

[0162] As shown in FIG7 , the resource scheduling method may include the following steps:

[0163] S701: The terminal device is started, but the first application is not running.

[0164] When the first application is not running, the terminal device may be in the first mode, and the limit power value is the first power consumption value. The first application may be an application started in the second mode, for example, a game application, a compilation application, a conference application, etc.

[0165] In a possible implementation, the terminal device can issue a first policy when the first application is not running, and the first policy includes a first power consumption value. In conjunction with the embodiment corresponding to FIG3 , the process of issuing the first policy can be as follows: the process manager can return the application usage in the form of a first event to the system event probe in the computer manager through the callback function of the system event driver node, and the system event probe reports the first event to the scene recognition module. The scene recognition module identifies that the first application is not currently running based on the first event reported by the system event probe. When the scene recognition module determines that the terminal device is in the first mode, such as the first scene, the scene recognition module in the terminal device can send the first scene to the basic policy matching manager; the basic policy matching manager can determine the first policy corresponding to the first scene and feedback the first policy to the scene recognition module; the scene recognition module can send the first policy to the scheduling engine of the application layer, and the scheduling engine further sends the first policy to the system and chip driver nodes and the power manager respectively.

[0166] The first policy may include one or more of the following: scenario identification, system load, or power consumption. The load condition may include one or more of the following: CPU load, disk load, GPU 3D usage, GPU video usage, or load level; and the parameters indicating power consumption may include one or more of the following: PL1 (or first power consumption value), PL2, or EPP.

[0167] In a possible implementation, the scheduling engine may also adjust the first strategy according to the load conditions to obtain a first target strategy, and then issue a more accurate first target strategy. This is not specifically limited in the embodiments of the present application.

[0168] S702: At the first time point, the terminal device turns off the screen.

[0169] Optionally, when the user does not perform any operation, the terminal device may turn off the screen when the user does not perform any operation for a set period of time.

[0170] Optionally, in response to a screen-off operation, the terminal device turns off the screen. The screen-off operation may include a user clicking a sleep button, a screen-off button, or a user double-clicking a first button, wherein the program code corresponding to the first button is used to trigger the terminal device to turn off the screen.

[0171] Optionally, when no application is in the DISPLAY state for a period of time equal to the screen-off setting, the terminal device turns off the screen. Wherein, DISPLAY can be understood as a video stream.

[0172] For example, when the terminal device's limit power value is the first power consumption value, the terminal device may switch from the first mode to the second mode upon detecting screen off, and issue a second policy, the second policy including the second power consumption value. The second power consumption value is the terminal device's limit power value PL1 in the second mode, and the second power consumption value is greater than the first power consumption value.

[0173] In combination with the embodiment corresponding to Figure 3, the process of issuing the second policy can be: when the power manager detects that the screen is turned off, it can return the screen off event to the system event probe in the computer manager through the callback function of the system event driver node, and the system event probe reports the screen off event to the scene recognition module. When the scene recognition module of the terminal device receives the screen off event reported by the system event module, it can determine that it can switch from the first mode to the second mode, for example, determine that it is currently in the second scene; the scene recognition module can send the second scene to the basic policy matching manager; the basic policy matching manager can determine the second policy corresponding to the second scene, and feedback the second policy to the scene recognition module; the scene recognition module can send the second policy to the scheduling engine of the application layer, and the further scheduling engine will issue the second policy to the system and chip driver nodes and the power manager respectively.

[0174] In a possible implementation, the scheduling engine may also adjust the second strategy according to the load conditions to obtain a second target strategy, and then issue a more accurate second target strategy. This is not specifically limited in the embodiments of the present application.

[0175] S703. At the second time point, the terminal device enters a sleep state.

[0176] Between the first time point and the second time point, the terminal device is in the second mode, and the limit power value in the second mode is the second power consumption value.

[0177] The second time point can be understood as the time point corresponding to when the user's inactivity time reaches the set sleep time.

[0178] Exemplarily, the terminal device can enter the sleep state in the second mode and save the process context at the second power consumption value to reduce the time consumed in entering the sleep state. After the terminal device enters the sleep state, the power consumption of the terminal device is much lower than the first power consumption value.

[0179] In conjunction with the embodiment corresponding to FIG3 , before the power manager determines to enter sleep mode, it can notify the process manager and modules such as the system event-driven node through broadcasting; optionally, the process manager can save the process context, and the system event-driven node can return the sleep event to the system event probe in the computer manager through the callback function of the system event-driven node. The system event probe will not continue to report the sleep event to the scene recognition module. Furthermore, the power manager can enter sleep mode.

[0180] S704. At a third time point, in response to the wake-up operation, the terminal device turns on the screen.

[0181] The wake-up operation may be a user operation using a mouse or keyboard.

[0182] From the third time point to the end of the terminal device waking up and lighting up the screen, the limit power value of the terminal device is the second power consumption value.

[0183] 3 , when the power manager detects that the screen is on, it may return the screen-on event to the computer manager through the callback function of the system event-driven node, and the computer manager may determine to maintain the second strategy.

[0184] For example, in response to the wake-up operation, the terminal device can turn on the screen, maintain the second power consumption value, and load the process context at the second power consumption value to reduce the time taken to exit the sleep state. Furthermore, the terminal device can perform scene recognition after both turning on the screen and waking up are completed, for example, issuing the first policy when recognizing the current scene before turning off the screen.

[0185] Based on this, the terminal device can reduce the time spent in entering and exiting the sleep state by setting condition 1, thereby improving the user's experience of using the sleep state.

[0186] Scenario 2: Screen off -> Lock screen -> Sleep -> Screen on -> Wake up -> Unlock

[0187] In an embodiment of the present application, the terminal device can enter the screen-off mode in the first mode and switch from the first mode to the second mode when the screen is off. When the lock screen is detected, the lock screen event is not reported, and then the terminal device enters the sleep state; when the terminal device detects a wake-up operation, the display screen is controlled to light up, the screen-lighting event is not reported, and the system is woken up and the terminal device is unlocked.

[0188] At this time, the second scenario can be: first mode -> screen off -> switch to second mode -> lock screen (do not report lock screen event) -> sleep -> screen on (do not report screen on event) -> wake up -> unlock

[0189] For scenario 2, Figure 8 is a flowchart of another resource scheduling method provided by an embodiment of the present application. In the embodiment corresponding to Figure 8, the terminal device can turn off the screen after the user has not operated for a period of time equal to the screen-off setting duration, go to sleep after the user has not operated for a period of time equal to the sleep setting duration, and lock the screen after the user has not operated for a period of time equal to the lock screen setting duration, where the lock screen setting duration is greater than the screen-off setting duration, and the screen-off setting duration is less than the sleep setting duration.

[0190] As shown in FIG8 , the resource scheduling method may include the following steps:

[0191] S801: The terminal device is started, but the first application is not running.

[0192] The steps described in S801 can refer to the description in S701 and will not be repeated here.

[0193] S802. At a fourth time point, in response to a screen-off operation, the terminal device turns off the screen.

[0194] The fourth time point may be similar to the description of the first time point, so the steps described in S802 may refer to the description in S702 and will not be repeated here.

[0195] In a possible implementation, when the terminal device detects that the screen is off, a screenoff flag may be set, with the screenoff value being true. A screenoff value of true indicates that the terminal device is in the screen-off state, and the terminal device may switch from the first mode to the second mode and issue a second policy. The process of the terminal device issuing the second policy can be seen in the steps shown in S702 and will not be repeated here.

[0196] S803. At the fifth time point, the terminal device locks the screen.

[0197] The fifth time point can be understood as the time point corresponding to when the user's inactivity time reaches the lock screen setting time.

[0198] In a possible implementation, the terminal device may also lock the screen at the fifth time point when detecting that the user inputs the win+L operation. The embodiment of the present application does not limit the method of locking the screen.

[0199] Refer to the description in condition 2. Since the lock screen state can cause the terminal device to enter the idle scene, the terminal device may not report the lock screen event when it detects that the screen is locked and is currently off, thereby avoiding the terminal device from switching from the second mode to the first mode.

[0200] For example, when the terminal device detects a lock screen event, it can determine whether the value of screenoff is true. When the value of screenoff is true, it can be determined that the terminal device is in the screen-off state. The terminal device may not report the lock screen event. For example, the terminal device ends the current judgment logic and returns to the function caller through return, avoiding the terminal device switching from the second mode to the first mode due to the reporting of the lock screen state.

[0201] In a possible implementation, when the terminal device detects a screen lock event and determines that the value of screenoff is not true, it can be determined that the terminal device is not in the screen off state. The terminal device can report the screen lock event and switch from the second mode to the first mode according to the screen lock event.

[0202] In combination with the embodiment corresponding to Figure 3, when the system probe module of the terminal device detects a lock screen event and determines that the value of screenoff is true according to the screenoff flag in S802, the system probe module in the computer manager may not report the lock screen event to the scene recognition module. In this scenario, the terminal device is still in the second mode.

[0203] In a possible implementation, when the terminal device detects a lock screen event, a lock screen (islocked) flag may be set, and the value of islocked is true. islocked is true to indicate that the terminal device is in a lock screen state.

[0204] S804. At the sixth time point, the terminal device enters a sleep state.

[0205] Between the fourth time point and the sixth time point, the limit power value of the terminal device is the second power consumption value.

[0206] The sixth time point may be understood as the time point corresponding to when the user's inactivity time reaches the set sleep time.

[0207] Exemplarily, the terminal device can enter the sleep state in the second mode and save the process context at the second power consumption value to reduce the time consumed in entering the sleep state. After the terminal device enters the sleep state, the power consumption of the terminal device is much lower than the first power consumption value.

[0208] S805. At the seventh time point, in response to the wake-up operation, the terminal device turns on the screen.

[0209] From the seventh time point to before the terminal device is unlocked, the terminal device is at a limit power value of the second power consumption value.

[0210] Refer to the description in condition 3. When the terminal device detects that the screen is on and is currently in the locked screen state, the terminal device will report the screen-on event with the locked screen state. Based on the locked screen state, the terminal device will issue a command set to the idle scene, so that the terminal device is in the first mode. When the terminal device enters the screen-on state from the locked screen, the terminal device may not report the screen-on event with the locked screen state when it detects the screen-on state and determines that it is currently in the locked screen state, so that the terminal device remains in the second mode.

[0211] In conjunction with the embodiment corresponding to Figure 3, when the system event probe detects a screen-on event, it can determine whether the value of the flag bit islocked carried in the screen-on event is true. If the value of islocked is true, the system event probe can determine that the terminal device is in the screen-locked state and does not report the screen-on event to the scene recognition module. At this time, the terminal device ends the current judgment logic and returns to the function caller through return, avoiding the terminal device switching from the second mode to the first mode due to the lock screen state carried in the screen-on event.

[0212] In a possible implementation, when the system event probe detects a screen-on event and determines that the value of islocked carried in the screen-on event is not true, it can be determined that the terminal device is not in a locked screen state. The system event probe can normally report the screen-on event to the scene recognition module, and the scene recognition module can perform scene recognition based on the screen-on event.

[0213] In a possible implementation, the terminal device may also set the value of islocked to false after not reporting the screen-on event. The value of islocked to false is used to clear the islocked flag to avoid affecting the next lock screen state.

[0214] Furthermore, after waking up the terminal device, the terminal device can unlock the terminal device based on an operation such as a user entering a password, and perform scene recognition after unlocking, for example, issuing a first policy when recognizing the first scene before the screen turns off. The terminal device can be in a busy state after unlocking, and perform scene recognition in the busy state.

[0215] Based on this, the terminal device can reduce the time spent entering and exiting the sleep state by setting conditions 1, 2, and 3 without changing the lock screen to enter the idle scene, thereby improving the user's experience of using the sleep state.

[0216] In combination with the embodiment corresponding to scenario two, the embodiments of the present application provide two examples, please refer to solution one and solution two for details.

[0217] Solution 1: The terminal device enters sleep mode from the default scenario, and no audio or video is played in the background.

[0218] Table 1 is a schematic diagram of a scene switching provided by an embodiment of the present application

[0219] As shown in Table 1, the terminal device can be in the second mode in the default scenario and in the first mode in the idle scenario.

[0220] Table 2 is a schematic diagram of device status changes provided in an embodiment of the present application.

[0221] Combined with Table 1 and Table 2, the terminal device can be in the default scene, enter the idle scene when no user operation on the terminal device is detected within 1 minute, and enter the sleep state after 5 minutes. The screen can be turned off before the terminal device enters the sleep state. At the moment the screen is turned off at 17:33:31, the current scene of the terminal device can be switched from the scene in the first mode to the scene in the second mode (such as the scene identifier is -1). Until it wakes up, the terminal device will not respond to the lock screen or the screen light state. The terminal device can remain in the second mode when entering and exiting the sleep state.

[0222] Solution 2: The terminal device enters sleep mode from the browser scene, and no audio or video is played in the background.

[0223] Table 3 is a schematic diagram of a scene switching provided by an embodiment of the present application

[0224] As shown in Table 1, the terminal device may be in the first mode in a browser scenario, in the second mode in a default scenario, and in the first mode in an idle scenario.

[0225] Table 4 is a schematic diagram of device status changes provided in an embodiment of the present application.

[0226] In combination with Table 3 and Table 4, the terminal device can be in a browser scene, enter an idle scene when no user operation on the terminal device is detected within 1 minute, and enter a sleep state after 4 minutes. The screen can be turned off before the terminal device enters the sleep state. At the moment the screen is turned off at 09:41:14, the scene of the terminal device can be switched from the scene in the first mode to the scene in the second mode (such as the scene identifier is -1). Until it wakes up, the terminal device will not respond to the lock screen or the screen light state. The terminal device can maintain the second mode when entering and exiting the sleep state. Furthermore, the terminal device can perform scene recognition after being unlocked, such as recognizing the browser scene before the screen is turned off.

[0227] Scenario 3: Lock screen -> Turn off screen -> Sleep -> Turn on screen -> Wake up -> Unlock

[0228] In an embodiment of the present application, the terminal device can enter the lock screen in the second mode, and switch from the second mode to the first mode when the screen is locked, and switch from the first mode to the second mode when the screen is detected to be off, and then enter the sleep state; when the terminal device detects a wake-up operation, it controls the display screen to light up, does not report the screen lighting event, wakes up the system, and unlocks the terminal device.

[0229] At this time, scenario three can be: second mode -> lock screen -> switch to first mode -> turn off screen -> switch to second mode -> sleep -> turn on screen (do not report the screen turn on event) -> wake up -> unlock

[0230] For scenario three, FIG9 is a flow chart of another resource scheduling method provided in an embodiment of the present application.

[0231] In the embodiment corresponding to Figure 9, the terminal device can be set to turn off the screen after the user has not operated for a period of time that reaches the screen-off setting period, to sleep after the user has not operated for a period of time that reaches the sleep setting period, and to lock the screen after the user has not operated for a period of time that reaches the lock screen setting period, the lock screen setting period is less than the screen-off setting period, and the screen-off setting period is less than the sleep setting period.

[0232] As shown in FIG9 , the resource scheduling method may include the following steps:

[0233] S901. The terminal device runs a first application.

[0234] When the terminal device runs the first application, the terminal device may be in the second mode and issue a second policy including a second power consumption value. The process of the terminal device issuing the second policy may be described in step S702 and will not be repeated here.

[0235] In a possible implementation, the terminal device may also enter the second mode after being powered on. The embodiment of the present application does not limit the manner in which the terminal device enters the second mode.

[0236] S902. At the eighth time point, the terminal device locks the screen.

[0237] The eighth time point can be understood as the time corresponding to when the user's inactivity time reaches the lock screen setting time.

[0238] Optionally, the terminal device may lock the screen when the user does not perform any operation for a period of time equal to the set lock screen time.

[0239] Optionally, the terminal device may also actively lock the screen when receiving the user input of win+L or the lock screen button on the keyboard, etc. The embodiment of the present application does not specifically limit this lock screen method.

[0240] The terminal device can switch from the second mode to the first mode when detecting the lock screen, and issue the first policy to enable the terminal device to enter the first mode. The process of the terminal device issuing the first policy can be referred to the description in S701 and will not be repeated here.

[0241] S903. At the ninth time point, in response to the screen-off operation, the terminal device turns off the screen.

[0242] The ninth time point can be understood as the time point corresponding to when the user's inactivity time reaches the screen-off setting time. Between the ninth time point and the eighth time point, the terminal device's limit power value is the first power consumption value, and the first power consumption value is less than the second power consumption value.

[0243] Optionally, when the terminal device determines in S901 that the first application is not running, the limit power value of the terminal device is the first power consumption value, and when the terminal device determines in S902 that the terminal device is locked, the limit power value of the terminal device is the first power consumption value. Further, when the terminal device determines in S903 that the terminal device is off, the terminal device can switch from the first mode to the second mode, that is, the limit power value of the terminal device between the ninth time point and the tenth time point can be the second power consumption value.

[0244] When the terminal device is in the first mode, the terminal device can switch from the first mode to the second mode when detecting that the screen is turned off, and issue the second policy. The process of the terminal device issuing the second policy can be referred to the description in S702 and will not be repeated here.

[0245] S904. At the tenth time point, the terminal device enters a sleep state.

[0246] Between the ninth time point and the tenth time point, the limit power value of the terminal device is the second power consumption value.

[0247] The tenth time point can be understood as the time point corresponding to when the user's inactivity time reaches the sleep setting time.

[0248] Exemplarily, the terminal device may enter a sleep state in the second mode and save the process context at the second power consumption value to reduce the time consumed in entering the sleep state. Furthermore, after the terminal device enters the sleep state, the power consumption of the terminal device is much lower than the first power consumption value.

[0249] S905. At the eleventh time point, in response to the wake-up operation, the terminal device lights up the screen.

[0250] After the eleventh time point, the limit power value of the terminal device is the second power consumption value.

[0251] The terminal device may not report the screen-on event when detecting the screen-on event. The process of not reporting the screen-on event can be found in the description of S805 and will not be repeated here.

[0252] Furthermore, after waking up the terminal device, the terminal device can unlock the terminal device based on the user entering a password, etc., and perform scene recognition after unlocking, for example, issuing a second strategy when recognizing the second scene currently before the lock screen.

[0253] Based on this, the terminal device can reduce the time spent entering and exiting the sleep state by setting conditions 1 and 3 without changing the lock screen to enter the idle scene, thereby improving the user's experience of using the sleep state.

[0254] In combination with the embodiment corresponding to scenario three, the embodiment of the present application provides an example, please refer to scenario three for details.

[0255] Solution 3: The terminal device enters sleep mode from the default scene lock screen.

[0256] Table 5 is a schematic diagram of a scene switching provided by an embodiment of the present application

[0257] Table 6 is a schematic diagram of device status changes provided in an embodiment of the present application.

[0258] Combined with Table 5 and Table 6, the terminal device can enter the idle scene under the lock screen when detecting the user input win+L operation, and enter the sleep state after a period of time. The screen can be turned off before the terminal device enters the sleep state, and at the moment of 10:41:36 when the screen is turned off, the scene in the first mode is switched to the scene in the second mode (such as the scene identifier is -1). Furthermore, the terminal device can perform scene recognition after unlocking and recognize the default scene.

[0259] Scenario 4: Screen off -> screen on

[0260] In an embodiment of the present application, the terminal device can enter the screen-off mode in the first mode and switch from the first mode to the second mode when the screen is off; when the terminal device detects a wake-up operation, it controls the display screen to light up and performs scene recognition.

[0261] At this time, the fourth scenario can be: first mode -> screen off -> switch to second mode -> screen on

[0262] For scenario 4, Figure 10 is a flow chart of another resource scheduling method provided in an embodiment of the present application. In the embodiment corresponding to Figure 10, the terminal device can turn off the screen after the user has not operated for a period of time that reaches the screen-off setting period.

[0263] As shown in FIG10 , the resource scheduling method may include the following steps:

[0264] S1001. The terminal device is started, but the first application is not running.

[0265] When the first application is not running, the terminal device may be in the first mode and issue a first policy, wherein the first policy includes a first power consumption value. The process of the terminal device issuing the first policy can be referred to the description in S701 and will not be repeated here.

[0266] S1002. At the twelfth time point, the terminal device turns off the screen.

[0267] The terminal device may issue the second policy when detecting that the screen is off. The triggering method of the screen off and the process of the terminal device issuing the second policy may refer to the description in S702 and will not be repeated here.

[0268] S1003. At the thirteenth time point, in response to the wake-up operation, the terminal device turns on the screen.

[0269] Between the thirteenth time point and the twelfth time point, the limit power value of the terminal device is the second power consumption value.

[0270] In response to the wake-up operation, the terminal device can turn on the screen and perform scene recognition after the screen is turned on. For example, when the first scene before the screen is turned off is recognized, the first strategy is issued.

[0271] Based on this, the terminal device can reduce the time spent in entering and exiting the sleep state by setting condition 1, thereby improving the user's experience of using the sleep state.

[0272] It should be understood that the interface provided in the embodiment of the present application is merely an example and does not constitute a limitation on the embodiment of the present application.

[0273] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0274] The method provided in the embodiment of the present application is described above in conjunction with Figures 4-10. The device for executing the above method provided in the embodiment of the present application is described below. As shown in Figure 11, Figure 11 is a structural schematic diagram of a resource scheduling device provided in the embodiment of the present application. The resource scheduling device can be a terminal device in the embodiment of the present application, or a chip or chip system within the terminal device.

[0275] As shown in FIG11 , a resource scheduling apparatus 1100 can be used in a communication device, circuit, hardware component, or chip, and includes a display unit 1101 and a processing unit 1102. The display unit 1101 is configured to support the display step performed by the resource scheduling apparatus 1100, and the processing unit 1102 is configured to support the information processing step performed by the resource scheduling apparatus 1100.

[0276] In a possible implementation, the resource scheduling apparatus 1100 may also include a communication unit 1103. Specifically, the communication unit is used to support the resource scheduling apparatus 1100 in executing the steps of sending and receiving data. The communication unit 1103 may be an input or output interface, a pin, or a circuit.

[0277] In a possible embodiment, the resource scheduling apparatus may further include a storage unit 1104. The processing unit 1102 and the storage unit 1104 are connected via a circuit. The storage unit 1104 may include one or more memories, which may be devices in one or more devices or circuits for storing programs or data. The storage unit 1104 may exist independently and be connected to the processing unit 1102 of the resource scheduling apparatus via a communication line. The storage unit 1104 may also be integrated with the processing unit 1102.

[0278] The storage unit 1104 can store computer-executable instructions for the method in the terminal device, so that the processing unit 1102 executes the method in the above embodiment. The storage unit 1104 can be a register, a cache, or a RAM, etc. The storage unit 1104 can be integrated with the processing unit 1102. The storage unit 1104 can be a read-only memory (ROM) or other type of static storage device that can store static information and instructions. The storage unit 1104 can be independent of the processing unit 1102.

[0279] Figure 12 is a schematic diagram of the hardware structure of another terminal device provided in an embodiment of the present application. As shown in Figure 12, the terminal device includes a processor 1201, a communication line 1204 and at least one communication interface (communication interface 1203 is exemplified in Figure 12).

[0280] The processor 1201 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the program of the present application.

[0281] Communications link 1204 may include circuitry that transmits information between the aforementioned components.

[0282] The communication interface 1203 uses any transceiver or other device for communicating with other devices or communication networks, such as Ethernet, wireless local area networks (WLAN), etc.

[0283] Possibly, the terminal device may further include a memory 1202 .

[0284] The memory 1202 may be a read-only memory (ROM) or other type of static storage device that can store static information and instructions, a random access memory (RAM) or other type of dynamic storage device that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including a compact disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may be independent and connected to the processor via a communication line 1204. The memory may also be integrated with the processor.

[0285] The memory 1202 is used to store computer-executable instructions for executing the solution of the present application, and the execution is controlled by the processor 1201. The processor 1201 is used to execute the computer-executable instructions stored in the memory 1202, thereby implementing the method provided by the embodiment of the present application.

[0286] Possibly, the computer-executable instructions in the embodiments of the present application may also be referred to as application code, and the embodiments of the present application do not specifically limit this.

[0287] In a specific implementation, as an embodiment, the processor 1201 may include one or more CPUs, such as CPU0 and CPU1 in FIG12 .

[0288] In a specific implementation, as an embodiment, the terminal device may include multiple processors, such as processor 1201 and processor 1205 in Figure 12. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. The processor here may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0289] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can store or a data storage device such as a server or data center that includes one or more available media integrated. For example, the available medium can include magnetic media (e.g., floppy disk, hard disk or tape), optical media (e.g., digital versatile disc (DVD)), or semiconductor media (e.g., solid state disk (SSD)).

[0290] The present application also provides a computer-readable storage medium. The methods described in the above embodiments can be implemented in whole or in part via software, hardware, firmware, or any combination thereof. Computer-readable media can include computer storage media and communication media, and can also include any medium that can transfer a computer program from one location to another. The storage medium can be any target medium that can be accessed by a computer.

[0291] As one possible design, computer-readable media may include compact disc read-only memory (CD-ROM), RAM, ROM, EEPROM or other optical disc storage; computer-readable media may include magnetic disk storage or other magnetic disk storage devices. Moreover, any connecting line may also be appropriately referred to as a computer-readable medium. For example, if the software is transmitted from a website, server or other remote source using a coaxial cable, fiber optic cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL or wireless technologies such as infrared, radio and microwave are included in the definition of medium. Disk and disc as used herein include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, while discs reproduce data optically using lasers.

[0292] The above combinations are also included within the scope of computer-readable media. The above are only specific embodiments of the present invention, but the scope of protection of the present invention 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 invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A resource scheduling method, characterized in that: The method comprises: The terminal device is started, and the limit power value of the terminal device is a first power consumption value; At the first moment, the terminal device turns off the screen; At the second moment, the terminal device locks the screen; At a third moment, the terminal device enters a sleep state, and between the first moment and the second moment and between the second moment and the third moment, the limit power value of the terminal device is a second power consumption value, and the second power consumption value is greater than the first power consumption value; At the fourth moment, the terminal device lights up the screen.

2. The method according to claim 1, characterized in that After the terminal device locks the screen, the method further includes: The terminal device does not set the limit power value of the terminal device to the first power consumption value based on the lock screen and the first flag bit being the first value, and the first flag bit being the first value is used to indicate that the terminal device is in a screen-off state.

3. The method according to claim 1 or 2, characterized in that: After the terminal device turns off the screen, the method further includes: The terminal device sets the limit power value of the terminal device to the second power consumption value based on the screen turning off.

4. The method according to claim 2, characterized in that: The terminal device includes: a system probe module and a scene recognition module, and the terminal device does not set the limit power value of the terminal device to the first power consumption value based on the lock screen and the first flag bit being the first value, including: Based on the lock screen and the first flag being the first value, the system probe module does not report the lock screen event to the scene recognition module, and does not set the limit power value of the terminal device to the first power consumption value.

5. The method according to claim 4, characterized in that After the terminal device turns on the screen, the method further includes: The system probe module does not report the screen-on event to the scene recognition module based on the screen-on and the second flag bit being the second value, wherein the second flag bit being the second value is used to indicate that the terminal device is in a locked screen state.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: The terminal device runs a first application, and the limit power value of the terminal device is the second power consumption value; At the fifth moment, the terminal device locks the screen; At the sixth moment, the terminal device turns off the screen, and the limit power value of the terminal device between the fifth moment and the sixth moment is the first power consumption value; At the seventh moment, the terminal device enters a sleep state; between the sixth moment and the seventh moment, the limit power value of the terminal device is the second power consumption value; At the eighth moment, the terminal device lights up the screen.

7. The method according to claim 6, characterized in that After the terminal device locks the screen, the method further includes: The terminal device enters a first step of setting the limit power value of the terminal device to the first power consumption value based on the lock screen and the first flag bit being the third value, and the first flag bit being the third value is used to indicate that the terminal device The device is not in the off state.

8. A terminal device, characterized in that: include: processor and memory, wherein The memory is used to store computer programs; The processor is configured to call and execute the computer program so that the terminal device executes the method according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that: Used to store a computer program, which, when executed on a computer, causes the computer to execute the method according to any one of claims 1 to 7.

10. A computer program product, characterized in that The invention comprises a computer program which, when being executed, causes a computer to execute the method according to any one of claims 1 to 7.

Images