Thread scheduling method, electronic device, and computer-readable storage medium

Abstract

The application relates to the technical field of electronic equipment, and provides a thread scheduling method, an electronic equipment and a computer readable storage medium, which comprise that the electronic equipment creates a garbage collection (GC) thread. When the GC thread is running, the electronic equipment adjusts the thread priority of the GC thread according to the load state of a CPU; wherein the thread priority of the GC thread corresponds to the load state of the CPU, when the load state of the CPU is a first state, the thread priority of the GC thread is a first priority, when the load state of the CPU is a second state, the thread priority of the GC thread is a second priority, the load of the first state is heavier than that of the second state, and the first priority is higher than the second priority. Therefore, when the GC thread is long-time suspended or blocks other threads due to the CPU load, the probability of the GC thread being executable can be improved by improving the thread priority, so that the suspension or blocking time is reduced as much as possible, and the process is ensured to run normally.

Description

Technical Field

[0001] This application relates to the field of electronic device technology, and in particular to a thread scheduling method, an electronic device, and a computer-readable storage medium. Background Technology

[0002] To facilitate memory management and improve system efficiency and performance, garbage collection (GC) mechanisms have been introduced into electronic devices. Therefore, a GC thread typically exists within the processes running on these devices for memory management. However, existing GC threads sometimes pause or block other threads for extended periods, affecting the normal operation of other threads and causing process malfunctions. Summary of the Invention

[0003] This application provides a thread scheduling method, an electronic device, and a computer-readable storage medium. When the GC thread experiences prolonged pauses or blocks other threads due to increased CPU load, the method can minimize the duration of pauses or blocks, thereby avoiding prolonged impact on the normal operation of other threads and ensuring normal process operation.

[0004] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0005] Firstly, a thread scheduling method is provided for use in electronic devices, the method comprising:

[0006] A garbage collection (GC) thread is created, with a thread priority of third priority. During GC thread execution, its thread priority is adjusted based on the CPU load status of the electronic device. Specifically, the GC thread priority corresponds to the CPU load status: when the CPU load status is in the first state, the GC thread priority is first priority; when the CPU load status is in the second state, the GC thread priority is second priority. The load in the first state is heavier than the load in the second state, and the first priority is higher than the second priority.

[0007] In this way, when the GC thread pauses or blocks other threads during its operation, and encounters increased CPU load causing the GC thread to pause or block other threads for a long time, the CPU load status can be used to appropriately increase the GC thread's thread priority. This increases the likelihood that the GC thread will be allocated CPU time, which in turn increases the probability that the GC thread can run. This minimizes the duration of the GC thread pausing or blocking other threads, reducing the impact on other threads and ensuring that the process runs normally.

[0008] In one possible implementation of the first aspect, the GC thread could be the GC thread within a system service process in an electronic device. In this case, if the GC thread in the system service process pauses for an extended period or blocks other threads, the synchronization binder communication between the system service process and other processes (such as the desktop launcher process and application processes) will be blocked, leading to application stuttering or slow response.

[0009] Therefore, in this implementation, if the GC thread that adjusts the thread priority according to the CPU load during operation is the GC thread in the system service process, the possibility of the GC thread in the system service process blocking the synchronous binder can be reduced by increasing the thread priority of the GC thread in the system service process. This avoids application lag or slow response issues and ensures a good user experience.

[0010] In one possible implementation of the first aspect, the GC thread execution includes multiple execution phases, but not every phase will necessarily result in pauses or blocking of other threads. Therefore, the multiple execution phases may include one or more preset adjustment phases. Furthermore, adjusting the GC thread priority based on the CPU load state during GC thread execution can include: adjusting the GC thread priority based on the CPU load state during the GC thread execution adjustment phase. Thus, the GC thread priority can be adjusted only in execution phases where pauses or blocking of other threads may occur, thereby saving resources and avoiding waste of CPU resources.

[0011] In one possible implementation of the first aspect, during the GC thread's adjustment phase, the thread priority of the GC thread is adjusted according to the CPU load state, including: when the GC thread starts its adjustment phase, adjusting the GC thread priority according to the CPU load state, and determining a first constraint duration corresponding to the adjustment phase; the first constraint duration is determined based on the historical execution time of the GC thread's adjustment phase; when the adjusted duration of the GC thread's thread priority reaches the first constraint duration, the GC thread's thread priority is adjusted to a third priority; the second priority is higher than the third priority.

[0012] Therefore, if the GC thread remains at high priority for an extended period, it can easily preempt the time slices of other threads, impacting their operation. Thus, by limiting the duration of a thread's priority boost through a first constraint, we can prevent the GC thread from maintaining high priority for too long and preempting the time slices of other threads, thereby avoiding any impact on their operation.

[0013] In one possible implementation of the first aspect, the thread scheduling method may further include: creating a state-determining thread; wherein the state-determining thread periodically reads the CPU load information and converts the CPU load information into an enumeration value, the enumeration value corresponding to the CPU load state; obtaining the enumeration value and determining the CPU load state based on the enumeration value.

[0014] Therefore, since thread priority promotion depends on CPU load, and CPU load is typically changing in real time, a dedicated state-determining thread can be created to accurately obtain CPU load information and ensure the accuracy of thread priority promotion. This state-determining thread periodically retrieves CPU load information and converts it into an enumeration value. When the CPU load status is needed, it can then be quickly, accurately, and in real-time obtained by directly reading the enumeration value.

[0015] In one possible implementation of the first aspect, determining the first constraint duration includes: reading the historical runtime of the adjustment phase from the runtime queue corresponding to the adjustment phase; calculating the average of the historical runtimes to obtain the first constraint duration corresponding to the adjustment phase. Therefore, when determining the first constraint duration based on historical runtimes, the accuracy of the constraint duration can be ensured by taking the average of multiple historical runtimes.

[0016] In one possible implementation of the first aspect, to determine the constraint duration based on historical execution time, the execution time of each run can be recorded. Therefore, the thread scheduling method may further include: recording the start time when the GC thread begins its adjustment phase, and recording the end time when the GC thread ends its adjustment phase; calculating the difference between the end time and the start time to obtain the execution time of this run in the adjustment phase, and writing the execution time of this run in the adjustment phase into the execution time queue corresponding to the adjustment phase.

[0017] In another possible implementation of the first aspect, in order to prevent the GC thread from being in a high priority state for a long time and preempting the time slices of other threads, thus affecting the normal operation of other threads, in this implementation, the thread priority of the GC thread is adjusted according to the CPU load state during the GC thread's adjustment phase. This may further include: adjusting the thread priority of the GC thread according to the CPU load state when the GC thread starts its adjustment phase; and adjusting the thread priority of the GC thread to the third priority when the GC thread finishes its adjustment phase; the second priority is higher than the third priority.

[0018] In another possible implementation of the first aspect, during the GC thread's adjustment phase, the thread priority of the GC thread is adjusted according to the CPU load state. This adjustment may further include: adjusting the GC thread priority based on the CPU load state at the start of the GC thread's adjustment phase; if the CPU load state changes during the adjustment phase, the GC thread priority is readjusted according to the changed CPU load state; and at the end of the GC thread's adjustment phase, the GC thread priority is adjusted to the third priority, where the second priority is higher than the third priority. This ensures that the GC thread's load state remains consistent with the CPU load state at all times, thereby reducing the impact of the GC thread on other threads and ensuring normal process operation.

[0019] In one possible implementation of the first aspect, the adjustment phase includes a marking pause phase, a recycling phase, and a compression pause phase.

[0020] In one possible implementation of the first aspect, for the system server process, if the GC thread in the system server process causes synchronous binder blocking, it will usually cause the application to lag or slow response in scenarios such as application startup, exit, and application interface switching.

[0021] Therefore, when the GC thread is a thread within the system server process, to conserve CPU resources, it's possible to specifically address application stuttering or slow response issues. That is, while the GC thread is running, its thread priority can be adjusted based on the CPU load of the electronic device. This can include:

[0022] When the GC thread (GC thread in the system server process) is running, if it is determined that the current application scenario is a preset adjustment scenario, the thread priority of the GC thread is adjusted according to the CPU load. The adjustment scenarios include application startup scenarios, application exit scenarios, and application interface switching scenarios.

[0023] In one possible implementation of the first aspect, for the GC thread in the system server process, when the GC thread is running, the thread priority of the GC thread is adjusted according to the load state of the central processing unit (CPU) of the electronic device. This may include: when the GC thread (i.e., the GC thread in the system server process) is running in the adjustment phase, if it is determined that the current application scenario state is a preset adjustment scenario, then the thread priority of the GC thread is adjusted according to the CPU load state.

[0024] In one possible implementation of the first aspect, during the adjustment phase of the GC thread (i.e., the GC thread in the system server process), if it is determined that the current application scenario state is a preset adjustment scenario, the thread priority of the GC thread is adjusted according to the CPU load state, which may include:

[0025] When the GC thread (i.e., the GC thread in the system server process) starts running the adjustment phase, if it is determined that the current application scenario state is the preset adjustment scenario, the thread priority of the GC thread is adjusted according to the CPU load state, and the first constraint duration corresponding to the adjustment phase is determined. The first constraint duration is determined based on the historical running time of the GC thread (i.e., the GC thread in the system server process) during the adjustment phase. When the duration of the GC thread (i.e., the GC thread in the system server process) after the thread priority adjustment reaches the first constraint duration, the thread priority of the GC thread (i.e., the GC thread in the system server process) is adjusted to the third priority. The second priority is higher than the third priority.

[0026] In one possible implementation of the first aspect, the thread scheduling method may further include: reading the application scenario state value and determining the application scenario state based on the application scenario state value.

[0027] In one possible implementation of the first aspect, when the GC thread is running, the thread priority of the GC thread is adjusted according to the load state of the CPU of the electronic device, including: when the GC thread is running, determining a second constraint duration and adjusting the thread priority of the GC thread according to the CPU load state; wherein, the second constraint duration is determined based on the historical running time of the GC thread; when the adjusted duration of the GC thread reaches the second constraint duration, the thread priority of the GC thread is adjusted to a third priority; the second priority is higher than the third priority.

[0028] The difference between determining the duration of the second constraint and determining the duration of the first constraint is that the historical execution time required to determine the duration of the second constraint is the historical execution time of the GC thread (i.e., the sum of the execution times of all execution phases). The other implementation processes are the same in principle, and will not be elaborated further.

[0029] In one possible implementation of the first aspect, the third priority corresponds to the original priority of the GC thread.

[0030] Secondly, this application provides an electronic device, comprising: one or more processors and a memory, the memory being coupled to the processor; the memory storing one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the electronic device performs the following steps:

[0031] A garbage collection (GC) thread is created, with a thread priority of third priority. During GC thread execution, its thread priority is adjusted based on the CPU load status of the electronic device. Specifically, the GC thread priority corresponds to the CPU load status: when the CPU load status is in the first state, the GC thread priority is first priority; when the CPU load status is in the second state, the GC thread priority is second priority. The load in the first state is heavier than the load in the second state, and the first priority is higher than the second priority.

[0032] In one possible implementation of the second aspect, the GC thread execution includes multiple execution phases, among which one or more preset adjustment phases are included. When the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: during the GC thread execution adjustment phase, adjusting the thread priority of the GC thread according to the CPU load state.

[0033] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: when the GC thread begins its adjustment phase, the thread priority of the GC thread is adjusted according to the CPU load state, and a first constraint duration corresponding to the adjustment phase is determined; the first constraint duration is determined based on the historical execution time of the GC thread's adjustment phase; when the adjusted duration of the GC thread's thread priority reaches the first constraint duration, the thread priority of the GC thread is adjusted to a third priority; the second priority is higher than the third priority.

[0034] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: creating a state determination thread; wherein the state determination thread periodically reads the CPU load information and converts the CPU load information into an enumeration value, the enumeration value corresponding to the CPU load state; obtaining the enumeration value and determining the CPU load state based on the enumeration value.

[0035] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: reading the historical runtime of the adjustment phase from the runtime queue corresponding to the adjustment phase; calculating the average of the historical runtimes to obtain the first constraint duration corresponding to the adjustment phase. Thus, when determining the first constraint duration based on the historical runtimes, the accuracy of the constraint duration can be ensured by taking the average of multiple historical runtimes.

[0036] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: when the GC thread starts running the adjustment phase, the start time is recorded, and when the GC thread ends running the adjustment phase, the end time is recorded; the difference between the end time and the start time is calculated to obtain the running time of this adjustment phase, and the running time of this adjustment phase is written into the running time queue corresponding to the adjustment phase.

[0037] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: when the GC thread begins its adjustment phase, the thread priority of the GC thread is adjusted according to the CPU load state; when the GC thread ends its adjustment phase, the thread priority of the GC thread is adjusted to the third priority; the second priority is higher than the third priority.

[0038] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: when the GC thread begins its adjustment phase, the thread priority of the GC thread is adjusted according to the CPU load state; during the operation of the adjustment phase, if the CPU load state changes, the thread priority of the GC thread is readjusted according to the changed CPU load state; when the GC thread ends its adjustment phase, the thread priority of the GC thread is adjusted to the third priority; the second priority is higher than the third priority.

[0039] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: when the GC thread is running, if it is determined that the current application scenario state is a preset adjustment scenario, the thread priority of the GC thread is adjusted according to the CPU load state; wherein, the adjustment scenario includes the application startup scenario, the application exit scenario, and the application interface switching scenario.

[0040] In one possible implementation of the second aspect, when the aforementioned computer instructions are executed by the processor, the electronic device further performs the following steps: while the GC thread is running, a second constraint duration is determined, and the thread priority of the GC thread is adjusted according to the CPU load state; wherein the second constraint duration is determined based on the historical running time of the GC thread; when the adjusted duration of the GC thread reaches the second constraint duration, the thread priority of the GC thread is adjusted to a third priority; the second priority is higher than the third priority.

[0041] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor in an electronic device, causes the electronic device to perform a thread scheduling method as described in the first aspect and any possible implementation thereof.

[0042] Fourthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the method described in the first aspect and any possible implementation thereof. The computer may be the aforementioned electronic device.

[0043] Understandably, the beneficial effects that the electronic device of any possible implementation of the second aspect, the computer-readable storage medium of the third aspect, and the computer program product of the fourth aspect can achieve can be referred to the beneficial effects of the first aspect and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0044] Figure 1 A schematic diagram illustrating how a GC thread blocks other threads, provided as an embodiment of this application;

[0045] Figure 2 A schematic diagram illustrating a GC thread blocking binder communication provided in an embodiment of this application;

[0046] Figure 3 A schematic diagram of an application interface that is lagging or slow to respond, provided for an embodiment of this application;

[0047] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0048] Figure 5 A software structure block diagram of an electronic device provided in an embodiment of this application;

[0049] Figure 6 A flowchart illustrating a thread scheduling method provided in this application embodiment. Figure 1 ;

[0050] Figure 7A flowchart illustrating a thread scheduling method provided in this application embodiment. Figure 2 ;

[0051] Figure 8 A schematic diagram of a process for real-time acquisition of CPU load status provided in an embodiment of this application;

[0052] Figure 9 A schematic diagram illustrating another process for real-time acquisition of CPU load status provided in an embodiment of this application;

[0053] Figure 10 A flowchart illustrating a GC thread scheduling method in a system server process provided in this application embodiment;

[0054] Figure 11 This application provides a schematic flowchart for determining the constraint duration in an embodiment.

[0055] Figure 12 A flowchart illustrating a thread scheduling method provided in this application embodiment. Figure 3 ;

[0056] Figure 13 An interaction timing diagram of a thread scheduling method provided in an embodiment of this application;

[0057] Figure 14 A schematic diagram illustrating non-blocking binder communication of a GC thread provided in an embodiment of this application;

[0058] Figure 15 This is a structural block diagram of a chip system provided in an embodiment of this application. Detailed Implementation

[0059] The technical solutions of the embodiments of this application will be clearly and completely 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. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with substantially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., are not necessarily different. Also, in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0060] Garbage collection (GC) is an automatic memory management mechanism that can be triggered to reclaim memory space occupied by applications. For example, when a portion of memory space occupied by an application is no longer accessed or used by the application, the GC mechanism can be triggered to reclaim that portion of memory space. In other words, applications can use the GC mechanism to return that portion of memory space to the operating system.

[0061] Therefore, in general, a process (corresponding to a running application) will include a GC thread. Simply put, a process usually includes a GC thread, which can be considered the process's daemon thread, capable of triggering the GC thread to reclaim the memory space occupied by the process.

[0062] With the development of electronic device technology, electronic devices can now support opening (launching) multiple applications. However, most electronic devices currently only include a central processing unit (CPU), and the CPU's processing power is limited; for example, a CPU may only be able to process the requests of one application at a time. Therefore, in order to make multiple open applications appear to run simultaneously, the concept of a timeslice has been introduced.

[0063] A time slice can be understood as the runtime allocated by the CPU to each process (i.e., application). By allocating time slices, the CPU can control the execution of each application in turn. In other words, the time period allocated by the CPU to a thread within a process is called that thread's time slice, which is the time the CPU allows that process to run. Generally, if a process is still running when its time slice expires, the CPU will preemptively allocate the time slice to another process. However, if a process is blocked or terminated before its time slice expires, the CPU will immediately switch processes to avoid wasting CPU resources.

[0064] In summary, because of the introduction of time slices, users can see that each application is running simultaneously on a macroscopic level. However, on a microscopic level, each application actually runs in turn based on the time slices allocated to it by the CPU.

[0065] Meanwhile, within a process, multiple threads can run concurrently based on the needs of the task execution (i.e., actual business requirements). Each thread within a process can have its own independent stack space and execution context, meaning each thread can run independently. Therefore, in addition to the aforementioned GC thread, a process typically includes other threads. It should be noted that the roles and types of these threads, besides the GC thread, can be created based on actual needs, and this application's embodiments do not impose any limitations on this.

[0066] Depending on the importance of the tasks to be performed by different threads within a process, different thread priorities are typically assigned. Thread priorities specify the execution order of corresponding threads. In other words, the CPU can schedule threads within a process based on their priorities, allocating time slices to threads based on their execution time. Therefore, thread priority determines the likelihood of a thread obtaining a CPU time slice in a multitasking environment.

[0067] However, the default thread priority for GC threads is currently quite low. For example, the thread priority of a GC thread can be 124, which can be understood as the lowest thread priority. Furthermore, in practice, the higher the thread priority within a process, the earlier the thread will be executed, and correspondingly, the greater the probability that the thread will receive a CPU time slice.

[0068] Therefore, due to thread priority limitations, under heavy CPU load, the CPU will prioritize scheduling threads with higher thread priorities. For example, a process can also include real-time (RT) threads and vital (VIP) threads with higher priorities than GC threads. Consequently, under heavy CPU load, the CPU may prioritize calling these higher-priority RT and VIP threads.

[0069] Therefore, under heavy CPU load, lower-priority threads, such as the GC thread, may experience prolonged periods without CPU scheduling. Even if the GC thread obtains a CPU time slice under heavy load, it may quickly be preempted by other more important threads, resulting in only a brief period of execution. Thus, under heavy CPU load, the GC thread may remain in a runnable state for an extended period, meaning it may be waiting for CPU scheduling.

[0070] In addition, since the GC thread typically needs to access and process all other live objects within the process during its execution, it will pause other threads (stop-the-world, STW) at certain stages to ensure the correctness of object processing. For example, the GC thread can notify other threads to suspend (i.e., pause other threads), thereby ensuring that other threads do not access the objects they need to process, thus guaranteeing the correctness of object processing.

[0071] Alternatively, to ensure the correctness of object processing, the GC thread can also block other threads using condition variables, locks, or other methods. Taking locks as an example... Figure 1 This diagram illustrates a scenario where a GC thread blocks other threads.

[0072] like Figure 1 As shown, when the GC thread is running, if it reaches the appropriate stage, it can acquire a lock to operate on an object. At this time, the object is in a state where it is locked by the GC thread, which can be simply understood as the GC thread having gained full control of the object. In this situation, because the object is locked by the GC thread, any other thread attempting to operate on or access this object will be blocked by the GC thread. Figure 1 Other threads competing for the lock are blocked, as shown. Furthermore, as... Figure 1 As shown, if other threads want to operate on or access this object, they need to wait until the GC thread unlocks the object (i.e., releases the lock) before other threads can successfully acquire the lock.

[0073] Thus, because the GC thread may pause or block other threads (such as blocking other threads by holding a lock), if the GC thread starts running after acquiring a CPU time slice and pauses other threads or holds a lock on a certain object, and then encounters a situation with heavy CPU load, the GC thread may be unable to acquire a CPU time slice for a long time after pausing other threads or holding a lock on an object, thereby causing the GC thread to enter a long-running runnable state.

[0074] Correspondingly, because the GC thread is in a runnable state for a long time, the time that the GC thread pauses other threads or holds the lock on this object will be continuously extended. This means that the time that other threads are paused or blocked by the GC thread will be longer, which can easily affect the normal operation of other threads and may lead to abnormal process operation.

[0075] Furthermore, for some very important or critical processes, such as system server processes, if the GC thread is paused or other threads are blocked for a long time due to the long-running runnable, the impact will be particularly obvious and serious.

[0076] Specifically, the system server process is the operating system (such as Android). TM The system server process is the core service manager in the system. Scenarios such as application startup, exit, and application interface switching typically require communication with the system server process. In other words, the system server process is very busy with inter-process communication because it provides a large number of basic services to applications.

[0077] For example, when the launcher receives a user's command to launch an application, it typically needs to communicate with the system server process to perform a series of operations such as obtaining services, managing process lifecycles, and managing activities in response to this launch command.

[0078] Currently, inter-process communication in electronic devices is primarily implemented using binders. Binder communication methods mainly include asynchronous binders and synchronous binders. When processes communicate using asynchronous binders, after sending an asynchronous binder call signal, the process can continue execution to the next step without waiting for a response from the receiver. However, synchronous binders differ from asynchronous binders. When processes communicate using synchronous binders, after sending a synchronous binder call signal, the process needs to receive feedback from the receiver before continuing execution to the next step. In other words, the process sending the synchronous binder call signal needs to obtain feedback from the receiver before it can continue its subsequent process.

[0079] Therefore, if an application process sends a synchronous binder call signal to the system server process (i.e., sends a message via synchronous binder), the application process will remain in a waiting state until it receives a response from the system server process. This is equivalent to the application's execution being blocked by the synchronous binder. Only after the application process receives a response from the system server process will the application continue running.

[0080] Meanwhile, after receiving a synchronization binder call signal from the application process, the system server process will have a corresponding thread respond to this signal and process it accordingly to provide feedback to the application process. However, if this thread in the system server process handling the synchronization binder call signal is paused or blocked by the GC thread for an extended period, it will be unable to process the synchronization binder call signal in a timely manner, resulting in a prolonged period without feedback to the application process. Thus, because the sent synchronization binder has no feedback, the application is blocked for a longer period; that is, the waiting time after the application sends a synchronization binder is extended, causing the application to experience lag or slow response.

[0081] For example, let's take the scenario of launching an application using a launcher as an example. Figure 2 A schematic diagram of a GC thread blocking binder communication is shown.

[0082] like Figure 2 As shown, since launching an application is typically triggered by the user clicking the application icon on the desktop, the application launch process primarily involves binder communication between the desktop launcher process (i.e., the launcher process) and the system server process. Therefore, after the launcher process sends a synchronization binder call signal to the system server process, it enters a waiting state after sending the signal, as it needs to receive feedback from the system server process before proceeding to the next step. Simultaneously, upon receiving the synchronization binder call signal from the launcher process, threads other than the GC thread begin to respond to this synchronization binder call signal and perform corresponding processing.

[0083] However, if the GC thread in the system server process pauses or blocks other threads during its execution, these other threads will be in a state of being paused or blocked by the GC thread. Only when the GC thread in the system server process ends its pause or stops blocking other threads can the other threads in the system server process continue processing (i.e., continue to handle the synchronization binder call signals) and provide feedback to the launcher process. The launcher process can only continue to the next step after receiving feedback.

[0084] In other words, without blocking the synchronization binder, the processing time for other threads in the system server process to perform the synchronization binder might only be ①+③, and the corresponding waiting time for the launcher process to receive feedback would also be ①+③. However, if... Figure 2 As shown, because the GC thread in the system server process pauses or blocks other threads, causing the synchronization binder to be blocked, the processing time for other threads in the system server process to perform synchronization binder increases to ①+②+③. Correspondingly, the waiting time for feedback in the launcher process also increases to ①+②+③. Thus, the time required for the launcher process to start the application increases from ①+③ to ①+②+③. From the user's perspective, the application startup response time becomes longer, meaning the application experiences stuttering or slow response during startup.

[0085] For example, taking a mobile phone as an example, Figure 3 This provides a schematic diagram of an application interface that is lagging or slow to respond.

[0086] like Figure 3 As shown, the phone displays the main interface 300 after powering on. This main interface can include application icons for various applications, such as clock, calendar, gallery, memo, file manager, email, music, and settings. Understandably, the actual number of application icons included on the phone's main interface 300 can be more than... Figure 3 The number of applications shown may vary, such as the main interface 300 may include application images corresponding to social applications, shopping applications, video applications, etc. This application embodiment does not impose any limitations on this.

[0087] The phone can launch the application corresponding to the application icon by responding to the user's click on the application icon on the main screen 300. For example... Figure 3 As shown, the phone can launch the music application in response to a user's tap on the music application icon. That is, after receiving the user's tap, the launcher process in the background begins binder communication with the system server process to launch the music application and display its interface in the foreground. Normally, the background launch of the music application is very fast; the phone can display the music application's playback interface 301 immediately after responding to the user's tap.

[0088] However, if the launcher process and the system server process use synchronous binder communication, and if the GC thread pauses or blocks other threads during this synchronous binder communication, then the synchronous binder communication will be blocked, causing the music application to launch more slowly in the background. Correspondingly, after the phone responds to the user's click on the music application icon, the foreground may first display interface 302, which may show the message "Starting," to inform the user that the music application is currently launching. Only after the synchronous binder communication in the background finishes blocking can the launcher process complete the music application launch, thus displaying the music application's playback interface 301. Therefore, from the user's perspective, the music application launch appears to be laggy or slow.

[0089] Understandable. Figure 3 The application interface shown is only an example of the embodiments of this application. According to the actual application design of the application developer, the application interface can have more features when the application has problems such as lag or slow response. This embodiment of the application does not limit this in any way.

[0090] For example, after the phone receives the user's command to launch the application, if there is a problem of lag or slow response caused by the GC thread during the startup process, the phone's interface may not change for a long time (such as displaying the main interface 300 for a long time), and the phone may be in an unresponsive state (similar to the phone freezing, with no response to user clicks). After waiting for a period of time, the phone will then display the application's interface (such as the music application's playback interface 301).

[0091] For example, if an application has a splash screen, and a GC thread causes lag or slow response during startup, the application interface may display the splash screen for an extended period without showing the main interface (e.g., a music app's playback screen not displaying for a long time, resulting in error code 301). Alternatively, if the application has a startup animation, the animation may fail to play or play choppy.

[0092] In summary, if other threads within the system server process are paused or blocked by the GC thread for an extended period, applications that rely on the system server process for services may experience lag or slow response times, severely impacting the user experience.

[0093] Therefore, to avoid prolonged pauses or blocking of other threads by the GC thread in a process, thereby reducing the impact of the GC thread on other threads and preventing process malfunctions, this application provides a thread scheduling method. This thread scheduling method can be applied to electronic devices. Simply put, in this application embodiment, when the GC thread is running in an electronic device, the electronic device can increase the thread priority of the GC thread as needed based on the current CPU load state.

[0094] Thus, because the GC thread pauses or blocks other threads during its operation, if the CPU load increases, other threads may be paused or blocked for an extended period, affecting their normal operation and causing process abnormalities. Therefore, the thread scheduling method provided in this application prioritizes the GC thread based on the CPU load state. This increases the likelihood of the GC thread being allocated CPU time when the CPU load is high after pausing or blocking other threads, thus increasing its runnable probability and preventing it from entering a prolonged runnable state. This reduces the duration of GC thread pauses or blocks other threads, minimizing its impact and preventing further process abnormalities.

[0095] Furthermore, if the GC thread in the system server process has its priority increased, it can prevent the GC thread from blocking synchronous binder communication, thus avoiding application stuttering or slow response. In other words, it can prevent application stuttering or slow response during startup, exit, or switching application interfaces.

[0096] In some embodiments, the aforementioned electronic device may include at least one of the following: mobile phone, foldable electronic device, tablet computer, desktop computer, laptop computer, handheld computer, notebook computer, ultra-mobile personal computer (UMPC), netbook, cellular phone, personal digital assistant (PDA), augmented reality (AR) device, virtual reality (VR) device, artificial intelligence (AI) device, wearable device, in-vehicle device, smart home device, or smart city device. This application does not impose any special limitation on the specific type of the electronic device.

[0097] For example, Figure 4 A schematic diagram of the structure of an electronic device is shown.

[0098] like Figure 4 As shown, the electronic device 100 may include a processor 110 (such as the CPU described above), an external memory interface 120, an internal memory 121, a universal serial bus (USB) connector 130, a charging management module 140, a power management module 141, a battery 142, antenna 1, 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 module 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc. The sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, etc.

[0099] Processor 110 may include one or more processing units, such as application processors (APs), modem processors, graphics processing units (GPUs), image signal processors (ISPs), controllers, video codecs, digital signal processors (DSPs), baseband processors, and / or neural network processing units (NPUs). These different processing units may be independent devices or integrated into one or more processors.

[0100] Processor 110 can generate operation control signals based on instruction opcodes and timing signals to control instruction fetching and execution. Specifically, in this embodiment, processor 110 can increase the thread priority of the GC thread as needed based on its own load status. For example, after the GC thread in the system server process runs, processor 110 can increase the thread priority of the GC thread in the system server process based on its own load status.

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

[0102] In some embodiments, the processor 110 may include one or more interfaces. These interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc. The processor 110 can connect to modules such as touch sensors, audio modules, wireless communication modules, displays, and camera modules through at least one of these interfaces.

[0103] It is understood that the interface connection relationships between the modules illustrated in the embodiments of this application are merely illustrative and do not constitute a structural limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0104] 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, it can save music, video, and other files to the external memory card, or transfer music, video, and other files from the electronic device to the external memory card.

[0105] Internal memory 121 can be used to store computer executable program code, including instructions. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phone book, etc.). In addition, 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. Processor 110 executes various functional methods or data processing of electronic device 100 by running instructions stored in internal memory 121 and / or instructions stored in memory disposed in the processor.

[0106] USB connector 130 is a USB standard compliant interface used to connect electronic device 100 and peripheral devices, specifically a Mini USB connector, Micro USB connector, USB Type-C connector, etc. Charging management module 140 receives charging input from a charger. The charger can be a wireless charger or a wired charger. Power management module 141 connects to battery 142, and charging management module 140 connects to processor 110.

[0107] The wireless communication function of electronic device 100 can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor, and baseband processor. Antenna 1 and antenna 2 are used to transmit and receive electromagnetic wave signals. Mobile communication module 150 can provide wireless communication solutions including 2G / 3G / 4G / 5G for applications on electronic device 100. Modem processor can include modulator and demodulator. Wireless communication module 160 can provide wireless communication solutions for electronic device.

[0108] The electronic device 100 can implement display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or modify display information. The display screen 194 is used to display images, videos, etc. Specifically, in this embodiment, the display screen 194 can be used to display the application interface of an application. In some embodiments, the electronic device 100 may include one or more display screens 194.

[0109] Electronic device 100 can realize camera function through camera module 193, ISP, video codec, GPU, display screen 194, application processor AP, neural network processor NPU, etc.

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

[0111] Button 190 may include a power button, volume buttons, etc. Indicator 192 may be an indicator light, used to indicate charging status, battery level changes, and also to indicate messages, missed calls, notifications, etc. SIM card interface 195 is used to connect a SIM card.

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

[0113] In some embodiments, the software system of an electronic device may adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered architecture of Android... TM Taking the system as an example, the software structure of the electronic device is illustrated.

[0114] For example, Figure 5 A software architecture block diagram of an electronic device is shown.

[0115] like Figure 5 As shown, the layered architecture divides the software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, Android... TM The system is divided into four layers, from top to bottom: the application layer, the application framework layer, the Android runtime (ART), and the kernel layer.

[0116] The application layer can include a series of application packages. These application packages can include applications such as gallery, calendar, maps, WLAN, music, SMS, calling, navigation, Bluetooth, and video.

[0117] The application framework layer provides application programming interfaces (APIs) and a programming framework for applications in the application layer. The application framework layer includes some predefined functions.

[0118] In the embodiments of this application, such as Figure 5 As shown, the application framework layer includes at least an application scenario state recognition module. This module can be used to identify the application's scenario state. The application's scenario state can include scenarios such as application startup, exit, and interface transitions (i.e., switching application interfaces). For example, switching application interfaces could mean switching from the application's main interface to another application interface.

[0119] In other embodiments, such as Figure 5 As shown, the application framework layer may also include a window manager, input manager, resource manager, notification manager, view system, content provider, and activity manager. Figure 5 (not shown), etc.

[0120] The window manager provides Window Manager Service (WMS), which can be used for window management, window animation management, surface management, and as a relay station for the input system.

[0121] Content providers store and retrieve data, making that data accessible to applications. This data can include videos, images, audio, phone calls made and received, browsing history and bookmarks, phone books, etc.

[0122] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0123] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0124] The notification manager allows applications to display notifications in the status bar. These notifications can be used to deliver informational messages and can disappear automatically after a short pause, requiring no user interaction. For example, the notification manager can be used to notify users of completed downloads or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0125] The Activity Manager can provide an Activity Manager Service (AMS), which can be used for starting, switching, and scheduling system components (such as activities, services, content providers, and broadcast receivers), as well as managing and scheduling application processes. In a specific embodiment, an application scenario state recognition module can be set within the Activity Manager; that is, the Activity Manager Service can include an application scenario state recognition module.

[0126] The Input Manager Service (IMS) provides input management services, which can be used to manage system inputs such as touchscreen input, keypad input, and sensor input. IMS retrieves events from input device nodes and, through interaction with the WMS (Windows Management System), distributes these events to appropriate windows.

[0127] The Android runtime, also known as the virtual machine, is primarily responsible for converting source code into machine code. The Android runtime mainly employs ahead-of-time (AOT) compilation and just-in-time (JIT) compilation technologies. In this embodiment, the Android runtime (virtual machine) includes a GC adjustment phase identification module, a priority boosting time self-learning module, a CPU real-time load status acquisition module, and a GC thread priority boosting module.

[0128] The GC adjustment phase identification module determines whether the GC thread has entered the adjustment phase, including the marking pause phase, the garbage collection phase, or the compaction pause phase. The priority boosting time self-learning module predicts the constraint duration based on the historical execution time of each adjustment phase during the GC thread's operation. This constraint duration is used to constrain the duration for which the GC thread's priority is boosted. The CPU real-time load status acquisition module obtains the CPU load status in real time, determining whether the current CPU load is light, medium, or heavy. The GC thread priority boosting module determines the thread priority that the GC thread needs to boost based on the CPU load status.

[0129] The kernel layer is the layer between hardware and software. In this embodiment, the kernel layer includes at least a CPU load storage node and a thread priority adjustment module. The CPU load storage node stores CPU load information, which the upper-layer virtual machine (i.e., the Android runtime) can read to determine the CPU load state. The thread priority adjustment module is used to adjust thread priorities, such as increasing the priority of GC threads in response to instructions from the GC thread priority promotion module. In other embodiments, the kernel layer may also include display drivers, camera drivers, audio drivers, sensor drivers, etc. Figure 5(Not shown), the specific configuration can be made according to actual needs, and this application embodiment does not limit it in any way.

[0130] The thread scheduling method proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings. It should be noted that the thread scheduling methods in the following embodiments can all be implemented in the electronic device 100 having the above-described hardware structure.

[0131] In some embodiments, the CPU load state can be divided into different levels according to the actual situation. For example, the CPU load state can be divided into heavy load, medium load, and light load. Among these three load states, light load represents the lightest CPU load, heavy load represents the heaviest CPU load, and medium load represents a load higher than light load but lower than heavy load. It should be noted that the CPU load state can also be divided into more or fewer than the above three load states, depending on actual needs; this application embodiment does not impose any limitations on this.

[0132] For example, CPU load states can be divided into only two types. For instance, CPU load states include a first state and a second state, where the load in the first state is heavier than that in the second state. Specifically, the first state can correspond to the aforementioned medium or heavy load, and the second state can correspond to the aforementioned light load. Alternatively, the first state can also include two levels simultaneously, i.e., the first state includes a first level and a second level. Here, the first level and the second level correspond one-to-one with the aforementioned medium and heavy loads. Specifically, the first level is heavy load, and the second level is medium load. Or, the first level is medium load, and the second level is heavy load.

[0133] Alternatively, the CPU load state can be divided into three states: state 1, state 2, and state 3. State 1 corresponds to heavy load, state 2 to medium load, and state 3 to light load.

[0134] Alternatively, the CPU load state can be divided into four types: the first state, the second state, the third state, and the fourth state. The severity of the load corresponding to these four load states is in the order of the first state > the second state > the third state > the fourth state.

[0135] To facilitate the description and understanding of the solution, the following embodiments of this application will mainly use three load states—heavy load (corresponding to the first state), medium load (corresponding to the second state), and light load (corresponding to the third state)—as examples to illustrate the thread scheduling method provided in the embodiments of this application.

[0136] Meanwhile, to enable on-demand thread priority increases based on CPU load, different CPU load levels can correspond to different thread priority increases. This allows electronic devices to appropriately and accurately increase the GC thread priority based on the actual CPU load, thus avoiding prolonged pauses or blocking of other threads by the GC thread, while also preventing the GC thread from preempting other threads' time slices due to excessively high priority.

[0137] In some embodiments, corresponding to the three load states mentioned above, thread priorities can be divided into three levels, namely, first priority, second priority, and third priority.

[0138] In this context, the first priority can correspond to heavy load, the second priority to medium load, and the third priority to light load. Furthermore, the first priority is higher than the second priority, and the second priority is higher than the third priority (i.e., first priority > second priority > third priority). In other embodiments, the priority corresponding to light load can be the original thread priority of the GC thread (i.e., the original priority). That is, in this case, the third priority corresponding to light load is the original priority of the GC thread; for example, the third priority can be 124 as described above.

[0139] Alternatively, in some other embodiments, the first priority may correspond to light load, the second priority to medium load, and the third priority to heavy load, with the first priority lower than the second priority, and the second priority lower than the third priority (i.e., first priority < second priority < third priority). In this case, the first priority corresponding to light load is the original thread priority of the GC thread, that is, the first priority can be 124 as described above.

[0140] It is understandable that the correspondence between load status and thread priority should be such that the higher the load, the higher the corresponding thread priority. Other specific settings can be made according to actual needs, and this application embodiment does not impose any limitations on this.

[0141] Additionally, it should be noted that the division of thread priorities into three levels in this application embodiment is based on the three load states described above. It is understood that if the CPU load state is actually divided into more or fewer states, the thread priorities can also be adapted to be divided more or fewer according to the actual CPU load state; this application embodiment does not impose any limitations on this.

[0142] For ease of description and understanding, the following embodiments of this application will mainly use the first priority (corresponding to heavy load) > second priority (corresponding to medium load) > third priority (corresponding to light load, i.e., original priority) as an example.

[0143] Figure 6 A flowchart of a thread scheduling method is shown below. Figure 6 The flowchart shown explains the thread scheduling method provided in the embodiments of this application.

[0144] like Figure 6 As shown, after the GC thread runs, the electronic device first determines the current CPU load. If the current CPU load is light, meaning the CPU load is not heavy, the GC thread can maintain its original thread priority (e.g., third priority) and obtain CPU time slices to run. Therefore, it is unlikely that the GC thread will pause for a long time or block other threads. Thus, when the CPU load is light, the electronic device does not need to promote the GC thread's thread priority; the GC thread can continue running according to its original logic.

[0145] If the electronic device determines that the CPU load is medium, indicating an increased CPU workload, then if the GC thread continues to maintain its original thread priority (e.g., third priority), the probability of the GC thread acquiring a CPU time slice will decrease. This could potentially lead to process malfunctions due to prolonged pauses or blocking of other threads. Therefore, when the CPU load is medium, to appropriately increase the probability of the GC thread acquiring a CPU time slice, the electronic device can adjust the GC thread's thread priority accordingly. That is, since medium load corresponds to second priority, the electronic device can raise the GC thread's thread priority from third priority to the relatively high second priority.

[0146] If the CPU load is determined to be heavy, indicating that the CPU load has reached or is close to full capacity, the probability of the GC thread acquiring a CPU time slice is very low. Therefore, to prevent the GC thread from pausing or blocking other threads for an extended period, leading to process malfunctions, the electronic device can adjust the GC thread's priority accordingly. Specifically, the electronic device can raise the GC thread's priority to the highest level. In other words, heavy load corresponds to the highest priority level, first priority, and the electronic device raises the GC thread's priority from third to first priority.

[0147] It is understood that in this embodiment, the GC thread can be manually triggered by the user or automatically triggered based on time and conditions. However, it should be noted that the time and conditions for automatically triggering the GC thread can be set according to the actual business logic, and this embodiment does not impose any limitations on this. For example, an electronic device can trigger the GC thread to reclaim memory (i.e., perform a minor GC) when the remaining memory is insufficient to store new objects. Alternatively, it can trigger the GC thread to reclaim memory (i.e., perform a full GC) when the number of objects promoted to the old generation exceeds the remaining space in the old generation.

[0148] In some embodiments, the memory reclamation tasks performed by the GC thread are typically divided into multiple phases, such as the marking phase, marking pause phase, reclaim phase, and compaction pause phase. However, the GC thread does not pause or block other threads in every phase during its execution.

[0149] Therefore, to avoid wasting CPU resources by ineffectively increasing the priority of the GC thread, electronic devices can selectively increase the priority of the GC thread only when it reaches a preset adjustment phase. This adjustment phase refers to the stage during GC execution where other threads may be paused or blocked. The adjustment phase in this embodiment can be pre-configured according to the GC's execution logic. In a specific embodiment, the preset adjustment phase includes the aforementioned marking pause phase, garbage collection phase, and compaction pause phase.

[0150] In other words, after the GC thread starts running, the electronic device can, when the GC thread reaches the adjustment phases such as the marking pause phase, the garbage collection phase, or the compaction pause phase, increase the GC thread priority as needed based on the CPU load. In some embodiments, the timing of the GC thread's start can be monitored by pre-inserting program instruments into the code that the GC thread needs to execute, or by using program instruments to monitor when the GC thread starts its adjustment phase.

[0151] For example, program instrumentation can be performed in advance before the code corresponding to adjustment phases such as the marking pause phase, the garbage collection phase, and the compaction pause phase. This allows the GC thread to receive feedback from the GC thread when it executes the code corresponding to the adjustment phase, thus determining whether the GC thread has reached the adjustment phase.

[0152] Figure 7 This diagram illustrates another thread scheduling process.

[0153] like Figure 7 As shown, after the GC thread starts running, it can first be determined whether the GC thread has reached the preset adjustment phase (whether it has reached the marking pause phase, the garbage collection phase, or the compaction pause phase). If the GC thread has not yet reached the preset adjustment phase, then this current running phase of the GC thread will not pause or block other threads; that is, the current running phase of the GC thread will not cause pauses or block other threads. Therefore, in this case, even if the GC thread enters a long-running runnable due to CPU load, it will not affect other threads, and there is no need to increase the thread priority of the GC thread in this running phase. Therefore, if the GC thread has not yet reached the preset adjustment phase, the GC thread continues to run, and the electronic device will not adjust the thread priority of the GC thread. In this case, the GC thread maintains its original thread priority (e.g., maintaining the third priority).

[0154] If it is determined that the GC thread has entered a preset adjustment phase, this phase indicates that other threads may be paused or blocked during execution. In other words, the GC thread may pause or block other threads during this phase, potentially affecting their operation. Therefore, if the GC thread has entered the preset adjustment phase, the electronic device needs to increase the GC thread priority to avoid prolonged pauses or blocking of other threads.

[0155] Therefore, to determine the required priority for the GC thread, the electronic device obtains the current CPU load status and raises the GC thread priority as needed based on the CPU load. For example, under medium load, the GC thread priority is raised from third to second priority. Under heavy load, the GC thread priority is raised from third to first priority. For details on the specific implementation of raising the GC thread priority according to the CPU load status, please refer to the above-mentioned... Figure 6 The description of the embodiments in this application will not be repeated here.

[0156] In summary, in this embodiment, the electronic device only begins to determine whether the CPU load is light, medium, or heavy when the GC thread reaches a preset adjustment phase, i.e., when it begins running the marking pause phase, the garbage collection phase, or the compaction pause phase. If the CPU load is light, the GC thread's priority is not adjusted, and the GC thread continues to run. If the CPU load is medium or heavy, the GC thread's priority is adjusted, raising it to the second priority corresponding to medium load or the third priority corresponding to heavy load.

[0157] In this embodiment of the application, for stages other than the marking pause stage, the recycling stage, and the compaction pause stage, since the GC thread generally does not pause or block other threads, the electronic device can avoid increasing the thread priority of the GC thread when running in other stages, thereby avoiding ineffective promotion and waste of CPU resources.

[0158] In some embodiments, the CPU load status can be determined by reading the CPU load information in real time. That is, whether the CPU load status is light, medium, or heavy, the electronic device can determine this by reading the CPU load information.

[0159] CPU load information can include CPU utilization. Electronic devices can then determine the CPU's load status by reading the CPU utilization. For example, with an eight-core CPU, the CPU utilization is 800% under full load. Therefore, depending on actual needs, the electronic device can be configured to determine a heavy load when the eight-core CPU utilization reaches 700%. When the eight-core CPU utilization reaches 500%, that is, between 500% and 700%, the electronic device can determine a medium load. Conversely, if the eight-core CPU utilization is below 500%, the CPU load can be determined to be light.

[0160] It should be noted that the utilization rates of 700% and 500% mentioned above are merely examples used in the embodiments of this application and do not constitute any limitation on the range of load states. It is understood that the specific range of CPU load states, such as light load, medium load, and heavy load, can be set according to actual needs, and this application embodiment does not impose any limitations on this. For example, the CPU load state can be determined to be heavy load when the utilization of the eight-core CPU reaches 650%. Alternatively, the CPU load state can be determined to be light load when the utilization of the eight-core CPU is below 400%.

[0161] In one specific embodiment, to ensure the accuracy of thread priority promotion, the CPU load status determined during thread priority promotion needs to be obtained in real time. Therefore, to obtain the CPU load status in real time and accurately, the CPU load status can be obtained by creating a thread, which executes a timed task to periodically read the CPU load information. Figure 8 A flowchart illustrating a real-time acquisition of CPU load status is shown below. Figure 8 The process of obtaining CPU load status in real time is explained.

[0162] like Figure 8 As shown, an electronic device can create a status-determining thread within a process (such as a system server process) after its creation. This status-determining thread can be dedicated to reading CPU load information, thereby obtaining the CPU's load status (such as light load, medium load, or heavy load) in real time. For example, the type of status-determining thread created by the electronic device can be a native thread.

[0163] After the state determination thread is created, the electronic device can set up a task for this thread to periodically acquire the CPU load status. The state determination thread then executes this timed task to periodically acquire the CPU load status. Thus, the electronic device can use this state determination thread to achieve real-time acquisition of the CPU load status.

[0164] like Figure 8 As shown, an electronic device obtains the CPU load status in real time by creating a status determination thread. Specifically, this can include: creating a task queue for this status determination thread, setting tasks for obtaining the CPU load status, and adding them to the task queue. Then, the status determination thread can read and execute these tasks from the task queue. Thus, by polling the queue, the status determination thread can periodically execute tasks to obtain the CPU load status.

[0165] The process of a state-determining thread acquiring the CPU load state can include: reading the CPU load information and converting it into enumeration values ​​corresponding to the CPU load states. That is, after reading the CPU load information, the state-determining thread converts it into enumeration values, which represent different load states. Then, the electronic device can determine the current CPU load state by reading this enumeration value set by the state-determining thread. In other words, after creating the state-determining thread, the electronic device can directly determine the current CPU load state by reading the enumeration value representing the CPU load state.

[0166] For example, CPU load information can be converted into three enumerated values: 0, 1, and 2. These three enumerated values ​​correspond one-to-one with three load states: light load, medium load, and heavy load. For instance, 0 represents light load, 1 represents medium load, and 2 represents heavy load. Alternatively, 0 represents heavy load, 1 represents heavy load, and 2 represents light load. The specific correspondence can be set according to actual needs, and this embodiment does not impose any limitations on it. Similarly, the specific numerical values ​​corresponding to the enumerated values ​​can also be set according to actual needs, and this embodiment does not impose any limitations on them.

[0167] In other embodiments, if the electronic device is preset to only prioritize GC threads within one or more processes (i.e., preset processes), then after process creation, the electronic device can first determine whether the currently created process belongs to the preset processes. If the currently created process belongs to the preset processes, the electronic device then creates a status-determining thread to obtain the CPU load status in real time. If the currently created process does not belong to the preset processes, the electronic device will not create an additional status-determining thread for this process; that is, the electronic device will not prioritize the GC threads within this process. In a specific embodiment, the preset processes may include the system server process.

[0168] Taking the system server process as an example, Figure 9 This diagram illustrates another process for obtaining CPU load status in real time.

[0169] like Figure 9 As shown, Figure 9 The process shown is in Figure 8 The illustrated process includes an additional step to determine whether it is a system server process. Specifically, after process creation, the electronic device first determines whether the created process is a system server process (i.e., whether it's a default process). If the created process is a system server process (i.e., a default process), the electronic device further creates a status determination thread to obtain real-time CPU load status. However, if the created process is not a system server process (i.e., not a default process), there's no need to adjust the thread priority of the GC thread within this process. Consequently, the electronic device doesn't need to create a status determination thread for this process to obtain real-time CPU load status, and the process terminates directly.

[0170] In other words, since this created process is not a system server process (i.e., not a default process), the electronic device will not prioritize the GC thread within this process when it runs. Therefore, there is no need to create a state-determining thread to obtain real-time CPU load status. Conversely, because no state-determining thread has been created to obtain real-time CPU load status for the GC thread, the electronic device cannot obtain real-time CPU load status during its operation. Consequently, it cannot prioritize the GC thread based on the CPU load status as needed.

[0171] In some embodiments, for the system server process, the synchronous binder blocking caused by the GC thread in the system server process mainly results in application lag or slow response. This means it affects the normal operation of the application during startup, exit, and application interface switching. Therefore, for the GC thread in the system server process, its thread priority can be increased only during the aforementioned adjustment scenarios (including application startup, exit, and application interface switching).

[0172] Figure 10 A flowchart illustrating a GC thread scheduling method in a system server process is shown.

[0173] like Figure 10 As shown, compared to Figure 7 The process shown is as follows: Figure 10 It limits the running GC thread to the GC thread in the system server process, and adds an extra step to determine whether the current scenario is an adjustment scenario. That is, as... Figure 10 As shown, for the system server process, after the GC thread in the system server process runs, and before the thread priority of the GC thread is increased as needed based on the CPU load, in addition to determining whether the GC thread has reached the preset adjustment phase, it is also possible to determine whether the current scenario is an adjustment scenario. That is, to determine whether the current application scenario state is application startup, exit, or application interface switching.

[0174] If the electronic device determines that the current scenario is not application startup, exit, or application interface switching, then the current application scenario state is not an adjustment scenario. In this case, the electronic device will not increase the thread priority of the GC thread in the system server process; that is, the GC thread in the system server process will maintain its original thread priority and continue running. However, if the electronic device determines that the current application scenario state is application startup, exit, or application interface switching, then the current scenario state is an adjustment scenario. In this case, to avoid the GC thread pausing for a long time or blocking other threads, which could cause the application to lag or become unresponsive during startup, exit, and application interface switching scenarios, the electronic device further performs the necessary adjustments based on the CPU load. It is understood that the specific implementation of adjusting the GC thread priority based on the CPU load in this embodiment can be found in the above-mentioned... Figure 6 , Figure 7 and Figure 9 The relevant descriptions will not be repeated in the embodiments of this application.

[0175] In some embodiments, the determination of an adjustment scenario can be made through an application scenario state value. That is, when the scenario state of an application in the foreground changes, the application scenario state value can be set accordingly. Then, when it is necessary to determine whether the application's scenario state is an adjustment scenario, the electronic device can determine whether the current scenario is an adjustment scenario by directly reading this application scenario state value.

[0176] For example, 0, 1, 2, and 3 can be used to represent different scenario states. Setting the application scenario state value to 0 indicates that the current application scenario state is "application launched." Setting it to 1 indicates that the current application scenario state is "application exited." Setting it to 2 indicates that the current application scenario state is "application transition" (application interface switching). Setting it to 3 indicates that the current application scenario state is "other scenario," meaning the application scenario state is not "adjustment scenario."

[0177] It should be noted that the above 0, 1, 2, and 3 are merely examples of application scenario state values ​​in the embodiments of this application, and do not constitute a limitation on the application scenario state values. The specific settings can be determined according to the actual situation, and the embodiments of this application do not impose any limitations on them.

[0178] In some embodiments, after the thread priority of the GC thread in a process (such as the system server process) is increased, in order to prevent the GC thread from occupying the time slice of other threads due to its high priority for a long time, the thread priority of the GC thread can be decreased again after the thread priority of the GC thread is increased.

[0179] For example, after the GC thread finishes running, its priority can be reduced back to its original priority. Alternatively, after the GC thread finishes its adjustment phase, its priority can be reduced back to its original priority. For instance, if the CPU load determines that the GC thread's priority needs to be increased from third to second (or first) priority, then after the GC thread finishes running, its priority can be reduced back to third priority.

[0180] Alternatively, when increasing the priority of a GC thread, a certain constraint duration can be set (such as a first constraint duration and a second constraint duration). This constraint duration restricts the time during which the GC thread's priority is increased. That is, a timer can start when the GC thread's priority is increased. If the timer exceeds the set constraint duration, it means that the increased priority of the GC thread has reached the constraint duration, and the electronic device will then reduce the GC thread's priority back to its original priority.

[0181] For example, if the CPU load status determines that the GC thread's thread priority needs to be raised from the third priority to the second priority (or the first priority), and the set constraint duration (such as the first constraint duration and the second constraint duration) is 10 seconds, then at the same time as the GC thread's thread priority is raised from the third priority to the second priority (or the first priority), a timer starts. After the timer duration reaches 10 seconds, the GC thread's thread priority is lowered back from the second priority (or the first priority) to the third priority.

[0182] It should be noted that the constraint duration can be configured according to actual needs. The 10 seconds mentioned above is only an example used in this application embodiment. In addition to 10 seconds, it can also be 5 seconds, 20 seconds, 100 seconds, etc. This application embodiment does not constitute any limitation on the constraint duration that needs to be set.

[0183] In one specific embodiment, the electronic device can predict the current execution time of the GC thread based on the historical execution time of the GC thread. Then, the predicted execution time is used as the constraint duration after the GC thread's thread priority is increased, and this predicted constraint duration is used to constrain the duration for which the GC thread's thread priority is increased.

[0184] Taking the GC thread in the system server process as an example, Figure 11 A flowchart illustrating the process of determining the duration of constraints is shown.

[0185] like Figure 11 As shown, after the GC thread in the process runs (such as the GC running in the system server process), when it reaches the adjustment phase that requires raising the thread priority, it synchronously records the start time of this adjustment phase.

[0186] Then, at the end of this adjustment phase, the end time (cur_time) is recorded. The execution time of this adjustment phase can then be calculated using the recorded start time (start_time) and end time (cur_time): cur_time - start_time.

[0187] Finally, the calculated runtime is placed into a queue (running time queue). The length of the queue can be set according to actual needs, and this embodiment does not impose any limitation on it. For example, the queue length can be 5, 10, or 20. The queue length corresponds to the number of runtimes it can store. For example, if the queue length is 5, then the queue can store the runtimes corresponding to the last 5 runs in the adjustment phase. Simultaneously, the queue is updated with runtimes according to the first-in, first-out (FIFO) principle.

[0188] Furthermore, since this application's embodiments are illustrated using the GC thread within the system server process as an example, therefore... Figure 11 There's also a step to determine whether it's a system service process. Therefore, the execution time of this adjustment phase is only calculated if it's confirmed that the currently running GC thread is a GC thread within the system server process. However, it should be noted that if the actual application doesn't require prioritizing GC threads in specific processes (such as not targeting the system server process), but rather indiscriminately prioritizing GC threads across all processes, then this "whether it's a system service process" determination step can be omitted as needed.

[0189] Of course, it is understandable that the step of determining whether it is a system service process can also be executed directly after the GC thread runs. That is, if it is determined that the GC thread is not a system service process, the process can be terminated directly, so there is no need to start recording the start_time when the GC thread runs to the adjustment phase.

[0190] Therefore, when it is determined that the thread priority of the GC thread needs to be increased on demand based on the CPU load, the electronic device can read the recorded execution time (i.e., historical execution time) from the queue that records execution time. Then, it calculates the average of all execution times in the queue to obtain the constraint duration (this is the first constraint duration; the calculation principle for the second constraint duration is the same and will not be repeated here). The electronic device can then increase the thread priority of the GC thread within this constraint duration. In other words, if the execution time after the thread priority increase reaches this constraint duration, the thread priority of the GC thread will be reduced to its original thread priority.

[0191] Taking the GC thread of the system server process as an example, Figure 12 A flowchart illustrating another thread scheduling method is shown.

[0192] like Figure 12 As shown, after the GC thread in the system server process runs, and after judging the adjustment phase and adjustment scenario, if it is determined that the GC thread priority needs to be increased as needed based on the CPU load, then before increasing the thread priority, the average execution time in the queue (i.e., the average historical execution time in the execution time queue) can be calculated to obtain the constraint duration (here, the first constraint duration corresponding to the adjustment phase). Then, the GC thread priority is increased under the constraint of the constraint duration. That is, as... Figure 12 As shown, when the CPU load is medium, the GC thread's priority can be increased to the second priority (e.g., from the third priority to the second priority) under the constraint of the duration. When the CPU load is heavy, the GC thread's priority can be increased to the first priority (e.g., from the third priority to the first priority) under the constraint of the duration.

[0193] In some embodiments, to ensure the accuracy of constraint timing under different adjustment phases, each adjustment phase should have its own corresponding queue. Specifically, the marking-pause phase has a corresponding first queue for recording the historical execution time of the marking-pause phase. When the GC thread reaches the marking-pause phase, it retrieves the historical execution time from the corresponding first queue to calculate the constraint duration corresponding to the marking-pause phase. This constraint duration is then used to constrain the thread priority increase duration during the marking-pause phase. Similarly, the garbage collection phase has a corresponding second queue for recording the historical execution time of the garbage collection phase. When the GC thread reaches the garbage collection phase, it retrieves the historical execution time from the corresponding second queue to calculate the constraint duration of the garbage collection phase. Furthermore, the garbage collection pause phase has a corresponding third queue for recording the historical execution time of the garbage collection pause phase. When the GC thread reaches the garbage collection pause phase, it retrieves the historical execution time from the corresponding third queue to calculate the constraint duration corresponding to the garbage collection pause phase.

[0194] Taking the system server process as an example, Figure 13 An interaction sequence diagram of a thread scheduling method is shown. The following, combined with... Figure 13 The thread scheduling method provided in this application embodiment is described from the perspective of the interaction between various modules / services in an electronic device.

[0195] After an electronic device is powered on, it first starts the system server process. During the startup of the system server process, the thread scheduling service provided in this embodiment can be started through the function cleargrowthLimit(). The thread scheduling service can implement the thread scheduling method provided in this embodiment. The cleargrowthLimit() function is originally used to clear the memory usage limit. In this embodiment, program instrumentation can be performed in advance in the cleargrowthLimit() function so that the thread scheduling service is started after the cleargrowthLimit() function is executed.

[0196] like Figure 13 As shown, after the thread scheduling service starts, the following modules will also be started: CPU real-time load status acquisition module, priority boosting time self-learning module, application scenario status recognition module, GC thread priority boosting module, and GC adjustment phase recognition module.

[0197] like Figure 13As shown, after the CPU real-time load status acquisition module starts, it first calls the function issystemserver() to determine whether the currently started process is a system server process. Because thread scheduling is performed on the system server process, if it is determined that it is not a system server process, the execution of this process can be terminated directly, waiting for the next process to start. However, if the CPU real-time load status acquisition module determines that the currently started process is a system server process, it calls the function createthreadpool() to create a corresponding status determination thread for the system server process.

[0198] Then, the CPU real-time load status acquisition module sets up a timed task for the status determination thread, which calls the function getcpuload() to periodically read CPU load information (such as the CPU utilization mentioned above) from the CPU load storage node (i.e., the kernel node). After the CPU real-time load status acquisition module reads the CPU load information, it calls the function transformcpuload() to convert the read CPU load information into the corresponding enumeration value.

[0199] like Figure 13 As shown, after the GC adjustment phase identification module starts, it begins monitoring the execution of the GC thread. In some embodiments, the GC thread can be triggered manually or automatically. In some embodiments, whether to trigger the GC thread can be specifically determined by the GC entry function `garbagecollectorinternal()`, that is, the time and conditions for triggering the GC thread can be configured in the entry function `garbagecollectorinternal()`. The configured time and conditions for the GC thread to run can be set according to the actual business logic, and this application embodiment does not impose any limitations on this. When it is determined that GC needs to be performed, the GC thread can be further started by calling the function `runphase()`.

[0200] If the GC adjustment phase identification module detects that the GC thread has started running and entered the preset adjustment phase, it notifies the priority boosting time self-learning module and the GC thread priority boosting module. Similarly, if the GC adjustment phase identification module detects that the GC thread has ended its adjustment phase, it also needs to notify the priority boosting time self-learning module and the GC thread priority boosting module. In some embodiments, the identification of the start and end of the adjustment phase can be achieved through program instrumentation. That is, if the GC thread starts running, enters the adjustment phase, or ends its adjustment phase, because of program instrumentation, the GC thread can provide feedback to the GC adjustment phase identification module. Therefore, the GC adjustment phase identification module can monitor the operation of the GC thread through this feedback.

[0201] like Figure 13 As shown, after the priority boosting time self-learning module starts, if it receives a notification from the GC adjustment phase identification module that the GC thread has started running into the adjustment phase, the priority boosting time self-learning module records the start time `start_time`. Simultaneously, to implement thread priority boosting for the system server process, the priority boosting time self-learning module can call the function `issystemserver()` to determine if it is a system service process. In other words, it determines whether the GC thread currently running the adjustment phase is a GC thread within the system server process.

[0202] In some embodiments, whether a process is a system server process can be determined by assigning values ​​to corresponding variables. When a process is created, the type of process can be characterized by assigning values ​​to variables. Therefore, by assigning values ​​to the process's corresponding variables, it can be determined whether the process is a system server process.

[0203] If the priority boosting time self-learning module determines that the GC thread currently running in the adjustment phase is not a GC thread within the systemserver process (meaning the current process is not the system server), then the module does not need to record the end time `cur_time` and will not calculate the execution time. However, if the GC thread currently running in the adjustment phase is a GC thread within the systemserver process (meaning the current process is the system server), then the priority boosting time self-learning module records the end time `cur_time` upon receiving notification that the adjustment phase has ended. Then, the module calculates the execution time based on the recorded start time `start_time` and end time `cur_time`: execution time = `cur_time` - `start_time`. Finally, the module places the calculated execution time into a queue (execution time queue).

[0204] like Figure 13 As shown, once the application scenario state recognition mode is activated, it can begin to set the application scenario state value in real time based on changes in the application's scenario state. In a specific embodiment, when the application scenario state recognition mode detects that the function `startactivity()` is called to transition the application (switch the application interface), it can determine that the current application's scenario state has changed. Then, the application scenario state recognition mode can call the function `setcurrentstate()` to set an application scenario state value that matches the current application's scenario state; that is, the set application scenario state value corresponds to the application transition scenario.

[0205] Similarly, when the application scenario state recognition mode detects that the function applyoomadjlsp() is called to start or exit the application, it can also determine that the current application scenario state has changed. Then, the application scenario state recognition mode calls the function setcurrentstate() to set an application scenario state value that corresponds to the current application scenario state; that is, the set application scenario state value corresponds to the scenario in which the application was started or exited. It should be noted that the specific setting of the application scenario state value can be set according to actual needs, and this application embodiment does not impose any limitations on it.

[0206] like Figure 13 As shown, after the GC thread priority promotion module starts, and after the GC thread priority promotion module receives the notification from the GC adjustment phase identification module that the GC thread has started running the adjustment phase, the GC thread priority promotion module can start executing the relevant priority adjustment process.

[0207] Specifically, since this embodiment of the application focuses on adjusting the priority of GC threads within the system server process, the GC thread priority elevation module first needs to determine whether the GC thread in the adjustment phase is a GC thread within the system server process, i.e., whether it is the system server process. If the GC thread priority elevation module determines that it is not the system server process, it means that there is no need to adjust the priority of the GC thread, and the GC thread priority elevation module can refrain from adjusting the thread priority of the GC thread. However, if it is determined to be the system server process, then to ensure that the GC thread does not block the synchronous binder communication of the system server process for an extended period during this adjustment phase, the GC thread priority elevation module needs to execute the following process, i.e., the GC thread priority elevation module needs to adjust the thread priority of the GC thread. In some embodiments, the GC thread priority elevation module can also determine whether the process is the system server process by assigning values ​​to process-related variables.

[0208] Next, after determining that it is a system server process, the GC thread priority elevation module can obtain the application scenario status value from the application scenario status recognition module. The GC thread priority elevation module uses the obtained application scenario status value to determine whether the current scenario is an adjustment scenario. For example, when the application scenario status value is 0, the current application scenario status is determined to be "application startup". When the application scenario status value is 1 or 2, the current application scenario status is determined to be "application exit" or "application transition", respectively.

[0209] Furthermore, the GC thread priority boosting module reads the historical execution time corresponding to the adjustment phase from the queue (i.e., the execution time queue) maintained by the priority boosting self-learning module. Then, it calculates the average of the historical execution times to obtain the constraint time (i.e., the first constraint time) corresponding to this adjustment phase. In a specific embodiment, the GC thread priority boosting module can obtain the constraint time by calling the function getpredicttime().

[0210] Simultaneously, the GC thread priority advancement module obtains the enumeration value (such as 0, 1, 2 above) corresponding to the CPU load status from the CPU real-time load status acquisition module, and determines the CPU load status, including light load, medium load, and heavy load, through the enumeration value. In this way, the GC thread priority advancement module can determine the thread priority that needs to be advanced for the GC thread; for example, the thread priority to be advanced could be the first priority or the second priority. In a specific embodiment, the GC thread priority advancement module can obtain the enumeration value corresponding to the CPU load status from the CPU real-time load status acquisition module by calling the function getcpustatus().

[0211] If the GC thread priority boosting module determines that it is currently in an adjustment phase and that the adjustment scenario is appropriate, it notifies the thread priority adjustment module to adjust the thread priority of the GC thread in the system server process. Furthermore, the GC thread priority boosting module needs to send the constraint duration and the desired priority boost to the thread priority adjustment module along with this notification. In other words, the notification carries the constraint duration and the desired priority boost.

[0212] After receiving the adjustment notification from the GC thread priority boosting module, the thread priority adjustment module adjusts the thread priority of the GC thread in the system server process within a constrained duration. For example, the thread priority adjustment module might boost the GC thread's priority from third to second or first priority. However, due to the constraint duration, once the boosted GC thread priority has elapsed, the thread priority adjustment module will then reduce the GC thread's priority back to its original level, i.e., back to third priority.

[0213] For example, let's take the scenario of launching an application using a launcher as an example. Figure 14 A schematic diagram of non-blocking binder communication by a GC thread is shown.

[0214] contrast Figure 14 and Figure 2 It can be seen that after the GC thread in the system server process increased its priority based on the CPU load, there were no prolonged pauses or blocking of other threads during GC execution. Correspondingly, the waiting time for feedback in the desktop launcher process (i.e., the launcher process) reverted to the original non-blocking time of ①+③. From the user's perspective, there were no obvious lags or slow responses during application startup.

[0215] It needs to be explained that, Figure 2 and Figure 14The durations ①, ② and ③ shown are only examples used in the embodiments of this application and do not constitute any limitation on the duration of thread processing, waiting time, etc. The specific value of the duration depends on the actual running situation, and the embodiments of this application do not impose any limitations on it.

[0216] Another embodiment of this application provides an electronic device, including: one or more processors and a memory. The memory is coupled to the processor; the memory stores one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the electronic device implements the thread scheduling method described in any of the above embodiments.

[0217] Another embodiment of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor in an electronic device, causes the electronic device to implement the thread scheduling method described in any of the above embodiments.

[0218] This application also provides a computer program product that, when run on a computer, causes the computer to perform the various functions or steps described in the above method embodiments.

[0219] This application also provides a chip system, such as... Figure 15 As shown, the chip system 150 includes at least one processor 1501 and at least one interface circuit 1502. The processor 1501 and the interface circuit 1502 are interconnected via lines. For example, the interface circuit 1502 can be used to receive signals from other devices (e.g., a computer's memory). As another example, the interface circuit 1502 can be used to send signals to other devices (e.g., the processor 1501).

[0220] For example, interface circuit 1502 can read instructions stored in memory and send those instructions to processor 1501. When the instructions are executed by processor 1501, the computer can perform the steps in the above embodiments. Of course, the chip system may also include other discrete devices, and this application embodiment does not specifically limit this.

[0221] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0222] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another apparatus, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0223] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0224] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0225] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, in essence, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0226] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A thread scheduling method, characterized by, Applied to electronic devices, including: Create a garbage collection (GC) thread; the GC thread operation includes multiple running phases, including one or more preset adjustment phases; When the GC thread starts running the adjustment phase, the thread priority of the GC thread is adjusted according to the load state of the CPU of the electronic device; wherein, the thread priority of the GC thread corresponds to the load state of the CPU. When the CPU load state is a first state, the thread priority of the GC thread is the first priority, and when the CPU load state is a second state, the thread priority of the GC thread is the second priority. The load in the first state is heavier than the load in the second state, and the first priority is higher than the second priority. After the target conditions are met, the thread priority of the GC thread is adjusted to the third priority; the second priority is higher than the third priority.

2. The method of claim 1, wherein, The electronic device includes a system service process, and the GC thread is the GC thread within the system service process.

3. The method of claim 1, wherein, The third priority corresponds to the original priority of the GC thread.

4. The method according to any one of claims 1 to 3, characterized in that, When the GC thread starts running the adjustment phase, the thread priority of the GC thread is adjusted according to the CPU load status. After the target conditions are met, the thread priority of the GC thread is adjusted to the third priority, including: When the GC thread starts running the adjustment phase, the thread priority of the GC thread is adjusted according to the CPU load status, and a first constraint duration corresponding to the adjustment phase is determined; the first constraint duration is determined based on the historical running time of the GC thread running the adjustment phase. When the duration of the adjusted thread priority of the GC thread reaches the first constraint duration, the thread priority of the GC thread is adjusted to the third priority.

5. The method according to any one of claims 1-3, characterized in that, The method further includes: A state determination thread is created; wherein the state determination thread periodically reads the CPU load information and converts the CPU load information into an enumeration value, the enumeration value corresponding to the CPU load state; Obtain the enumeration value and determine the CPU load status based on the enumeration value.

6. The method of claim 4, wherein, Determining the duration of the first constraint includes: Read the historical runtime of the adjustment phase from the runtime queue corresponding to the adjustment phase; Calculate the average historical running time to obtain the first constraint duration corresponding to the adjustment phase.

7. The method according to any one of claims 1-3, characterized in that, The method further includes: When the GC thread starts running the adjustment phase, the start time is recorded, and when the GC thread finishes running the adjustment phase, the end time is recorded. Calculate the difference between the end time and the start time of the operation to obtain the running time of this operation in the adjustment phase, and write the running time of this operation in the adjustment phase into the running time queue corresponding to the adjustment phase.

8. The method according to any one of claims 1-3, characterized by, When the GC thread starts running the adjustment phase, the thread priority of the GC thread is adjusted according to the CPU load status. After the target conditions are met, the thread priority of the GC thread is adjusted to the third priority, including: When the GC thread starts running the adjustment phase, the thread priority of the GC thread is adjusted according to the CPU load status; When the GC thread finishes the adjustment phase, its thread priority is adjusted to the third priority.

9. The method of any one of claims 1-3, wherein, The method further includes: If the CPU load changes during the adjustment phase, the thread priority of the GC thread is readjusted according to the changed CPU load.

10. The method of any one of claims 1-3, wherein, The adjustment phase includes a marking pause phase, a recycling phase, and a compression pause phase.

11. The method of any one of claims 1-3, wherein, The step of adjusting the thread priority of the GC thread according to the CPU load state of the electronic device when the GC thread starts running the adjustment phase includes: When the GC thread starts running the adjustment phase, if it is determined that the current application scenario state is a preset adjustment scenario, the thread priority of the GC thread is adjusted according to the CPU load state; wherein, the adjustment scenario includes the application startup scenario, the application exit scenario, and the application interface switching scenario.

12. The method of claim 11, wherein, The method further includes: reading application scenario state values ​​and determining the scenario state of the application based on the application scenario state values.

13. A thread scheduling method, characterized by, Applied to electronic devices, including: Create a garbage collection (GC) thread; When the GC thread is running, a second constraint duration is determined, and the thread priority of the GC thread is adjusted according to the CPU load state. The second constraint duration is determined based on the historical execution time of the GC thread. The thread priority of the GC thread corresponds to the CPU load state. When the CPU load state is in a first state, the thread priority of the GC thread is the first priority. When the CPU load state is in a second state, the thread priority of the GC thread is the second priority. The load in the first state is heavier than the load in the second state, and the first priority is higher than the second priority. When the duration of the adjusted thread priority of the GC thread reaches the second constraint duration, the thread priority of the GC thread is adjusted to the third priority; the second priority is higher than the third priority.

14. The method of claim 13, wherein, The third priority corresponds to the original priority of the GC thread.

15. An electronic device, comprising: include: One or more processors and a memory, the memory being coupled to the processor; the memory storing one or more computer program codes, the computer program codes including computer instructions; when the processor executes the computer instructions, the electronic device causes the electronic device to perform the thread scheduling method as described in any one of claims 1-12 or 13-14.

16. A computer readable storage medium having stored thereon a computer program, characterized in that, When the computer program is executed by the processor of the electronic device, the electronic device performs the thread scheduling method as described in any one of claims 1-12 or 13-14.

17. A computer program product comprising a computer program, characterized in that, The computer program, when executed by a processor in an electronic device, causes the electronic device to perform the thread scheduling method as claimed in any one of claims 1-12 or 13-14.

Images