Processor resource management method and related apparatus

Abstract

This application provides a processor resource management method and related apparatus. The electronic device can identify critical threads, critical dependent threads, and non-critical threads. When running critical threads and critical dependent threads, the electronic device can dynamically adjust the processor frequency according to the task processing status of the critical threads and critical dependent threads, achieving precise allocation of processor resources to critical threads and critical dependent threads. The electronic device can constrain the allocation of processor resources to non-critical threads. The above methods can improve the utilization efficiency of processor resources. The electronic device can provide users with a smooth user experience while saving power and reducing the possibility of excessively rapid temperature rise, achieving a balance between smooth device performance and the needs for long battery life and rapid cooling.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to processor resource management methods and related devices. Background Technology

[0002] With the development of electronic devices, applications (such as video playback apps, game apps, social media apps, etc.) on mobile phones, tablets, smartwatches, and other electronic devices offer increasingly rich functionality, meeting users' needs in various aspects of daily life, work, and travel. The operation of applications on electronic devices depends on the processor's computing power resources. The higher the computing power resources provided by the electronic device for its applications, the smoother the application runs, but this also leads to increased power consumption and higher device temperature. As the demand for computing power resources from applications continues to grow, improving the utilization efficiency of processor resources is a pressing issue that needs to be addressed. Summary of the Invention

[0003] This application provides a processor resource management method and related apparatus. The electronic device can identify critical threads, critical dependent threads, and non-critical threads. The electronic device can prioritize allocating processor resources to critical threads and critical dependent threads, and constrain the allocation of processor resources to non-critical threads. This method can improve the utilization efficiency of processor resources and provide users with a smooth experience using the electronic device.

[0004] Firstly, this application provides a processor resource management method. This method is applied to an electronic device containing a first critical thread list. When the first critical thread is running, the electronic device identifies the critical dependent threads of the first critical thread. The first critical thread is any thread in the first critical thread list. The critical dependent threads of the first critical thread include threads other than the first critical thread on a first critical path. One node on the first critical path corresponds to one thread. Both the head node and the tail node on the first critical path correspond to the first critical thread. There is a wake-up relationship between adjacent nodes on the first critical path. The electronic device increases the running priority of the critical dependent threads of the first critical thread.

[0005] The list of critical threads mentioned above can be found in this application. Figure 3B , Figure 4A The key thread information is shown below. The first critical path can be found in this application. Figure 3C The critical path shown is: thread x1 — thread x2 — thread x4 — thread x1.

[0006] As can be seen, the above method can identify threads that critical threads directly and indirectly depend on, and prioritize allocating processor resources to threads that critical threads depend on. This reduces the likelihood of critical threads being blocked for extended periods due to missed identification of indirectly dependent threads. This improves the running speed of critical threads, thereby enhancing the smoothness of interaction between electronic devices and users.

[0007] In conjunction with the first aspect, in some embodiments, the first critical thread list is associated with a first application scenario. Before the electronic device raises the priority of the critical dependent threads of the first critical thread, the electronic device determines that the electronic device is in the first application scenario based on the first application running in the foreground.

[0008] As can be seen, electronic devices can identify the critical threads and critical dependent threads corresponding to the current application scenario and increase the priority of the critical dependent threads corresponding to the current application scenario. This can improve the smoothness of the foreground application and provide users with a smooth experience of using electronic devices.

[0009] In conjunction with the first aspect, in some embodiments, the electronic device further includes a second key thread list, which is associated with a second application scenario; after the electronic device increases the priority of the key dependent threads of the first key thread, the electronic device determines that it is in the second application scenario based on the second application running in the foreground; the electronic device identifies the key dependent threads of the second key thread, where the second key thread is any thread in the second key thread list, and the key dependent threads of the second key thread include threads other than the second key thread on the second key path, where one node on the second key path corresponds to one thread, and both the head node and the tail node on the second key path correspond to the second key thread, and there is a wake-up relationship between adjacent nodes on the second key path; the electronic device increases the priority of the key dependent threads of the second key thread.

[0010] After determining that the electronic device is in the second application scenario based on the application running in the foreground, the electronic device lowers the priority of the critical dependent threads of the first critical thread.

[0011] As can be seen, when application scenarios switch, electronic devices can prioritize the execution of corresponding threads to ensure that processor resources are allocated preferentially to the critical threads of applications running in the foreground. This improves the smoothness of foreground applications and provides users with a seamless experience of using electronic devices.

[0012] In conjunction with the first aspect, in some embodiments, the electronic device identifies the critical dependent threads of the first critical thread, searches for the critical dependent threads of the first critical thread in the first critical dependent thread list, the first critical dependent thread list including the critical dependent threads of the first critical thread, and the first critical dependent thread list is obtained by the electronic device from the server.

[0013] The first list of critical dependent threads can be found in this application. Figure 3B The thread protection list shown is sent by server 200 to electronic device 100.

[0014] As can be seen, electronic devices can directly search for the critical threads' critical dependencies in the first list of critical dependent threads obtained from the server. This improves the speed of critical dependency thread identification.

[0015] In conjunction with the first aspect, in some embodiments, the electronic device detects a first thread wake-up event, which is used to indicate that the first thread wakes up the first wake-up relationship corresponding to the second thread; the electronic device determines that the second thread is a critical dependent thread of the first critical thread based on the historical wake-up relationships of threads in the electronic device, the historical wake-up relationships including a first historical number of times the first wake-up relationship occurs, and a second historical number of times that the first thread and the second thread were actually critical dependent threads of the first critical thread in history when the first wake-up relationship occurred, wherein the first historical number is greater than the first historical number threshold, and the ratio of the second historical number to the first historical number is greater than the first probability threshold; the electronic device also searches for the critical dependent threads of the first critical thread in the second critical dependent thread list, the second critical dependent thread list including the critical dependent threads of the first critical thread, the second critical dependent thread list being generated by the electronic device based on the historical wake-up relationships of threads.

[0016] The first wake-up relationship can be referenced in this application. Figure 4B The wake-up relationship shown is 1.

[0017] The historical awakening relationship can be referenced in this application. Figure 4B The historical transition matrix information is shown. The first historical count can be referenced to the wake-up relationship count shown in Table 2 of this application. The second historical count can be referenced to the wake-up relationship count shown in Table 3 of this application.

[0018] It can be seen that electronic devices can obtain the latest wake-up relationships between threads in real time based on the thread execution status, thereby identifying the critical dependent threads of critical threads in real time.

[0019] In conjunction with the first aspect, in some embodiments, the second critical dependent thread list does not include the second thread. After the electronic device determines that the second thread is a critical dependent thread of the first critical thread based on the historical wake-up relationship of threads in the electronic device, the electronic device adds the second thread to the second critical dependent thread list.

[0020] In conjunction with the first aspect, in some embodiments, after the electronic device adds the second thread to the second critical dependent thread list, the electronic device determines the historical number of times the first wake-up relationship has occurred as the third historical number based on the historical wake-up relationship, and the historical number of times the first thread and the second thread were actually critical dependent threads of the first critical thread when the first wake-up relationship occurred as the fourth historical number, wherein the ratio of the fourth historical number to the third historical number is less than the first probability threshold; the electronic device then removes the second thread from the second critical dependent thread list.

[0021] It can be seen that electronic devices can obtain the latest wake-up relationships between threads in real time based on the thread execution status, thereby adaptively updating critical dependent threads. Moreover, as the electronic device is used for a longer period of time, it can more accurately identify critical dependent threads.

[0022] In conjunction with the first aspect, in some embodiments, the second critical dependency thread list is obtained by updating the first critical dependency thread list, which is obtained by the electronic device from the server, and contains critical dependency threads of one or more critical threads in the first critical thread list.

[0023] In conjunction with the first aspect, in some embodiments, the electronic device divides threads within the electronic device into foreground groups and non-foreground groups. Foreground groups include threads of foreground applications running in the foreground and threads in system services associated with foreground applications. Non-foreground groups include threads in system services not associated with foreground applications and threads of background applications running in the background. The electronic device detects the CPU load rate of threads in the foreground groups. When the CPU load rate of threads in the foreground groups increases, the electronic device determines a first increase in the CPU time slice length based on the increase in the CPU load rate of the foreground groups. The electronic device increases the CPU time slice length of threads in the foreground groups based on the first increase and decreases the CPU time slice length of threads in the non-foreground groups.

[0024] It can be seen that the threads in the foreground group are those with high user sensitivity. Based on this thread grouping, the electronic device can suppress the processor resources obtained by threads in non-foreground groups when the CPU load rate of the foreground group is high, providing a longer CPU time slice for the threads in the foreground group. In this way, the threads in the foreground group can obtain more processor resources when the workload is heavy, thus completing tasks faster and providing users with a smooth device experience. Furthermore, when the CPU load rate of the foreground group decreases, the electronic device can provide a longer CPU time slice to the threads in non-foreground groups, allowing their tasks to execute quickly. This method, by grouping and managing the CPU time slices of different thread groups, can effectively improve the utilization efficiency of processor resources, ensuring smooth device operation while allowing threads in non-foreground groups to continue running.

[0025] In conjunction with the first aspect, in some embodiments, the electronic device detects a first foreground event before detecting the CPU load rate of the threads in the foreground group. The first foreground event includes a change in a foreground application running in the foreground.

[0026] Understandably, when the aforementioned first foreground event occurs, the CPU load of threads in the foreground group may change. When the electronic device detects a foreground event, adjusting the CPU weight ratio based on the change in the CPU load rate of the foreground group can reduce the number of times the electronic device detects the CPU load rate of the foreground group, thereby improving the efficiency of managing the CPU time slices of each thread group.

[0027] In conjunction with the first aspect, in some embodiments, the electronic device divides the threads in the electronic device into foreground groups and non-foreground groups. The foreground groups include threads of foreground applications running in the foreground and threads of system services associated with foreground applications. The non-foreground groups include threads of system services not associated with foreground applications and threads of background applications running in the background. The electronic device detects the overall load and / or the device case temperature of the electronic device. The overall load includes the CPU load of the threads in the foreground and non-foreground groups. When the overall load is a first load and / or the device case temperature is a first temperature, the electronic device determines a first bandwidth quota based on the first load and / or the first temperature, and applies CPU bandwidth quotas to the threads in the non-foreground groups based on the first bandwidth quota.

[0028] It can be seen that electronic devices can apply bandwidth quotas to threads in non-foreground groups based on overall system load and / or device temperature. Bandwidth quotas can reduce the overall system load per unit time. Specifically, the higher the overall system load, the greater the degree of bandwidth quota suppression applied to threads in non-foreground groups; the higher the device temperature, the greater the degree of bandwidth quota suppression applied to threads in non-foreground groups. The aforementioned bandwidth quota suppression method can control the overall system load and device temperature of electronic devices, reducing the impact of threads in non-foreground groups on the operation of threads in foreground groups when the overall system load is too high, and also reducing the occurrence of excessively high device temperatures.

[0029] In conjunction with the first aspect, in some embodiments, when the overall load changes to a second load and / or the device casing temperature changes to a second temperature, the electronic device determines a second bandwidth quota based on the second load and / or the second temperature, and performs CPU bandwidth quotas on threads in non-foreground groups based on the second bandwidth quota; wherein, if the second load is higher than the first load and / or the second temperature is higher than the first temperature, the second bandwidth quota is less than the first bandwidth quota.

[0030] In conjunction with the first aspect, in some embodiments, the electronic device divides the threads in the electronic device into a foreground group, a normal thread group, and a restricted thread group. The foreground group includes threads of foreground applications running in the foreground and threads in system services associated with foreground applications. The restricted thread group includes threads in system services that are not associated with foreground applications and can be delayed, and threads in background applications that can be delayed. The normal thread group includes threads in system services that are not associated with foreground applications and are not in the restricted thread group, and threads in background applications that are not in the restricted thread group. The electronic device continuously applies CPU bandwidth quotas to the threads in the restricted thread group according to a third bandwidth quota. The electronic device detects the overall load of the electronic device and / or the device case temperature. The overall load includes the CPU load of the threads in the foreground group, the non-normal thread group, and the restricted thread group. When the overall load is a first load and / or the device case temperature is a first temperature, the electronic device determines a first bandwidth quota based on the first load and / or the first temperature, and applies CPU bandwidth quotas to the threads in the normal thread group based on the first bandwidth quota.

[0031] As can be seen, the electronic device can persistently suppress bandwidth quotas for threads with high CPU load and low latency to reduce sudden load spikes. The electronic device can also dynamically suppress bandwidth quotas for threads outside the restricted thread group in the non-foreground group based on overall system load and / or device temperature. This controls the overall system load and device temperature, reducing the impact of threads in the non-foreground group on the execution of threads in the foreground group when the overall system load is too high, and also reducing the risk of overheating.

[0032] In conjunction with the first aspect, in some embodiments, the electronic device divides threads within the electronic device into foreground groups and non-foreground groups. The foreground groups include threads of foreground applications running in the foreground and threads in system services associated with foreground applications. The non-foreground groups include threads in system services not associated with foreground applications and threads of background applications running in the background. When it is detected that a third thread is waiting for a fourth thread to release a first shared resource or waiting to obtain a first running result from a fourth thread, the electronic device assigns a first tag to the fourth thread, where the third thread is a thread in the foreground group and the fourth thread is a thread in the non-foreground group. The electronic device performs one or more of the following operations on the thread with the first tag: increasing its running priority, increasing its CPU time slice length, or removing its CPU bandwidth quota. When the fourth thread releases the first shared resource or sends the first running result to the third thread, the electronic device removes the first tag from the fourth thread.

[0033] The third thread waiting for the fourth thread to release the first shared resource or waiting to obtain the first running result from the fourth thread can include situations where the third thread waits for the fourth thread to release the binder / thread lock.

[0034] As can be seen, when threads in the foreground group depend on threads in non-foreground groups, the electronic device can temporarily increase the priority of threads in non-foreground groups that are depended on by the foreground group, increase the CPU time slice length of those threads, and remove bandwidth quota restrictions on those threads. Furthermore, it can move threads in non-foreground groups that are depended on by the foreground group to the foreground group where the required reaction and execution time is needed. Compared to changing the thread group of the dependent threads, the above method of setting critical sections can more efficiently reduce priority inversion and improve the smoothness of thread execution in the foreground group.

[0035] In conjunction with the first aspect, in some embodiments, the foreground group includes key threads in a first list of key threads, and key dependent threads of the key threads in the first list of key threads.

[0036] In conjunction with the first aspect, in some embodiments, the electronic device detects the overall load of the electronic device and / or the device case temperature, the overall load including the load of all threads in the electronic device; the electronic device determines a first CPU frequency based on the overall load and / or the device case temperature, and controls the CPU frequency when running non-critical threads below the first CPU frequency, the non-critical threads including critical threads in the first critical thread list and threads other than the critical dependent threads of the critical threads in the first critical thread list.

[0037] It can be seen that by suppressing the CPU frequency of non-critical threads, electronic devices can save power and reduce the rapid overheating of electronic devices while keeping non-critical threads running.

[0038] In conjunction with the first aspect, in some embodiments, the first key thread is used to complete the multi-frame task. During the operation of the first key thread and the key dependent thread of the first key thread, the electronic device determines the time period in which the first frequency adjustment moment is located in the multi-frame task based on the CPU frequency adjustment cycle. At the first frequency adjustment moment, the electronic device detects whether the first frame task is completed. If the first frame task is not completed, the electronic device increases the CPU frequency to the second CPU frequency according to the first frequency adjustment function. The first frequency adjustment function is a power function with CPU computing power as the dependent variable, the running time of one frame task in the multi-frame task as the independent variable, and the exponent being a positive number less than 1.

[0039] The first frequency modulation function can refer to the optimal frequency modulation function in the embodiments of this application.

[0040] In conjunction with the first aspect, in some embodiments, if the first frame task is completed, the electronic device reduces the CPU frequency to a third CPU frequency.

[0041] In conjunction with the first aspect, in some embodiments, the start time and the completion time of the first frame task are not the frequency adjustment time determined according to the CPU frequency adjustment cycle. When the start time of the first frame task is detected, the electronic device increases the CPU frequency to the fourth CPU frequency; when the completion time of the first frame task is detected, the electronic device decreases the CPU frequency to the fifth CPU frequency.

[0042] It can be seen that electronic devices can increase the CPU frequency in real time at the start of frame tasks for critical threads and critical dependent threads, and decrease the CPU frequency in real time at the end of frame tasks for critical threads and critical dependent threads. During the execution of frame tasks for critical threads and critical dependent threads, electronic devices can adjust the CPU frequency according to the optimal frequency adjustment function. This can improve the accuracy of allocating processor resources to critical threads and critical dependent threads, thereby improving the utilization efficiency of processor resources and achieving a balance between smooth device performance and the needs for long battery life and rapid cooling.

[0043] In conjunction with the first aspect, in some embodiments, after the first frame task is completed, the electronic device determines the second frequency modulation time within the time period of the second frame task in the multi-frame task based on the CPU frequency modulation cycle; at the second frequency modulation time, the electronic device detects whether the second frame task is completed; if the second frame task is not completed, the electronic device increases the CPU frequency to the sixth CPU frequency according to the first frequency modulation function.

[0044] In conjunction with the first aspect, in some embodiments, the first key thread is a thread for determining the content to be displayed in the user interface, and one frame task in the multi-frame task includes determining the content to be displayed in a frame of the user interface; or, the first key thread is a thread for rendering the user interface, and one frame task in the multi-frame task includes rendering a frame of the user interface.

[0045] The first frequency modulation function mentioned above is:

[0046]

[0047] Where u(t) is the computing power provided by the CPU of the electronic device at a certain moment, maxUtil is the maximum computing power of the CPU of the electronic device, Time is the time from the current moment to the time when the synchronization signal of the current frame task is sent. The synchronization signal of the current frame task is used to instruct the electronic device to run the current frame task, deadline is the period for the electronic device to refresh the user interface, margin is determined according to the duration of the completion of one or more frames of tasks in the first key thread before the currently running frame task, kk and α are determined according to the historical running data of one or more threads and the CPU energy efficiency curve of the electronic device, and one or more threads include the first key thread and the key dependent threads of the first key thread.

[0048] Secondly, this application provides a processor resource management method. The electronic device divides threads within the device into foreground groups and non-foreground groups. Foreground groups include threads of foreground applications running in the foreground and threads in system services associated with foreground applications. Non-foreground groups include threads in system services not associated with foreground applications and threads of background applications running in the background. The electronic device performs one or more of the following operations on the threads in the non-foreground groups: adjusting the CPU time slice length of one or more threads in the non-foreground groups based on changes in the load rate of threads in the foreground groups; allocating CPU bandwidth quotas to one or more threads in the non-foreground groups; and controlling the CPU frequency below a first CPU frequency when running one or more threads in the non-foreground groups.

[0049] As can be seen, electronic devices can group threads. Different processor resource management strategies can be applied to different thread groups to improve the accuracy of processor resource allocation and achieve a balance between smooth device performance and the needs for long battery life and rapid cooling.

[0050] In conjunction with the second aspect, in some embodiments, when the CPU load rate of the threads in the foreground group increases, the electronic device determines a first increase in the CPU time slice length based on the increase in the CPU load rate of the threads in the foreground group; the electronic device increases the CPU time slice length of one or more threads in the foreground group based on the first increase and decreases the CPU time slice length of one or more threads in the non-foreground group.

[0051] It can be seen that the threads in the foreground group are those with high user sensitivity. Based on this thread grouping, the electronic device can suppress the processor resources obtained by threads in non-foreground groups when the CPU load rate of the foreground group is high, providing a longer CPU time slice for the threads in the foreground group. In this way, the threads in the foreground group can obtain more processor resources when the workload is heavy, thus completing tasks faster and providing users with a smooth device experience. Furthermore, when the CPU load rate of the foreground group decreases, the electronic device can provide a longer CPU time slice to the threads in non-foreground groups, allowing their tasks to execute quickly. This method, by grouping and managing the CPU time slices of different thread groups, can effectively improve the utilization efficiency of processor resources, ensuring smooth device operation while allowing threads in non-foreground groups to continue running.

[0052] In conjunction with the second aspect, in some embodiments, the electronic device detects the overall load of the electronic device and / or the device case temperature, the overall load including the CPU load of threads in the foreground group and non-foreground group; when the overall load is a first load and / or the device case temperature is a first temperature, the electronic device determines a first bandwidth quota based on the first load and / or the first temperature, and applies CPU bandwidth quotas to one or more threads in the non-foreground group based on the first bandwidth quota.

[0053] It can be seen that electronic devices can apply bandwidth quotas to threads in non-foreground groups based on overall system load and / or device temperature. Bandwidth quotas can reduce the overall system load per unit time. Specifically, the higher the overall system load, the greater the degree of bandwidth quota suppression applied to threads in non-foreground groups; the higher the device temperature, the greater the degree of bandwidth quota suppression applied to threads in non-foreground groups. The aforementioned bandwidth quota suppression method can control the overall system load and device temperature of electronic devices, reducing the impact of threads in non-foreground groups on the operation of threads in foreground groups when the overall system load is too high, and also reducing the occurrence of excessively high device temperatures.

[0054] In conjunction with the second aspect, in some embodiments, when the overall load changes to a second load and / or the device casing temperature changes to a second temperature, the electronic device determines a second bandwidth quota based on the second load and / or the second temperature, and applies CPU bandwidth quotas to one or more threads in the non-foreground group based on the second bandwidth quota; wherein, if the second load is higher than the first load and / or the second temperature is higher than the first temperature, the second bandwidth quota is less than the first bandwidth quota.

[0055] In conjunction with the second aspect, in some embodiments, the non-foreground group includes a normal thread group and a restricted thread group. The restricted thread group includes threads in system services that are not associated with the foreground application and can be delayed, and threads in background applications that can be delayed. The normal thread group includes threads in system services that are not associated with the foreground application and are not in the restricted thread group, and threads in background applications that are not in the restricted thread group. CPU bandwidth quotas are applied to one or more threads in the non-foreground group. The electronic device continuously applies CPU bandwidth quotas to one or more threads in the restricted thread group according to a third bandwidth quota. The electronic device detects the overall load of the electronic device and / or the device case temperature. The overall load includes the CPU load of the threads in the foreground group, the non-normal thread group, and the restricted thread group. When the overall load is a first load and / or the device case temperature is a first temperature, the electronic device determines a first bandwidth quota based on the first load and / or the first temperature, and applies CPU bandwidth quotas to one or more threads in the normal thread group according to the first bandwidth quota.

[0056] As can be seen, the electronic device can persistently suppress bandwidth quotas for threads with high CPU load and low latency to reduce sudden load spikes. The electronic device can also dynamically suppress bandwidth quotas for threads outside the restricted thread group in the non-foreground group based on overall system load and / or device temperature. This controls the overall system load and device temperature, reducing the impact of threads in the non-foreground group on the execution of threads in the foreground group when the overall system load is too high, and also reducing the risk of overheating.

[0057] In conjunction with the second aspect, in some embodiments, the first CPU frequency is determined based on the overall load of the electronic device and / or the device case temperature, the overall load including the load of all threads in the electronic device.

[0058] In conjunction with the second aspect, in some embodiments, when it is detected that a third thread is waiting for a fourth thread to release a first shared resource or waiting to obtain a first running result from a fourth thread, the electronic device assigns a first tag to the fourth thread, where the third thread is a thread in the foreground group and the fourth thread is a thread in the non-foreground group; the electronic device performs one or more of the following operations on the thread with the first tag: increasing the running priority, increasing the CPU time slice length, and removing the CPU bandwidth quota; when the fourth thread releases the first shared resource or sends the first running result to the third thread, the electronic device removes the first tag from the fourth thread.

[0059] As can be seen, when threads in the foreground group depend on threads in non-foreground groups, the electronic device can temporarily increase the priority of threads in non-foreground groups that are depended on by the foreground group, increase the CPU time slice length of those threads, and remove bandwidth quota restrictions on those threads. Furthermore, it can move threads in non-foreground groups that are depended on by the foreground group to the foreground group where the required reaction and execution time is needed. Compared to changing the thread group of the dependent threads, the above method of setting critical sections can more efficiently reduce priority inversion and improve the smoothness of thread execution in the foreground group.

[0060] Thirdly, this application provides an electronic device. The electronic device may include a memory and a processor. The memory may be used to store a computer program. The processor may be used to invoke the computer program to execute any possible implementation method as described in the first or second aspect.

[0061] Fourthly, this application provides a computer-readable storage medium storing instructions that, when executed by a processor, can implement any possible implementation method as described in the first or second aspect.

[0062] Fifthly, this application provides a computer program product that may contain computer instructions that, when executed on a processor, can implement any possible implementation method as described in the first or second aspect.

[0063] In a sixth aspect, this application provides a chip for use in an electronic device, the chip including one or more processors, the processors being configured to invoke computer instructions to cause the electronic device to perform any possible implementation method as described in the first or second aspect.

[0064] It is understood that the electronic device provided in the third aspect, the computer-readable storage medium provided in the fourth aspect, the computer program product provided in the fifth aspect, and the chip provided in the sixth aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0065] Figure 1 This is a schematic diagram of processor resource management provided in an embodiment of this application;

[0066] Figure 2A This is a flowchart of a thread scheduling method provided in an embodiment of this application;

[0067] Figure 2B This is a schematic diagram illustrating thread priority adjustment provided in an embodiment of this application;

[0068] Figure 3A and Figure 3BThis is a schematic diagram illustrating the identification of critical dependent threads provided in an embodiment of this application;

[0069] Figure 3C This is a schematic diagram of a wake-up relationship tree provided in an embodiment of this application;

[0070] Figure 4A and Figure 4B This is another schematic diagram illustrating the identification of critical dependent threads provided in an embodiment of this application;

[0071] Figures 4C to 4G This is a schematic diagram of some wake-up relationship trees provided in the embodiments of this application;

[0072] Figure 5 This is a schematic diagram of thread grouping provided in an embodiment of this application;

[0073] Figure 6A This is a flowchart of a method for grouping and managing CPU time slices provided in an embodiment of this application;

[0074] Figure 6B This is a schematic diagram illustrating a grouped management of CPU time slices provided in an embodiment of this application;

[0075] Figure 7A This is a flowchart of a method for bandwidth quota suppression based on thread grouping provided in an embodiment of this application;

[0076] Figure 7B This is a flowchart of another method for bandwidth quota suppression based on thread grouping provided in this application embodiment;

[0077] Figure 8 This is a flowchart of a processor resource allocation method provided in an embodiment of this application;

[0078] Figure 9 This is a flowchart of a method for suppressing the CPU frequency of non-critical threads provided in an embodiment of this application;

[0079] Figure 10 This is a schematic diagram of a frequency modulation curve provided in an embodiment of this application;

[0080] Figure 11A This is a schematic diagram illustrating the determination of an optimal frequency modulation function according to an embodiment of this application;

[0081] Figure 11B This is a schematic diagram of a CPU energy efficiency curve provided in an embodiment of this application;

[0082] Figure 12A This is a flowchart of a method for determining the optimal frequency modulation function provided in an embodiment of this application;

[0083] Figure 12BThis is a schematic diagram of thread execution provided in an embodiment of this application;

[0084] Figure 12C This is a flowchart of a method for determining frame loss data and power consumption of critical threads and critical dependent threads based on a set of slope parameters and curvature parameters, provided in an embodiment of this application.

[0085] Figure 12D This is a frequency modulation schematic diagram provided in an embodiment of this application;

[0086] Figure 13A This is a schematic diagram of a frame interpolation scenario provided in an embodiment of this application;

[0087] Figure 13B This is a schematic diagram of a frame skipping scenario provided in an embodiment of this application;

[0088] Figure 14A This is a schematic diagram of an optimal frequency modulation curve provided in an embodiment of this application;

[0089] Figure 14B This is a schematic diagram comparing an optimal frequency modulation curve and a non-optimal frequency modulation curve provided in an embodiment of this application;

[0090] Figure 15 This is a frequency modulation schematic diagram provided in an embodiment of this application;

[0091] Figure 16A This is a schematic diagram of the hardware structure of an electronic device 100 provided in an embodiment of this application;

[0092] Figure 16B This is a schematic diagram of the software structure of an electronic device 100 provided in an embodiment of this application. Detailed Implementation

[0093] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. As used in the specification and appended claims of this application, the singular expressions "a," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one" and "one or more" refer to one or more (including two). The term "and / or" is used to describe the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0094] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0095] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0096] This application provides a processor resource management method. For example... Figure 1 As shown, electronic devices can manage their processor resources based on information exchange between the software and hardware layers (i.e., software-hardware collaboration). The software layer of an electronic device can include its system and kernel. At the software layer, the device can identify critical threads, critical dependent threads, and non-critical threads. Critical dependent threads can include threads that critical threads directly or indirectly depend on. At the hardware layer, the device can adjust the processor frequency by considering factors such as processor energy efficiency, device temperature, and the power consumption of other components (e.g., communication modules, cameras, screens, etc.), thereby managing processor resources. Specifically, when running critical threads and critical dependent threads, the device can dynamically adjust the processor frequency based on their task processing status, achieving precise allocation of processor resources to critical and critical dependent threads. The device can also constrain the allocation of processor resources to non-critical threads. This ensures the operation of non-critical threads while reducing the possibility of non-critical threads consuming excessive processor resources and blocking critical and critical dependent threads when their workload is heavy.

[0097] As can be seen, the above method accurately identifies critical threads, critical dependent threads, and non-critical threads to precisely allocate appropriate processor resources to different threads. This method can improve the utilization efficiency of processor resources and reduce situations where processor resources are over-supplied or under-supplied to threads. In this way, electronic devices can provide users with a smooth user experience while saving power and reducing the risk of overheating, achieving a balance between smooth device performance and the needs for long battery life and rapid cooling.

[0098] To facilitate understanding, some concepts involved in this application are introduced here.

[0099] Thread: A thread is the smallest unit of execution that an operating system can schedule. A thread is the execution unit within a process. A thread can refer to a single, sequential flow of control within a process. A process is an instance of a running program in the operating system, responsible for resource allocation and scheduling, and possessing its own address space and other auxiliary data. A process can contain multiple threads, and these threads can share the same process's resources (such as memory resources, file descriptors, etc.).

[0100] A thread's lifecycle can include: creation state, running state, ready state, blocked state, and terminated state. The creation state indicates that the thread is being created. The running state indicates that the thread is using the central processing unit (CPU) and is running. The ready state indicates that the thread is currently ready to run, but when it will actually run depends on when the scheduler schedules it. For example, if the CPU is currently occupied by another process, the thread may be in the ready state, waiting for the scheduler to call it. The blocked state indicates that the thread is temporarily stopped and is voluntarily relinquishing its CPU usage, waiting for a target event to occur (such as waiting for a resource it needs to access to be released by another thread). The terminated state indicates that the thread has finished running.

[0101] Critical threads: Critical threads represent threads that significantly impact the perceived smoothness of an electronic device's operation. If a critical thread is blocked for an extended period, the user will noticeably experience lag and unresponsiveness. In some embodiments, critical threads may include, but are not limited to: the user interface (UI) thread, the render service (RS) thread, the audio playback thread, and the main thread of the foreground application. The UI thread is responsible for handling user interface interactions and determining the specific content displayed. The RS thread is used to render the user interface. If the UI and RS threads are blocked for extended periods, the electronic device may experience slow user response, dropped frames, and interface lag, negatively impacting the user experience. The RS thread can also be called the graphics thread. The audio playback thread is used to implement audio playback. If the audio playback thread is blocked for an extended period, the electronic device may experience audio playback stuttering. The application's main thread is the starting point of the application and is created when the application starts. The application's main thread is used to perform application initialization operations, including resource allocation and environment setup. The application's main thread can create one or more child threads. If the main thread of the foreground application is blocked for an extended period, the foreground application may experience slow startup and subsequent lag.

[0102] Critical dependent threads: Critical dependent threads can include threads that a critical thread directly or indirectly depends on. For example, thread 1 is a critical thread. Thread 1 depends on thread 2. Thread 2 depends on thread 3. Then, both thread 2 and thread 3 are critical dependent threads. Thread 2 is a thread that thread 1 directly depends on, and thread 3 is a thread that thread 1 indirectly depends on. Precisely allocating processor resources to critical dependent threads in electronic devices can effectively reduce the blocking of critical threads and improve the smoothness of interaction between electronic devices and users.

[0103] Non-critical threads: Non-critical threads refer to threads other than critical threads and critical dependent threads. Delaying the execution of non-critical threads on electronic devices generally does not affect the user's perception of the device's smoothness. For example, non-critical threads can include background data download threads. The slow execution of background data download threads does not affect the user's interaction with the foreground application. When processor resources are limited, electronic devices can suppress the processor resources provided by non-critical threads, prioritizing the rapid execution of critical threads and critical dependent threads, thus improving the smoothness of the interaction between the electronic device and the user.

[0104] Dependency: A dependency between two threads means that the execution of one thread depends on the other thread releasing shared resources, returning results, or sending event notifications. For example, thread 1 depends on thread 2. Thread 2 can be called the dependent thread of thread 1. Thread 1 needs to wait for thread 2 to release shared resources it needs to access, or for thread 2 to return results it needs, or for thread 2 to send appropriate event notifications to it before it can enter the ready state. While thread 2 is running, thread 1 is in a blocked state. If thread 2 cannot run in time due to insufficient priority or improper processor resource allocation, thread 1 will be forced to wait and may remain blocked for a long time.

[0105] Dependencies can be explicit or implicit. Explicit dependencies represent dependencies where there is a direct call relationship. For example, thread 1 calls thread 2 during runtime and waits for thread 2 to return its result. After thread 2 obtains the result needed by thread 1, it can wake up thread 1 and send the result to thread 1. Thread 1 can then continue running based on the result from thread 2. In this process, thread 1 depends on thread 2, and the dependency between them can be called an explicit dependency. Implicit dependencies represent dependencies where there is no direct call relationship. For example, thread 1 needs to access resource A during runtime. Currently, resource A is being accessed by thread 3 (i.e., thread 3 holds the lock on resource A). Thread 1 needs to wait for thread 3 to release the lock on resource A before it can access resource A. Therefore, while thread 3 holds the lock on resource A, thread 1 enters a blocked state. When thread 3 releases the lock on resource A, thread 1 can enter a ready state and access resource A after gaining CPU access. In this process, thread 1 depends on thread 3, and the dependency between them can be called an implicit dependency.

[0106] Awakening Relationships: Awakening relationships can include the dependency relationships described above, as well as the relationship where one thread wakes up the other when there is no dependency between two threads. For example, if thread 1 explicitly depends on thread 2, then thread 1 and thread 2 have a wake-up relationship. Thread 1 will wake up thread 2 (i.e., thread 2 is the awakened thread), and thread 2 will also wake up thread 1 after running for a period of time (i.e., thread 1 is the awakened thread). If thread 1 implicitly depends on thread 3, then thread 1 and thread 3 have a wake-up relationship. Thread 1 can be considered as being awakened by thread 3. If thread 1 and thread 4 do not have a dependency relationship, then thread 1 may wake up thread 4 during its execution. Thread 1 and thread 4 have a wake-up relationship. Thread 1 will not enter a blocked state due to the execution of thread 4. Thread 1 and thread 4 can run in parallel.

[0107] Processor resources: Processor resources can include the CPU's computing power. CPU computing power can be described in terms of dhrystonemillion instructions executed per second (DMIPS). Here, CPU computing power = number of CPU cores * clock speed * DMIPS. The CPU clock speed represents the clock frequency at which the CPU cores operate. It can be seen that the higher the CPU's operating frequency, the more computing power it provides, and the smoother the thread execution. However, the more computing power the CPU provides, the higher its power consumption. Adjusting the processor resources provided to threads in electronic devices can include, but is not limited to: adjusting the CPU time slice occupied by a thread and adjusting the CPU frequency during thread execution. A CPU time slice represents the duration a thread can run on the CPU at a time.

[0108] Kernel: The kernel is the main component of the operating system (OS) and the core interface between electronic device hardware and its processes. The kernel provides the most basic functions of the OS and is responsible for managing system processes, memory, device drivers, files, and network systems.

[0109] refer to Figure 2A , Figure 2A An exemplary flowchart of a thread scheduling method provided in this application is shown.

[0110] S211, The application sends a system call request.

[0111] The application can be any application on an electronic device, such as an instant messaging application, a short video application, or a shopping application.

[0112] System calls are interfaces provided by the operating system to applications. Applications obtain services from the operating system through system call requests. To ensure the stability and security of the operating system and prevent illegal operations by applications, applications need to request services from the operating system through system calls when performing resource-related operations (such as memory allocation, read / write operations, file management, etc.), and the operating system will then perform the requests. Application processes can switch their running state from user mode to kernel mode through system calls. Once the system call is completed, the process's running state switches back from kernel mode to user mode.

[0113] S212, The call request enters the kernel.

[0114] S213. The kernel receives the call request and allocates resources for the application's threads.

[0115] S214. Create a thread.

[0116] Applications can create threads based on the resources allocated to them in order to perform corresponding tasks (e.g., tasks that update the user interface, tasks that update audio, etc.).

[0117] S215. Identify critical threads and critical dependent threads, increase the scheduling priority of critical threads and critical dependent threads, and dynamically adjust the processor frequency when critical threads and / or critical dependent threads are running.

[0118] In some embodiments, the electronic device can determine whether the thread created in step S214 is a critical thread. The electronic device may store a list of critical threads corresponding to different application scenarios. The lists of critical threads for different application scenarios may be the same, partially different, or completely different. The electronic device can determine the current application scenario based on the application currently running in the foreground. For example, application scenarios may include: short video playback and switching scenarios, chat scenarios in instant messaging applications, browsing products in shopping applications, etc. If the thread created in step S214 is within the list of critical threads corresponding to the current application scenario, the electronic device can determine that the thread is a critical thread; otherwise, the thread is not a critical thread.

[0119] If the thread created in step S214 above is a critical thread, the electronic device can further identify the critical dependent threads of that critical thread.

[0120] If the thread created in step S214 above is not a critical thread, the electronic device can detect whether the thread is a critical dependent thread.

[0121] The method for identifying critical dependent threads will be described in subsequent embodiments. It will not be elaborated here.

[0122] Electronic devices can elevate the scheduling priority of critical threads and critical dependent threads. After the scheduling priority is increased, the electronic device can prioritize the execution of critical threads and critical dependent threads. Optionally, for high-priority threads, the electronic device can also allocate longer CPU time slices so that these threads can complete their execution quickly.

[0123] like Figure 2B As shown, the scheduler in an electronic device can schedule threads sequentially according to their order in the thread run queue, allocating processor access to the currently scheduled thread. Before the electronic device identifies critical threads and critical dependent threads, these threads are at the tail of the thread run queue. After identifying critical threads and critical dependent threads, the electronic device can increase their priority. For example, the electronic device can move critical threads and critical dependent threads from the tail to the head of the thread run queue. In this way, the scheduler in the electronic device can prioritize scheduling critical threads and critical dependent threads.

[0124] In some embodiments, the electronic device may also dynamically adjust the processor frequency while critical threads and / or critical dependent threads are running.

[0125] For example, when critical threads or critical dependent threads have a large workload, electronic devices can increase the processor frequency so that these threads can complete their tasks within a certain timeframe. This reduces the likelihood of insufficient processor resources being allocated to critical threads and critical dependent threads, which could lead to delays and stuttering.

[0126] For example, when critical threads or critical dependent threads have a small workload, or when they have completed their target task but need to wait for subsequent tasks to be executed, electronic devices can reduce the processor frequency to reduce power consumption. This reduces the waste of processor resources caused by excessive allocation of processor resources to critical threads and critical dependent threads, which helps improve the battery life of electronic devices and reduce overheating.

[0127] The method for dynamically adjusting the processor frequency of an electronic device will be described in subsequent embodiments. It will not be elaborated here.

[0128] It should be noted that the above-mentioned increase in the scheduling priority of critical threads is optional. That is, the electronic device can also dynamically adjust the processor frequency only when critical threads and / or critical dependent threads are running.

[0129] In some embodiments, if the thread created in step S214 above is a non-critical thread, the electronic device can constrain the supply of processor resources provided by the non-critical thread when running it. The specific method for constraining the supply will be described in subsequent embodiments. It will not be elaborated here.

[0130] S216, Thread execution.

[0131] S217, user interface / audio and other updates.

[0132] The tasks performed by the thread may include user interface / audio updates. This application does not limit the type of the tasks described above.

[0133] As described above, this method accurately identifies critical threads, critical dependent threads, and non-critical threads, thereby prioritizing critical threads and critical dependent threads and precisely allocating appropriate processor resources to different threads. This improves processor resource utilization efficiency and reduces situations where processor resources are over- or under-supplied to threads. In this way, electronic devices can provide users with a smooth user experience while conserving power, reducing overheating, and achieving a balance between smooth performance, long battery life, and rapid cooling.

[0134] The following describes a method for identifying critical dependent threads provided in an embodiment of this application.

[0135] In some embodiments, electronic devices can identify critical dependent threads based on an offline mode. Offline mode can mean that critical dependent threads are identified on the server side based on critical thread information and historical wake-up relationship data of application threads. The server can send the critical dependent thread information to the user-side electronic device (e.g., mobile phone, tablet, smartwatch, etc.). The user-side electronic device can then identify whether the currently running thread is a critical dependent thread based on the aforementioned critical dependent thread information, and thus determine the corresponding processor resource allocation strategy.

[0136] Figure 3A and Figure 3B An exemplary diagram illustrating an identification of critical dependent threads provided in this application is shown.

[0137] like Figure 3A and Figure 3B As shown, the offline function module can be a module deployed on server 200. The offline function module can receive historical wake-up relationship data and key thread information of application threads, and output a thread protection list. The thread protection list may contain information about critical dependent threads.

[0138] The historical wake-up relationship data of the application threads can include various wake-up relationships between threads collected based on big data statistics. In some embodiments, when the application runs on a user-side electronic device, the event tracker in the electronic device can track the running state of the threads and generate a trace file. The aforementioned event tracker can be the FunctionTrace module (which can be abbreviated as the ftrace module). The aforementioned trace file can include data such as the thread execution time and the dependencies between threads. The historical wake-up relationship data of the application threads can be the data contained in the aforementioned trace file.

[0139] Key thread information can include the names of key threads corresponding to different application scenarios. The offline function module can identify the key dependent threads of key threads in different application scenarios.

[0140] The information about critical dependent threads in the above thread protection list may include the application scenario to which the critical dependent thread belongs and the name of the critical dependent thread.

[0141] like Figure 3B As shown, the offline function module may include a wake-up relationship analysis module, a statistical integration module, and a selection module.

[0142] The wake-up relationship analysis module can be used to construct a wake-up relationship tree based on the historical wake-up relationship data of application threads. This wake-up relationship tree can be constructed based on a directed acyclic graph (DAG). Then, the wake-up relationship analysis module can reverse-engineer the critical path from the wake-up relationship tree based on key thread information to obtain critical path data.

[0143] Figure 3C An exemplary schematic diagram of a wake-up relationship tree is shown.

[0144] like Figure 3C As shown, the wake-up relationship analysis module can construct a wake-up relationship tree containing threads x1 to x7 based on the historical wake-up relationship data of application threads. Black circles represent key threads, and white circles represent threads. A solid line connecting two circles indicates a dependency relationship between the threads represented by those two circles. A dashed line connecting two circles indicates a wake-up relationship between the threads represented by those two circles.

[0145] like Figure 3C As shown, thread x1 wakes up threads x2 and 3, thread x2 wakes up threads x4 and x6, thread x3 wakes up thread x5, thread x4 wakes up thread x1, and thread x5 wakes up thread x7. The wake-up relationship analysis module can determine the critical path in the wake-up relationship data through a reverse inference method. The critical path can be a path in the wake-up path where the starting point and ending point are the same critical thread. For example, thread x1 is the critical thread. Starting with thread x1, the wake-up relationship analysis module can find the thread that wakes up thread x1 in the wake-up relationship tree, which is thread x4. Further, starting with thread x4, the wake-up relationship analysis module can find the thread that wakes up thread x4 in the wake-up relationship tree, which is thread x2. Further, starting with thread x2, the wake-up relationship analysis module can find the thread that wakes up thread x2 in the wake-up relationship tree, which is thread x1. In this way, the wake-up relationship analysis module can determine the critical path as thread x1—thread x2—thread x4—thread x1. The threads other than the critical thread in this critical path (i.e., threads x2 and thread x4) are critical dependent threads.

[0146] The wake-up relationship analysis module can send wake-up path data and critical path data to the statistics integration module. Wake-up path data can include the number of times each wake-up relationship occurs in the wake-up relationship tree, the priority of each thread among all threads in the wake-up relationship tree, and the runtime of threads in the wake-up relationship tree. Critical path data can include dependencies on the critical path and the priority of threads on the critical path among all threads on the critical path.

[0147] The statistics integration module can statistically integrate wake-up path data and critical path data to generate a list of critical dependent threads. The list of critical dependent threads may include the names of the critical dependent threads. Optionally, the list may also include one or more of the following information: the frequency of the critical dependent thread on the critical path, the number of times the critical dependent thread appears in the wake-up relationship, the priority of the critical dependent thread on the critical path, the priority of the critical dependent thread among all threads in the wake-up relationship tree, and the duration of the critical dependent thread's execution.

[0148] The list of critical dependent threads can be found in Table 1 below.

[0149]

[0150] Table 1

[0151] The overall priority in Table 1 represents the priority of the critical dependency thread among all threads in the wake-up relationship tree. Table 1 is merely an illustrative example of this application and should not be construed as limiting the application.

[0152] In some embodiments, the statistics and integration module can send a list of critical dependent threads to the selection module. The selection module can filter out a subset of critical dependent threads from all critical dependent threads based on one or more of the following information: the frequency of critical dependent threads appearing on the critical path, the number of times critical dependent threads appear in wake-up relationships, the priority of critical dependent threads on the critical path, the overall priority of critical dependent threads, and the runtime of critical dependent threads, and generate a thread protection list.

[0153] Server 200 can send a thread protection list to electronic device 100. Electronic device 100 can store the thread protection list and determine whether its running threads are critical threads or critical dependent threads based on the thread protection list. Electronic device 100 can be a user-side electronic device. In some embodiments, server 200 can send the aforementioned thread protection list to electronic device 100 when the system version of electronic device 100 is upgraded. Optionally, server 200 can update the aforementioned thread protection list periodically or irregularly and send the updated thread protection list to electronic device 100. This can improve the accuracy of electronic device 100 in identifying critical threads and critical dependent threads.

[0154] Alternatively, server 200 can directly send information about all critical dependent threads to electronic device 100. That is, server 200 can filter critical dependent threads without using a selection module.

[0155] like Figure 3B As shown, electronic device 100 may include an application, a kernel, and memory. Upon receiving a thread protection list from server 200, electronic device 100 may store the thread protection list in memory. The memory may also store critical thread information. The kernel may include an event tracker and a scheduler. Applications may initiate system call requests to the kernel. System call requests are described above. Figure 2A The following describes step S211. The event tracker can use the aforementioned system call requests to track and obtain the running information of the corresponding threads. The scheduler can be used to obtain critical thread information and thread protection lists, and determine whether thread priority adjustment is needed based on the thread protection lists.

[0156] Optionally, the electronic device 100 may also include an application scenario detection module. This module can detect the current application scenario of the electronic device 100 based on information such as the application currently running in the foreground and received user operations. Based on key thread information, the thread protection list, and the current application scenario, the module can determine the key threads and key dependent threads corresponding to the current application scenario. The module can then send these key threads and key dependent threads to the scheduler. The scheduler can then increase the priority of the key threads and key dependent threads corresponding to the current application scenario.

[0157] In some embodiments, the electronic device can identify critical dependent threads based on an online mode. The online mode can mean that the user-side electronic device collects and records the wake-up relationships of its running threads, and identifies whether a currently running thread is a critical thread based on the critical thread information and the wake-up relationships recorded by the electronic device. As the number of running threads on the electronic device increases, the number of wake-up relationships recorded by the electronic device also increases. The electronic device can periodically or irregularly update its identified critical dependent threads (e.g., reclassifying threads that were previously non-critical as critical dependent threads, or reclassifying previously identified critical dependent threads as non-critical threads).

[0158] Figure 4A and Figure 4B An exemplary diagram illustrating another method for identifying critical dependent threads provided in this application is shown.

[0159] like Figure 4AAs shown, the electronic device 100 may include applications, a kernel, and memory. The kernel may include an event tracker, a scheduler, and online function modules. The memory may store critical thread information and a thread protection list.

[0160] In electronic device 100, applications can initiate system call requests to the kernel. An event tracker can track and obtain the execution information of the corresponding thread based on these system call requests. The event tracker can determine the thread wake-up event corresponding to the application's system call request based on the thread's execution information. The event tracker can send the thread wake-up event to the online functional module. The online functional module can obtain critical thread information from memory and determine whether the woken thread is a critical dependent thread based on the thread wake-up event and the critical thread information. If the currently woken thread is a critical dependent thread, the online functional module can instruct the scheduler to increase the priority of the currently woken thread.

[0161] Optionally, the electronic device 100 may also include an application scenario detection module. This module can detect the current application scenario of the electronic device 100 based on information such as the application currently running in the foreground and received user operations. Based on key thread information, the module can determine the key thread corresponding to the current application scenario. The module can then send the key thread corresponding to the current application scenario to the online function module. The online function module can identify the key dependent threads corresponding to the current scenario based on thread wake-up events and the key thread.

[0162] In some embodiments, the online functional module can update the thread protection list based on the identification results of critical threads or critical dependent threads of multiple threads over a period of time. The scheduler can adjust the priority of corresponding threads based on the critical dependent threads in the thread protection list. In addition, the scheduler can also obtain critical thread information and increase the priority of critical threads.

[0163] Online function modules can be arranged according to Figure 4B The method shown is used to identify whether a thread is a critical thread or a critical dependent thread.

[0164] S411. Received a thread wake-up event. The thread wake-up event corresponds to wake-up relationship 1.

[0165] The wake-up relationship 1 can include a waking thread and a woken-up thread. For example, wake-up relationship 1 can be that thread x1 (i.e., the waking thread) wakes up thread x2 (i.e., the woken-up thread). Alternatively, wake-up relationship 1 can be that thread x2 (i.e., the waking thread) wakes up thread x4 (i.e., the woken-up thread). This application embodiment does not limit the wake-up relationship 1.

[0166] S412. Check if a wake-up relationship tree is currently being created.

[0167] If a wake-up relationship tree is already being created, the online function module can perform the following step S413.

[0168] If there is no wake-up relationship tree being created at present, the online function module can perform the following step S414.

[0169] S413. Update the wake-up relationship tree based on wake-up relationship 1.

[0170] In some embodiments, if wake-up relationship 1 does not exist in the wake-up relationship tree, and the wake-up thread in wake-up relationship 1 is an existing thread in the wake-up relationship tree, the online function module can add wake-up relationship 1 to the wake-up relationship tree and perform the following step S415.

[0171] If wake-up relationship 1 already exists in the wake-up relationship tree, then the wake-up relationship tree does not need to be updated.

[0172] If the wake-up thread in wake-up relation 1 is not an existing thread in the wake-up relation tree, the online functional module does not need to add wake-up relation 1 to the wake-up relation tree. In this case, the online functional module does not need to check whether wake-up relation 1 is on the critical path (i.e., it does not need to execute subsequent steps S415-S419).

[0173] S414. Create a wake-up relationship tree based on wake-up relationship 1.

[0174] For example, if wake-up relationship 1 is thread x1 waking up thread x2, and the online functional module detects that there is currently no wake-up relationship tree being created, then the online functional module can create one. Figure 4C The wake-up relationship tree is shown below. Figure 4C As shown, the circle representing thread x1 points to the circle representing thread x2, which means that thread x1 wakes up thread x2.

[0175] In some embodiments, if the wake-up thread in wake-up relationship 1 is a critical thread, the online functional module can create a wake-up relationship tree starting from that critical thread. If the wake-up thread in wake-up relationship 1 is not a critical thread, the online functional module does not need to create a wake-up relationship tree. That is to say, if there is no wake-up relationship tree being created and the wake-up thread in wake-up relationship 1 is not a critical thread, the online functional module does not need to check whether wake-up relationship 1 is on the critical path.

[0176] The wake-up relation tree can be stored in memory as a tree data structure during runtime. The online functional module allows for CRUD operations on the wake-up relation tree.

[0177] S415. Detect whether the wake-up relationship tree has ended.

[0178] The online function module can detect whether the wake-up relationship tree has ended based on wake-up relationship 1. Specifically, if the wake-up thread in wake-up relationship 1 is an existing thread in the wake-up relationship tree, and the wake-up thread in wake-up relationship 1 is a key thread in the wake-up relationship tree, then the wake-up relationship tree has ended. Otherwise, the wake-up relationship tree has not yet ended.

[0179] If the wake-up relationship tree is not finished, the online function module can perform the following step S416.

[0180] If the wake-up relationship tree ends, the online function module can execute the following step S418.

[0181] S416. Update the historical transition matrix information and read the historical transition matrix information. The historical transition matrix information includes the historical wake-up transition matrix and the critical path wake-up transition matrix. The historical wake-up transition matrix contains the historical number of times the wake-up relationship has occurred, and the critical path wake-up transition matrix contains the historical number of times the wake-up relationship has occurred on the critical path.

[0182] The historical wake-up transition matrix can be found in Table 2 below.

[0183]

[0184] Table 2

[0185] Taking threads x1, x2 and x4 on the critical path as an example, the critical path wake-up transition matrix can be found in Table 3 below.

[0186]

[0187]

[0188] Table 3

[0189] If wake-up relationship 1 already exists in the current wake-up relationship tree, the online function module can increment the count of wake-up relationship 1 by 1 in the historical wake-up transition matrix.

[0190] For example, if wake-up relationship 1 is thread x1 waking up thread x2, and the online function module detects that there is already a wake-up relationship... Figure 4D The wake-up relationship tree shown means that the online functional module does not need to adjust the wake-up relationship tree, but the number of times thread x1 wakes up thread x2 in the historical wake-up transition matrix is ​​incremented by 1.

[0191] For example, if wake-up relationship 1 is thread x2 waking up thread x4, and the online function module detects that there is already a wake-up relationship... Figure 4D The wake-up relationship tree shown indicates that the online function modules can be updated. Figure 4D The wake-up relationship tree shown is generated. Figure 4E The wake-up relationship tree is shown below. Figure 4E As shown, the online function module is in Figure 4D Based on the wake-up relationship tree shown, a branch pointing from thread x2 to thread x4 has been added. If the historical wake-up transition matrix already contains a row and column corresponding to thread x4, the online functional module does not need to update the historical wake-up transition matrix. If the historical wake-up transition matrix does not contain a row and column corresponding to thread x4, the online functional module can add that row and column to the historical wake-up transition matrix.

[0192] If wakeup relationship 1 is on an existing critical path, the online functional module can increment the count of wakeup relationship 1 by 1 in the critical path wakeup transition matrix. The aforementioned critical path can be determined by the online functional module based on previous wakeup relationships and critical thread information.

[0193] For example, if wake-up relationship 1 is thread x2 waking up thread x4, and the existing critical path is thread x1—thread x2—thread x4—thread x1, then the online functional module can increment the number of wake-up relationship 1 by 1 in the critical path wake-up transition matrix.

[0194] For example, if wake-up relationship 1 is thread x3 waking up thread x5, and the online function module detects that there is already a wake-up relationship... Figure 4D The wake-up relationship tree shown indicates that the online function modules can be updated. Figure 4D The wake-up relationship tree shown is generated. Figure 4F The wake-up relationship tree is shown below. Figure 4F As shown, the online function module is in Figure 4D Based on the wake-up relationship tree shown, a branch from thread x3 to thread x5 is added. The online functional module can update the historical wake-up transition matrix according to the description in the previous embodiment. If the critical path is thread x1—thread x2—thread x4—thread x1, then wake-up relationship 1 is not in the existing critical path; therefore, the online functional module does not need to update the critical path wake-up transition matrix.

[0195] S417. Detect whether wake-up relationship 1 is on the critical path based on the historical transition matrix information.

[0196] In some embodiments, the online functional module can detect the probability of historical wake-up relationship 1 occurring on the critical path based on the historical wake-up transition matrix and the critical path wake-up transition matrix. The probability of wake-up relationship 1 occurring on the critical path can be predicted using a Markov modeling probability prediction method. Alternatively, the probability of wake-up relationship 1 occurring on the critical path can be: the number of times wake-up relationship 1 appears on the critical path in the critical path wake-up transition matrix ÷ the number of times wake-up relationship 1 appears in the historical wake-up transition matrix. The online functional module can detect whether the historical probability of wake-up relationship 1 occurring on the critical path is greater than a preset probability threshold, and whether the number of times wake-up relationship 1 appears in the historical wake-up transition matrix is ​​greater than a preset frequency threshold. For example, the probability threshold can be 0.7, 0.8, etc., and the frequency threshold can be 10, 20, etc. This application embodiment does not limit the values ​​of the probability threshold and the frequency threshold.

[0197] If the probability of wake-up relationship 1 on the critical path is greater than a probability threshold in the past, and the number of times wake-up relationship 1 appears in the historical wake-up transition matrix is ​​greater than a frequency threshold, then the online functional module can determine that wake-up relationship 1 is on the critical path. That is, the thread in wake-up relationship 1 is a critical thread or a critical dependent thread.

[0198] If the probability of wake-up relationship 1 on the critical path is less than or equal to a probability threshold, or if the number of times wake-up relationship 1 appears in the historical wake-up transition matrix is ​​less than or equal to a frequency threshold, then the online functional module can determine that wake-up relationship 1 is not on the critical path. That is, the thread woken up in wake-up relationship 1 is not a critical dependent thread.

[0199] Understandably, the currently constructed wake-up relationship tree is not yet complete, and the online functional module cannot yet deduce the critical path of the currently constructed wake-up relationship tree. Since the critical path may change (e.g., the threads that the critical thread depends on may change), wake-up relationship 1 may have been on the critical path but is not currently on it, or it may have been not on the critical path but is currently on it. The online functional module can predict whether wake-up relationship 1 is on the critical path of the currently constructed wake-up relationship tree based on the aforementioned historical transition matrix information. The probability that wake-up relationship 1 was on the critical path historically reflects the probability that wake-up relationship 1 was on a previously determined critical path. The higher the historical probability of wake-up relationship 1 being on the critical path, the higher the probability that wake-up relationship 1 is on the critical path of the currently constructed wake-up relationship tree. The more times wake-up relationship 1 appears historically, the more frequently the thread in wake-up relationship 1 is awakened, and the higher the probability that the thread in wake-up relationship 1 is a critical dependent thread.

[0200] If wake-up relationship 1 is determined to be on the critical path, the online functional module can instruct the scheduler to increase the priority of the awakened threads in wake-up relationship 1.

[0201] S418. Based on the wake-up relationship tree and key thread information, reverse the critical path and update the historical transition matrix information.

[0202] For example, in step S415 above, when the wake-up relationship tree is determined to be complete, the online functional module constructs... Figure 4G The wake-up relationship tree is shown. The online function module reverse-engineers the critical path from this wake-up relationship tree. The method for reverse-engineering the critical path can be referred to the description in the previous embodiment. Here, we still take thread x1 as the critical thread as an example. According to Figure 4G The wake-up relationship tree shown indicates that the online functional module can determine the critical path as thread x1—thread x2—thread x8—thread x1.

[0203] If the critical path previously determined by the online functional module was thread x1—thread x2—thread x4—thread x1, then the online functional module can update the critical path to... Figure 4G The critical path shown is (i.e., thread x1—thread x2—thread x8—thread x1). It can be seen that the wake-up relationship corresponding to thread x2 waking up thread x4 was once on the critical path, but it is not on the critical path during the current execution of the critical thread x1.

[0204] Specifically, when the critical path is updated to thread x1—thread x2—thread x8—thread x1, the online functional module can update the above critical path wake-up transition matrix. The online functional module can add the row and column corresponding to thread x8 to the critical path wake-up transition matrix. The row and column corresponding to thread x4 can still be retained in the critical path wake-up transition matrix.

[0205] S419, Delete the wake-up relationship tree.

[0206] Once the wake-up relationship tree ends, the online functional module can delete it. The module can then recreate the wake-up relationship tree the next time a wake-up relationship event is received.

[0207] In some embodiments, based on the updated historical transition matrix information in step S418, the online functional module can update the thread protection list. Specifically, the online functional module can calculate the probability of each wake-up relationship in the critical path wake-up transition matrix historically occurring on the critical path, and the corresponding number of times these wake-up relationships appear in the historical wake-up transition matrix. The probability of a wake-up relationship historically occurring on the critical path can be calculated as: the number of times the wake-up relationship appears on the critical path in the critical path wake-up transition matrix ÷ the number of times the wake-up relationship appears in the historical wake-up transition matrix.

[0208] If a wake-up relationship has a probability greater than a probability threshold on the critical path in the past, and the number of times this wake-up relationship appears in the historical wake-up transition matrix is ​​greater than a number threshold, then the online functional module can add the threads other than the critical thread in this wake-up relationship to the thread protection list as critical dependent threads.

[0209] If the probability of a wake-up relationship corresponding to a thread that was previously added to the thread protection list on the critical path is less than or equal to the probability threshold, or if the number of times the wake-up relationship corresponding to the thread is in the historical wake-up transition matrix is ​​less than or equal to the number threshold, the online functional module can remove the thread from the thread protection list.

[0210] This application does not limit the timing of when the online functional module updates the thread protection list. For example, the online functional module can update the thread protection list periodically. Alternatively, the online functional module can update the thread protection list after each wake-up relation tree is constructed and the critical path is derived.

[0211] As can be seen, both the offline and online modes described above can accurately identify threads that are directly and indirectly dependent on the critical thread. This reduces the likelihood of indirect dependent threads being blocked and causing the critical thread to be blocked for an extended period when they are missed. Specifically, in offline mode, the electronic device 100 can directly use the thread protection list sent from the server 200 to identify critical dependent threads. This improves the speed of critical dependent thread identification. In online mode, the electronic device 100 can obtain the latest wake-up relationships between threads in real time based on thread execution, thereby adaptively updating critical dependent threads. Moreover, as the electronic device 100 is used for longer periods, it can identify critical dependent threads more accurately.

[0212] In some embodiments, the electronic device 100 may store general critical thread information. This general critical thread information may include thread names that serve as critical threads in multiple application scenarios. For example, the general critical thread information may include the RS thread. When a critical thread in the aforementioned general critical thread information is detected to be running, the electronic device 100 may identify the critical dependent threads of the critical thread based on the aforementioned offline mode and / or online mode. Then, the electronic device 100 may increase the running priority of the aforementioned critical dependent threads.

[0213] In some embodiments, the critical threads corresponding to different application scenarios may be different. The electronic device 100 can store critical thread information for different application scenarios. The electronic device can determine the critical thread based on the current application scenario, and then identify the critical dependent threads of the critical thread in the current application scenario. The method for identifying application scenarios can be found in the description of the foregoing embodiments.

[0214] For example, when application 1 is running in the foreground of electronic device 100, electronic device 100 can identify the current application scenario as application scenario 1. Key thread information associated with application scenario 1 may include: the RS thread and the UI thread of application 1. The UI thread of application 2 can be used to determine the display content contained in the user interface of application 1. Electronic device 100 can identify the key dependent threads of the UI thread of application 1 and increase the running priority of the key dependent threads of the UI thread of application 1. When the application running in the foreground of electronic device 100 is switched from application 1 to application 2, electronic device 100 can identify the current application scenario change to application scenario 2. Key thread information for application scenario 2 may include the RS thread and the UI thread of application 2. The UI thread of application 2 can be used to determine the display content contained in the user interface of application 2. Electronic device 100 can identify the key dependent threads of the UI thread of application 2 and increase the running priority of the key dependent threads of the UI thread of application 2. Wherein, after the application running in the foreground is switched from application 1 to application 2, application 1 becomes a background application. Electronic device 100 can decrease the running priority of the key dependent threads of the UI thread of application 1. Furthermore, since the RS thread is a critical thread in both application scenario 1 and application scenario 2, the electronic device 100 can set the critical dependent threads of the RS thread to high priority in both application scenario 1 and application scenario 2.

[0215] In some embodiments, the electronic device can combine the aforementioned offline mode and online mode to identify critical dependent threads. The electronic device 100 can store the aforementioned... Figure 3B The thread protection list sent by server 200 is shown. The online functional modules in electronic device 100 can update the thread protection list based on the actual critical path during thread execution within electronic device 100, using the thread protection list sent by server 200 as a basis.

[0216] In some embodiments, the electronic device 100 may store a thread priority configuration file. This application embodiment does not limit the format of the thread priority configuration file. For example, the thread priority configuration file may be an Extensible Markup Language (XML) file.

[0217] Electronic device 100 can be based on the above Figure 3B or Figure 4A The thread protection list shown determines the thread priority configuration file. The thread priority configuration file can contain priority configuration policies for critical threads and critical dependent threads. The scheduler can increase the priority of critical threads and critical dependent threads based on the above thread priority configuration file. This allows for the priority allocation of processor resources to critical threads and critical dependent threads.

[0218] When the above thread protection list is updated, the thread priority configuration file can be updated accordingly.

[0219] In some embodiments, the scheduler in the electronic device 100 creates a related thread group (RTG). The RTG provides the ability to optimize the scheduling of a group of threads, supports individual load statistics and prediction for threads within the RTG group, and allows setting priority CPU clusters. This enables the selection of the optimal CPU for threads within the RTG group and the selection of appropriate CPU frequency adjustment points based on the group's load. The scheduler in the electronic device 100 can add critical threads and critical dependent threads to the RTG group and ensure the supply of processor resources to critical threads and critical dependent threads based on the RTG group's internal mechanisms. The scheduler can update the threads within the RTG group based on updates to the protected thread list. This application does not limit the implementation method of the RTG group.

[0220] The methods described above for prioritizing critical threads and critical dependent threads based on thread priority configuration files or RTG grouping are merely illustrative examples of this application. The electronic device 100 may also employ other methods to prioritize critical threads and critical dependent threads. This application does not limit these methods.

[0221] In some embodiments, electronic devices can group threads. Different processor resource management strategies can be applied to different thread groups to improve the accuracy of processor resource allocation and achieve a balance between smooth device performance and the needs for long battery life and rapid cooling.

[0222] Figure 5 An exemplary schematic diagram of a thread grouping provided in this application is shown.

[0223] like Figure 5As shown, threads in an electronic device can include threads for foreground applications, threads for system services, and threads for background applications. Foreground applications can include applications running in the foreground of the electronic device. The electronic device can display the user interface of the foreground application on the screen or play audio from the foreground application. Foreground applications can receive user input and interact with the user. System services can include programs that perform specified system functions to support the operation of other applications. System services typically run in the background. For example, system services may include, but are not limited to, services that manage open application windows on the device, power management services, services that provide location information, network connectivity services, etc. Background applications can include applications that run in the background of the electronic device, excluding system services. When an application runs in the background, it typically cannot interact with the user. In some embodiments, a foreground application becomes a background application after being moved to the background; a background application can also be brought to the foreground and become a foreground application. For example, an electronic device runs a shopping application in the foreground (i.e., displays the user interface of the shopping application) and an instant messaging application in the background. In response to an operation that brings up the user interface of the instant messaging application, the electronic device can display the user interface of the instant messaging application on the screen and cancel the display of the user interface of the shopping application. In this way, shopping applications change from front-end applications to back-end applications, and instant messaging applications change from back-end applications to front-end applications.

[0224] In some embodiments, electronic devices can divide threads into different service groups based on parameters such as the foreground / background running status of the application or service to which the thread belongs, and the type of task the thread needs to perform.

[0225] For example, an electronic device can categorize foreground application threads, system service threads, and background application threads into one or more of the following service groups: foreground services, foreground-related services, system-resident services, system-delayable services, background-delayable services, and background insignificant services. Foreground services may include threads of foreground applications. Foreground-related services may include a portion of the system service threads that need to be invoked by the foreground service. System-resident services may include threads in the system service that need to run persistently for a long time. System-delayable services may include threads in the system service that can run with a delay. Background-delayable services may include threads in the background application that can run with a delay. Background insignificant services may include threads in the background application that are not part of the background-delayable services.

[0226] Optionally, the aforementioned foreground services and related foreground services can also be grouped into a single service group. Similarly, the aforementioned system-delayable services and background-delayable services can also be grouped into a single service group. System-delayable services and background-delayable services may include, but are not limited to: threads for upload / download services, threads for application compilation and installation services, threads for software upgrade and update services, etc. This application does not limit the method for identifying system-delayable services and background-delayable services.

[0227] In some embodiments, the threads in one or more of the aforementioned service groups can be dynamically changed. For example, when application 1 is running in the foreground and application 2 is running in the background, the threads of application 1 can be assigned to a foreground service, and the threads of application 2 can be assigned to a background deferred service or a background insignificant service. When application 2 changes to running in the foreground and application 1 changes to running in the background, the threads of application 1 can be moved from the foreground service to a background deferred service or a background insignificant service, and the threads of application 2 can be moved to the foreground service. The threads in the foreground associated service can also change from threads associated with application 1 to threads associated with application 2.

[0228] In some embodiments, the electronic device can also divide threads into different CPU groups based on the urgency of allocating processor resources to the threads. The electronic device can divide the CPU groups based on the aforementioned service groups. The more important a thread is or the higher its user sensitivity, the higher the urgency of allocating processor resources to that thread by the electronic device. Higher user sensitivity to a thread means that it is more easily noticed by the user if the thread is blocked or delayed.

[0229] For example, the electronic device can classify the aforementioned service groups into one or more of the following CPU groups: top-level thread group, secondary thread group, normal system thread group, restricted thread group, and normal background thread group. The CPU groups, ordered from highest to lowest importance in allocating processor resources to threads, can be: top-level thread group, secondary thread group, normal system thread group, normal background thread group, and restricted thread group. The top-level thread group can include threads in foreground services. The top-level thread group can also be called the top-app group. The secondary thread group can include threads in foreground related services. The secondary thread group can also be called the foreground group. The normal system thread group can include threads in system resident services. The normal system thread group can also be called the system group. The restricted thread group can include threads in system time-delayed services and background time-delayed services. The restricted thread group can also be called the limit-background group. The normal background thread group can include threads in background unimportant services. The normal background thread group can also be called the background group. The names of the aforementioned CPU groups are merely illustrative examples of this application and should not be construed as limiting this application.

[0230] Optionally, the top-level thread group and the secondary thread group can also be grouped into one CPU group. The normal system thread group, the restricted thread group, and the normal background thread group can also be grouped into one CPU group. Alternatively, the normal system thread group and the normal background thread group can be grouped into one CPU group.

[0231] In some embodiments, the threads described above may have priorities. A thread's priority determines its importance when it is scheduled. Higher-priority threads can be scheduled more frequently when competing for processor resources to ensure timely responses.

[0232] Electronic devices may include a real-time (RT) scheduler and a completely fair scheduler (CFS). The RT scheduler and the CFS scheduler can employ different scheduling strategies to schedule threads. The RT scheduler and the CFS scheduler can be used to schedule threads with different priorities. For example, the CFS scheduler can be used to schedule threads with priorities in priority range 1. The RT scheduler can be used to schedule threads with priorities in priority range 2. This application does not limit the values ​​of priority range 1 and priority range 2. For example, priority range 1 can be [1, 40]. Priority range 2 can be [41, 139]. That is, if a thread's priority is greater than or equal to 1 and less than or equal to 40, then the thread can be scheduled by the CFS scheduler. If a thread's priority is greater than or equal to 41 and less than or equal to 139, then the thread can be scheduled by the RT scheduler.

[0233] The CFS scheduler can be used to determine the processor resource requirements of threads based on parameters such as thread type and thread priority, and then allocate processor resources to each thread as needed, so as to achieve a relatively fair allocation of processor resources to each thread.

[0234] The RT scheduler can be used to schedule threads based on their priority. The highest priority thread will acquire processor resources first. Furthermore, high-priority threads can preempt lower-priority resources.

[0235] In the CPU groupings described above, the top-level thread group and the secondary thread group can contain threads with priorities in priority range 1 and threads with priorities in priority range 2. Threads in the top-level thread group and the secondary thread group with priorities in priority range 1 can be scheduled by the CFS scheduler. Threads in the top-level thread group and the secondary thread group with priorities in priority range 2 can be scheduled by the RT scheduler. Threads in the normal system thread group, the restricted thread group, and the normal background thread group can all be threads with priorities in priority range 1; therefore, all threads in these groups can be scheduled by the CFS scheduler.

[0236] In some embodiments, the electronic device can identify critical threads, critical dependent threads, and non-critical threads. For details, please refer to the description in the foregoing embodiments. If the electronic device identifies a thread in any of the following service groups as a critical dependent thread: a system resident service, a system time-delayable service, a background time-delayable service, or a background unimportant service, the electronic device can move this thread from the ordinary system thread group / restricted thread group / ordinary background thread group to the top-level thread group / secondary thread group. Optionally, if the electronic device identifies a thread in a foreground service or a foreground associated service as a non-critical dependent thread, the electronic device can move this thread from the top-level thread group / secondary thread group to the ordinary system thread group / restricted thread group / ordinary background thread group.

[0237] It should be noted that the above-described service grouping and CPU grouping of threads are merely illustrative examples of this application and should not be construed as limiting the application. Electronic devices may also divide threads into more or fewer service groups and more or fewer CPU groups.

[0238] In some embodiments, based on the above Figure 5 As shown in the CPU grouping diagram, electronic devices can manage and group CPU time slices allocated to threads.

[0239] Figure 6A An exemplary flowchart of a method for grouping and managing CPU time slices is shown.

[0240] S611. Initialize the ratio of CPU weights in each group of CPU groups to equal weights. The CPU weight corresponding to a group is used to indicate the length of the CPU time slice allocated by the scheduler to the threads in that group.

[0241] In some embodiments, the CPU grouping of threads may include a top-level thread group, a secondary thread group, a normal system thread group, a restricted thread group, and a normal background thread group. The electronic device may initialize the CPU weights of the top-level thread group, secondary thread group, normal system thread group, restricted thread group, and normal background thread group to 1:1:1:1:1. Figure 6B As shown, the CPU time slice ratio for the top-level thread group, secondary thread group, normal system thread group, restricted thread group, and normal background thread group can all be 20%. The length of the CPU time slice allocated to a CPU group is: total CPU time * CPU time slice ratio of the CPU group. The total CPU time can be the total duration of CPU time slices that the scheduler can allocate, i.e., the size of the scheduler's scheduling region. The scheduling region can also be called the scheduling cycle.

[0242] The scheduler can allocate CPU time slices to multiple threads within a CPU group based on the length of the CPU time slice allocated to that group. The CPU time slice lengths allocated to multiple threads within a CPU group can be the same or different.

[0243] It should be noted that the CPU weight ratio of the aforementioned groups can be used as the basis for the CFS scheduler to allocate CPU time slices to the threads it manages. Specifically, the CPU time slice ratio of the top-level thread group can be the proportion of CPU time slices occupied by threads managed by the CFS scheduler within the CFS scheduler's scheduling area. Similarly, the CPU time slice ratio of the second-level thread group can be the proportion of CPU time slices occupied by threads managed by the CFS scheduler within the CFS scheduler's scheduling area. The CPU time slices of threads managed by the RT scheduler in both the top-level and second-level thread groups can be allocated by the RT scheduler, and are not determined by the CPU weights of the aforementioned groups.

[0244] S612. When a foreground event is detected, calculate the CPU load rate of the foreground group, which includes the top-level thread group and the secondary thread group.

[0245] Foreground events can be used to indicate events corresponding to tasks performed by foreground applications, including but not limited to: application startup events, audio / video switching events, page update or switching events, etc. The aforementioned page update or / or switching events may include events where the foreground application changes (e.g., the user interface displayed on the electronic device changes from the user interface of application 1 to the user interface of application 2). This application does not limit the method for detecting foreground events.

[0246] When a foreground event is detected, the electronic device can calculate the CPU load rate of the foreground group. The CPU load of a thread can represent the number of times a thread needs to perform CPU operations. The more tasks a thread needs to execute, the higher its CPU load. This application does not limit the method for detecting the CPU load of a thread. For example, the CPU load can be calculated based on the CPU window-assist load tracing (WALT) scheduling cycle.

[0247] In some embodiments, the CPU load rate of the foreground group may specifically include: the proportion of the CPU load of the threads managed by the CFS scheduler in the top-level thread group and the secondary thread group to the CPU load of all threads managed by the CFS scheduler.

[0248] Alternatively, the CPU load rate of the foreground group can include: the proportion of the CPU load of all threads in the top-level thread group and the second-level thread group to the CPU load of all threads in the electronic device.

[0249] S613. Adjust the CPU weight ratio of each group in the CPU group according to the change of CPU load rate of the foreground group.

[0250] In some embodiments, when the CPU load rate of the foreground group increases, the electronic device may proportionally increase the proportion of CPU time slices allocated to the foreground group.

[0251] like Figure 6B As shown, when the CPU load rate of the foreground group increases by 10%, the CPU time slice ratio of the foreground group can increase by 10% accordingly. It can be seen that before the CPU load rate of the foreground group increases, the combined CPU time slice ratio of the top-level thread group and the secondary thread group is 40%. After the CPU load rate of the foreground group increases by 10%, the combined CPU time slice ratio of the top-level thread group and the secondary thread group is 50%, an increase of 10%. Correspondingly, after the CPU load rate of the foreground group increases by 10%, the CPU time slice ratio of the non-foreground group (i.e., the normal system thread group, the restricted thread group, and the normal background thread group) decreases from 60% to 50%.

[0252] In some embodiments, since the foreground group includes a top-level thread group and a secondary thread group, the electronic device can increase the CPU time slice ratio of the top-level thread group and the secondary thread group based on the increase in the CPU time slice ratio of the foreground group. For example, the increase in the CPU time slice ratio of the top-level thread group and the secondary thread group can be the same. If the CPU time slice ratio of the foreground group increases by 10%, the CPU time slice ratio of both the top-level thread group and the secondary thread group can increase by 5% (i.e., both increase from 20% to 25%). Alternatively, the electronic device can determine the CPU time slice ratio of the top-level thread group and the secondary thread group based on the CPU load of the top-level thread group and the CPU load of the secondary thread group. If the CPU load of the top-level thread group is greater than the CPU load of the secondary thread group, the increase in the CPU time slice ratio of the top-level thread group can be greater than the increase in the CPU time slice ratio of the secondary thread group. Similarly, since the non-foreground group includes a normal system thread group, a restricted thread group, and a normal background thread group, the electronic device can reduce the CPU time slice ratio of the normal system thread group, the restricted thread group, and the normal background thread group based on the decrease in the CPU time slice ratio of the non-foreground group. The CPU time slice ratios for normal system thread groups, restricted thread groups, and normal background thread groups can be reduced equally or unevenly.

[0253] like Figure 6B As shown, when the load rate of the foreground group increases by 10%, the electronic device can change the CPU weights of the top-level thread group, secondary thread group, normal system thread group, restricted thread group, and normal background thread group from 1:1:1:1:1 to 3:3:2:2:2. The electronic device's CFS scheduler can allocate CPU time slices to threads in each CPU group according to the 3:3:2:2:2 CPU weights.

[0254] In some embodiments, when the CPU load rate of the foreground group decreases, the electronic device can proportionally reduce the CPU time slice ratio of the foreground group. The method for proportionally reducing the CPU time slice ratio of the foreground group can refer to the method for proportionally increasing the CPU time slice ratio of the foreground group described above. It will not be repeated here.

[0255] This application does not limit the method by which the electronic device adjusts the CPU weight ratio based on changes in the CPU load rate of the foreground group. Besides proportionally increasing or decreasing the CPU time slice ratio of the foreground group, the electronic device can also increase or decrease the CPU time slice ratio of the foreground group at different ratios. For example, if the CPU load rate of the foreground group increases by X%, the electronic device can increase the CPU time slice ratio of the foreground group by 2X%. When the CPU load rate of the foreground group decreases by X%, the electronic device can decrease the CPU time slice ratio of the foreground group by 0.5X.

[0256] Understandably, when the aforementioned foreground events occur, the CPU load of threads in the foreground group may change. When the electronic device detects a foreground event, adjusting the CPU weight ratio based on the change in the CPU load rate of the foreground group can reduce the number of times the electronic device detects the CPU load rate of the foreground group, thereby improving the efficiency of managing the CPU time slices of each thread group.

[0257] In some embodiments, beyond the detection of foreground events described above, the electronic device can also calculate the CPU load rate of the foreground group at other times. For example, the electronic device can periodically calculate the CPU load rate of the foreground group and adjust the CPU weight ratio as the CPU load rate of the foreground group changes, thereby adjusting the CPU time slice length allocated to each thread group. This application embodiment does not limit the timing of the electronic device calculating the CPU load rate of the foreground group and adjusting the CPU weight ratio.

[0258] S614. When the front-end event ends, restore the CPU weights of each group in the CPU group to their initial weights.

[0259] The end of a foreground event indicates that the task corresponding to the foreground event has been completed. When the foreground time ends, the electronic device can restore the CPU weights of each group in the CPU group to their initial weights, such as proportional weights.

[0260] As the above method shows, threads in the foreground group are those with high user sensitivity. Based on this CPU grouping, electronic devices can suppress processor resources allocated to threads outside the foreground group when the CPU load rate of the foreground group is high, providing longer CPU time slices for threads in the foreground group. This allows foreground threads to obtain more processor resources when the workload is heavy, enabling them to complete tasks faster and providing a smooth user experience. Furthermore, when the CPU load rate of the foreground group decreases, the electronic device can provide longer CPU time slices to threads outside the foreground group, allowing their tasks to execute quickly. This method, by grouping and managing CPU time slices for different CPU groups, effectively improves processor resource utilization efficiency, ensuring smooth device operation while allowing threads outside the foreground group to continue running.

[0261] In some embodiments, based on the above Figure 5 As shown in the CPU groups, electronic devices can suppress the bandwidth quota of processor resources obtained by different CPU groups.

[0262] Bandwidth quota is a mechanism that limits CPU execution time slices on an absolute time basis. As described in the previous embodiments, electronic devices can allocate CPU time slices to threads. Bandwidth quota can represent that within the CPU time slice allocated to a thread, the thread is only allowed to run for a fixed time quota. When the time quota is exceeded, the thread will be restricted from running. After obtaining the next CPU time slice, the thread can continue to run within the corresponding time quota.

[0263] Figure 7A An exemplary flowchart illustrates a method for bandwidth quota suppression based on thread grouping.

[0264] S711. Obtain the overall load and / or temperature of the electronic device.

[0265] Overall system load represents the proportion of CPU computing power consumed by all threads running in an electronic device over a given period of time, relative to the maximum computing power the CPU can provide. A higher overall system load indicates greater CPU computing power consumption, and consequently, faster power consumption and temperature rise of the electronic device.

[0266] Device temperature can be the temperature of the electronic device's casing, such as the temperature of the back cover. Alternatively, device temperature can also be the temperature of the electronic device's processor.

[0267] S712. Determine the processor's bandwidth quota based on the overall system load and / or device temperature, and apply bandwidth quotas to one or more groups among the normal system thread group, restricted thread group, and normal background thread group based on the bandwidth quota.

[0268] In some embodiments, the electronic device may store a correspondence between overall load and / or device temperature and bandwidth quota. Based on this correspondence, the electronic device can determine the current bandwidth quota of the processor.

[0269] The relationship between the overall load and the bandwidth quota can be found in Table 4 below.

[0270] Total load Bandwidth quota ＞90％ 10％ (80％，90％] 30％ (60％，80％] 50％

[0271] Table 4

[0272] Table 4 shows that when the overall system load is greater than 90%, the bandwidth quota can be 10%. A 10% bandwidth quota means that the electronic device allows a thread to run for 10% of its CPU time slice. For example, if the electronic device allocates a CPU time slice of 100ms to a thread, then the time quota for the thread is 10ms. When the overall system load is greater than 80% and less than or equal to 90%, the bandwidth quota can be 30% (i.e., a time quota of 30% of the corresponding CPU time slice). When the overall system load is greater than 60% and less than or equal to 80%, the bandwidth quota can be 50% (i.e., a time quota of 50% of the corresponding CPU time slice). It can be seen that the higher the overall system load, the lower the bandwidth quota, and the greater the degree of bandwidth quota suppression imposed on threads by the electronic device.

[0273] The relationship between equipment temperature and bandwidth quota can be found in Table 5 below.

[0274] Equipment temperature (°C) Bandwidth quota ＞46 10％ (42，46] 30％ (38，42] 50％

[0275] Table 5

[0276] As shown in Table 5, when the device temperature is greater than 46℃, the bandwidth quota can be 10%. When the device temperature is greater than 42℃ and less than or equal to 46℃, the bandwidth quota can be 30%. When the device temperature is greater than 38℃ and less than or equal to 42℃, the bandwidth quota can be 50%. It can be seen that the higher the device temperature, the lower the bandwidth quota, and the greater the degree of bandwidth quota suppression of threads by electronic devices.

[0277] Tables 4 and 5 above are merely illustrative examples of this application and should not be construed as limiting the application. In addition to the above table lookup methods, electronic devices can also determine the bandwidth quota corresponding to the current overall load or device temperature based on relevant models or calculation formulas.

[0278] In some embodiments, the electronic device can determine the bandwidth quota by combining the overall load and the device temperature. For example, based on the correspondence between overall load and bandwidth quota shown in Table 4 above, and the correspondence between device temperature and bandwidth quota shown in Table 5 above, the electronic device can use the smaller value between the bandwidth quota corresponding to the current overall load and the bandwidth quota corresponding to the current device temperature for bandwidth quota allocation, or the electronic device can use the average value between the bandwidth quota corresponding to the current overall load and the bandwidth quota corresponding to the current device temperature for bandwidth quota allocation. This application does not limit the method for determining the bandwidth quota based on overall load and device temperature.

[0279] When the overall load and / or device temperature change, the electronic device can dynamically adjust the degree of bandwidth quota suppression on the threads.

[0280] In some embodiments, the electronic device can assign bandwidth quotas to one or more groups among the normal system thread group, the restricted thread group, and the normal background thread group. Because Figure 5 The threads in the top-level and secondary thread groups shown are the more important threads; therefore, electronic devices do not need to allocate bandwidth quotas for the top-level and secondary thread groups.

[0281] In some embodiments, when the overall load is less than a preset threshold (e.g., 60%), and / or the device temperature is less than a preset threshold (e.g., 38°C), the electronic device may stop applying bandwidth quotas to the normal system thread group, the restricted thread group, and the normal background thread group. This application embodiment does not limit the value of the above threshold.

[0282] As described above, electronic devices can apply bandwidth quotas to threads in non-foreground groups based on overall system load and / or device temperature. Bandwidth quotas can reduce the overall system load per unit time. Specifically, the higher the overall system load, the greater the degree of bandwidth quota suppression applied to threads in non-foreground groups; similarly, the higher the device temperature, the greater the degree of bandwidth quota suppression applied to threads in non-foreground groups. This bandwidth quota suppression method can control the overall system load and device temperature of the electronic device, reducing the impact of threads in non-foreground groups on the operation of threads in the foreground group when the overall system load is too high, and also reducing the risk of excessively high device temperatures.

[0283] Figure 7B An exemplary flowchart of another method for bandwidth quota suppression based on thread grouping is shown.

[0284] S721: Persistently allocate bandwidth quotas to the restricted thread group based on the processor's bandwidth quota of 1.

[0285] The bandwidth quota of 1 can be preset. This application embodiment does not limit the value of the bandwidth quota of 1. For example, the bandwidth quota of 1 can be 10%.

[0286] In some embodiments, the electronic device can identify threads in a restricted thread group that are time-delayed and have high CPU load. The CPU load of a thread can be referenced from the foregoing. Figure 6A The introduction states that threads with high CPU load can include those whose CPU load exceeds a preset load threshold. Electronic devices can use a bandwidth quota of 1 to persistently allocate bandwidth to the aforementioned delayed threads with high CPU load.

[0287] S722. Determine the processor's bandwidth quota 2 based on the overall system load and / or device temperature, and apply bandwidth quotas to the normal system thread group and the normal background thread group based on the bandwidth quota 2.

[0288] The method for determining bandwidth quota based on overall system load and / or equipment temperature can be found in the aforementioned [reference needed]. Figure 7A The method shown is described below.

[0289] As demonstrated by the methods described above, electronic devices can persistently suppress bandwidth quotas for threads with high CPU load and low latency to reduce sudden load spikes. Furthermore, electronic devices can dynamically suppress bandwidth quotas for threads outside the restricted thread groups in non-foreground groups based on overall system load and / or device temperature. This allows for control over the overall system load and temperature of the electronic device, reducing the impact of non-foreground threads on foreground threads when the overall system load is too high, and also mitigating the risk of overheating.

[0290] In some embodiments, the electronic device can persistently allocate bandwidth quotas to ordinary system thread groups, restricted thread groups, and ordinary background thread groups according to a preset bandwidth quota. This application embodiment does not limit the value of the preset bandwidth quota.

[0291] In some embodiments, priority inversion may occur during thread execution. Priority inversion can mean that when a high-priority thread needs to access a shared resource, that resource is already held by a low-priority thread, and this low-priority thread may be preempted by other medium-priority threads while accessing the shared resource, thus causing the high-priority thread to be blocked by many lower-priority threads.

[0292] To address the priority inversion issue, electronic devices can set up critical sections and add threads that are dependent on by the foreground group from non-foreground groups to these critical sections. Electronic devices can achieve faster execution of threads within critical sections through one or more of the following measures: increasing the priority of threads in the critical section, removing bandwidth quota restrictions on threads in the critical section, increasing the CPU time slice length for threads in the critical section, etc.

[0293] Figure 8 An exemplary flowchart of a method for allocating processor resources is shown.

[0294] S811. When it is detected that thread 1 in the foreground group is waiting for the binder / thread lock held by thread 2 in the non-foreground group to be released, thread 2 is marked as a critical section. The non-foreground group includes the normal system thread group, the restricted thread group, and the normal background thread group.

[0295] Binder is a mechanism for inter-process communication, allowing data transfer and method calls between different processes. In some embodiments, if thread 1 needs to use the result of thread 2 during its execution, thread 1 can wake up thread 2 based on the binder. At this time, thread 2 holds the binder that thread 1 depends on, and thread 1 needs to wait for thread 2 to release the binder before it can continue running.

[0296] Thread locks can be used to lock shared resources to prevent multiple threads from accessing or modifying them simultaneously. When multiple threads need to modify or access a shared resource, a thread lock ensures that only one thread can perform read and write operations on the shared resource at a time. In some embodiments, if thread 2 holds a thread lock on a shared resource, thread 1 must wait for thread 2 to release the lock when it needs to access the shared resource.

[0297] In some embodiments, the electronic device can detect whether a thread in the foreground group is waiting for a binder / thread lock held by a thread in a non-foreground group to be released. As can be seen from the foregoing embodiments, the electronic device may perform operations such as CPU time slice reduction and / or bandwidth quota suppression on threads in non-foreground groups. If a thread in the foreground group is waiting for a binder / thread lock held by a thread in a non-foreground group to be released, the aforementioned CPU time slice reduction and / or bandwidth quota suppression may cause the thread in the foreground group to be blocked for a long time, affecting the smoothness of the electronic device's operation.

[0298] This example illustrates the scenario where thread 1 in the foreground group waits for the binder / thread lock held by thread 2 in the non-foreground group to be released. The electronic device can label thread 2 as a critical section. Labeling thread 2 as a critical section indicates that thread 2 is added to the critical section. This application does not limit the implementation method of the aforementioned critical section label.

[0299] S812. Perform one or more of the following operations on threads with critical section labels: increase priority, increase CPU time slice length, or remove bandwidth quota suppression.

[0300] In some embodiments, the CFS scheduler in the electronic device may perform one or more of the following operations on thread 2: increase priority, increase CPU time slice length, and remove bandwidth quota suppression.

[0301] Increasing the priority of thread 2 can reduce the likelihood of processor resources being preempted by other higher-priority threads while thread 2 is running. This can also reduce the possibility of threads with lower priority than thread 1 starting to run before thread 1 due to their higher priority than thread 2, thus preventing thread 1 from being blocked for a long time while waiting for thread 2 to release the binder / thread lock.

[0302] Increasing the CPU time slice length and removing bandwidth quota suppression can both enable thread 2 to run quickly, so that thread 2 can release the binder / lock that thread 1 depends on as soon as possible.

[0303] S813. When thread 2 releases the binder / thread lock, remove the critical section label of thread 2.

[0304] When thread 2 releases the binder / thread lock that thread 1 depends on, the electronic device can remove the critical section label from thread 2. Removing the critical section label from thread 2 indicates that thread 2 is being removed from the critical section. Once the critical section label for thread 2 is removed, the CFS scheduler in the electronic device can restore thread 2's priority and CPU time slice length to their initial state (i.e., the state before thread 2 entered the critical section). Furthermore, the electronic device can, according to the aforementioned... Figure 7A or Figure 7B The method shown suppresses the bandwidth quota for thread 2.

[0305] As described above, when threads in a foreground group (e.g., top-level thread group / secondary thread group) depend on threads in a non-foreground group (e.g., normal system thread group / restricted thread group / normal background thread group), the electronic device can temporarily increase the priority of the non-foreground thread that is depended on by the foreground group, increase the CPU time slice length of that thread, and remove bandwidth quota restrictions on that thread. Furthermore, it can move the non-foreground thread that is depended on by the foreground group to the foreground group where the required response and execution time is available. Compared to changing the thread group of the dependent thread, the above method of setting critical sections can more efficiently reduce priority inversion and improve the smoothness of thread execution in the foreground group.

[0306] In some embodiments, based on the non-critical threads identified in the foregoing embodiments, the electronic device can suppress the CPU frequency of the non-critical threads.

[0307] Figure 9 An exemplary flowchart illustrates a method for suppressing CPU frequency in non-critical threads.

[0308] S911. Determine the maximum CPU frequency for non-critical threads based on parameters such as overall system load and / or device temperature.

[0309] The overall load and equipment temperature can be referenced from the above. Figure 7A The introduction states that non-critical threads can include threads running on an electronic device, excluding critical threads and critical dependent threads. Methods for identifying critical dependent threads can be found in the preceding section. Figure 3A and Figure 3B For an introduction, or refer to the above... Figure 4A and Figure 4B Introduction.

[0310] In some embodiments, the electronic device may store a correspondence between the overall load and / or device temperature and the maximum CPU frequency corresponding to non-critical threads.

[0311] The relationship between overall system load and the maximum CPU frequency corresponding to non-critical threads can be found in Table 6 below.

[0312] Total load Maximum CPU frequency for non-critical threads Load range 1 Frequency 1 Load range 2 Frequency 2 Load range 3 Frequency 3

[0313] Table 6

[0314] The relationship between device temperature and the maximum CPU frequency for non-critical threads can be found in Table 7 below.

[0315] Equipment temperature Maximum CPU frequency for non-critical threads Temperature range 1 Frequency 1 Temperature range 2 Frequency 2 Temperature range 3 Frequency 3

[0316] Table 7

[0317] Tables 6 and 7 above are merely illustrative examples of this application and should not be construed as limiting this application.

[0318] It should be noted that the higher the overall system load, the lower the maximum CPU frequency for non-critical threads, and the greater the degree of CPU frequency suppression for non-critical threads by the electronic device. Similarly, the higher the device temperature, the lower the maximum CPU frequency for non-critical threads, and the greater the degree of CPU frequency suppression for non-critical threads by the electronic device.

[0319] In some embodiments, the electronic device can determine the maximum CPU frequency for non-critical threads by combining overall system load and device temperature. When the overall system load and / or device temperature change, the electronic device can dynamically adjust the CPU frequency suppression level for non-critical threads.

[0320] Beyond overall system load and device temperature, electronic devices can also determine the maximum CPU frequency for non-critical threads based on other factors. For example, an electronic device can also determine the maximum CPU frequency for non-critical threads based on its current power consumption. Specifically, the higher the current power consumption of the electronic device, the lower the maximum CPU frequency for non-critical threads.

[0321] S912. When running non-critical threads, the CPU operating frequency is controlled below the maximum CPU frequency corresponding to the non-critical thread.

[0322] In some embodiments, when running non-critical threads, the CPU operating frequency may vary dynamically, and the CPU operating frequency shall not exceed the maximum CPU frequency corresponding to the non-critical thread.

[0323] S913. When one or more non-critical threads are identified as critical dependent threads, the CPU frequency suppression on these one or more non-critical threads is lifted.

[0324] From the above Figure 4A and Figure 4B As shown in the method, electronic devices can detect critical dependent threads in real time based on online mode. When one or more threads are detected to have changed from non-critical to critical, the electronic device can operate without controlling the CPU frequency below the maximum CPU frequency corresponding to the non-critical thread (i.e., releasing CPU frequency suppression) while these threads are running. The aforementioned threads that change from non-critical to critical can include those updating the aforementioned... Figure 4A The thread protection list shown refers to newly added threads.

[0325] In some embodiments, when a thread changes from a critical dependent thread to a non-critical thread, the electronic device can control the CPU's operating frequency below the maximum CPU frequency corresponding to the non-critical thread (i.e., suppress the CPU frequency of this thread) while this thread is running. The thread that changes from a critical dependent thread to a non-critical thread may include updates to the aforementioned... Figure 4A The thread protection list shown refers to the threads that are removed from the thread protection list.

[0326] As can be seen from the above methods, by suppressing the CPU frequency of non-critical threads, electronic devices can save power and reduce the rapid overheating of electronic devices while keeping non-critical threads running.

[0327] In some embodiments, the electronic device may further divide the threads within the electronic device into Group 1 and Group 2. Group 1 may include key threads in the current application scenario and their critical dependent threads, as well as threads of the foreground application. Group 2 may include other threads outside of Group 1. The electronic device can calculate the CPU load rate of Group 1 and adjust the ratio of CPU weights between Group 1 and Group 2 based on changes in the load rate of Group 1, thereby adjusting the CPU time slice length of threads in Group 1 and Group 2 (see the foregoing for details). Figure 6A (The method shown).

[0328] Optionally, the electronic device can allocate CPU bandwidth quotas to threads in group 2 (see above for details). Figure 7A (The method shown). In addition, the electronic device can also identify the time-delayable threads in group 2 and assign a persistent CPU bandwidth quota to the aforementioned time-delayable threads.

[0329] Optionally, the electronic device can also detect whether a thread in group 1 is waiting for the release of a binder / thread lock held by a thread in group 2. For example, if thread a1 in group 1 is waiting for the release of a binder / thread lock held by thread a2 in group 2, the electronic device can add thread a2 to the critical section (see the foregoing for details). Figure 8 (The method shown).

[0330] Optionally, the electronic device can suppress the frequency of threads in group 2 (see above for details). Figure 9 (The method shown).

[0331] In some embodiments, the electronic device can dynamically adjust the frequency of critical threads and critical dependent threads in the electronic device to achieve precise allocation of processor resources to critical threads and critical dependent threads.

[0332] In subsequent embodiments of this application, the dynamic frequency modulation method is specifically described using a thread related to drawing frames (hereinafter referred to as the drawing frame thread) as an example. Here, a drawing frame can refer to the user interface displayed by the electronic device. The number of times the electronic device refreshes and draws an image on the screen per unit time can be determined by the refresh rate of the electronic device's screen. For example, if the refresh rate of the electronic device is 120 Hz, then the electronic device can refresh the screen once every 8.3 ms, that is, draw one frame of image every 8.3 ms. Threads related to drawing frames may include the UI thread, the RS thread, critical dependency threads that the UI thread depends on, and critical dependency threads that the RS thread depends on.

[0333] Figure 10 An exemplary schematic diagram of a frequency modulation curve is shown. Electronic devices can follow... Figure 10 The frequency modulation curve shown dynamically modulates the frequency of the drawing thread.

[0334] Figure 10 The frequency modulation function corresponding to the frequency modulation curve shown can be found in the following formula (1):

[0335]

[0336] Here, u(t) represents the CPU computing power provided to the thread at a certain moment. maxUtil represents the maximum computing power that the CPU can provide. For example, maxUtil can be 1024. Time represents the duration that the electronic device has been drawing a frame of an image, that is, the duration from the moment the frame drawing instruction (such as the frame synchronization signal) is issued to the current moment. deadline represents the frame duration or frame period, which can be determined by the screen refresh rate. For example, if the screen refresh rate is 120Hz, the deadline can be 8.3ms. If the screen refresh rate is 60Hz, the deadline can be 16.67ms. margin represents the duration of each frame in history for completing its corresponding frame task. For example, margin can be a cumulative amount determined by the historical average runtime. If a historical frame times out (e.g., the frame drawing task is not completed within 8.3ms), the margin will increase. If the historical frame runtime is shortened (e.g., the frame drawing task is completed in less than 8.3ms), the margin will decrease.

[0337] exist Figure 10 In the coordinate axis shown, the vertical axis can be u(t), and the horizontal axis can be the aforementioned Time. It can be seen that, with a fixed margin, the CPU computing power provided to the frame-drawing thread during the process of drawing one frame of an image by the electronic device increases linearly with time. The electronic device can store a frequency-point computing power table. The electronic device can adjust the CPU frequency based on the computing power determined by the aforementioned frequency modulation curve.

[0338] The frequency point computing power table can be found in Table 8 below.

[0339] computing power frequency Computing power 1 Frequency 1 Computing power 2 Frequency 2 …… ……

[0340] Table 8

[0341] In some embodiments, the CPU of an electronic device may include multiple CPU cores. Different CPU cores may operate at different frequencies. Different CPU cores may run different threads simultaneously, handling different tasks. The aforementioned frequency-based computing power table may include the frequencies of different CPU cores under a given CPU computing power. Thus, the electronic device can adjust the frequency of the CPU core running that thread based on the computing power provided to that thread.

[0342] In addition to the frequency computing power table mentioned above, electronic devices can also adjust the CPU frequency according to computing power in other ways.

[0343] Depend on Figure 10As shown in the frequency modulation curves, the electronic device provides less computing power to the frame-drawing thread in the early stages of drawing an image frame, resulting in a slower task completion speed. If the frame-drawing thread has a large workload to complete for drawing one image frame, the task may not be completed in time, leading to dropped frames. Furthermore, the electronic device provides more computing power to the frame-drawing thread in the background of drawing an image frame. If the frame-drawing thread has a small workload to complete for drawing one image frame, the task may have already been completed, while the electronic device continues to provide high computing power, resulting in a waste of processor resources. Therefore, Figure 10 The frequency modulation curve shown is not conducive to the efficient utilization of processor resources.

[0344] In order to improve the utilization efficiency of processor resources, electronic devices can perform dynamic frequency modulation based on the frequency modulation function shown in the following formula (2).

[0345]

[0346] Where kk is the slope parameter, which can be used to change the slope of the frequency modulation function. α is the curvature parameter, which can be used to change the curvature of the frequency modulation function.

[0347] In some embodiments, the server can perform simulations based on historical CPU load data to determine the values ​​of kk and α under the optimal frequency modulation function. The server can then send the optimal frequency modulation function to the user-side electronic device. The user-side electronic device can use the optimal frequency modulation function to dynamically adjust the frequency of critical threads such as the frame-drawing thread and critical dependent threads. The method for determining the optimal frequency modulation function provided in this application is described in detail below.

[0348] Figure 11A An exemplary schematic diagram for determining the optimal frequency modulation function is shown.

[0349] like Figure 11A As shown, server 200 may include a task generation module and a frequency modulation simulator.

[0350] The task generation module can generate a task data list based on historical CPU load data and frequency computing power tables. Historical CPU load data can include thread execution duration and CPU frequency during thread execution. In some embodiments, historical CPU load data can be trace files generated by tracking the running threads of an electronic device. For example, historical CPU load data can include thread execution data (such as runtime and CPU frequency) after one or more applications are launched on an electronic device over a period of time (e.g., 12 hours, 24 hours, etc.).

[0351] The task data list can include the frame task volume of critical threads and critical dependent threads. For example, the historical CPU load data mentioned above can include the multi-frame task volume of the drawing thread drawing multiple frames of images. Each frame task volume can correspond to a frame sequence number. The frame task volume for drawing one frame of an image can be calculated from the runtime of the drawing thread executing this frame task volume and the computing power corresponding to the CPU frequency.

[0352] The task generation module can send a list of task data to the frequency modulation simulator.

[0353] The frequency modulation simulator can determine the optimal frequency modulation function based on the task data list and CPU energy efficiency curve.

[0354] CPU energy efficiency curves can be used to reflect the relationship between CPU computing power and power consumption during operation. Different CPU models may have different CPU energy efficiency curves.

[0355] Figure 11B An example diagram of a CPU energy efficiency curve is shown.

[0356] like Figure 11B As shown, the horizontal axis *u* of the CPU energy efficiency curve represents the computing power provided by the CPU, and the vertical axis *g(u)* represents the power consumption of the CPU at a certain computing power, that is, the power consumption required for the CPU to complete a unit of task. It can be seen that the greater the computing power provided by the CPU, the higher the CPU power consumption. Furthermore, the CPU energy efficiency curve is a convex curve. This indicates that as the computing power provided by the CPU increases, the increase in CPU power consumption is greater for every unit increase in computing power.

[0357] For example, the optimal energy efficiency portion of the CPU energy efficiency curve can be... Figure 11B The computing power shown falls within the range of u1 to u2. It's understandable that in the portion of the CPU energy efficiency curve where the computing power is less than u1, although the CPU power consumption is low, the computing power is too small, leading to slow thread execution and sluggish device performance. In the portion of the CPU energy efficiency curve where the computing power is greater than u2, the increase in CPU power consumption for each unit increase in computing power is too high, meaning the power cost of increasing computing power is too great. Therefore, providing computing power within the range of u1 to u2 is beneficial for fast thread execution and allows for the execution of more tasks with less power consumption, saving the power of the electronic device. The values ​​of u1 and u2 mentioned above are related to the functional expression of the CPU energy efficiency curve. This application does not limit the values ​​of u1 and u2.

[0358] Figure 11B The CPU energy efficiency curves shown are merely illustrative examples of this application and should not be construed as limiting the scope of this application.

[0359] The frequency modulation simulator can traverse the range of values ​​for the slope and curvature parameters of the frequency modulation function based on the simulation granularity, and determine the frequency modulation function under different combinations of slope and curvature parameter values.

[0360] The slope parameter is kk in formula (2) above. The curvature parameter is α in formula (2) above. The simulation granularity, the range of values ​​for kk, and the range of values ​​for α can all be preset. For example, the range of values ​​for kk can be greater than or equal to 0.1 and less than or equal to 20. The range of values ​​for α can be greater than or equal to 0.1 and less than or equal to 5. The simulation granularity can be 0.1. Based on this simulation granularity, the frequency modulation simulator can determine 200 values ​​from the range of values ​​for kk and 50 values ​​from the range of values ​​for α, thereby determining 10,000 different combinations of values ​​for kk and α (i.e., 10,000 different frequency modulation functions). The simulation granularity, the range of values ​​for kk, and α above are merely exemplary descriptions of this application and should not be construed as limiting this application. In some embodiments, the simulation granularity used for taking values ​​within the range of values ​​for kk and the simulation granularity used for taking values ​​within the range of values ​​for α can be different.

[0361] The frequency modulation simulator can traverse the task data list, simulate frame loss and power consumption of critical threads and critical dependent threads under different frequency modulation functions, and determine the optimal frequency modulation function based on the frame loss data and power consumption. The power consumption of the critical threads and critical dependent threads can be determined based on the CPU energy efficiency curve.

[0362] Server 200 can send the optimal frequency modulation function determined by the frequency modulation emulator to electronic device 100. The CPU energy efficiency curve used by the frequency modulation emulator in server 200 can be the CPU energy efficiency curve of the CPU in electronic device 100. In this way, electronic device 100 can accurately allocate processor resources based on this optimal frequency modulation function when running critical threads and critical dependent threads.

[0363] The following is about Figure 11A The method for determining the optimal frequency modulation function of server 200 is described in detail.

[0364] Figure 12A An exemplary flowchart of a method for determining the optimal frequency modulation function is shown.

[0365] S1211. Obtain historical CPU load data, CPU energy efficiency curve, and frequency point computing power table. Historical CPU load data includes thread runtime and CPU frequency during thread runtime.

[0366] S1212. Extract the runtime and CPU frequency of key threads and key dependent threads from historical CPU load data.

[0367] In some embodiments, the task generation module in server 200 can extract the runtime and CPU frequency of the drawing frame thread from historical load data, such as the runtime and CPU frequency of the UI thread and its critical dependent threads, the RS thread and its critical dependent threads.

[0368] Figure 12B An exemplary diagram illustrates the operation of the UI thread and the RS thread.

[0369] like Figure 12B As shown, electronic devices can send frame synchronization signals based on frame periods. These frame synchronization signals can be used to instruct the UI thread and RS thread to execute corresponding frame-drawing tasks frame by frame. For example, with a screen refresh rate of 120Hz, the frame period can be 8.3ms. The frame-drawing tasks executed by the UI thread may include determining the specific content displayed in each frame of the user interface. The frame-drawing tasks executed by the RS thread may include rendering and displaying each frame of the user interface based on the specific content determined by the UI thread. When the UI thread executes frame-drawing tasks within a frame period, it may need to rely on the operation of one or more critical dependent threads. Similarly, when the RS thread executes frame-drawing tasks within a frame period, it may need to rely on the operation of one or more critical dependent threads.

[0370] For example, such as Figure 12B As shown, upon receiving frame synchronization signal 1, the UI thread determines the content to be displayed in the first frame of the user interface and sends a drawing instruction to the RS thread via interprocess communication (IPC) to draw the first frame of the user interface. Upon receiving frame synchronization signal 2, the RS thread draws the first frame of the user interface according to the aforementioned drawing instruction. The RS thread can instruct the graphics processing unit (GPU) to draw the user interface. Furthermore, upon receiving frame synchronization signal 2, the UI thread determines the content to be displayed in the second frame of the user interface and sends a drawing instruction to the RS thread via IPC to draw the second frame of the user interface. The time interval between frame synchronization signals 1 and 2, and the time interval between frame synchronization signals 2 and 3, constitute the frame period. Upon receiving frame synchronization signal 3, the RS thread draws the second frame of the user interface according to the aforementioned drawing instruction. This process continues, allowing the UI thread and RS thread to refresh the user interface frame by frame on the screen.

[0371] The runtime of the UI thread can include the runtime for the UI thread to execute each frame rendering task. The runtime for the UI thread to execute a single frame rendering task is related to the workload of that frame. With a fixed CPU processing power, the more workload a single frame rendering task has, the longer the runtime for the UI thread to execute that frame. For example, the runtime for the UI thread to execute a single frame rendering task may be less than 8.3ms, or it may exceed 8.3ms. It should be noted that the runtime for the UI thread to execute a single frame rendering task may include the time the UI thread spends waiting for its critical dependent threads to run while executing that frame.

[0372] The runtime of the RS thread can be referenced from the runtime of the UI thread mentioned above.

[0373] S1213. Based on the frequency point computing power table, the runtime of the critical thread and the critical dependent thread, and the CPU frequency during runtime, determine the task data list of the critical thread and the critical dependent thread. The task data list includes the frame task volume of the critical thread and the critical dependent thread.

[0374] The task generation module in server 200 can determine the CPU computing power corresponding to the CPU frequency of the critical thread and critical dependent threads based on the frequency computing power table. The task generation module can calculate the frame task volume for each frame of tasks executed by the critical thread and critical dependent threads, and then generate a task data list. The task data list can be found in Table 9 below.

[0375] Frame number Frame task volume 1 Task Quantity 1 2 Task quantity 2 …… ……

[0376] Table 9

[0377] The frame sequence number can be arranged sequentially according to the execution order of each frame task. For example, in the frame tasks executed by the UI thread and the RS thread, the frame sequence number can be... Figure 12B The sequence number of the frame synchronization signal is shown. The workload of a frame task can be the product of the runtime of the frame task and the computing power of the CPU during the runtime of the frame task, or it can be the integral of the computing power of the CPU during the runtime of the frame task over the runtime of the frame task. In some embodiments, the above-mentioned frame workload can be the workload after normalization.

[0378] The task data list above may include the number of tasks executed by the UI thread for each frame, and the number of tasks executed by the RS thread for each frame.

[0379] The tasks executed by the UI thread and RS thread for each frame can be referred to in the preceding text. Figure 12BThe introduction states that, in some embodiments, if the critical thread is an audio playback thread, the workload of one frame task executed by the audio playback thread may include the workload of playing one frame of audio. This application does not limit the task type of each frame task executed by the critical thread and the critical dependent thread.

[0380] S1214. Obtain the form of the frequency modulation function, as well as the value range and simulation granularity of the slope and curvature parameters in the frequency modulation function.

[0381] The form of the frequency modulation function can be found in the aforementioned formula (2).

[0382] S1215. Determine the frequency modulation function based on the range of values ​​for the slope parameter and curvature parameter during the simulation granularity traversal.

[0383] S1216. Traverse the task data list and simulate the frame loss data and power consumption of critical threads and critical dependent threads when using the frequency adjustment function to dynamically adjust the frequency of critical threads and critical dependent threads according to the CPU energy efficiency curve.

[0384] Methods for determining the frame loss data and power consumption of critical threads and critical dependent threads can be found in subsequent parts of this application. Figure 12C The method shown.

[0385] S1217. Determine whether the range of values ​​for the slope parameter and curvature parameter has been traversed.

[0386] If the range of values ​​for the slope parameter and curvature parameter has been traversed, the frequency modulation simulator in server 200 can execute the following step S1218.

[0387] If the range of values ​​for the slope parameter and curvature parameter has not been fully traversed, the frequency modulation simulator in server 200 can continue to execute the above step S1215.

[0388] S1218. Determine the optimal frequency modulation function based on the frame loss data and power consumption corresponding to the frequency modulation function under multiple different combinations of slope and curvature parameters.

[0389] A frequency modulation (FM) simulator can determine different frequency modulation functions based on different combinations of slope and curvature parameters. The FM simulator can simulate the frame loss and power consumption corresponding to different frequency modulation functions when frequency-modulating the same critical thread and critical dependent threads.

[0390] In some embodiments, the frequency modulation simulator can first select the frequency modulation function with the minimum frame loss data, and then determine the frequency modulation function with the minimum power consumption among the frequency modulation functions with the minimum frame loss data as the optimal frequency modulation function. Alternatively, the frequency modulation simulator can first select the frequency modulation function with the minimum power consumption, and then determine the frequency modulation function with the minimum frame loss data among the frequency modulation functions with the minimum power consumption as the optimal frequency modulation function. Alternatively, the frequency modulation simulator can perform a weighted summation of the frame loss data and power consumption corresponding to the frequency modulation function, and determine the frequency modulation function with the minimum weighted sum value as the optimal frequency modulation function.

[0391] The method described above for determining the optimal frequency modulation function based on the frame loss data and power consumption corresponding to the frequency modulation function is merely an illustrative example of this application and should not be construed as limiting this application.

[0392] Figure 12C An exemplary flowchart illustrates a method for determining frame loss data and power consumption of critical threads and critical dependent threads based on a set of slope parameters and curvature parameters.

[0393] S1221. Determine the frame-CPU frequency modulation allocation result based on the frame period and CPU frequency modulation period.

[0394] In some embodiments, the frame period can represent the time interval between two consecutive frame synchronization signal transmissions. The frame synchronization signal can be referred to in the foregoing. Figure 12B The CPU frequency adjustment cycle can be described as the time interval between two consecutive adjustments to the CPU frequency.

[0395] The CPU frequency adjustment period and the frame period can be different. For example, the frame period can be 8.3ms, while the CPU frequency adjustment period can be 4ms. Therefore, the timing of CPU frequency adjustment by an electronic device may occur at different times within different frame periods.

[0396] For example, an electronic device might perform the first CPU frequency adjustment at 4ms, the second at 8ms, the third at 12ms, and the fourth at 16ms. The critical thread of the electronic device runs the first frame task from 0 to 8.3ms and the second frame task from 8.3ms to 16.6ms. Therefore, the first CPU frequency adjustment could occur at 4ms of the frame period containing the first frame task. The second CPU frequency adjustment could occur at 8ms of the frame period containing the first frame task. The third CPU frequency adjustment could occur at 3.7ms of the frame period containing the second frame task. The fourth CPU frequency adjustment could occur at 7.7ms of the frame period containing the second frame task.

[0397] The frame-CPU frequency modulation allocation result can be used to indicate the correspondence between the CPU frequency modulation cycle and the frame cycle, so as to determine which frame cycle the current CPU frequency modulation is in. In this way, the electronic device can determine whether to increase or decrease the frequency based on whether the frame task in the frame cycle in which the current CPU frequency modulation is located has been completed.

[0398] S1222. Determine the frequency modulation function 1 corresponding to the CPU computing power, slope parameter 1, and curvature parameter 1 of the first frame.

[0399] The CPU computing power of the first frame can be preset. The frequency modulation emulator can determine the CPU frequency of the first frame corresponding to the computing power of the first frame according to the frequency modulation computing power table. This application embodiment does not limit the value of the CPU computing power of the first frame.

[0400] S1223. Determine whether the task data list has been processed.

[0401] Once the task data list is processed, it indicates that the frequency modulation simulator has simulated all frame tasks in the task data list using frequency modulation function 1. Specifically, simulating a single frame task using frequency modulation function 1 means that during the execution of a frame task, the frequency modulation simulator uses frequency modulation function 1 to adjust the CPU frequency, thereby determining the execution duration and power consumption of that frame task under the influence of frequency modulation function 1.

[0402] In some embodiments, the frequency modulation simulator can use frequency modulation function 1 to simulate each frame of the task in the task data list in sequence according to the frame number arrangement in the task data list.

[0403] If the task data list is processed, the frequency modulation simulator can execute the following step S1227.

[0404] If the task data list has not been processed, the frequency modulation simulator can perform the following step S1224.

[0405] S1224. Based on the current frame number, the remaining task quantity of the previous frame, the historical CPU computing power simulation list, and the frame-CPU frequency modulation allocation result, determine the runtime simulation result and computing power simulation result corresponding to the current frame task when using frequency modulation function 1 for frequency modulation.

[0406] The frequency modulation simulator can obtain the current frame sequence number and then determine the task load of the current frame based on the frame sequence number.

[0407] In some embodiments, the previous frame task of the current frame task may not have completed all its tasks within its running frame period (e.g., 8.3ms). In this case, the remaining tasks from the previous frame can continue within the frame period corresponding to the current frame task. Specifically, within the frame period corresponding to the current frame task, the frequency modulation simulator can first complete the remaining tasks from the previous frame before starting the current frame task. If there are no remaining tasks from the previous frame task, the frequency modulation simulator can directly start running the current frame task within the frame period corresponding to the current frame task.

[0408] The historical CPU computing power simulation list can include all frame tasks preceding the current frame task, their execution time under the influence of frequency modulation function 1, and the computing power corresponding to each execution stage. The frequency modulation simulator can determine the value of the margin in frequency modulation function 1 based on the existing data in the historical CPU computing power simulation list, and then simulate the current frame task based on the frequency modulation function 1 corresponding to that margin. In some embodiments, the value of the margin can be the average execution time of the currently existing frame tasks in the historical CPU computing power simulation list.

[0409] Figure 12D An exemplary diagram is shown, illustrating the simulation of different frame tasks of a thread based on frequency modulation function 1.

[0410] like Figure 12D As shown, the CPU frequency adjustment cycle is 4ms. The CPU frequency adjustment cycle can also be called the computing power control cycle. The frame rendering cycle can be 8.3ms. The frame rendering cycle can be the frame cycle of the frame rendering thread (e.g., UI thread, RS thread). The CPU computing power of the first frame can be u12. The frequency adjustment emulator can start running the first frame task of the frame rendering thread from 0ms.

[0411] The frequency modulation simulator can start running the first frame task of the drawing thread at 0ms, that is, to simulate the first frame task.

[0412] Within 0-4ms, the CPU computing power provided by the frequency modulation emulator to the frame drawing thread can be u12. The 4ms mark is the CPU frequency adjustment point. At the 4ms mark, the frequency modulation emulator can determine whether the first frame task has been completed. If not, the frequency modulation emulator can increase the CPU computing power provided to the frame drawing thread from u12 to u12 according to the frequency modulation function 1. Figure 12DThe u14 shown refers to increasing the CPU frequency. During the 4-8ms interval, the CPU computing power provided by the frequency modulation emulator to the frame-drawing thread can be u14. Specifically, when frequency modulation function 1 is used during the execution of the first frame task, the margin value in frequency modulation function 1 can be preset. For example, the margin value can be 6ms. Furthermore, when CPU frequency modulation is performed at the aforementioned 4ms interval, since the execution time of the first frame task is 4ms, the Time value in frequency modulation function 1 can also be 4ms. Thus, the frequency modulation emulator can calculate the adjusted CPU frequency based on frequency modulation function 1 when CPU frequency modulation is performed at the 4ms interval.

[0413] like Figure 12D As shown, the completion time of the first frame task is 6.2ms. It can be understood that 6.2ms may include the time it takes for the drawing thread (such as the UI thread or RS thread) to run the first frame task and the time it takes for the drawing thread to wait for its critical dependent threads to run in order to run the first frame task.

[0414] The 8ms interval can be used for CPU frequency adjustment. Since the 8ms interval is still within the first frame drawing cycle, the frequency adjustment emulator can determine whether the first frame task is complete. If complete, the frequency adjustment emulator can reduce the CPU computing power provided to the frame drawing thread from u14 to... Figure 12D The u11 shown refers to reducing the CPU frequency. During the 8th-12th ms interval, the CPU computing power provided by the frequency modulation emulator to the frame drawing thread can be u11. The value of u11 can be preset. In this embodiment, the value of u11 is not limited.

[0415] The frequency modulation simulator can start running the second frame task of the drawing thread at 8.3ms, that is, to simulate the second frame task.

[0416] The 12ms mark is the CPU frequency adjustment point. Since the 12ms mark falls within the second frame rendering cycle, the frequency adjustment emulator can determine whether the second frame task is complete. If not, the frequency adjustment emulator can increase the CPU computing power provided to the rendering thread from u11 to u12 according to frequency adjustment function 1. Figure 12D As shown in u13, when frequency modulation function 1 is used during the execution of the second frame task, the value of margin in frequency modulation function 1 can be the runtime of the first frame task (e.g., 6.2ms). Furthermore, when CPU frequency modulation is performed at the 12ms level, since the execution time of the second frame task is 3.7ms (i.e., 12ms - 8.3ms), the value of Time in frequency modulation function 1 can be 3.7ms. Thus, the frequency modulation simulator can calculate the adjusted CPU frequency when CPU frequency modulation is performed at the 12ms level based on frequency modulation function 1.

[0417] like Figure 12DAs shown, the completion time of the second frame task is 7.5ms. It can be seen that the second frame task completes at 15.8ms (i.e., 8.3ms + 7.5ms). Understandably, the 7.5ms can include the time taken for the rendering thread (e.g., the UI thread, or the RS thread) to run the second frame task, as well as the time taken for that rendering thread to wait for its critical dependent threads to run.

[0418] The 16ms mark is the CPU frequency adjustment point. Since the 16ms mark falls within the second frame rendering cycle, the frequency adjustment emulator can determine whether the second frame task is complete. If complete, the frequency adjustment emulator can reduce the CPU computing power allocated to the rendering thread from u13 to... Figure 12D u11 is shown.

[0419] Similarly, the frequency modulation simulator can start running the third frame task of the drawing thread at 16.6ms, that is, to simulate the third frame task. During the execution of the third frame task, when frequency modulation function 1 is used, the margin value in frequency modulation function 1 can be the average runtime of the first and second frame tasks, i.e., (6.2+7.5) / 2 = 6.85ms. And so on, the frequency modulation simulator can use frequency modulation function 1 to complete the simulation of all frame tasks in the task data list.

[0420] When using frequency modulation function 1 to simulate each frame task, the frequency modulation simulator can use the simulation results of the runtime and computing power of each frame task when frequency modulation function 1 is used for frequency modulation.

[0421] For example, such as Figure 12D As shown, when using frequency modulation function 1, the simulation result of the runtime of the first frame task is 6.2ms. The computing power simulation result can include: the CPU computing power of the first frame task is u12 within the first 0-4ms and the CPU computing power is u14 within the first 4-6.2ms.

[0422] When using frequency modulation function 1, the simulation result of the runtime of the second frame task is 7.5ms. The simulation result of computing power can include: the CPU computing power is u11 during the first 0-3.7ms of the second frame task and u13 during the first 3.7-7.5ms.

[0423] Figure 12D The computing power adjustment process shown is merely an illustrative example of this application and should not be construed as limiting this application.

[0424] S1225. Determine the remaining task quantity for the current frame, update the thread runtime list based on the runtime simulation results corresponding to the current frame task, and update the historical computing power simulation list based on the computing power simulation results corresponding to the current frame task.

[0425] If the workload of the current frame task is not completed within the frame period corresponding to the current frame task (e.g., 8.3ms), the remaining workload of the current frame task can be completed within the frame period corresponding to the next frame task. The simulation result of the runtime corresponding to the current frame task can be expressed as the time taken to complete all the workload of the current frame task when using frequency modulation function 1 for frequency modulation.

[0426] The list of thread runtimes can be found in Table 10 below.

[0427] Frame number Simulation results for runtime (ms) 1 6.2 2 7.5 3 T3 …… ……

[0428] Table 10

[0429] The historical computing power simulation list can be found in Table 11 below.

[0430]

[0431] Table 11

[0432] Tables 10 and 11 above are merely illustrative examples of this application and should not be construed as limiting this application.

[0433] The frequency modulation simulator can add the runtime simulation results corresponding to the current frame task to the above thread runtime list, and add the computing power simulation results corresponding to the current frame task to the above historical computing power simulation list.

[0434] S1226, Increment the frame number by 1.

[0435] The frequency modulation simulator can increment the frame number of the current frame task by 1 in steps S1223 and S1225 above, and then execute step S1223 to determine whether the task data list has been processed. If the task data list does not contain the frame number obtained by incrementing the frame number by 1, the frequency modulation simulator can determine that the task data list has been processed. If the task data list contains the frame number obtained by incrementing the frame number by 1, the frequency modulation simulator can determine this frame number as the currently processed frame number and use frequency modulation function 1 to simulate the current frame task according to the methods in steps S1224 and S1225 above.

[0436] S1227. Based on the thread runtime list and the historical computing power simulation list, determine the frame loss data and power consumption of the critical thread and the critical dependent thread when using frequency modulation function 1 for frequency modulation.

[0437] After simulating all frame tasks in the task data list using frequency modulation function 1, the frequency modulation simulator can determine the frame loss data and power consumption of critical threads and critical dependent threads when using frequency modulation function 1, based on the thread runtime list and the historical computing power simulation list.

[0438] In some embodiments, the thread runtime list and the historical computing power simulation list may include the runtime data of the multi-frame tasks of the UI thread under the action of frequency modulation function 1. The frequency modulation simulator can calculate the frame loss data and power consumption of the UI thread under the action of frequency modulation function 1. The frame loss data may include the number of frames lost (or the amount of frames lost).

[0439] The number of frames dropped by the UI thread under the action of frequency modulation function 1 can be calculated according to the following formula (3).

[0440]

[0441] Where n1 represents the total number of frame tasks in the UI thread in the task data list. For example, if the task data list contains 100 frame tasks in the UI thread, then n1 is 100. The simulation result of the runtime of the i-th frame task in the UI thread can be obtained by looking up the thread runtime list. The duration threshold 1 can be preset. For example, the duration threshold 1 can be 8.33ms, 16.66ms, or 33.33ms, etc. The embodiments of this application do not limit the value of the duration threshold 1.

[0442] If the simulation result of the runtime of the i-th frame task is greater than the duration threshold 1, it indicates that the i-th frame task has experienced frame dropping. It is understandable that after the UI thread completes a frame task, it will instruct the RS thread to draw the image corresponding to the frame. The runtime of a frame task of the UI thread is greater than the drawing frame period, so there may not actually be any frame dropping in the user interface. Therefore, the duration threshold 1 can be greater than the drawing frame period (e.g., 8.3ms). The power consumption of the UI thread under the action of frequency modulation function 1 can be calculated according to the following formula (4).

[0443]

[0444] Where m represents the total number of frequency adjustments during the execution of the UI thread's frame task in the task data list. Computational power i represents the computational power value after the i-th frequency adjustment. Runtime i represents the runtime of the UI thread's frame task after the i-th frequency adjustment. Referring to Table 11 above, for example, the first frame task is the UI thread's frame task. The computational power value of the frequency adjustment emulator after the first frequency adjustment is u12, and the runtime of the UI thread's frame task is 4ms. Therefore, computational power 1 × runtime 1 = 4 × u12. The computational power value of the frequency adjustment emulator after the second frequency adjustment is u14, and the runtime of the UI thread's frame task is 2.2ms. Therefore, computational power 2 × runtime 2 = 2.2 × u12. f() can be the conversion formula between power consumption and computational power. f() can be determined by the CPU energy efficiency curve.

[0445] In some embodiments, the thread runtime list and the historical computing power simulation list may include the running data of the multi-frame tasks of the RS thread under the action of frequency modulation function 1. The frequency modulation simulator can calculate the frame loss data and power consumption of the RS thread under the action of frequency modulation function 1.

[0446] The number of frames dropped by the RS thread under the action of frequency modulation function 1 can be calculated according to the following formula (5).

[0447]

[0448] Here, n2 represents the total number of frame tasks in the RS thread in the task data list. For example, if the task data list contains 100 frame tasks in the RS thread, then n2 is 100. The simulation result of the runtime of the i-th frame task in the RS thread can be obtained by looking up the thread runtime list. The runtime threshold 2 can be preset. The runtime threshold 2 can be the same as or different from the runtime threshold 1 mentioned above. It is understandable that the frame tasks of the RS thread are directly related to the rendering and display of the user interface. The runtime of a frame task in the RS thread is longer than the drawing frame period, and the probability of frame dropping in the user interface is relatively high. Therefore, the value of the runtime threshold 2 can be less than the value of the runtime threshold 1 mentioned above. This can more accurately reflect the number of dropped frames.

[0449] The power consumption of the RS thread under the action of frequency modulation function 1 can be calculated by referring to the above formula (4).

[0450] Since both the UI thread and the RS thread are frame-drawing threads, the frequency modulation emulator can determine the total number of dropped frames based on the number of dropped frames by the UI thread and the RS thread under the frequency modulation function 1. For example, the frequency modulation emulator can determine the total number of dropped frames by summing the number of dropped frames by the UI thread and the RS thread under the frequency modulation function 1. Alternatively, the frequency modulation emulator can determine the total number of dropped frames by performing a weighted sum of the number of dropped frames by the UI thread and the RS thread under the frequency modulation function 1.

[0451] The frequency modulation emulator can also determine the total power consumption based on the power consumption of the UI thread and the RS thread under the action of frequency modulation function 1. For example, the frequency modulation emulator can determine the total power consumption by summing the power consumption of the UI thread and the RS thread under the action of frequency modulation function 1.

[0452] The method for using frequency modulation simulators with frequency modulation functions corresponding to other slope and curvature parameters can refer to the above method for using frequency modulation function 1 for simulation.

[0453] The frequency modulation simulator can determine the optimal frequency modulation function based on the total number of dropped frames and total power consumption of the UI thread and RS thread in the task data list when using different frequency modulation functions. These different frequency modulation functions can include those with different combinations of slope and curvature parameters.

[0454] In some embodiments, not limited to the UI thread and RS thread, the frequency modulation emulator can also combine the number of dropped frames and power consumption of other types of critical threads (such as the audio playback thread) under the action of the frequency modulation function to determine the total number of dropped frames and total power consumption corresponding to the frequency modulation function, and then select the optimal frequency modulation function. Optionally, the frequency modulation emulator can use only the number of dropped frames and power consumption of the UI thread under the action of the frequency modulation function to determine the total number of dropped frames and total power consumption corresponding to the frequency modulation function, and then select the optimal frequency modulation function. Alternatively, the frequency modulation emulator can use only the number of dropped frames and power consumption of the RS thread under the action of the frequency modulation function to determine the total number of dropped frames and total power consumption corresponding to the frequency modulation function, and then select the optimal frequency modulation function.

[0455] In some embodiments, when the frequency modulation simulator uses a frequency modulation function (e.g., frequency modulation function 1) to simulate a frame task, it may also consider frame insertion scenarios and / or frame skipping scenarios to improve the accuracy of the simulation results.

[0456] Frame interpolation can be used to advance short-frame tasks so that subsequent long-frame tasks can complete within their respective frame periods. Frame interpolation can reduce frame drops caused by timeouts in frame tasks. Short-frame tasks refer to frames with a small number of tasks that can be completed ahead of schedule within the frame period. Long-frame tasks refer to frames with a large number of tasks that cannot be completed within the frame period.

[0457] Figure 13A An exemplary schematic diagram of a frame interpolation scenario is shown.

[0458] like Figure 13A As shown, the UI thread's first and second frame tasks are both short frame tasks, while the third frame task is a long frame task. Without frame interpolation, the UI thread can start running the third frame task upon receiving frame synchronization signal 3. However, due to the large workload of the third frame task, the UI thread may not have completed its task when it receives frame synchronization signal 4.

[0459] When using a frame interpolation strategy, electronic devices can detect the completion time of each frame task. When a short frame task completes ahead of schedule within the frame period, the electronic device can send a virtual synchronization signal to the UI thread to instruct the UI thread to start running the next frame task.

[0460] For example, such as Figure 13AAs shown, when the first frame task is detected to have completed execution at time t11, the electronic device can send virtual frame synchronization signal 2 to the UI thread. Time t11 can be any time within the frame period corresponding to frame synchronization signal 1 and frame synchronization signal 2. According to virtual frame synchronization signal 2, the UI thread can start running the second frame task. When the second frame task is detected to have completed execution at time t12, the electronic device can send virtual frame synchronization signal 3 to the UI thread. Time t12 is earlier than the time frame synchronization signal 3 is sent. According to virtual frame synchronization signal 3, the UI thread can start running the third frame task. It can be seen that since the UI thread has already started running the third frame task before the arrival of frame synchronization signal 3, the UI thread can complete all the tasks of the third frame task before the arrival of frame synchronization signal 4. This avoids the third frame task having any remaining tasks that need to be run in the next frame period.

[0461] When using frequency modulation (FM) functions to simulate frame tasks, the FM simulator can employ a frame interpolation strategy. Since frame interpolation advances the execution time of one or more frame tasks, the FM simulator can determine which frame task is actually running each time FM is applied, thereby determining the execution period of each frame task and the CPU computing power required during execution.

[0462] Frame skipping can be used to discard tasks that have been waiting for too long. Frame skipping can reduce the number of dropped frames by reducing the backlog of frame tasks.

[0463] Figure 13B An example diagram of a frame skipping scenario is shown.

[0464] This section uses RS thread frame skipping as an example to introduce the frame skipping scenario.

[0465] like Figure 13B As shown, the UI thread can run corresponding frame tasks based on the received frame synchronization signal. (As mentioned above...) Figure 12B As the introduction states, after the UI thread completes a frame task, it sends the drawing instructions corresponding to that frame task to the RS thread, instructing the RS thread to draw the user interface corresponding to that frame task.

[0466] For example, after receiving frame synchronization signal 3, the UI thread can run its third frame task (e.g., determining the content displayed in the third frame of the user interface). The workload of the third frame task is relatively large. After receiving frame synchronization signal 4, the UI thread can continue to run the remaining workload of the third frame task, and after the third frame task has finished running, it can start running its fourth frame task.

[0467] After the UI thread finishes its 3rd frame task, it can send a drawing frame instruction to the RS thread to render the 3rd frame of the user interface. Based on this drawing frame instruction, the RS thread can run its 3rd frame task (e.g., rendering and displaying the 3rd frame of the user interface). The RS thread's 3rd frame task is also quite demanding. The RS thread's 3rd frame task is not yet complete until it receives frame synchronization signal 6. Therefore, after receiving frame synchronization signal 6, the RS thread can continue running its 3rd frame task.

[0468] After receiving frame synchronization signal 5, the UI thread can run its 5th frame task, and after receiving frame synchronization signal 6, it can run its 6th frame task. Specifically, after completing its 4th frame task, the UI thread can send a drawing command to the RS thread to render the 4th frame of the user interface, and after completing its 5th frame task, it can send a drawing command to the RS thread to render the 5th frame of the user interface. However, since the RS thread is currently running its 3rd frame task, both the RS thread's 4th frame task (e.g., rendering and displaying the 4th frame of the user interface) and 5th frame task (e.g., rendering and displaying the 5th frame of the user interface) must wait for the RS thread's 3rd frame task to complete.

[0469] In some embodiments, when the waiting time for a task frame exceeds a preset time threshold, the thread can skip this frame and directly run the next task frame. This application embodiment does not limit the value of the aforementioned time threshold. For example, when the third task frame of the RS thread completes execution, the waiting time for the fourth task frame of the RS thread is T4, and the waiting time for the fifth task frame of the RS thread is T5. If both T4 and T5 are greater than the aforementioned time threshold, the RS thread can skip the fourth and fifth tasks frame frame of the RS thread. After running the third task frame of the RS thread, the RS thread can run the sixth task frame of the RS thread according to the frame synchronization signal 7 (e.g., rendering and displaying the sixth frame user interface).

[0470] When simulating frame tasks using frequency modulation functions, frequency modulation emulators can employ a frame skipping strategy. Frame skipping cancels the execution of one or more frame tasks. The frequency modulation emulator can determine the number of dropped frames based on the number of skipped frames. The number of dropped frames can include the number of skipped frames. Furthermore, since skipped frame tasks are not executed, the frequency modulation emulator does not need to calculate the power consumption corresponding to the skipped frame tasks when calculating the power consumption of threads.

[0471] Understandably, in real-world thread execution scenarios, electronic devices may employ frame interpolation and / or frame skipping strategies for thread frame tasks. When using a frequency modulation (FM) simulator for simulation, employing frame interpolation and / or frame skipping strategies can more realistically simulate the actual thread execution process, thereby finding the optimal FM function more accurately.

[0472] Based on the simulation of the frequency modulation simulator, the optimal frequency modulation function determined by the frequency modulation simulator has the following characteristics: the curvature parameter of the optimal frequency modulation function is less than 1 (i.e., the frequency modulation curve corresponding to the optimal frequency modulation function is an upward convex curve), the convexity of the frequency modulation curve corresponding to the optimal frequency modulation function is positively correlated with the convexity of the CPU energy efficiency curve, and the increase of the optimal frequency modulation function slows down with the increase of the frame task running time (i.e., Time in the aforementioned formula (2)), which is consistent with the trend that the task load of the frame task decreases with the increase of the frame task running time. The frequency modulation curve corresponding to the optimal frequency modulation function can be called the optimal frequency modulation curve.

[0473] Figure 14A An example diagram of an optimal frequency modulation curve is shown.

[0474] like Figure 14A As shown, the optimal frequency modulation curve is a convex curve. The coordinate axis containing the optimal frequency modulation curve can be referenced from the previous section. Figure 10 The diagram illustrates the coordinate axes of the frequency modulation curve. It can be seen that during the initial period of the frame task's execution (i.e., when time t is relatively small), the increase in computing power u(t) is significant. As time t (i.e., Time in the frequency modulation function) increases, the rate of increase in computing power u(t) gradually decreases.

[0475] The slope and curvature parameters of the optimal frequency tuning curve are related to the CPU energy efficiency curve. Different CPU energy efficiency curves may correspond to different optimal frequency tuning curves. In some embodiments, the server 200 can be based on... Figure 11A The frequency modulation simulator shown simulates and obtains the optimal frequency modulation function for any CPU model. Specifically, the frequency modulation simulator can determine the optimal frequency modulation function for a CPU model based on historical CPU load data from a certain period of time and the CPU energy efficiency curve of that model. The method for determining the optimal frequency modulation function can be found above. Figure 12A and Figure 12C The method shown.

[0476] Figure 14B An exemplary diagram comparing an optimal frequency modulation curve and a non-optimal frequency modulation curve is shown.

[0477] like Figure 14B As shown, the black line represents the optimal frequency modulation curve, and the gray line represents the non-optimal frequency modulation curve. The non-optimal frequency modulation curve can be referred to the aforementioned... Figure 10 The frequency modulation curves shown are examples of non-optimal frequency modulation curves. It is understandable that all frequency modulation curves other than the optimal one are considered non-optimal. Figure 14B The non-optimal frequency modulation curve shown is only one example of a non-optimal frequency modulation curve.

[0478] Comparing the optimal and non-optimal frequency modulation (FM) curves reveals that they intersect at time t3. Before time t3, the optimal FM curve has higher computing power at the same time. After time t3, the optimal FM curve has lower computing power at the same time.

[0479] A shorter time interval t represents the period at which a task frame has just begun running; at this point, the task frame definitely has tasks yet to be completed. A longer time interval t represents the period after a task frame has been running for some time; at this point, the task frame may have already completed its tasks.

[0480] Compared to suboptimal frequency scaling curves, optimal frequency scaling curves can more quickly increase CPU computing power when time t is relatively short (i.e., at the beginning of a task frame). This not only improves the running speed of the task frame, allowing it to complete its workload more quickly, but also reduces the likelihood of abruptly increasing the frequency at the end of a task frame. Conversely, optimal frequency scaling curves can slow down the rate of CPU computing power growth when time t is relatively long (i.e., at the end of a task frame). This reduces the likelihood of rapidly increasing CPU computing power after a task frame has been completed, thus minimizing wasted CPU resources.

[0481] From the above Figure 11B As shown in the energy efficiency curve, when the computing power is between u1 and u2, the CPU has the best energy efficiency (that is, the CPU can execute the most tasks under the same power consumption).

[0482] like Figure 14B As shown, the optimal frequency modulation curve corresponds to a computing power of u1 at time t1 and u2 at time t5. The non-optimal frequency modulation curve corresponds to a computing power of u1 at time t2 and u2 at time t4. Time t1 is earlier than time t2, and time t5 is later than time t4. Compared to the non-optimal frequency modulation curve, when frequency modulation is based on the optimal curve, the CPU can maintain its optimal energy efficiency for a longer period. This is beneficial for efficiently utilizing CPU resources, enabling the CPU to complete more tasks with less power consumption.

[0483] As can be seen, the optimal frequency modulation curve described above can improve the running speed of frame tasks, enabling them to complete within the corresponding frame period. This reduces performance issues such as stuttering caused by dropped frames. Furthermore, the optimal frequency modulation curve can reduce the power consumption of electronic devices during frame task execution, thereby increasing battery life and reducing the risk of excessively rapid temperature rise.

[0484] In some embodiments, the foregoing Figure 11A The task generation module and frequency modulation simulator shown can be used by developers as tools to determine the optimal frequency modulation function. This tool can help developers determine the optimal frequency modulation function for any CPU model. Specifically, it provides an input interface for developers to input historical CPU load data, CPU energy efficiency curves, the value ranges of slope and curvature parameters, and simulation granularity. Based on the parameters input by the developer, the tool can generate and output the optimal frequency modulation function.

[0485] In some embodiments, in addition to using the optimal frequency modulation function, the electronic device can also combine one or more other frequency modulation strategies for frequency modulation. For example, the electronic device can also detect the start and end times of each frame of critical threads and critical dependent threads. Besides using the optimal frequency modulation function according to a preset CPU frequency modulation cycle, the electronic device can also increase the frequency at the start of a frame of task execution and decrease the frequency at the end of a frame of task execution. This can better conserve the power of the electronic device.

[0486] Figure 15 An exemplary diagram of a frequency modulation provided in this application is shown.

[0487] Here, we will still take a CPU frequency adjustment period of 4ms and a frame drawing period of 8.3ms as an example to illustrate the schematic diagram of CPU frequency adjustment during the operation of the frame drawing thread.

[0488] like Figure 15 As shown, the electronic device can start running the first frame task of the frame drawing thread at 0ms. When it detects that 0ms is the start time of the first frame task, the electronic device can increase the CPU computing power to u22. Specifically, according to the frequency computing power table, the electronic device can adjust the CPU frequency to the CPU frequency corresponding to u22. This adjustment of the CPU frequency may include adjusting the frequency of the CPU core of the first frame task of the frame drawing thread. This embodiment does not limit the amount of CPU computing power (i.e., u22) increased by the electronic device at the start time of the frame task.

[0489] During the first 4ms, the CPU used to run the first frame task of the rendering thread can maintain the CPU frequency corresponding to u22. Within this first 4ms, if a critical thread within the rendering thread (e.g., the UI thread or the RS thread) pauses execution and waits for a critical dependent thread within the rendering thread (e.g., a critical dependent thread of the UI thread or a critical dependent thread of the RS thread) to run, the critical dependent thread will receive more processor resources and run faster, thus reducing the waiting time of the critical thread.

[0490] The 4ms interval can be the CPU frequency adjustment time determined based on the CPU frequency adjustment cycle. At the 4ms interval, the electronic device can determine whether the first frame's task has been completed. If not, the electronic device can increase the CPU computing power to u24 according to the optimal frequency adjustment function. The method for determining u24 can be found in the previous section. Figure 12D The method for determining u14 is shown. Specifically, based on the frequency calculation table, the electronic device can adjust the CPU frequency to the CPU frequency corresponding to u24.

[0491] like Figure 15 As shown, the completion time of the first frame task is 6.2ms. When the end time of the first frame task is detected at 6.2ms, the electronic device can reduce the CPU computing power to u21. Specifically, according to the frequency point computing power table, the electronic device can adjust the CPU frequency to the CPU frequency corresponding to u21. This embodiment does not limit the amount of CPU computing power (i.e., u21) reduced by the electronic device at the end time of the frame task.

[0492] The 8ms mark can be considered the CPU frequency adjustment time determined based on the CPU frequency adjustment cycle. Since the 8ms mark is still within the first frame's rendering cycle, the electronic device can determine whether the first frame's task is complete. It can be seen that the first frame's task was completed before the 8ms mark. Because the electronic device has already downclocked the CPU when the first frame's task was completed, it does not need to adjust the CPU frequency according to the optimal frequency adjustment function at the 8ms mark.

[0493] The electronic device can start running the second frame task of the drawing thread at 8.3ms. When it detects that 8.3ms is the start time of the second frame task, the electronic device can increase the CPU computing power to u22.

[0494] The 12ms interval can be the CPU frequency adjustment time determined based on the CPU frequency adjustment cycle. Since the 12ms interval falls within the second frame rendering cycle, the electronic device can determine whether the second frame task is completed. If not, the electronic device can increase the CPU computing power to u23 according to the optimal frequency adjustment function. The method for determining u23 can be referred to the aforementioned methods. Figure 12DThe method for determining u13 is shown. Specifically, based on the frequency calculation table, the electronic device can adjust the CPU frequency to the CPU frequency corresponding to u23.

[0495] like Figure 15 As shown, the completion time of the second frame task is 7.5ms. When the end time of the second frame task is detected at 15.8ms (i.e., 8.3ms + 7.5ms), the electronic device can reduce the CPU computing power to u21.

[0496] The 16ms mark can be considered the CPU frequency adjustment time determined based on the CPU frequency adjustment cycle. Since the 16ms mark falls within the second frame rendering cycle, the electronic device can determine whether the second frame task is complete. It can be seen that the second frame task was completed before the 16ms mark. Because the electronic device has already downclocked the CPU when the second frame task is completed, the electronic device does not need to adjust the CPU frequency according to the optimal frequency adjustment function at the 16ms mark.

[0497] Depend on Figure 15 It is known that electronic devices can increase the CPU frequency in real time at the start of frame tasks for critical threads and critical dependent threads, and decrease the CPU frequency in real time at the end of frame tasks for critical threads and critical dependent threads. During the execution of frame tasks for critical threads and critical dependent threads, electronic devices can adjust the CPU frequency according to the optimal frequency adjustment function. This can improve the accuracy of allocating processor resources to critical threads and critical dependent threads, thereby improving the utilization efficiency of processor resources and achieving a balance between smooth device performance and the needs for long battery life and rapid cooling.

[0498] The structure of the electronic device involved in this application is described below.

[0499] Figure 16A An exemplary schematic diagram of the hardware structure of an electronic device 100 is shown.

[0500] like Figure 16A As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0501] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0502] Processor 110 may include one or more processing units, such as: application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU), etc. Different processing units may be independent devices or integrated into one or more processors.

[0503] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0504] The processor 110 may also include a memory for storing instructions and data. In some examples, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or is recurring. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0505] In this application, a computer program may be stored in the memory to enable a controller or processor to implement the audio transmission method of this application through an interface or protocol. Exemplarily, the computer program stored in the memory may be used to: identify critical threads, critical dependent threads, and non-critical threads; increase the priority of critical threads and critical dependent threads; manage CPU time slices allocated to threads in groups; allocate CPU bandwidth quotas to threads in a target group; perform one or more of the following operations on threads temporarily dependent on by threads in the foreground group: increase priority, increase CPU time slice length, remove bandwidth quota suppression; suppress CPU frequency for threads in the target group; and dynamically adjust the CPU frequency according to an optimal frequency adjustment function during the operation of critical threads and critical dependent threads.

[0506] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback.

[0507] The charging management module 140 receives charging input from a charger, which can be a wireless charger or a wired charger. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0508] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, internal memory 121, external memory, display 194, camera 193, and wireless communication module 160, etc.

[0509] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

[0510] Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover one or more communication frequency bands. Different antennas can also be multiplexed to improve antenna utilization. For example, antenna 1 can be multiplexed as a diversity antenna for a wireless local area network. In some other embodiments, the antennas can be used in conjunction with tuning switches.

[0511] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1.

[0512] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

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

[0514] The display screen 194 is used to display images, videos, etc. In some embodiments, the electronic device 100 may include one or N display screens 194, where N is a positive integer greater than 1.

[0515] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0516] The ISP is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, converting it into an image visible to the naked eye.

[0517] Camera 193 is used to capture still images or videos. In some embodiments, electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0518] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP can perform Fourier transforms on the frequency energy.

[0519] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

[0520] The external storage interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 through the external storage interface 120 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0521] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

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

[0523] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0524] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or make hands-free calls through the speaker 170A.

[0525] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When the electronic device 100 receives a telephone call or voice message, the receiver 170B can be brought close to the ear to hear the voice.

[0526] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 170C, inputting the sound signal into microphone 170C.

[0527] The 170D headphone jack is used to connect wired headphones.

[0528] In this application, the speaker 170A, receiver 170B, and microphone 170C are all optional.

[0529] The sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, gravity sensors, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, angle sensors, etc.

[0530] Buttons 190 include a power button, volume buttons, etc. Motor 191 can generate vibration feedback. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, and also to indicate messages, missed calls, notifications, etc.

[0531] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and detach from the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The electronic device 100 interacts with the network through the SIM card to achieve functions such as calls and data communication. In some examples, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be removed from it.

[0532] Electronic device 100 can be a mobile phone, tablet computer, smartwatch, smart bracelet, speaker, television, etc. This application embodiment does not limit the type of electronic device 100.

[0533] Figure 16B An exemplary schematic diagram of the software structure of an electronic device 100 is shown.

[0534] The electronic device 100 may run an operating system. This operating system can be any operating system currently used in the industry, including but not limited to: operating systems based on OpenHarmony, such as HarmonyOS; or other operating systems, such as… A mobile operating system can also refer to various open-source operating systems or their derivatives, such as Linux OS and other embedded operating systems; it can also be a future-oriented operating system, such as an AI operating system based on artificial intelligence. An operating system is a set of interconnected system software programs that manage and control the operation of electronic devices, utilize and run hardware and software resources, and provide public services to organize user interaction. In electronic devices, the operating system occupies a crucial position, connecting to the physical hardware layer below and providing a runtime environment for application software above.

[0535] The software structure of the electronic device 100 is illustrated below using HarmonyOS as an example. Those skilled in the art can deduce the implementations of the embodiments of this application under other specific operating systems based on this.

[0536] like Figure 16B As shown, the software structure of electronic device 100 can be divided into several layers. In some embodiments, from bottom to top, these layers are: kernel layer, system service layer, framework layer, and application layer. Layers communicate with each other through software interfaces. System functions can be tailored, added, or combined at the subsystem granularity in different device deployment scenarios. Each subsystem can also be tailored, added, or combined at the functional granularity. Electronic device 100 may also include a hardware layer. The hardware layer may include hardware devices such as CPU, GPU, flash memory, liquid crystal display (LCD), Bluetooth, camera, battery, and heat dissipation module. Applications in the application layer of electronic device 100 can control the hardware devices in the hardware layer through the framework layer, system service layer, and kernel layer.

[0537] The kernel layer can include the Kernel Abstraction Layer (KAL), kernel subsystems, and driver subsystems. The KAL provides basic kernel capabilities to upper layers by shielding the differences between multiple kernels, including but not limited to process / thread management, memory management, file system, network management, and peripheral management. Kernel subsystems can support the selection of suitable OS kernels for different resource-constrained devices, and are not limited to Linux, HarmonyOS, LiteOS, etc. The driver subsystem can include driver frameworks. Driver frameworks are the foundation for an open system hardware ecosystem, providing unified peripheral access capabilities and a framework for driver development and management. Driver frameworks include: display drivers, camera drivers, audio drivers, Bluetooth drivers, sensor drivers, etc. The kernel layer may also include a scheduler. The scheduler can be used to schedule the execution order of threads and allocate resources such as CPU computing power to threads.

[0538] The system service layer comprises the core capabilities of the system, providing services to applications through the framework layer. This layer includes, but is not limited to, the following subsystems:

[0539] The system's basic capability subsystems provide the foundational capabilities for the operation, scheduling, and migration of distributed applications across multiple devices. For example, they may include a global resource scheduling subsystem, distributed data management, a distributed soft bus, and a compiler / runner; they may also include a multi-modal input subsystem, a graphics subsystem, and a security subsystem.

[0540] Basic software service subsystems: provide common and general software services; for example, event notification subsystem, telephone service subsystem, multimedia subsystem, etc.

[0541] Enhanced software service subsystem suite: Provides differentiated capability-enhancing software services for different devices; for example, it may include proprietary business subsystems for smart screens, wearable devices, and IoT devices.

[0542] Hardware service subsystem set: provides hardware services; for example, it may include location service subsystem, user IAM (Identity and Access Management) subsystem, wearable proprietary hardware service subsystem, biometric identification, IoT proprietary hardware service subsystem, etc.

[0543] The global resource scheduling subsystem can be used to manage and schedule the hardware and software resources, such as processor resources, in the electronic device 100.

[0544] In some embodiments, the global resource scheduling subsystem can set parameters related to thread execution priorities so that the scheduler in the kernel layer can adjust thread priorities.

[0545] In some embodiments, the global resource scheduling subsystem can also adjust the CPU weight ratio of thread groups based on the CPU load rate of threads in different thread groups, so that the scheduler in the kernel layer can adjust the CPU time slice length allocated to different thread groups.

[0546] In some embodiments, the global resource scheduling subsystem can also set parameters related to the CPU bandwidth quota of a thread so that the scheduler in the kernel layer can apply bandwidth quotas to the thread when scheduling the corresponding thread.

[0547] In some embodiments, the global resource scheduling subsystem may also label the threads that the threads in the foreground group temporarily depend on as critical sections, so that the scheduler in the kernel layer can prioritize scheduling threads with critical section labels, allocate longer CPU time slices to threads with critical section labels, and remove bandwidth quota suppression on threads with critical section labels.

[0548] In some embodiments, the global resource scheduling subsystem can also adjust the CPU frequency at the kernel layer. For example, when running non-critical threads, the CPU frequency can be controlled below a preset maximum frequency. This suppresses the CPU frequency of non-critical threads, saving power and reducing rapid overheating. As another example, when running critical threads and critical dependent threads, the CPU frequency can be dynamically adjusted based on an optimal frequency adjustment function. This allows for precise allocation of processor resources to critical and critical dependent threads, reducing oversupply or undersupply of processor resources. These CPU frequency adjustments can improve processor resource utilization efficiency while ensuring the smooth operation of critical and critical dependent threads, providing users with a smooth experience using electronic devices.

[0549] Distributed data management enables data synchronization, data storage, data sharing, and data access across all scenarios and devices.

[0550] The distributed soft bus provides communication-related capabilities, including: WLAN service capabilities, Bluetooth service capabilities, soft bus, inter-process communication RPC (Remote Procedure Call) and other communication capabilities.

[0551] A compiler / runner is a unified compilation and runtime platform designed to support the joint compilation and execution of multiple programming languages ​​and multiple chip platforms. For example, a compiler / runner could be the ArkCompiler.

[0552] The framework layer provides application programming interfaces (APIs) and programming frameworks for applications in the application layer. Examples include the UI framework module (which provides a complete infrastructure for UI development of system applications, including UI functionalities such as components, layouts, animations, and interactive events, as well as real-time interface preview tools), the user application framework, and the Ability framework (an Ability is a lightweight application; the Ability framework schedules and manages the operation and lifecycle of Abilities). Different devices may run different operating systems, and therefore support different APIs.

[0553] The HarmonyOS API is a series of open capabilities provided to support HarmonyOS application development. The HarmonyOS API can be set at the framework layer or independently of the framework layer. Examples include: Audio API (audio service), Push API (push service), and Account API (account service).

[0554] Applications can include system apps and extended / third-party apps. System apps can include the desktop, control bar, settings, contacts, phone, camera, etc., while extended / third-party apps can include social apps, travel apps, short video apps, shopping apps, etc.

[0555] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described method embodiments.

[0556] This application also provides a computer program product, including a computer program that, when run on a processor, can implement the steps in the various method embodiments described above.

[0557] This application also provides a chip system, which includes a processing circuit and an interface circuit. The interface circuit receives code instructions and transmits them to the processing circuit. The processing circuit executes the code instructions to enable the chip system to implement the steps of any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0558] It is understood that the user interfaces described in the embodiments of this application are merely example interfaces and do not constitute a limitation on the solution of this application. In other embodiments, the user interface may adopt different interface layouts, may include more or fewer controls, and may add or remove other functional options, as long as they are based on the same inventive concept provided in this application, they are all within the protection scope of this application.

[0559] It should be noted that, without causing contradictions or conflicts, any feature in any embodiment of this application, or any part of any feature, can be combined, and the combined technical solution is also within the scope of the embodiments of this application.

[0560] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A processor resource management method, characterized in that, The method is applied to an electronic device, and the method includes: The electronic device determines that it is in the first application scenario based on the first application running in the foreground. The electronic device runs a first key thread associated with the first application scenario. The first key thread is a thread that affects the user's perception of the smoothness of the electronic device's operation. The first key thread includes any one of the following: user interface thread, rendering service thread, audio playback thread, and the main thread of the foreground application. The electronic device identifies the critical dependent threads of the first critical thread. The critical dependent threads of the first critical thread include threads other than the first critical thread on the first critical path. The first critical path is constructed based on the history of wake-up relationships between threads. One node on the first critical path corresponds to one thread. The head node and the tail node on the first critical path both correspond to the first critical thread. There is a wake-up relationship between two adjacent nodes on the first critical path. The electronic device increases the priority of critical dependent threads of the first critical thread. The application running in the foreground of the electronic device is switched from the first application to the second application; The electronic device determines that it is in a second application scenario based on the second application running in the foreground; The electronic device identifies the key dependent threads of the second key thread. The second key thread is associated with the second application scenario. The key dependent threads of the second key thread include threads other than the second key thread on the second key path. The second key path is constructed based on the history of wake-up relationships between threads. One node on the second key path corresponds to one thread. The head node and tail node on the second key path both correspond to the second key thread. There is a wake-up relationship between two adjacent nodes on the second key path. The electronic device increases the priority of critical dependent threads of the second critical thread and decreases the priority of critical dependent threads of the first critical thread.

2. The method according to claim 1, characterized in that, The electronic device identifies the critical dependent threads of the first critical thread, including: The electronic device obtains the critical dependent threads of the first critical thread according to the first critical dependent thread list. The first critical dependent thread list includes the critical dependent threads of the first critical thread. The first critical dependent thread list is obtained by the electronic device from the server, or the first critical dependent thread list is generated or updated by the electronic device.

3. The method according to claim 1, characterized in that, The electronic device identifies the critical dependent threads of the first critical thread, including: The electronic device detects a first thread wake-up event, which is used to indicate a first wake-up relationship corresponding to the first thread waking up the second thread. The electronic device acquires a first historical number of times the first wake-up relationship occurs and a second historical number of times the first wake-up relationship occurs on the first critical path; In response to the first historical count being greater than the first count threshold, and the ratio of the second historical count to the first historical count being greater than the first probability threshold, the electronic device identifies the threads other than the first critical thread among the first thread and the second thread as critical dependent threads of the first critical thread.

4. The method according to claim 2, characterized in that, The first critical dependency thread list is generated or updated by the electronic device, and the method further includes: The electronic device detects a first thread wake-up event, which is used to indicate a first wake-up relationship corresponding to the first thread waking up the second thread. The electronic device acquires a first historical number of times the first wake-up relationship occurs and a second historical number of times the first wake-up relationship occurs on the first critical path; In response to the first historical count being greater than the first count threshold, and the ratio of the second historical count to the first historical count being greater than the first probability threshold, the electronic device adds the first thread and the threads in the second thread other than the first critical thread to the first critical dependent thread list.

5. The method according to claim 2 or 4, characterized in that, The first critical dependency thread list includes a third thread, and the method further includes: The electronic device detects a second thread wake-up event, which is used to instruct a third thread to wake up other threads or other threads to wake up the third thread in a second wake-up relationship. The electronic device acquires the third historical number of times the second wake-up relationship occurs and the fourth historical number of times the second wake-up relationship occurs on the first critical path; In response to the third historical count being less than or equal to the second count threshold, or the ratio of the fourth historical count to the third historical count being less than or equal to the second probability threshold, the electronic device removes the third thread from the first critical dependent thread list.

6. The method according to any one of claims 2-4, characterized in that, The first critical thread is any thread in the first critical thread list, and the first critical dependent thread list contains critical dependent threads of one or more critical threads in the first critical thread list.

7. The method according to claim 1, characterized in that, The method further includes: The electronic device divides the threads in the electronic device into foreground groups and non-foreground groups. The foreground groups include threads of foreground applications running in the foreground and threads of system services associated with the foreground applications. The non-foreground groups include threads of system services not associated with the foreground applications and threads of background applications running in the background. The electronic device detects the CPU load rate of the threads in the foreground group; When the CPU load rate of the threads in the foreground group increases, the electronic device determines a first increase in the CPU time slice length based on the increase in the CPU load rate of the threads in the foreground group. The electronic device increases the CPU time slice length of the threads in the foreground group according to the first increase amount, and decreases the CPU time slice length of the threads in the non-foreground group.

8. The method according to claim 7, characterized in that, Before the electronic device detects the CPU load rate of the threads in the foreground group, the method further includes: The electronic device detects a first foreground event, the first foreground event including a change in a foreground application running in the foreground.

9. The method according to claim 1, characterized in that, The method further includes: The electronic device divides the threads in the electronic device into foreground groups and non-foreground groups. The foreground groups include threads of foreground applications running in the foreground and threads of system services associated with the foreground applications. The non-foreground groups include threads of system services not associated with the foreground applications and threads of background applications running in the background. The electronic device detects the overall load of the electronic device and / or the device case temperature, wherein the overall load includes the CPU load of the threads in the foreground group and the non-foreground group; When the overall load is a first load and / or the device casing temperature is a first temperature, the electronic device determines a first bandwidth quota based on the first load and / or the first temperature, and applies CPU bandwidth quotas to the threads of the non-foreground group based on the first bandwidth quota.

10. The method according to claim 9, characterized in that, The method further includes: When the overall load changes to a second load and / or the device casing temperature changes to a second temperature, the electronic device determines a second bandwidth quota based on the second load and / or the second temperature, and applies CPU bandwidth quotas to the threads of the non-foreground group based on the second bandwidth quota. If the second load is higher than the first load and / or the second temperature is higher than the first temperature, then the second bandwidth quota is less than the first bandwidth quota.

11. The method according to claim 1, characterized in that, The method further includes: The electronic device divides the threads in the electronic device into a foreground group, a normal thread group, and a restricted thread group. The foreground group includes threads of foreground applications running in the foreground and threads of system services associated with the foreground applications. The restricted thread group includes threads of system services that are not associated with the foreground applications and can be delayed, and threads of background applications running in the background that can be delayed. The normal thread group includes threads of system services that are not associated with the foreground applications and are not in the restricted thread group, and threads of background applications that are not in the restricted thread group. The electronic device continuously allocates CPU bandwidth quotas to the threads of the restricted thread group based on the third bandwidth quota. The electronic device detects the overall load and / or the device case temperature, whereby the overall load includes the CPU load of the threads in the foreground group, the normal thread group, and the restricted thread group. When the overall load is a first load and / or the device casing temperature is a first temperature, the electronic device determines a first bandwidth quota based on the first load and / or the first temperature, and applies CPU bandwidth quotas to the threads of the ordinary thread group based on the first bandwidth quota.

12. The method according to claim 1, characterized in that, The method further includes: The electronic device divides the threads in the electronic device into foreground groups and non-foreground groups. The foreground groups include threads of foreground applications running in the foreground and threads of system services associated with the foreground applications. The non-foreground groups include threads of system services not associated with the foreground applications and threads of background applications running in the background. When it is detected that a third thread is waiting for a fourth thread to release a first shared resource or waiting to obtain a first running result from the fourth thread, the electronic device will tag the fourth thread with a first tag. The third thread is a thread in the foreground group, and the fourth thread is a thread in the non-foreground group. The electronic device performs one or more of the following operations on the thread with the first tag: increases the running priority, increases the CPU time slice length, and removes the CPU bandwidth quota. When the fourth thread releases the first shared resource or sends the first running result to the third thread, the electronic device removes the first tag of the fourth thread.

13. The method according to any one of claims 7-12, characterized in that, The foreground group includes key threads in the first key thread list, and key dependent threads of the key threads in the first key thread list.

14. The method according to claim 1, characterized in that, The electronic device detects the overall load of the electronic device and / or the device housing temperature, wherein the overall load includes the load of all threads in the electronic device; The electronic device determines a first CPU frequency based on the overall load and / or device case temperature, and controls the CPU frequency when running non-critical threads to be below the first CPU frequency. The non-critical threads include critical threads in the first critical thread list and threads other than critical dependent threads of the critical threads in the first critical thread list.

15. The method according to claim 1, characterized in that, The first critical thread is used to complete multi-frame tasks, and the method further includes: During the execution of the first critical thread and the critical dependent thread of the first critical thread, the electronic device determines the first frequency modulation moment based on the CPU frequency modulation cycle, which falls within the time period of the execution of the first frame task in the multi-frame task. At the first frequency modulation moment, the electronic device detects whether the first frame task has been completed; If the first frame task is not completed, the electronic device will increase the CPU frequency to the second CPU frequency according to the first frequency modulation function; The first frequency modulation function is a power function with CPU computing power as the dependent variable, the running time of one frame task in the multi-frame task as the independent variable, and the exponent being a positive number less than 1.

16. The method according to claim 15, characterized in that, The method further includes: If the first frame task is completed, the electronic device will reduce the CPU frequency to a third CPU frequency.

17. The method according to claim 15, characterized in that, The method further includes the following: The start time and completion time of the first frame task are not the frequency adjustment time determined according to the CPU frequency adjustment cycle. When the first frame task is detected to have started running, the electronic device increases the CPU frequency to the fourth CPU frequency; When the completion of the first frame task is detected, the electronic device reduces the CPU frequency to the fifth CPU frequency.

18. The method according to any one of claims 15-17, characterized in that, After the first frame task completes execution, the method further includes: The electronic device determines the time period during which the second frequency modulation moment falls within the second frame task in the multi-frame task based on the CPU frequency modulation cycle. At the second frequency modulation moment, the electronic device detects whether the second frame task has been completed; If the second frame task is not completed, the electronic device increases the CPU frequency to the sixth CPU frequency according to the first frequency modulation function.

19. The method according to any one of claims 15-17, characterized in that, The first key thread is a thread used to determine the content displayed in the user interface, and one frame task in the multi-frame task includes determining the content displayed in one frame of the user interface; or, the first key thread is a thread used to render the user interface, and one frame task in the multi-frame task includes rendering one frame of the user interface.

20. The method according to claim 19, characterized in that, The first frequency modulation function is: Where u(t) is the computing power provided by the CPU of the electronic device at a certain moment, maxUtil is the maximum computing power of the CPU of the electronic device, Time is the time from the current moment to the time when the synchronization signal of the current frame task is issued, the synchronization signal of the current frame task is used to instruct the electronic device to run the current frame task, deadline is the period for the electronic device to refresh the user interface, margin is determined according to the duration of the completion of one or more frames of tasks in the first key thread before the currently running frame task, kk and α are determined according to the historical running data of one or more threads and the CPU energy efficiency curve of the electronic device, the one or more threads include the first key thread and the key dependent threads of the first key thread.

21. The method according to any one of claims 2-4, characterized in that, The first critical dependency thread list is generated based on one or more of the following: the frequency of critical dependency threads appearing on the critical path, the number of times critical dependency threads appear in wake-up relationships, the priority of critical dependency threads on the critical path, the overall priority of critical dependency threads, or the runtime of critical dependency threads.

22. An electronic device, characterized in that, The electronic device includes a memory and a processor, wherein the memory is used to store a computer program; the processor executes the computer program to implement the method of any one of claims 1-21.

23. A computer-readable storage medium storing instructions, characterized in that, When the instructions are executed by the processor, they implement the method of any one of claims 1-21.

24. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the method of any one of claims 1-21.

Images