Thread scheduling method, electronic equipment and computer readable storage medium

Abstract

The invention relates to the technical field of electronic equipment, and provides a thread scheduling method, electronic equipment and a computer readable storage medium, and the method comprises the steps that the electronic equipment creates a garbage collection GC thread; when the GC thread runs, the electronic equipment adjusts the thread priority of the GC thread according to the load state of the 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 the first state, the thread priority of the GC thread is the first priority, when the load state of the CPU is the second state, the thread priority of the GC thread is the 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 pauses or blocks other threads for a long time due to CPU load increase, the running probability of the GC thread can be improved by improving the thread priority, so that the pause or blocking duration is reduced as far as possible, and normal running of the process is ensured.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of electronic devices, and in particular to a thread scheduling method, an electronic device, and a computer-readable storage medium. Background Art

[0002] To facilitate memory management and improve system efficiency and performance, garbage collection (GC) mechanisms have been introduced in existing electronic devices. Consequently, processes running on these devices typically include a GC thread for memory management. However, existing GC threads can pause or block other threads for extended periods of time, impacting their normal operation and causing process anomalies. Summary of the Invention

[0003] Embodiments of the present application provide a thread scheduling method, an electronic device, and a computer-readable storage medium. When a GC thread pauses for a long time or blocks other threads due to increased CPU load, the duration of the pause or blockage can be minimized as much as possible, thereby avoiding affecting the normal operation of other threads for a long time and ensuring normal process operation.

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

[0005] In a first aspect, a thread scheduling method is provided, which is applied to an electronic device, and the method includes:

[0006] A garbage collection GC thread is created, and the thread priority of the GC thread is the third priority; when the GC thread is running, the thread priority of the GC thread is adjusted according to the load status of the central processing unit CPU of the electronic device; wherein, the thread priority of the GC thread corresponds to the load status of the CPU, when the load status of the CPU is the first state, the thread priority of the GC thread is the first priority, and when the load status of the CPU is the second state, the thread priority of the GC thread is the second priority, the load of the first state is heavier than the load of 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 operation, and the CPU load increases, causing the GC thread to pause or block other threads for a long time, the thread priority of the GC thread can be appropriately increased according to the CPU load status, thereby increasing the possibility of the GC thread being allocated CPU time, that is, the probability of the GC thread being able to run can be increased, and the duration of the GC thread pausing or blocking other threads can be minimized to reduce the impact on other threads and ensure the normal operation of the process.

[0008] In one possible implementation of the first aspect, the GC thread may be a GC thread in a system service process in the electronic device. Thus, because the GC thread in the system service process pauses or blocks other threads for a long time, synchronous binder communication between the system service process and other processes (such as a desktop launcher process and an application process) may be blocked, thereby causing the application to freeze or respond slowly.

[0009] Therefore, in this implementation, if the GC thread that adjusts the thread priority according to the CPU load status during operation is the GC thread in the system service process, the possibility of the GC thread in the system service process blocking the synchronization binder can be reduced by improving the thread priority of the GC thread in the system service process, thereby avoiding the problem of application freeze or slow response, and ensuring that users have a good user experience.

[0010] In one possible implementation of the first aspect, the GC thread operation includes multiple operation phases, but not every operation phase will necessarily cause the problem of pausing or blocking other threads. Therefore, the multiple operation phases may include one or more preset adjustment phases. Furthermore, when the GC thread is running, adjusting the thread priority of the GC thread based on the load status of the central processing unit (CPU) of the electronic device may include: during the GC thread operation adjustment phase, adjusting the thread priority of the GC thread based on the CPU load status. In this way, the thread priority of the GC thread can be adjusted only in the operation phase where the problem of pausing or blocking other threads may occur, thereby saving resources and avoiding wasting CPU resources.

[0011] In a possible implementation of the first aspect, when the GC thread runs in the adjustment phase, the thread priority of the GC thread is adjusted according to the load status of the CPU, including: when the GC thread starts to run in the adjustment phase, the thread priority of the GC thread is adjusted according to the load status of the CPU, and a first constraint duration corresponding to the adjustment phase is determined; the first constraint duration is determined according to the historical running time of the GC thread running in the adjustment phase; when the duration after the thread priority of the GC thread is adjusted 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.

[0012] Therefore, if the GC thread maintains a high priority for a long time, it is likely to preempt the time slices of other threads and affect the operation of other threads. Therefore, by using the first constraint duration to constrain the duration of the thread priority after being raised, it can prevent the GC thread from maintaining a high priority for a long time and preempting the time slices of other threads, thereby avoiding affecting the operation of other threads.

[0013] In a possible implementation of the first aspect, the thread scheduling method may further include: 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, and the enumeration value corresponds to the CPU load state; obtaining the enumeration value, and determining the CPU load state according to the enumeration value.

[0014] Therefore, because thread priority increases depend on the CPU load status, which typically changes in real time, a state determination thread dedicated to obtaining the CPU load status can be created to accurately obtain the CPU load status in real time to ensure the accuracy of thread priority increases. The state determination thread periodically obtains CPU load information and converts it into an enumeration value. When the CPU load status is required, it can be directly read from the enumeration value to quickly, accurately, and in real time obtain the CPU load status.

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

[0016] In one possible implementation of the first aspect, to determine the constraint duration based on historical run times, the run time of each run can be recorded during each run. Therefore, the thread scheduling method may further include: recording the start time of the run when the GC thread begins the adjustment phase, and recording the end time of the run when the GC thread ends the adjustment phase; calculating the difference between the end time and the start time to obtain the run time of the current run during the adjustment phase, and writing the run time of the current run during the adjustment phase to the run 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 high priority for a long time and preempting time slices of other threads, thereby affecting the normal operation of other threads, in this implementation, during the GC thread operation adjustment phase, the thread priority of the GC thread is adjusted according to the CPU load status. The implementation may also include: when the GC thread starts to run in the adjustment phase, adjusting the thread priority of the GC thread according to the CPU load status; when the GC thread ends the operation in the adjustment phase, adjusting the thread priority of the GC thread to the third priority; the second priority is higher than the third priority.

[0018] In another possible implementation of the first aspect, during the GC thread's running adjustment phase, the thread priority of the GC thread is adjusted according to the CPU load state. Adjusting the thread priority of the GC thread according to the CPU load state during the GC thread's running adjustment phase may also include: adjusting the thread priority of the GC thread according to the CPU load state when the GC thread begins running the adjustment phase; if the CPU load state changes during the running of the adjustment phase, readjusting the thread priority of the GC thread according to the changed CPU load state; and adjusting the thread priority of the GC thread to a third priority when the GC thread ends running the adjustment phase; the second priority being higher than the third priority. This ensures that the GC thread and the CPU load state remain consistent at all times, thereby reducing the impact of the GC thread on other threads and ensuring normal operation of the process.

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

[0020] In a 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 become stuck or respond slowly in scenarios such as application startup, exit, and application interface switching.

[0021] Therefore, when the GC thread is a thread in the system server process, in order to save CPU resources, the problem of application lag or slow response can be specifically solved. That is, when the GC thread is running, the thread priority of the GC thread is adjusted according to the load status of the electronic device's central processing unit (CPU). This can include:

[0022] When the GC thread (the GC thread in the system server process) 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 status; among them, the adjustment scenarios include the application startup scenario, the application exit scenario, and the application interface switching scenario.

[0023] In a 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 status of the central processing unit CPU of the electronic device, which can include: when the GC thread (i.e., the GC thread in the system server process) runs in the adjustment phase, if it is determined that the scene state of the current application is a preset adjustment scene, the thread priority of the GC thread is adjusted according to the load status of the CPU.

[0024] In a possible implementation of the first aspect, when a GC thread (i.e., a GC thread in a system server process) runs an adjustment phase, if it is determined that the current application scenario state is a preset adjustment scenario, adjusting the thread priority of the GC thread based on the CPU load state may include:

[0025] When the GC thread (i.e., the GC thread in the system server process) starts to run the adjustment phase, if it is determined that the scenario state of the current application is a preset adjustment scenario, 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 according to the historical running time of the GC thread (i.e., the GC thread in the system server process) running the adjustment phase; when the duration after the thread priority of the GC thread (i.e., the GC thread in the system server process) is adjusted 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 a possible implementation manner of the first aspect, the thread scheduling method may further include: reading an application scenario state value, and determining a scenario state of the application program according to the application scenario state value.

[0027] In a 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 status of the central processing unit (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 load status of the CPU; wherein the second constraint duration is determined according to the running time of the historical running of the GC thread; when the duration after the thread priority of the GC thread is adjusted reaches the second constraint duration, adjusting the thread priority of the GC thread to a third priority; the second priority is higher than the third priority.

[0028] Among them, the difference between determining the second constraint duration and determining the first constraint duration mentioned above is that the historical running time required to determine the second constraint duration is the historical running time of the GC thread (that is, the sum of the running time of all running stages). The other implementation process principles are the same and will not be repeated here.

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

[0030] In a second aspect, the present application provides an electronic device comprising: one or more processors and a memory, the memory being coupled to the processor; one or more computer program codes stored in the memory, the computer program codes comprising computer instructions; when the processor executes the computer instructions, the electronic device performs the following steps:

[0031] A garbage collection GC thread is created, and the thread priority of the GC thread is the third priority; when the GC thread is running, the thread priority of the GC thread is adjusted according to the load status of the central processing unit CPU of the electronic device; wherein, the thread priority of the GC thread corresponds to the load status of the CPU, when the load status of the CPU is the first state, the thread priority of the GC thread is the first priority, and when the load status of the CPU is the second state, the thread priority of the GC thread is the second priority, the load of the first state is heavier than the load of 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 operation includes multiple operation phases, including one or more preset adjustment phases. When the processor executes the computer instructions, the electronic device further performs the following steps: during the GC thread operation adjustment phase, adjusting the thread priority of the GC thread based on the CPU load status.

[0033] In a possible implementation of the second aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: when the GC thread starts to run the adjustment phase, the thread priority of the GC thread is adjusted according to the load status of the CPU, and a first constraint duration corresponding to the adjustment phase is determined; the first constraint duration is determined according to the historical running time of the GC thread running the adjustment phase; when the duration after the thread priority of the GC thread is adjusted reaches the first constraint duration, the thread priority of the GC thread is adjusted to the third priority; the second priority is higher than the third priority.

[0034] In a possible implementation of the second aspect, when the above-mentioned 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 load information of the CPU and converts the load information of the CPU into an enumeration value, and the enumeration value corresponds to the load state of the CPU; obtaining the enumeration value, and determining the load state of the CPU according to the enumeration value.

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

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

[0037] In a possible implementation of the second aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: when the GC thread starts to run in the adjustment phase, the thread priority of the GC thread is adjusted according to the load status of the CPU; when the GC thread ends the adjustment phase, the thread priority of the GC thread is adjusted to a third priority; the second priority is higher than the third priority.

[0038] In a possible implementation of the second aspect, when the above-mentioned computer instructions are executed by the processor, the electronic device further performs the following steps: when the GC thread starts to run in the adjustment phase, adjusting the thread priority of the GC thread according to the load status of the CPU; during the operation of the adjustment phase, if the load status of the CPU changes, readjusting the thread priority of the GC thread according to the changed load status of the CPU; when the GC thread ends the operation of the adjustment phase, adjusting the thread priority of the GC thread to the third priority; the second priority is higher than the third priority.

[0039] In a possible implementation of the second aspect, when the above-mentioned 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 scene state of the current application is a preset adjustment scene, the thread priority of the GC thread is adjusted according to the load state of the CPU; wherein the adjustment scene includes the application startup scene, the application exit scene and the application interface switching scene.

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

[0041] In a third aspect, the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor in an electronic device, the electronic device executes the thread scheduling method of the first aspect and any possible implementation thereof.

[0042] In a fourth aspect, the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the method of the first aspect and any possible implementation thereof. The computer may be the electronic device described above.

[0043] It can be understood that the beneficial effects that can be achieved by 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 be referred to as the beneficial effects in the first aspect and any possible implementation thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 A schematic diagram of a GC thread blocking other threads provided in an embodiment of the present application;

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

[0046] Figure 3 A schematic diagram of an application interface with a stuck or slow response time provided in an embodiment of the present application;

[0047] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

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

[0049] Figure 6 A schematic diagram of a thread scheduling method provided in an embodiment of the present application Figure 1 ;

[0050] Figure 7A schematic diagram of a thread scheduling method provided in an embodiment of the present application Figure 2 ;

[0051] Figure 8 A schematic diagram of a process for obtaining the CPU load status in real time provided in an embodiment of the present application;

[0052] Figure 9 A schematic diagram of another process for obtaining the CPU load status in real time provided in an embodiment of the present application;

[0053] Figure 10 A flowchart of a GC thread scheduling method in a system server process provided in an embodiment of the present application;

[0054] Figure 11 A schematic diagram of a process for determining a constraint duration provided in an embodiment of the present application;

[0055] Figure 12 A schematic diagram of a thread scheduling method provided in an embodiment of the present application Figure 3 ;

[0056] Figure 13 An interactive timing diagram of a thread scheduling method provided in an embodiment of the present application;

[0057] Figure 14 A schematic diagram of a GC thread not blocking binder communication provided in an embodiment of the present application;

[0058] Figure 15 This is a structural block diagram of a chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0059] The technical solutions of the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Among them, in the description of the embodiments of the present application, the terms used in the following embodiments are only for the purpose of describing specific embodiments, and are not intended to limit the present application. In addition, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, if the words "first", "second" and the like are used to distinguish between the same items or similar items with substantially the same functions and effects. Those skilled in the art will understand that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not necessarily limit them to be different. And, in the description of the embodiments of the present application, unless otherwise specified, the meaning of "multiple" means two or more.

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

[0061] Therefore, under normal circumstances, a process (corresponding to a running application) will include a GC thread. In simple terms, a process usually includes a GC thread. This GC thread in the process can be regarded as the daemon thread of the process, which can be triggered to reclaim the memory space occupied by the process.

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

[0063] A timeslice can be understood as the runtime allocated by the CPU to each process (i.e., application). By allocating timeslices, the CPU controls the execution of each application in turn. Specifically, the time period allocated by the CPU to a thread within a process is called the thread's timeslice; it represents the time the CPU allows that process to run. Generally, if a process is still running when the timeslice expires, the CPU deprives it of its time slice and assigns it to another process. However, if a process becomes blocked or terminates before the timeslice expires, the CPU immediately switches the process to avoid wasting CPU resources.

[0064] In general, because of the introduction of time slicing, users can see that each application is running simultaneously at a macro level. However, at a micro level, each application actually runs in turn based on the time slice allocated by the CPU.

[0065] At the same time, in a process, according to the needs of executing tasks (i.e., actual business needs), multiple threads can run concurrently in a process. Each thread in a process can have an independent stack space and execution context, that is, each thread in a process can run independently. Therefore, for a process, in addition to the above-mentioned GC thread, this process generally includes other threads. It should be noted that the role and type of other threads in the process, except for the GC thread, can be created based on actual needs, and the embodiments of the present application do not impose any restrictions on this.

[0066] Thread priorities are typically assigned to threads within a process based on the importance of the tasks they need to perform. Thread priorities specify the order in which threads are executed. In other words, the CPU schedules threads within a process based on thread priorities, allocating execution time slices to them. Therefore, thread priorities determine the likelihood of a thread receiving a CPU time slice in a multitasking environment.

[0067] However, the default thread priority for GC threads is currently 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 of a thread in a process, the higher its execution order and, accordingly, the greater its probability of obtaining CPU time slices.

[0068] Therefore, due to thread priority restrictions, when the CPU is under heavy load, the CPU will prioritize threads with higher priorities. For example, a process may also include real-time (RT) and important (VIP) threads with higher priorities than GC threads. Furthermore, when the CPU is under heavy load, the CPU may prioritize these higher-priority RT and VIP threads.

[0069] This can cause low-priority threads, such as the GC thread, to be unable to be scheduled by the CPU for extended periods of time under heavy CPU load. Even if the GC thread does obtain a CPU time slice under heavy CPU load, it may be quickly preempted by other, more important threads, and the GC thread will only run briefly. Therefore, under heavy CPU load, the GC thread is likely to remain in the runnable state for extended periods, meaning it will be waiting for CPU scheduling.

[0070] In addition, since the GC thread generally needs to access all other live objects in the process and process them accordingly during its execution, to ensure the correct object processing, the GC thread will also pause other threads (stop the world, STW) at certain stages. For example, the GC thread can notify other threads to suspend (i.e., pause other threads). This ensures that other threads do not access the objects it needs to process, thereby ensuring the correct object processing.

[0071] Alternatively, in order to ensure the correctness of object processing, the GC thread can also block other threads through condition variables, locks, etc. Taking locks as an example, Figure 1 A schematic diagram showing a GC thread blocking other threads.

[0072] like Figure 1 As shown in the figure, when the GC thread is running, if it reaches the corresponding stage, the GC thread can obtain a certain object by locking it and operate on it. At this time, the object is in a state of being locked by the GC thread, which can be simply understood as the GC thread taking all control of the object. In this case, because the object is locked by the GC thread, if other threads want to operate or access this object, they will be blocked by the GC thread, such as Figure 1 As shown, other threads competing for the lock are blocked. Figure 1 As shown, if other threads want to operate or access this object, they need to wait until the GC thread unlocks the object (that is, releases the lock) before other threads can successfully hold the lock.

[0073] In this way, because the GC thread may suspend other threads or block other threads (such as holding a lock to block other threads), if the GC thread starts running after obtaining the CPU time slice and suspends other threads or locks an object, and then encounters a heavy CPU load, the GC thread may not be able to obtain the CPU time slice for a long time after suspending other threads or locking the object, causing the GC thread to enter a long runnable state.

[0074] Correspondingly, because the GC thread is in a long-term runnable state, the time the GC thread suspends other threads or the time it holds the lock on the object will be continuously extended, that is, the time other threads are suspended or blocked by the GC thread will be longer, which will easily affect the normal operation of other threads and may cause abnormal operation of the process.

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

[0076] Specifically, the system server process is the operating system (such as Android TM As the core service manager in the system, application startup, exit, and interface switching often require communication with the system server process. This means that because the system server process provides a large number of basic services for applications, inter-process communication is very busy.

[0077] For example, when the desktop launcher receives the user's launch operation for an application, the desktop launcher generally needs to communicate with the system server process in response to the launch operation in the process of launching the application in order to perform a series of operations such as obtaining services, process lifecycle management, and Activity management.

[0078] Currently, communication between processes in electronic devices is mainly achieved through binders. Binder communication methods mainly include asynchronous binder and synchronous binder. Among them, if asynchronous binder is used for communication between processes, then after the process sends the asynchronous binder call signal, it can continue to execute the next process without waiting for the receiver's response. However, synchronous binder is different from asynchronous binder. If synchronous binder is used for communication between processes, after the process sends the synchronous binder call signal, it needs to wait for feedback from the receiver before continuing to execute the next process. In other words, the process that sends the synchronous binder call signal needs to obtain feedback from the receiver before continuing to execute the next process.

[0079] Therefore, if the application process sends a synchronous binder call signal to the system server process (that is, sends a message through the synchronous binder), the application process will remain in a waiting state until it receives feedback from the system server process. This is equivalent to the application's execution being blocked by the synchronous binder. The application will continue to run only after the application process receives feedback from the system server process.

[0080] At the same time, after the system server process receives the synchronous binder call signal sent by the application process, a corresponding thread will respond to this synchronous binder call signal and perform corresponding processing to feedback to the application process. However, if the thread in the system server process that handles the synchronous binder call signal is paused or blocked by the GC thread for a long time, this thread will not be able to process the synchronous binder call signal in a timely manner, resulting in a long period of time without feedback to the application process. In this way, because the sent synchronous binder does not provide feedback, the application is blocked for a longer time. In other words, after the application sends the synchronous binder, the waiting time will be extended, and the application will experience lag or slow response.

[0081] For example, take the scenario where the launcher starts the application as an example. Figure 2 A schematic diagram showing a GC thread blocking binder communication.

[0082] like Figure 2 As shown, because application launches are typically triggered by users clicking on an 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. After the launcher process sends a synchronous binder call signal to the system server process, it enters a state of waiting for feedback because it needs to receive feedback from the system server process before continuing to the next process. Simultaneously, after the system server process receives the synchronous binder call signal from the launcher process, threads other than the GC thread begin processing the synchronous binder call signal accordingly.

[0083] However, if the GC thread in the system server process pauses or blocks other threads during execution, these threads will be paused or blocked by the GC thread. Only when the GC thread in the system server process is no longer paused or no longer blocks other threads can other threads in the system server process continue processing (i.e., continue processing the synchronization binder call signal) and provide feedback to the launcher process. Only after receiving this feedback can the launcher process proceed to the next step.

[0084] That is, without blocking the synchronization binder, the processing time of the other threads in the system server process to synchronize the binder can only be ①+③, and the corresponding launcher process waits for feedback for only ①+③. However, as shown in Figure 2 , because the GC thread in the system server process suspends or blocks other threads to cause the synchronization binder to be blocked, the processing time of the other threads in the system server process to synchronize the binder is increased to ①+②+③, and the corresponding launcher process waits for feedback for ①+②+③. In this way, the time required for the launcher process to start the application is increased from ①+③ to ①+②+③, and from the user side, the response time of the application startup is lengthened, that is, the application has a problem of lag or slow response during startup.

[0085] For example, taking a mobile phone as an example, Figure 3 , an exemplary application interface of an application lag or slow response is provided.

[0086] As shown in Figure 3 , the mobile phone can display a home interface 300 after booting. The home interface can include various application images corresponding to the application programs, such as a clock, a calendar, a gallery, a memo, a file management, an email, music, and settings, and the like. It can be understood that the application icons actually included in the home interface 300 of the mobile phone can be more or less than those shown in Figure 3 , such as a social application, a shopping application, a video application, and the like, and the present application embodiments do not make any limitation thereto.

[0087] The mobile phone can start the application program corresponding to the application icon in response to the click operation of the user on the application icon in the home interface 300. As shown in Figure 3 , the mobile phone can start the music application in response to the click operation of the user on the music application icon. That is, after the mobile phone receives the click operation of the user on the music application icon, the launcher process in the background of the mobile phone starts binder communication with the system server process in the mobile phone to start the music application and display the application interface of the music application in the foreground. Under normal circumstances, the processing speed of starting the music application in the background is very fast, and after the mobile phone responds to the click operation of the user on the music application icon, the mobile phone can display the play interface 301 of the music application.

[0088] However, if the launcher process and the system server process are in synchronous binder communication, and if the GC thread suspends or blocks other threads during the synchronous binder communication, the synchronous binder communication will be blocked, and the speed of starting the music application in the background will be slowed down. Correspondingly, after the phone responds to the user's click operation on the music application icon, the foreground can first display interface 302, and can display a prompt information "starting" in interface 302 to prompt the user that the music application is currently being started. After the synchronous binder communication in the background of the phone is blocked, the launcher process can complete the starting of the music application, and then display the play interface 301 of the music application. In this way, from the user's point of view, the starting of the music application appears to be stuck or slow to respond.

[0089] It can be understood that, Figure 3 It can be understood that,

[0090] For example, after the phone receives the user's starting operation on the application program, if the GC thread causes the application program to be stuck or slow to respond during the starting process, the interface of the phone can not change for a long time (such as displaying the main interface 300 for a long time), and the phone can be in a state of being unable to respond to the operation (similar to the phone being dead, and the user's click operation has no response), and after waiting for a period of time, the phone displays the application interface of the application program (such as the play interface 301 of the music application).

[0091] For example, if the application program has a design starting interface when starting, during the starting process of the application program, if the GC thread causes the application program to be stuck or slow to respond, the application interface can display the starting interface for a long time without displaying the application main interface (such as not displaying the play interface 301 of the music application for a long time). Or, if the starting process of the application program has a starting animation, the starting animation can not be played or can not be played smoothly.

[0092] In summary, for the system server process, if other threads in the system server process are suspended or blocked by the GC thread for a long time, the application program that depends on the system server process to provide services can be stuck or slow to respond, thereby seriously affecting the user's experience.

[0093] Based on this, in order to prevent the GC thread in the process from pausing for a long time or blocking other threads, thereby reducing the impact of the GC thread on other threads and avoiding abnormal process operation, an embodiment of the present application provides a thread scheduling method. This thread scheduling method can be applied to electronic devices. Simply put, when the GC thread in the electronic device is running, the electronic device can increase the thread priority of the GC thread as needed based on the current CPU load status.

[0094] In this way, because the GC thread pauses or blocks other threads during operation, if the CPU load increases, it will cause other threads to be paused or blocked for a long time by the GC thread, thereby affecting the normal operation of other threads and causing abnormal process operation. Therefore, the thread scheduling method provided in the embodiment of the present application increases the thread priority based on the CPU load status when the GC thread is running. Therefore, if the GC thread encounters a heavy CPU load after pausing or blocking other threads, the possibility of the GC thread being allocated CPU time can be increased by increasing the thread priority, that is, the probability of the GC thread being runnable can be increased, and the GC thread can be prevented from entering a long runnable state after pausing or blocking other threads. This can reduce the duration of the GC thread pausing or blocking other threads to a certain extent, avoid the GC thread pausing or blocking other threads for a long time, thereby reducing the impact of the GC thread on other threads and avoiding further abnormalities in the operation of the process.

[0095] Furthermore, if the thread priority of the GC thread in the system server process is increased, it can also prevent the GC thread from blocking synchronous binder communication, thereby preventing application lag or slow response. In other words, it can avoid application lag or slow response when starting, exiting, or switching application interfaces.

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

[0097] For example, Figure 4 A structural diagram 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, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera module 193, a display 194, and a subscriber identification module (SIM) card interface 195. The sensor module 180 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

[0099] The processor 110 can include one or more processing units, for example: the processor 110 can include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units can be independent devices, or can be integrated in one or more processors.

[0100] The processor 110 can generate operation control signals according to instruction operation codes and timing signals to complete the control of fetching and executing instructions. In the embodiments of the present application, the processor 110 can raise the thread priority of the GC thread on demand according to its own load state. For example, after the GC thread in the system server process runs, the processor 110 can raise the thread priority of the GC thread in the system server process according to its own load state.

[0101] The processor 110 can also be provided with a memory for storing instructions and data. In some embodiments, the memory in the processor 110 can be a cache memory. The memory can save instructions or data that have been used or used frequently by the processor 110. If the processor 110 needs to use the instructions or data, it can directly call from the memory. Avoiding repeated access, reducing the waiting time of the processor 110, thus improving the efficiency of the system.

[0102] In some embodiments, the processor 110 may include one or more interfaces. The interface 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. The processor 110 may be connected to modules such as a touch sensor, an audio module, a wireless communication module, a display screen, and a camera module through at least one of the above interfaces.

[0103] It is understood that the interface connection relationship between the modules illustrated in the embodiments of the present application is merely an illustrative illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection methods from the above embodiments, or a combination of multiple interface connection methods.

[0104] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device 100. The external memory card communicates with the processor 110 via the external memory interface 120 to implement data storage functions. For example, files such as music and videos can be saved on the external memory card or transferred from the electronic device to the external memory card.

[0105] The internal memory 121 can be used to store computer executable program code, which includes instructions. The internal memory 121 may include a program storage area and a data storage area. Among them, the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc. The data storage area can store data created during the use of the electronic device 100 (such as audio data, a phone book, etc.), etc. In addition, the internal memory 121 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. The processor 110 executes various functional methods or data processing of the electronic device 100 by running instructions stored in the internal memory 121, and / or instructions stored in a memory provided in the processor.

[0106] The USB connector 130 is an interface that complies with USB standards and can be used to connect the electronic device 100 to peripheral devices. Specifically, it can be a Mini USB connector, a Micro USB connector, a USB Type-C connector, etc. The charging management module 140 is used to receive charging input from a charger. The charger can be a wireless charger or a wired charger. The power management module 141 is used to connect the battery 142, the charging management module 140, and the 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 for electronic device 100, including 2G / 3G / 4G / 5G. The modem processor can include a modulator and a demodulator. Wireless communication module 160 provides wireless communication solutions for the 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, which is connected to the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. The processor 110 may include one or more GPUs, which execute program instructions to generate or change display information. Among them, the display screen 194 is used to display images, videos, etc. Specifically in the embodiment of the present application, the display screen 194 can be used to display the application interface of the application. In some embodiments, the electronic device 100 may include one or more display screens 194.

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

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

[0111] The buttons 190 may include a power button, a volume button, etc. The indicator 192 may be an indicator light, which may be used to indicate the charging status, power changes, messages, missed calls, notifications, etc. The SIM card interface 195 is used to connect a SIM card.

[0112] It should be understood that the structures illustrated in the embodiments of the present application do not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0113] In some embodiments, the software system of the electronic device can adopt a layered architecture, an event-driven architecture, a micro-core architecture, a micro-service architecture, or a cloud architecture. TM Taking the system as an example, the software structure of the electronic device is illustrated.

[0114] For example, Figure 5 A software structure 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 division of labor. The layers communicate with each other through software interfaces. In some embodiments, the Android TM The system is divided into four layers, from top to bottom: application layer, application framework layer, Android runtime (ART), and kernel layer.

[0116] The application layer can include a series of application packages. Application packages can include applications such as gallery, calendar, map, WLAN, music, SMS, call, navigation, Bluetooth, video, etc.

[0117] The application framework layer provides an application programming interface (API) and programming framework for the applications in the application layer. The application framework layer includes some predefined functions.

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

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

[0120] The window manager provides window management services (WMS). WMS can be used for window management, window animation management, surface management, and as a transfer station for the input system.

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

[0122] The view system includes visual controls, such as those for displaying text and images. The view system is used to build applications. A display interface can consist of one or more views. For example, a display interface containing a text notification icon might include a view for displaying text and a view for displaying images.

[0123] The resource manager provides various resources for applications, such as localized strings, icons, images, layout files, video files, and so on.

[0124] The Notification Manager allows applications to display notifications in the status bar. These messages can be displayed briefly and then disappear automatically without user interaction. For example, the Notification Manager is used to notify users of completed downloads and message reminders. The Notification Manager can also display notifications in the top status bar of the system as icons or scrolling text, such as notifications from background applications, or as dialog windows on the screen. Examples include text messages in the status bar, beeps, vibrations on electronic devices, and flashing indicator lights.

[0125] The Activity Manager can provide an Activity Management Service (AMS), which can be used to start, switch, and schedule system components (such as activities, services, content providers, and broadcast receivers), as well as manage and schedule application processes. In a specific embodiment, an application scenario state recognition module can be set within the Activity Manager, that is, the Activity Management Service can include the application scenario state recognition module.

[0126] The Input Manager provides Input Management Service (IMS), which manages system inputs, such as touch screen input, key input, and sensor input. The IMS retrieves events from input device nodes and, through interaction with the WMS, distributes the events to the appropriate window.

[0127] The Android runtime, also known as a virtual machine, is primarily responsible for converting source code into machine code. The Android runtime primarily utilizes ahead-of-time (AOT) and just-in-time (JIT) compilation techniques. In this embodiment of the present application, the Android runtime (virtual machine) includes a GC adjustment phase identification module, a priority boost 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 is used to determine whether the GC thread has run into the adjustment phase, including the marking pause phase, the recycling phase, or the compaction pause phase. The priority boost time self-learning module is used to predict the constraint duration based on the historical running time of each adjustment phase during the running of the GC thread. This constraint duration is used to constrain the duration for which the thread priority of the GC thread is boosted. The CPU real-time load status acquisition module is used to obtain the CPU load status in real time, such as determining whether the current CPU load status is light load, medium load, or heavy load. The GC thread priority boost module is used to determine the thread priority that the GC thread needs to boost based on the CPU load status.

[0129] The kernel layer is a layer between hardware and software. In an embodiment of the present application, the kernel layer includes at least a CPU load storage node and a thread priority adjustment module. Among them, the CPU load storage node stores the CPU load information, and the upper virtual machine (i.e., the Android runtime) can determine the CPU load status by reading the CPU load information. The thread priority adjustment module is used to adjust the thread priority of the thread, such as increasing the thread priority of the GC thread in response to the instruction of the GC thread priority enhancement module. In other embodiments, the kernel layer may also include display drivers, camera drivers, audio drivers, sensor drivers, etc. ( Figure 5The specific configuration can be based on actual needs, and the embodiments of the present application do not impose any limitation on this.

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

[0131] In some embodiments, the load state of the CPU can be divided into different degrees according to actual conditions. For example, the load state of the CPU can be divided into heavy load, medium load and light load. Among the three load states of light load, medium load and heavy load, the load state of light load represents that the load on the CPU is the lightest, the load state of heavy load represents that the load on the CPU is the heaviest, and the load state of medium load is higher than light load but lower than heavy load. It should be noted that the load state of the CPU can also be divided into more or fewer than the above three load states, and can be specifically divided according to actual needs. The embodiments of the present application do not impose any restrictions on this.

[0132] Exemplarily, the load state of the CPU can be divided into only two types. For example, the load state of the CPU includes a first state and a second state, and the load of the first state is heavier than the load of the second state. Specifically, the first state may correspond to the above-mentioned medium load or heavy load, and the second state corresponds to the above-mentioned light load. For another example, the first state can also include two degrees at the same time, that is, the first state includes a first degree and a second degree. Among them, the first degree and the second degree correspond one-to-one to the above-mentioned medium load and heavy load. Specifically, the first degree is heavy load, and the second degree is medium load. Or, the first degree is medium load, and the second degree is heavy load.

[0133] Alternatively, the CPU load state is divided into three types, including a first state, a second state, and a third state, wherein the first state corresponds to a heavy load, the second state corresponds to a medium load, and the third state corresponds to a light load.

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

[0135] To facilitate the description and understanding of the solution, the following embodiments of the present application will mainly use the three load states of 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 the present application.

[0136] Furthermore, to increase thread priority as needed 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, thereby preventing the GC thread from pausing for extended periods or blocking other threads, and preventing the GC thread from preempting other threads' time slices due to an excessively high priority increase.

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

[0138] Among them, the first priority may correspond to a heavy load, the second priority may correspond to a medium load, and the third priority may correspond to a light load. In addition, the first priority is higher than the second priority, and the second priority is higher than the third priority (i.e., the first priority > the second priority > the third priority). At the same time, in other embodiments, the priority corresponding to the light load may be the original thread priority (i.e., the original priority) of the GC thread. That is, in this case, the third priority corresponding to the light load is the original priority of the GC thread, for example, the third priority may be the above-mentioned 124.

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

[0140] It can be understood that the correspondence between load status and thread priority only needs to ensure that the heavier the load, the higher the corresponding thread priority. Other specific settings can be made according to actual needs, and the embodiments of this application do not impose any restrictions on this.

[0141] In addition, it should be noted that the three-tier thread priority classification in this embodiment of the present application is based on the three aforementioned load states. It is understood that if the CPU load state is actually divided into more or fewer states, the thread priority can also be adaptively divided into more or fewer states according to the actual CPU load state, and this embodiment of the present application does not impose any limitation on this.

[0142] To facilitate the description and understanding of the solution, the following embodiments of the present application will mainly be explained using the example of the first priority (corresponding to heavy load) > the second priority (corresponding to medium load) > the third priority (corresponding to light load, i.e. the original priority).

[0143] Figure 6 A schematic diagram of a thread scheduling method is shown below. Figure 6 The process shown explains the thread scheduling method provided in the embodiment of the present application.

[0144] like Figure 6 As shown, after the GC thread runs, the electronic device first determines the current CPU load status. If the current CPU load status is light load, light load means that the current CPU load is not very heavy. In this case, the GC thread maintains the original thread priority (such as the third priority) and can obtain the CPU time slice to run, so it is less likely that the GC thread will be suspended for a long time or block other threads. Therefore, when the CPU load is light, the electronic device does not need to increase the thread priority of the GC thread, and the GC thread can continue to run according to the original logic.

[0145] If the electronic device determines that the CPU load state is medium load, medium load means that the current CPU load has increased. In this case, if the GC thread continues to maintain the original thread priority (such as the third priority), the probability of the GC thread obtaining the CPU time slice will decrease, which may cause the process to run abnormally due to long-term suspension or blocking of other threads. Therefore, when the CPU load is medium load, in order to appropriately increase the probability that the GC thread can obtain the CPU time slice, the electronic device can adjust the thread priority of the GC thread accordingly. That is, since medium load corresponds to the second priority, the electronic device can increase the thread priority of the GC thread from the third priority to the higher second priority.

[0146] If it is determined that the CPU load state is overloaded, overload indicates that the current CPU load has reached full load or is about to reach full load. In this case, the probability that the GC thread can obtain the CPU time slice is very low. Therefore, in order to avoid the GC thread pausing for a long time or blocking other threads, causing abnormal process operation, the electronic device can also adjust the thread priority of the GC thread accordingly. That is, the electronic device can increase the thread priority of the GC thread to the highest level. In other words, overload corresponds to the first priority of the highest level, and the electronic device increases the thread priority of the GC thread from the third priority to the first priority.

[0147] It is understandable that in the embodiment of the present application, the GC thread can be manually triggered by the user, or it can be automatically triggered based on time and conditions. However, it should be noted that the time and conditions for automatically triggering the GC thread to run can be set according to the actual business logic, and the embodiment of the present application does not impose any restrictions on this. For example, the electronic device can trigger the start of the GC thread to reclaim memory (i.e., execute minro GC) when the remaining memory is insufficient to store new objects. Alternatively, when the objects promoted to the old generation are larger than the remaining space in the old generation, the start of the GC thread is triggered to reclaim memory (i.e., execute full GC).

[0148] In some embodiments, the memory reclamation tasks performed by a GC thread are typically divided into multiple phases, including a marking phase, a marking pause phase, a reclaim phase, and a compaction pause phase. Furthermore, the GC thread does not pause or block other threads in all phases of its execution.

[0149] Therefore, in order to avoid wasting CPU resources by ineffectively raising the thread priority of the GC thread, the electronic device can specifically raise the thread priority of the GC thread only when the GC thread runs to a preset adjustment phase. Among them, this adjustment phase is the phase during the GC operation process where other threads may be paused or blocked. The adjustment phase in the embodiment of the present application can be pre-configured according to the operation logic of the GC. In a specific embodiment, the preset adjustment phase includes the three phases mentioned above: the marking pause phase, the recycling phase, and the compression pause phase.

[0150] That is, after the GC thread runs, the electronic device can raise the thread priority of the GC thread as needed based on the CPU load status when the GC thread enters the adjustment phase such as the marking pause phase, the recycling phase, or the compaction pause phase. In some embodiments, the timing of the GC thread starting to run can be monitored by pre-instrumenting the code required for the GC thread to run, or the timing of the GC thread starting to run the adjustment phase can be monitored by using program instrumentation.

[0151] For example, program instrumentation can be performed in advance before the code corresponding to the adjustment stages such as the mark pause stage, the reclaim stage, and the compaction pause stage, so that when the GC thread executes the code corresponding to the adjustment stages such as the mark pause stage, the reclaim stage, or the compaction pause stage, feedback from the GC thread can be received, thereby determining that the GC thread has reached the adjustment stage such as the mark pause stage, the reclaim stage, and the compaction pause stage.

[0152] Figure 7 A schematic diagram of another thread scheduling process is shown.

[0153] like Figure 7 As shown, after the GC thread runs, it can be determined whether the GC thread has run to the preset adjustment stage (whether it has run to the marking pause stage, the recycling stage or the compression pause stage). If the GC thread has not yet run to the preset adjustment stage, then the running stage that the GC thread currently needs to run will not be a stage where other threads are paused or blocked, that is, the GC thread’s current running stage will not be a stage where other threads are paused or blocked. Therefore, in this case, even if the GC thread enters a long runnable state due to heavy CPU load, it will not affect other threads, so there is no need to increase the thread priority of the GC thread in this running stage. Therefore, if the GC thread has not yet run to the preset adjustment stage, 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 (such as maintaining it at the third priority).

[0154] If the GC thread is determined to have reached the preset adjustment phase, this indicates that this phase will pause or block other threads. This means that the GC thread will pause or block other threads during this phase, potentially affecting the execution of other threads. Therefore, if the GC thread reaches the preset adjustment phase, the electronic device needs to increase the thread priority of the GC thread to avoid prolonged pauses or blocking of other threads.

[0155] Furthermore, in order to determine the thread priority that needs to be increased for the GC thread, the electronic device obtains the current CPU load status and increases the thread priority of the GC thread as needed according to the CPU load status. For example, under medium load conditions, the priority of the GC thread is increased from the third priority to the second priority. Under heavy load conditions, the priority of the GC thread is increased from the third priority to the first priority. For the specific implementation of increasing the thread priority of the GC thread as needed according to the CPU load status, please refer to the above-mentioned Figure 6 The description of the embodiments of the present application will not be repeated here.

[0156] In general, in the embodiment of the present application, only when the GC thread runs to the preset adjustment stage, that is, starts to run the mark pause stage, the recovery stage or the compression pause stage, the electronic device will start to judge whether the CPU load state is light load, medium load or heavy load. If the CPU load state is light load, the thread priority of the GC thread is not adjusted, and the GC thread continues to run. If the CPU load state is medium load or heavy load, the thread priority of the GC thread is adjusted, and the thread priority of the GC thread is increased to the second priority corresponding to the medium load or increased to the third priority corresponding to the heavy load.

[0157] In the embodiment of the present application, for phases other than the marking pause phase, the recycling phase, and the compression pause phase, since the GC thread generally does not pause or block other threads, the electronic device may not increase the thread priority of the GC thread when running in other phases, thereby avoiding invalid increase and waste of CPU resources.

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

[0159] The load information of the CPU may include the utilization of the CPU. In this way, the electronic device can determine the load status of the CPU by reading the utilization of the CPU. For example, taking an eight-core CPU as an example, when the eight-core CPU is fully loaded, the utilization of the CPU is 800%. Therefore, according to actual needs, it can be set that when the utilization of the eight-core CPU reaches 700%, the electronic device can determine that the load status of the CPU is heavy load. When the utilization of the eight-core CPU reaches 500%, that is, when the utilization of the eight-core CPU is between 500% and 700%, the electronic device can determine that the load status of the CPU is medium load. Correspondingly, if the utilization of the eight-core CPU is lower than 500%, it can be determined that the load status of the CPU is light load.

[0160] It should be noted that the above utilization rates of 700% and 500% are only used as examples in the embodiments of this application and do not constitute any limitation on the range of load status. It is understandable that the load status of the CPU, such as the range of light load, medium load and heavy load, can be set according to actual needs, and the embodiments of this application do not impose any limitation on this. For example, when the utilization of the eight-core CPU reaches 650%, the CPU load status is determined to be heavy load. Alternatively, when the utilization of the eight-core CPU is lower than 400%, the CPU load status is determined to be light load.

[0161] In a specific embodiment, to ensure the accuracy of thread priority enhancement, the CPU load status determined when performing thread priority enhancement 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, having the created thread execute a scheduled task, and periodically reading the CPU load information. Figure 8 A schematic diagram of a process for obtaining the CPU load status in real time is shown below. Figure 8 Explain the process of obtaining the CPU load status in real time.

[0162] like Figure 8 As shown, after a process (such as a system server process) is created, the electronic device can create a state determination thread for the created process. This created state determination thread can be dedicated to reading CPU load information, thereby obtaining the CPU load status (such as light load, medium load, or heavy load) in real time. Exemplarily, the type of state determination 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 the state determination thread to periodically obtain the CPU load status, so that the state determination thread executes this scheduled task and can periodically obtain the CPU load status. Furthermore, 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, the electronic device can obtain the CPU load status in real time by creating a status determination thread. Specifically, the process may include: creating a task queue for the status determination thread, setting a task for obtaining the CPU load status, and placing it into the task queue. The status determination thread can then read and execute the task in the task queue. Thus, the status determination thread can periodically execute the task of obtaining the CPU load status through queue polling.

[0165] The process of the state determination thread executing the task of obtaining the CPU load state may include: reading the CPU load information and converting the CPU load information into an enumeration value corresponding to the CPU load state. That is, after the state determination thread reads the CPU load information, the state determination thread converts the read CPU load information into an enumeration value, and uses the enumeration value to represent different load states. Furthermore, the electronic device can determine the current CPU load state by reading the enumeration value set by the state determination thread. In other words, after creating the state determination 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, the CPU load information can be converted into three enumeration values ​​of 0, 1, and 2. The three enumeration values ​​0, 1, and 2 correspond one-to-one to the three load states of light load, medium load, and heavy load. For example, 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 the embodiments of the present application do not impose any restrictions on this. At the same time, the specific numerical values ​​corresponding to the enumeration values ​​can also be set according to actual needs, and the embodiments of the present application do not impose any restrictions on this.

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

[0168] Taking the system server process as an example, Figure 9 A schematic diagram of another process for obtaining the CPU load status in real time is shown.

[0169] like Figure 9 As shown, Figure 9 The process shown is in Figure 8 The process shown has an additional step of determining whether it is a system server process. That is, after the process is created, the electronic device first determines whether the currently created process is a system server process (i.e., determines whether it is a preset process). If the currently created process is a system server process (i.e., it is determined to be a preset process), the electronic device will further create a status determination thread to obtain the CPU load status in real time. If the currently created process is not a system server process (i.e., it is determined not to be a preset process), then there is no need to adjust the thread priority of the GC thread in this process, and the corresponding electronic device does not need to create a status determination thread for this process to obtain the CPU load status in real time, thereby directly ending the process.

[0170] In other words, since the created process is not a system server process (i.e., not a preset process), the electronic device will not increase the thread priority of the GC thread in this process when it runs, so there is no need to create a state determination thread to obtain the CPU load status in real time. Conversely, when the GC thread in this process runs, because no state determination thread is created for it to obtain the CPU load status in real time, the electronic device cannot obtain the CPU load status in real time when this GC thread runs, and naturally cannot increase the thread priority of the GC thread in this process on demand based on the CPU load status.

[0171] In some embodiments, for system server processes, the primary impact of synchronous binder blocking caused by the GC thread in the system server process is application lag or slow response. This impacts application performance in scenarios such as application startup and exit, and switching between application interfaces. Therefore, for the GC thread in the system server process, its thread priority can be increased only in the aforementioned adjustment scenarios (including application startup and exit, and switching between application interfaces).

[0172] Figure 10 The figure shows a flow chart of a GC thread scheduling method in a system server process.

[0173] like Figure 10 As shown, compared Figure 7 The process shown, Figure 10 The GC thread being run is limited to the GC thread in the system server process, and an additional step is added to determine whether the current scene is an adjustment scene. Figure 10 As shown, for the system server process, after the GC thread in the system server process runs and before the GC thread priority is increased as needed based on the CPU load, in addition to determining whether the GC thread has reached the preset adjustment phase, it can also determine whether the current scenario is an adjustment scenario. In other words, it can determine whether the current application scenario is starting, exiting, or switching between application interfaces.

[0174] If the electronic device determines that the current scenario is not the startup, the exit or the application interface switching of the application program, it indicates that the current scenario state of the application program is not the adjustment scenario. In this case, the electronic device does not promote the thread priority of the GC thread in the system server process, i.e., the GC thread in the system server process maintains the original thread priority and continues to run. If the electronic device determines that the current scenario state of the application program is the startup, the exit or the application interface switching of the application program, it indicates that the current scenario state is the adjustment scenario. In this case, in order to avoid the problem that the GC thread is suspended for a long time or blocks other threads, causing the application program to be slow or unresponsive in the startup, the exit and the application interface switching scenarios, the electronic device further executes the step of promoting the thread priority of the GC thread according to the load state of the CPU as needed. It can be understood that the specific implementation of promoting the thread priority of the GC thread according to the load state of the CPU as needed in the embodiments of the present application can refer to the related descriptions of the above Figure 6 、 Figure 7 and Figure 9 , and the embodiments of the present application will not be described here.

[0175] In some embodiments, the judgment of the adjustment scenario can be determined by using the application scenario state value. That is, when the scenario state of the application program in the foreground of the electronic device changes, the electronic device can set the application scenario state value accordingly. Then, when it is necessary to determine whether the scenario state of the application program is the adjustment scenario, the electronic device can determine whether the current scenario is the adjustment scenario by directly reading the application scenario state value.

[0176] For example, 0, 1, 2 and 3 can be used to represent different scenario states respectively. For example, setting the application scenario state value to 0 indicates that the current scenario state of the application program is the startup of the application program. Setting the application scenario state value to 1 indicates that the current scenario state of the application program is the exit of the application program. Setting the application scenario state value to 2 indicates that the current scenario state of the application program is the application transition (application interface switching). Setting the application scenario state value to 3 indicates that the current scenario state of the application program is other scenarios, i.e., the scenario state of the application program is not the adjustment scenario.

[0177] It should be noted that the above 0, 1, 2 and 3 are only examples of the application scenario state value in the embodiments of the present application, and do not constitute a limitation on the application scenario state value. The specific setting can be determined according to the actual situation, and the embodiments of the present application do not make any limitation.

[0178] In some embodiments, after the thread priority of the GC thread in a process (such as a system server process) is increased, in order to prevent the GC thread from being at a high priority for a long time and preempting time slices of other threads, the thread priority of the GC thread can be lowered again after the thread priority of the GC thread is increased.

[0179] For example, after the GC thread finishes running, the thread priority can be lowered back to the original thread priority of the GC thread. Alternatively, after the GC thread finishes running in the adjustment phase, the thread priority can be lowered back to the original thread priority of the GC thread. For example, if the CPU load status determines that the thread priority of the GC thread needs to be increased from the third priority to the second priority (or the first priority), then after the GC thread finishes running, the thread priority of the GC thread is further lowered from the second priority (or the first priority) to the third priority.

[0180] Alternatively, when raising the thread priority of the GC thread, a certain constraint duration (e.g., a first constraint duration and a second constraint duration) can be set. The set constraint duration constrains the time during which the thread priority of the GC thread is raised. That is, a timer can be started at the same time as the thread priority of the GC thread is raised. If the timer duration exceeds the set constraint duration, indicating that the thread priority of the GC thread after being raised has reached the constraint duration, the electronic device will then lower the thread priority of the GC thread back to its original thread priority.

[0181] For example, if it is determined through the CPU load status that the thread priority of the GC thread 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 when the thread priority of the GC thread is raised from the third priority to the second priority (or the first priority), the timing starts. After the timing reaches 10 seconds, the thread priority of the GC thread is lowered from the second priority (or the first priority) to the third priority.

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

[0183] In a 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. The predicted execution time is then used as a constraint duration for raising the thread priority of the GC thread, and the predicted constraint duration is used to constrain the duration for which the thread priority of the GC thread is raised.

[0184] Take the GC thread in the system server process as an example, Figure 11 A schematic diagram of a process for determining a constraint duration is shown.

[0185] like Figure 11 As shown, after the GC thread in the process runs (such as the GC in the system server process), when it reaches the adjustment phase where the thread priority needs to be increased, the start_time of the start of this adjustment phase is synchronously recorded.

[0186] Then, when the adjustment phase ends, the end time cur_time of the adjustment phase is recorded. Then, the running time of the adjustment phase can be calculated by the recorded start time start_time and end time cur_time to obtain the running time = cur_time-start_time.

[0187] Finally, the calculated running time is placed in a queue (running time queue). The length of the queue can be set according to actual needs, and the embodiments of the present application do not impose any restrictions on this. For example, the queue length can be 5, 10, and 20. The length of the queue corresponds to the number of running times that can be stored. For example, if the queue length is 5, then the queue can store the running times corresponding to the last 5 runs in the adjustment phase history. At the same time, the queue updates the running time according to the first-in, first-out principle.

[0188] In addition, since the embodiment of the present application is described by taking the GC thread in the system server process as an example, Figure 11 There is also a step to determine whether it is a system service process. Therefore, the running time of this adjustment phase is only calculated if the currently running GC thread is determined to be a GC thread in the system server process. However, it should be noted that if the actual application does not require the thread priority of the GC threads in one or more processes (for example, not the system server process) to be increased, but rather the thread priority of the GC threads in all processes needs to be increased uniformly, then this step of determining whether it is a system service process can be removed as needed.

[0189] Of course, it is understandable that the step of judging whether it is a system service process can also be performed directly after the GC thread is running. That is, if it is determined that it is not a GC thread of the system service process, the process can be ended directly, and there is no need to start recording the start_time when this GC thread runs to the adjustment stage.

[0190] Further, when it is determined that the thread priority of the GC thread needs to be raised on demand according to the load state of the CPU, the electronic device can read the recorded running time (i.e., the historical running time) from the queue recording the running time (the running time queue). Then, the average of all running times in the queue is calculated to obtain the constraint duration (here, the first constraint duration is obtained, and the calculation principle of the second constraint duration is the same, which will not be described here). Then, the electronic device can raise the thread priority of the GC thread under the constraint of this constraint duration. That is, if the duration after the thread priority is raised reaches this constraint duration, the thread priority of the GC thread is lowered to the original thread priority.

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

[0192] As Figure 12 shown, after the GC thread in the system server process runs and after the adjustment stage and adjustment scenario are judged, if it is determined that the thread priority of the GC thread needs to be raised on demand according to the load state of the CPU, the average of the running times in the queue (i.e., the average of the historical running times in the running time queue) can be calculated before the thread priority is raised to obtain the constraint duration (here, the first constraint duration corresponding to the adjustment stage). Then, the thread priority of the GC thread is raised under the constraint of the constraint duration. That is, as Figure 12 shown, when the load state of the CPU is medium load, the thread priority of the GC thread can be raised to the second priority (for example, from the third priority to the second priority) under the constraint of the constraint duration. When the load state of the CPU is heavy load, the thread priority of the GC thread can be raised to the first priority (for example, from the third priority to the first priority) under the constraint of the constraint duration.

[0193] In some embodiments, in order to ensure the accuracy of the constraint time in different adjustment stages, different adjustment stages should correspond to a queue. That is, the mark pause stage has a corresponding first queue, which is used to record the historical running time of the mark pause stage. When the GC thread runs to the mark pause stage, the historical running time is obtained from the corresponding first queue to calculate the constraint duration corresponding to the mark pause stage, and this constraint duration is used to constrain the thread priority increase duration in the mark pause stage. Similarly, the recycling stage has a corresponding second queue, which is used to record the historical running time of the recycling stage. When the GC thread runs to the recycling stage, the historical running time is obtained from the corresponding second queue to calculate the constraint duration of the recycling stage. And, the recycling pause stage has a corresponding third queue, which is used to record the historical running time of the recycling pause stage. When the GC thread runs to the recycling pause stage, the historical running time is obtained from the corresponding third queue to calculate the constraint duration corresponding to the recycling pause stage.

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

[0195] After powering on an electronic device, it first starts the system server process. During the startup of the system server process, the thread scheduling service provided by the embodiment of the present application can be started through the cleargrowthLimit() function. This thread scheduling service can implement the thread scheduling method provided by the embodiment of the present application. The cleargrowthLimit() function is originally used to clear the upper limit of memory usage. The embodiment of the present application can pre-insert the program 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 is started, the CPU real-time load status acquisition module, priority improvement time self-learning module, application scenario status identification module, GC thread priority improvement module and GC adjustment stage identification module included in the thread scheduling service will be started accordingly.

[0197] like Figure 13As shown, after the CPU real-time load status acquisition module is launched, it first calls the function issystemserver() to determine whether the currently launched process is a system server process. Because thread scheduling is performed for system server processes, if it is determined not to be a system server process, the current process is terminated and the next process is launched. If the CPU real-time load status acquisition module determines that the currently launched process is a system server process, it calls the function createthreadpool() to create a corresponding status determination thread for the system server process.

[0198] The CPU real-time load status acquisition module then sets a timer task for the status determination thread, which calls the function getcpuload() to periodically read the CPU load information (which may include, for example, the CPU utilization rate) from the CPU load storage node (i.e., the kernel node). After reading the CPU load information, the CPU real-time load status acquisition module 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 is started, it starts to monitor the operation of the GC thread. In some embodiments, the GC thread can be triggered to run manually, or the GC thread can be triggered to run automatically. In some embodiments, whether to trigger the GC thread to run can be specifically determined by the GC entry function garbagecollectorinternal(), that is, the time and conditions for triggering the GC thread to run can be configured in the entry function garbagecollectorinternal(). Among them, whether the configured time and conditions for the GC thread to run can be set according to the actual business logic, and the embodiments of the present application do not impose any restrictions on this. When it is determined that GC needs to be executed, 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 starts running and starts running to the preset adjustment phase, the priority boost time self-learning module and the GC thread priority boosting module are notified. At the same time, if the GC adjustment phase identification module detects that the GC thread ends running in the adjustment phase, the priority boost time self-learning module and the GC thread priority boosting module also need to be notified. 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, starts running to the adjustment phase, or ends running in the adjustment phase, because there is program instrumentation, the GC thread can feedback to the GC adjustment phase identification module. Thus, the GC adjustment phase identification module can monitor the running status of the GC thread through the feedback of the GC thread.

[0201] like Figure 13 As shown, after the priority boost time self-learning module is activated, if the GC adjustment phase identification module notifies the GC thread that it has entered the adjustment phase, the priority boost time self-learning module records the start time, start_time. Furthermore, to boost thread priority for system server processes, the priority boost time self-learning module can determine whether the process is a system server process by calling the issystemserver() function. In other words, it determines whether the GC thread currently entering the adjustment phase is a GC thread in the system server process.

[0202] In some embodiments, determining 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 represented by assigning values ​​to variables. Therefore, assigning values ​​to corresponding variables in a process can determine whether the process is a system server process.

[0203] If the priority promotion time self-learning module determines that the GC thread running to the adjustment stage is not the GC thread in the system server process, indicating that the current is not the system server process, the priority promotion time self-learning module does not need to record the running end time cur_time any more, and will not calculate the running time consumption. If the GC thread running to the adjustment stage is the GC thread in the system server process, indicating that the current is the system server process, when the priority promotion time self-learning module receives the notification of the end of the running of the adjustment stage, it records the running end time cur_time. Then, the priority promotion time self-learning module calculates the running time consumption according to the recorded start running time start_time and the running end time cur_time, and the running time consumption = cur_time-start_time. Finally, the priority promotion time self-learning module puts the statistical running time consumption into the queue (running time consumption queue).

[0204] As shown in Figure 13 application scene state value corresponding to the application transition scene. As shown in

[0205] Similarly, when the application scene state recognition mode monitors that the function applyoomadjlsp() is called to start or exit the application program, it can also be determined that the scene state of the current application program has changed. Then, the application scene state recognition mode calls the function setcurrentstate() to set the application scene state value corresponding to the current application program scene state, that is, the set application scene state value corresponds to the scene of starting or exiting the application program. It should be noted that the specific setting of the application scene state value can be set according to actual needs, and the embodiments of the present application do not make any limitation thereto.

[0206] As shown in Figure 13 After the GC thread priority promotion module is started, after the GC thread priority promotion module receives the notification of the start of the adjustment stage of the GC thread from the GC adjustment stage recognition module, the GC thread priority promotion module can start to execute the related process of priority adjustment.

[0207] Specifically, because the embodiment of the present application is aimed at adjusting the priority of the GC thread in the system server process, the GC thread priority improvement module first needs to determine whether the GC thread in the running adjustment phase is the GC thread in the system server process, that is, to determine whether it is a system server process. If the GC thread priority improvement module determines that it is not a system server process, indicating that there is no need to adjust the priority of the GC thread, then the GC thread priority improvement module may not adjust the thread priority of the GC thread. If it is determined to be a system server process, then in order to ensure that the GC thread does not block the synchronous binder communication of the system server process for a long time during this adjustment phase, the GC thread priority improvement module needs to execute the following process, that is, the GC thread priority improvement module needs to adjust the thread priority of the GC thread. In some embodiments, the GC thread priority improvement module can also determine whether the process is a system server process by assigning a value to the corresponding variable of the process.

[0208] Next, after determining that the process is a system server process, the GC thread priority enhancement module can obtain the application scenario status value from the application scenario status identification module. The GC thread priority enhancement 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 can be determined to be application launch. When the application scenario status value is 1 or 2, the previous application scenario status can be determined to be application exit or application transition, respectively.

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

[0210] Meanwhile, the GC thread priority promotion module obtains an enumeration value corresponding to the load state of the CPU (such as 0, 1, and 2 described above) from the CPU real-time load state obtaining module, and determines the load state of the CPU through the enumeration value, including light load, medium load, and heavy load. In this way, the GC thread priority promotion module can determine the thread priority that needs to be promoted for the GC thread, for example, the thread priority that needs to be promoted can be the first priority or the second priority. In a specific embodiment, the GC thread priority promotion module can obtain the enumeration value corresponding to the load state of the CPU from the CPU real-time load state obtaining module by calling the function getcpustatus ().

[0211] If the GC thread priority promotion module determines that the current is the adjustment stage and the adjustment scenario, it notifies the thread priority adjustment module to adjust the thread priority of the GC thread in the system server process. Moreover, the GC thread priority promotion module needs to send the constraint time length and the required promoted priority to the thread priority adjustment module along with the notification. That is, the notification carries the constraint time length and the required promoted priority.

[0212] After receiving the adjustment notification sent by the GC thread priority promotion module, the thread priority adjustment module adjusts the thread priority of the GC thread in the system server process within the constraint time length. For example, the thread priority adjustment module promotes the thread priority of the GC thread from the third priority to the second priority or the first priority. Meanwhile, because of the constraint of the constraint time length, in the case that the time length after the promotion of the thread priority of the GC thread reaches the constraint time length, the thread priority adjustment module lowers the thread priority of the GC thread to the original thread priority, that is, back to the third priority.

[0213] For example, in the scenario of starting an application by the launcher, Figure 14 A schematic diagram of the GC thread not blocking binder communication is shown.

[0214] For comparison Figure 14 and Figure 2 It can be seen that after the GC thread in the system server process promotes the thread priority according to the load state of the CPU, there is no phenomenon of long-time pause or blocking other threads during the GC running process. Correspondingly, the time length of the desktop launcher process (i.e., the launcher process) waiting for feedback returns to ①+③ when there is no blocking. From the user side, the startup of the application does not appear obvious lag or slow response problem.

[0215] It should be noted that Figure 2 and Figure 14The durations ①, ② and ③ shown are only used as examples in the embodiments of this application. They do not constitute any limitation on the duration of thread processing, waiting time, etc. The specific value of the duration depends on the actual operating conditions, and the embodiments of this application do not impose any limitation on this.

[0216] Another embodiment of the present application provides an electronic device comprising: one or more processors and a memory. The memory is coupled to each of the processors; the memory stores one or more computer program codes, each of which includes 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 the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor in an electronic device, the electronic device implements the thread scheduling method described in any of the above embodiments.

[0218] The embodiment of the present application further provides a computer program product, which, when executed on a computer, enables the computer to execute the functions or steps in the above method embodiment.

[0219] The present application also provides a chip system. 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 can be interconnected via a line. For example, the interface circuit 1502 can be used to receive signals from other devices (such as a computer memory). For another example, the interface circuit 1502 can be used to send signals to other devices (such as the processor 1501).

[0220] For example, the interface circuit 1502 can read instructions stored in the memory and send the instructions to the processor 1501. When the instructions are executed by the processor 1501, the computer can execute the various steps in the above embodiment. Of course, the chip system can also include other discrete devices, which are not specifically limited in this embodiment of the application.

[0221] Through the description of the above implementation methods, technical personnel in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional modules is used as an example. In actual applications, the above-mentioned functions can be 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 devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

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

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

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

[0226] The above content is only a specific embodiment of this application, but the scope of protection of this application is not limited to this. Any changes or replacements within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A thread scheduling method, characterized in that: Used in electronic equipment, including: Create a garbage collection GC thread; When the GC thread is running, the thread priority of the GC thread is adjusted according to the load status of the central processing unit (CPU) of the electronic device; wherein, the thread priority of the GC thread corresponds to the load status of the CPU, when the load status of the CPU is a first state, the thread priority of the GC thread is a first priority, and when the load status 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 the load of the second state, and the first priority is higher than the second priority.

2. The method according to claim 1, characterized in that The electronic device includes a system service process, and the GC thread is a GC thread in the system service process.

3. The method according to claim 1 or 2, characterized in that The GC thread operation includes multiple operation phases, and the multiple operation phases include one or more preset adjustment phases; The step of adjusting the thread priority of the GC thread according to the load status of the central processing unit (CPU) of the electronic device when the GC thread is running includes: When the GC thread runs the adjustment phase, the thread priority of the GC thread is adjusted according to the load status of the CPU.

4. The method according to claim 3, characterized in that When the GC thread runs the adjustment phase, adjusting the thread priority of the GC thread according to the load status of the CPU includes: When the GC thread starts to run the adjustment phase, the thread priority of the GC thread is adjusted according to the load status of the CPU, and a first constraint duration corresponding to the adjustment phase is determined; the first constraint duration is determined based on a historical running time of the GC thread running the adjustment phase; When the duration after the thread priority of the GC thread is adjusted 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.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: 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, wherein the enumeration value corresponds to the CPU load state; The enumeration value is obtained, and the load state of the CPU is determined according to the enumeration value.

6. The method according to claim 4, characterized in that The determining of the first constraint duration includes: Reading the historical running time of the adjustment stage from the running time queue corresponding to the adjustment stage; An average value of the historical running time is calculated to obtain the first constraint duration corresponding to the adjustment stage.

7. The method according to any one of claims 4 to 6, characterized in that The method further comprises: When the GC thread starts to run the adjustment phase, the start time of the run is recorded; and when the GC thread ends the run of the adjustment phase, the end time of the run is recorded; The difference between the end time and the start time of the operation is calculated to obtain the operation time of the current operation in the adjustment phase, and the operation time of the current operation in the adjustment phase is written into the operation time queue corresponding to the adjustment phase.

8. The method according to claim 3, characterized in that When the GC thread runs the adjustment phase, adjusting the thread priority of the GC thread according to the load status of the CPU includes: When the GC thread starts to run the adjustment phase, the thread priority of the GC thread is adjusted according to the load status of the CPU; when the GC thread ends running the adjustment phase, the thread priority of the GC thread is adjusted to a third priority; the second priority is higher than the third priority.

9. The method according to claim 3, characterized in that When the GC thread runs the adjustment phase, adjusting the thread priority of the GC thread according to the load status of the CPU includes: When the GC thread starts to run the adjustment phase, adjusting the thread priority of the GC thread according to the load status of the CPU; During the operation of the adjustment phase, if the load state of the CPU changes, the thread priority of the GC thread is readjusted according to the changed load state of the CPU; When the GC thread finishes running in the adjustment phase, the thread priority of the GC thread is adjusted to a third priority; the second priority is higher than the third priority.

10. The method according to any one of claims 3 to 9, characterized in that The adjustment phase includes a marking pause phase, a recycling phase, and a compression pause phase.

11. The method according to any one of claims 2 to 10, characterized in that The step of adjusting the thread priority of the GC thread according to the load status of the central processing unit (CPU) of the electronic device when the GC thread is running includes: When the GC thread is running, if it is determined that the scene state of the current application is a preset adjustment scene, the thread priority of the GC thread is adjusted according to the load state of the CPU; wherein the adjustment scene includes the application startup scene, the application exit scene and the application interface switching scene.

12. The method according to claim 11, characterized in that The method further includes: reading an application scenario state value, and determining the scenario state of the application program according to the application scenario state value.

13. The method according to claim 1 or 2, characterized in that The step of adjusting the thread priority of the GC thread according to the load status of the central processing unit (CPU) of the electronic device when the GC thread is running includes: When the GC thread is running, determining a second constraint duration, and adjusting the thread priority of the GC thread according to the load status of the CPU; wherein the second constraint duration is determined according to the historical running time of the GC thread; When the duration after the thread priority of the GC thread is adjusted 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.

14. The method according to any one of claims 4 to 13, characterized in that The third priority corresponds to the original priority of the GC thread.

15. An electronic device, characterized in that: include: One or more processors and a memory, wherein the memory is coupled to the processor; one or more computer program codes are stored in the memory, and the computer program codes include computer instructions; when the processor executes the computer instructions, the electronic device executes the thread scheduling method according to any one of claims 1 to 14.

16. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor of an electronic device, the electronic device is caused to execute the thread scheduling method according to any one of claims 1 to 14.

17. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor in an electronic device, the electronic device executes the thread scheduling method according to any one of claims 1 to 14.

Images