Thread processing method, medium, electronic equipment and program product

Abstract

The invention relates to the technical field of terminals, and discloses a thread processing method, a medium, electronic equipment and a program product. In the application starting process, whether a first thread initiating calling and a called second thread meet a scheduling identifier transmission condition or not is judged firstly. When it is judged that the scheduling identifier transmission condition is met, whether the scheduling identifier (such as a VIP identifier) needs to be transmitted from the first thread to the second thread or not can be further judged according to the type of the calling mode, and how to adjust the transmission depth of the second thread when the scheduling identifier is set for the second thread. When the scheduling identifier is transmitted in the first type of calling mode, the transmission depth is forcibly not set for the called second thread, or the transmission depth is forcibly set to be 0, so that the situation that the scheduling identifier cannot be normally transmitted for the second thread and a higher scheduling priority cannot be set for the second thread is avoided. And furthermore, the problem that the first thread is blocked by the second thread can be improved, and the starting speed of the application is increased.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to a thread processing method, medium, electronic device and program product. Background Technology

[0002] When users use applications on a terminal device, the application's response speed, such as startup speed, is one of the important indicators of product performance. Slow response speed is usually manifested as delayed click effects, operation waiting, or long white screen time when users perform touch operations such as clicking and swiping on the screen.

[0003] When a user performs a launch operation on an application, such as clicking the application's icon, the software system in the terminal device can receive the corresponding input interrupt event and call the corresponding process and related thread to handle the input interrupt event, so as to display the application's launch animation on the screen and launch the application. At this time, the launch speed can be measured by the duration from the time the application's input interrupt event is received to the time the first frame of the launch animation is displayed; the longer the duration, the slower the launch speed.

[0004] It's understandable that each process or thread requires certain hardware resources, such as processor resources, to run. Therefore, when a terminal device is running the application's startup process and related threads, if the device's load is high, some threads corresponding to that startup operation may have their processor resources preempted by other task processes and / or threads. For example, dependent threads that depend on the critical threads corresponding to that startup operation may have their processor resources preempted due to lower call priority, thus blocking these critical threads and resulting in a slower application startup speed. Summary of the Invention

[0005] This application provides a thread processing method, medium, electronic device, and program product that can improve the response speed of the display screen when an application starts.

[0006] In a first aspect, embodiments of this application provide a thread processing method applied to an electronic device. The method includes: when a first thread calls a second thread through a first calling method, determining whether the first thread and the second thread meet the scheduling identifier passing condition, wherein the second thread is a thread related to the startup animation of a first application; when the scheduling identifier passing condition is met, determining the type of the first calling method; when the type of the first calling method is determined to be a first type, setting a scheduling identifier for the second thread and prohibiting setting a passing depth for the second thread or setting the passing depth of the second thread to the minimum passing depth; when the type of the first calling method is determined to be a second type, setting a scheduling identifier for the second thread and adjusting the passing depth of the second thread according to the passing depth of the first thread, wherein the scheduling priority of the thread with the scheduling identifier set is higher than the scheduling priority of the thread without the scheduling identifier set.

[0007] It's understandable that when passing the scheduling flag in the first type of invocation method, forcing the second thread not to have a passing depth, or forcing it to be set to 0, prevents the second thread from failing to pass the scheduling flag correctly and thus failing to set a higher scheduling priority for it. This ensures that the passing depth of the scheduling flag for each thread is passed correctly, guaranteeing that critical threads and related dependent threads during application startup can set their scheduling flags. This allows these threads to be scheduled for processor resources with higher priority, thereby improving application startup speed.

[0008] In one possible implementation of the first aspect described above, the conditions for passing the scheduling flag include: the thread initiating the call has a scheduling flag set, and the passing depth of the thread initiating the call is less than the maximum passing depth, such as 0. Therefore, if the thread initiating the call, such as the first thread, meets the conditions for passing the scheduling flag, it means that the passing depth of the scheduling flag in the first thread can be passed to other threads.

[0009] In one possible implementation of the first aspect described above, the scheduling flag passing condition further includes: the called thread has a scheduling flag and a passing depth set, and the passing depth is less than the maximum passing depth; or, the called thread has not set a scheduling flag and a passing depth. Therefore, if the called thread, such as the second thread, satisfies the scheduling flag passing condition, it means that the passing depth of the scheduling flag in the second thread can be set.

[0010] In one possible implementation of the first aspect described above, the method further includes: when either the first thread or the second thread does not meet the scheduling flag passing condition, not adjusting the scheduling flag and passing depth of the second thread. In this case, the second thread may be in a runnable state, and the first thread needs to wait for the second thread to enter a runnable state before it can call the second thread, and thus the first thread can run.

[0011] In one possible implementation of the first aspect described above, adjusting the transit depth of the second thread based on the transit depth of the first thread includes: if the second thread has no transit depth set, then incrementing the transit depth of the first thread by 1 to obtain a second depth value, and updating the transit depth of the second thread to the second depth value; if the second thread has a transit depth set to a first depth value, then incrementing the transit depth of the first thread by 1 to obtain a second depth value, and updating the transit depth of the second thread to the maximum value between the first and second depth values, such that the transit depth of the second thread is less than or equal to the maximum transit depth. For example, the minimum transit depth is 0, and the maximum transit depth is 2. This limits the number of times the inter-thread scheduling flag is passed, thereby limiting the number of threads with set scheduling flags, and ensuring that critical threads and dependent threads during application startup can be allocated more processor resources according to higher scheduling priority after their scheduling flags are set.

[0012] In one possible implementation of the first aspect described above, the method further includes: if the type of the first invocation method is the second type, when the second thread is finished being invoked by the first thread, removing the scheduling flag and propagation depth of the second thread, or setting the propagation depth of the second thread to the minimum propagation depth. This ensures that subsequent calls to the second thread by other threads can correctly propagate the scheduling flag to that second thread.

[0013] In one possible implementation of the first aspect described above, the method further includes: when the first process receives the first input event, setting a scheduling flag for the critical thread used to process the first input event and setting the propagation depth to a minimum propagation depth, such as 0. Here, the first input event is the input event corresponding to a user's touch operation on the icon of the first application displayed on the screen, and the first thread is the critical thread, or the first thread is a thread that has lock contention with the critical thread; the second thread is a thread that has a dependency relationship with the critical thread. For example, the first thread and the second thread can be threads related to the startup animation of the first application. Thus, when both the first thread and the second thread have scheduling flags, such as a VIP flag, the response of the first thread and the second thread can be faster, thereby ensuring that the startup animation can respond quickly during the startup of the first application, such as shortening the response time from when the user clicks the icon of the first application to when the screen displays the first frame of the startup animation of the first application.

[0014] In one possible implementation of the first aspect above, the key threads include at least one of the following: the animation processing thread android.anim in the system service systemServer process and the window management thread wmshell in the system user interface systemUI process; the second thread is the animation loading thread AnimationSinkUtil in the launcher process and the display frame rate determination thread (AGP service thread) in the frame rate service process.

[0015] In one possible implementation of the first aspect above, when the first thread is a window management thread, the second thread is a display resource loading thread; when the first thread is a display resource loading thread, the second thread is a display frame rate determination thread.

[0016] In one possible implementation of the first aspect above, the first type is the SHORT type, where the duration of a thread call using the SHORT type is less than or equal to a preset duration; the second type includes at least one of the following: a binder type, or a lock contention type. The lock contention type is also known as a lock type, such as a mutex lock or a read-write lock. The binder type mentioned above can be a synchronization binder type.

[0017] In one possible implementation of the first aspect described above, the method further includes: when the second thread is finished being invoked by the first thread, if the type of the first invocation method is a second type, such as a lock type, then the first thread invokes the second thread through the second invocation method and determines whether the first thread meets the scheduling flag passing condition; if the first thread meets the scheduling flag passing condition, it is determined that the type of the second invocation method is a first type, such as a SHORT type, a scheduling flag is set for the second thread, and no passing depth is set for the second thread or the passing depth is set to the minimum passing depth. Thus, after the first thread invokes the second thread through the first invocation method of the lock type, it can invoke the second thread through the second invocation method of the SHORT type and successfully set the scheduling flag for the second thread, enabling the second thread to provide lock release response information to the first thread according to a higher scheduling priority, allowing the first thread to release the lock for the second thread. This ensures that both the first and second threads run quickly.

[0018] In one possible implementation of the first aspect above, setting a scheduling flag and setting a propagation depth of the key thread used to process the first input event includes: dividing the thread corresponding to the first input event into scheduling groups to obtain a foreground process group; setting a scheduling flag and setting a propagation depth of the minimum foreground process group for each of the at least one third thread used to execute the first input event in the foreground process group (such as the native foreground grouping of the Android system) to add the at least one third thread to a high-level process group, wherein the scheduling priority of the threads in the high-level process group is higher than the scheduling priority of the threads in the foreground process group; determining at least one fourth thread among the threads used to process the first input event that has a dependency relationship with at least one third thread and has a fixed thread name, setting a scheduling flag and setting a propagation depth of the minimum foreground process group for each of the at least one fourth thread to add the at least one fourth thread to the high-level process group.

[0019] Secondly, embodiments of this application provide a readable medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the thread processing method in the first aspect and any possible implementation thereof.

[0020] Thirdly, embodiments of this application provide an electronic device, including: a memory for storing instructions executed by one or more processors of the electronic device, and a processor, one of the processors of the electronic device, for executing the thread processing method in the first aspect and any possible implementation thereof.

[0021] Fourthly, embodiments of this application provide a computer program product that, when run on an electronic device, enables the electronic device to implement the thread processing method in the first aspect and any possible implementation thereof.

[0022] The beneficial effects of the second, third, and fourth aspects can be referred to the relevant descriptions in the first aspect, and will not be repeated here. Attached Figure Description

[0023] Figure 1A A schematic diagram of a display interface on a screen during the application startup process, provided in an embodiment of this application;

[0024] Figure 1B A schematic diagram of a display interface on a screen during the application startup process, provided in an embodiment of this application;

[0025] Figure 1C A schematic diagram of a display interface on a screen during the application startup process, provided in an embodiment of this application;

[0026] Figure 1DA schematic diagram of a display interface on a screen during the application startup process, provided in an embodiment of this application;

[0027] Figure 1E A schematic diagram of a display interface on a screen during the application startup process, provided in an embodiment of this application;

[0028] Figure 1F A schematic diagram of a display interface on a screen during the application startup process, provided in an embodiment of this application;

[0029] Figure 2 A schematic diagram of the response trajectory during the startup process of an application, provided as an embodiment of this application;

[0030] Figure 3 A schematic diagram illustrating the process of transmitting scheduling identifiers between processes, provided as an embodiment of this application;

[0031] Figure 4 A timing diagram illustrating the process invocation method during application startup, provided as an embodiment of this application;

[0032] Figure 5 This is a schematic diagram of a thread invocation scenario under the SHORT type invocation method provided in the embodiments of this application;

[0033] Figure 6 A flowchart illustrating a thread processing method provided in an embodiment of this application;

[0034] Figure 7 A schematic diagram illustrating the process of thread invocation and scheduling identifier passing for the binder type in this application embodiment;

[0035] Figure 8 A flowchart illustrating a thread processing method during application startup provided in an embodiment of this application;

[0036] Figure 9 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0037] The illustrative embodiments of this application include, but are not limited to, thread processing methods, media, electronic devices, and program products.

[0038] To better understand the solutions of this application, the following describes the terminology used in the embodiments of this application.

[0039] 1. Thread: The smallest unit of computation that an operating system can schedule. It is contained within a process and is the actual unit of operation within the process. Multiple threads can run concurrently within a process, and each thread can execute different tasks in parallel.

[0040] 2. Runnable State: Also known as the ready state. Threads in the runnable state reside in the runnable thread pool, waiting to be selected by the thread scheduler to acquire the right to use a processor such as the Central Processing Unit (CPU). In other words, threads in the runnable state have acquired all the resources required for operation except for CPU resources.

[0041] 3. Running State: When a runnable thread acquires CPU resources, its state changes to running. A thread in the running state can execute program code.

[0042] 4. binder

[0043] binder is for Android TM This is an inter-process communication (IPC) mechanism in the Android system. Its core principle is communication through inter-process proxy objects. In Android... TM In the system, each process has a Binder driver used to create and manage Binder objects. These Binder objects are encapsulated within the Binder driver and identified and accessed through Binder references. When one process needs to communicate with another process, it can obtain the Binder object in the other process through the Binder reference and pass messages through this object.

[0044] 5. Locking mechanism

[0045] Locking mechanisms, also known as lock contention, are synchronization mechanisms between processes. Locking mechanisms include mutexes (mutexes) and read-write locks (RWSEMs). A mutex is a synchronization mechanism used to protect shared resources. When a process (or thread) holds a mutex, other processes (or threads) cannot access the shared resource protected by that lock, preventing multiple processes (or threads) from modifying the shared resource simultaneously and thus avoiding data inconsistency problems. Conversely, a read-write lock is a synchronization mechanism that allows multiple processes (or threads) to read a shared resource simultaneously, but only allows one process (or thread) to write to the shared resource at a time.

[0046] When an electronic device (such as a mobile phone) launches an application (APP) icon, if the device's load is high, the critical threads in the application's startup process may become blocked because their dependent threads cannot be allocated hardware resources, resulting in a slow startup speed. Specifically, these dependent threads are in a runnable state because they cannot be allocated application resources, while the critical threads must wait for these dependent threads to complete their execution before they can start running. This blocking of critical threads leads to delays in the application's startup animation response.

[0047] It is understandable that software systems in electronic devices, such as Android, TM The system runs various processes and their associated threads that implement various software functions. Each process or thread requires certain hardware resources, such as processor resources. The utilization rate of processor resources in an electronic device can be called processor load or system load. When the processor load is low, the electronic device has sufficient processor resources to allocate to each process and its associated threads, thus the execution time of each process and its associated threads is short. When the processor load is high, the electronic device cannot provide enough processor resources to allocate to each process and its associated threads, causing processes and / or threads to compete for limited processor resources, resulting in queuing and slow response times, increasing the execution time of each process and its associated threads.

[0048] It's understandable that a processor's susceptibility to high loads is related to its performance. Higher performance processors are less prone to high loads, while lower performance processors are more likely to experience them. Processor performance is determined by the number of physical cores, the architecture of each core, and its base frequency. Generally, with the same architecture and base frequency, more physical cores result in higher performance; similarly, with the same architecture, higher base frequencies lead to higher performance. Furthermore, processor performance is also related to core temperature. Overheating causes cores to reduce their operating frequency, leading to a decrease in processor performance.

[0049] Specifically, when an electronic device receives a user's command to launch an application, it can launch and run the application. Specifically, the electronic device's display screen can show icons for various applications. When a user taps an application's icon, the electronic device can receive an input interrupt event for that operation. In response to this input interrupt event, the electronic device can load the application's launch animation, display the animation, and open the application, such as displaying the application's running interface.

[0050] Reference Figures 1A to 1F The diagram shown illustrates an application scenario where an electronic device launches an application, illustrating the changes in the display interface on the screen during the application launch process.

[0051] like Figure 1A As shown, the electronic device 10 displays a desktop interface that includes applications such as a browser, music player, gallery, and email. The user... Figure 1A After the browser icon 101 shown is clicked, the electronic device 10, in response to the click, can load the browser's startup animation and display the frames of the animation sequentially. For example, in response to the click, the electronic device 10 can... Figure 1B The interface shown displays the first frame image A1 of the browser's startup animation. Subsequently, the electronic device 10 can sequentially display the following on the screen: Figures 1C to 1F Image frames A2 to A5 in the startup animation shown. Figures 1B to 1F The image frames A2 to A5 of the browser's startup animation shown are merely an example. In practical applications, the number of image frames in the application's startup animation can be 19 or 20, or more, to make the display effect of the startup animation smoother. Furthermore, after displaying the browser's startup animation on the screen, the electronic device 10 can display the browser's running interface (not shown).

[0052] In some embodiments, Figures 1A to 1F In the application startup scenario shown, the application startup speed can be measured by the time from when the electronic device 10 receives the user's input interruption event to the browser icon 101 to when the first frame image A1 in the startup animation is displayed.

[0053] In some embodiments, the browser startup process involves input event transmission, system server processes, system UI processes, surface Flinger processes, kernel processes, launcher processes, and other processes within the software system of the electronic device 10. The response time of these processes will affect the application startup speed.

[0054] Reference Figure 2 The image shown is a schematic diagram of the response trajectory during the startup process of an application. Figure 2 As shown, in the user's application on the desktop, such as Figure 1AThe browser's click event, as shown, involves the following processes in sequence: launcher process -> system server process -> system UI process -> launcher process -> AGP service process -> launcher process. Specifically, Figure 2 The animation loading thread (such as AnimationSinkUtil) in the launcher process can call the display frame rate determination thread (such as the AGP service thread, AGPService) in the frame rate service process to obtain the display frame rate of the application's startup animation. The animation display thread (such as onAnimationStart) in the launcher process can then display the application's startup animation based on the obtained display frame rate. However, if the AGP service thread is in a runnable state and cannot be allocated processor resources, this will cause the animation loading thread AnimationSinkUtil and the animation display thread onAnimationStart in the launcher process to be blocked. This results in a longer waiting time before the first frame of the startup animation is displayed during application startup, i.e., a slower startup speed.

[0055] Currently, Android TM The task processing flow categorizes processes and threads into foreground or background process groups. For example, foreground processes and the systemServer process are grouped as foreground processes. During CPU scheduling, processes and threads in the foreground process group can be assigned real-time (RT) tasks or given higher priorities to receive more CPU resources. Conversely, background processes, such as the frame rate service process, are grouped as background processes, and processes and threads in this group are assigned non-real-time tasks or lower priorities. In this case, threads in the foreground process group have a higher scheduling priority than threads in the background process group. However, under high load scenarios, some critical threads that affect user experience depend on other threads. If the dependent threads have low priorities and cannot receive CPU scheduling, it will affect the scheduling of critical threads. For example, during application startup, the AGP thread in the frame rate service process may not receive CPU scheduling, affecting the scheduling of critical threads such as animation loading and animation display threads.

[0056] In some embodiments, this application can set up a high-level process group (or CPU VIP group), and set a scheduling flag (or VIP flag) for the threads or processes in this group, so that the scheduling priority of the threads in the high-level process group is higher than the scheduling priority of the threads in the native Android foreground process group. In this case, compared with the threads in the foreground process group, under completely fair scheduler (CFS) / real-time task (RT) scheduling, if the priorities are the same, the threads in the high-level process group have a higher resource tilt priority or influence core selection, that is, the threads in the high-level process group have a higher scheduling priority.

[0057] In some embodiments, when an electronic device is under high load, a scheduling flag can be set for a critical thread. Furthermore, when a critical thread calls other dependent threads, the scheduling flag of the critical thread can be passed to the dependent threads, making the dependent threads easier to schedule by being flagged for scheduling.

[0058] It is understandable that if too many threads or processes in a software system have scheduling flags set, it will cause almost all threads in the software system to have the same scheduling priority, thus preventing critical threads that require priority scheduling from being scheduled first.

[0059] In some embodiments, to prevent too many threads or processes in the software system from having scheduling flags set, this application can limit the number of times the scheduling flag is passed, such as limiting the number of times the scheduling flag is passed to less than or equal to 2. For example, this application can set a passing depth for threads with scheduling flags set, where the passing depth represents the number of times the scheduling flag has been passed, and set the passing depth to be less than or equal to the maximum passing depth, such as 2.

[0060] In some embodiments, scheduling flag passing conditions can be set, such as: the calling thread sets a scheduling flag and the set passing depth is less than or equal to the maximum passing depth; and the called thread either does not set a scheduling flag and passing depth, or sets a scheduling flag and the passing depth is the minimum passing depth. Therefore, when the first thread and the second thread meet the scheduling flag passing conditions, passing the scheduling flag between the first thread and the second thread is allowed. When the first thread and the second thread meet the scheduling flag passing conditions, passing the scheduling flag between the first thread and the second thread is not allowed. As an example, a minimum passing depth of 0 and a maximum passing depth of 2 will be used for illustration.

[0061] It is understandable that the process of passing the scheduling flag can include enabling and disabling the scheduling flag. Enabling means setting the scheduling flag and the passing depth for the thread. Disabling means removing the scheduling flag and the passing depth for the thread, or, alternatively, setting the scheduling flag to the minimum passing depth (e.g., 0) without removing it.

[0062] Reference Figure 3 The diagram shown is a schematic representation of the process for transmitting scheduling identifiers between processes according to an embodiment of this application. Figure 3 The diagram illustrates the scheduling flags and propagation depth during calls between the launcher process and two other processes, such as the frame rate service process and the systemUI process. It can be understood that thread calls in this application can be cross-process thread calls, and in this case, thread calls can also be represented as calls between processes / threads.

[0063] In some embodiments, the type of inter-thread invocation may include SHORT type, binder type, and lock type (such as mutex lock and read-write lock). The type of thread invocation may affect the enabling and disabling of the thread's scheduling flag.

[0064] Depend on Figure 3 It is known that the calling methods for binder and lock types (mutex and read-write locks) allow the calling thread to enable (vip_enable) or disable the scheduling flag (vip_disable) for the called thread. However, the calling method for SHORT allows the calling thread to enable vip_enable, but not disable vip_disable. This is understandable because the SHORT calling method, due to its short call duration (e.g., 3 milliseconds), cannot remove the propagation depth set for the called thread, thus preventing vip_enable.

[0065] For ease of explanation, the following embodiments can be divided into a first type and a second type of invocation method. The first type is the SHORT type, and the second type includes binder types (such as synchronous binders) and lock types, etc. It can be understood that the first type has a shorter execution time, while the second type has an uncertain execution time.

[0066] Combination Figure 3The process of passing the scheduling flag under the SHORT type invocation method is explained. Specifically, for example, another process of the systemUI process has a scheduling flag set and a passing depth (vip_depth) set to 0. When this other process calls the launcher process using the SHORT type invocation method, it enables vip_enable for the launcher process at the beginning of the call to set the passing depth (vip_depth) of the launcher process to 1. However, when the launcher process finishes the call, this invocation method cannot disable vip_disable, that is, it cannot remove the launcher process's vip_depth. Subsequently, for example, when another process of the systemUI process has a scheduling flag set and a passing depth (vip_depth) set to 0, the launcher process's vip_depth remains 1. At this time, when this other process calls the launcher process using the binder type invocation method (such as synchronous Binder), it enables vip_enable for the launcher process at the beginning of the call to set the vip_depth of the launcher process to 2. At this point, since the launcher process's vip_depth has reached the maximum transmission depth of 2, the launcher process cannot pass the scheduling flag to other processes, such as the frame rate service process.

[0067] Understandable, by Figure 2 It is known that during the application startup process, the launcher process depends on the frame rate service process, such as the AGP service thread within the frame rate service process. If the launcher process cannot correctly pass the scheduling flag to the frame rate service process, it will be unable to set a higher scheduling priority for that frame rate service process. When the electronic device is under high load, the frame rate service process may not be allocated processor resources due to its low scheduling priority, causing it to enter the runnable state, thus blocking the launcher process and slowing down the application startup speed.

[0068] To address the issue of slow application startup caused by the inability to properly transmit thread propagation depth, this application provides a thread processing method that ensures the normal transmission of the scheduling identifier corresponding to the thread. This method guarantees that critical threads and related dependent threads in the application startup process can set scheduling identifiers, enabling these threads to be scheduled for processor resources with higher scheduling priority, thereby improving the application startup speed.

[0069] Specifically, this method first determines whether the initiating thread and the called second thread meet the conditions for passing the scheduling flag, i.e., whether passing the scheduling flag between the first thread and the called second thread is allowed. Then, if the conditions for passing the scheduling flag are met, it can further determine whether the scheduling flag needs to be passed from the first thread to the second thread based on the type of invocation, and how to adjust the passing depth of the second thread when setting the scheduling flag for it. It can be understood that first-type invocation methods, such as SHORT, cannot clear the passing depth of the scheduling flag corresponding to the thread, while second-type invocation methods, such as binder and lock types, can clear the passing depth of the scheduling flag corresponding to the thread. Therefore, when the invocation method is determined to be of the second type, the passing depth of the second thread can be adjusted based on the passing depth of the first thread. Conversely, when the invocation method is determined to be of the first type, a scheduling flag can be set for the second thread, and setting the passing depth for the second thread can be prohibited or set to the minimum passing depth. Thus, when passing the scheduling flag in the first type of invocation method, by forcibly not setting a passing depth for the called second thread, or forcibly setting the passing depth to 0, the situation where the scheduling flag cannot be passed to the second thread normally, thus preventing the second thread from being set with a higher scheduling priority, can be avoided. This, in turn, helps to improve the problem of the second thread blocking the first thread, improving the application's startup speed.

[0070] Combination Figure 2 The process response trajectory shown during the application startup process and Figure 3 The scheduling identifier transmission process shown is referenced. Figure 4 The diagram shown is a sequence diagram illustrating the call methods of each process during application startup. Figure 4 As shown, this timing diagram includes the following steps:

[0071] Step 1: The launcher process calls the deliverinput thread to receive input events triggered by the user's click on the application icon, such as when the user presses the icon on the screen. The deliverinput thread is used to process user input such as click events.

[0072] Step 2: The launcher process calls the startActivity thread, which in turn calls the internal startActivityInner sub-thread in the systemServer process to launch the application, such as creating the application's main activity (MainActivity). For example, the launcher process can use the binder mechanism to call the startActivityInner() method in the systemServer process across processes.

[0073] Step 3: The systemServer process calls the addStartingWindow, doFrame, and finishDrawing threads in the systemUI process to draw the frames of the application's startup animation.

[0074] Step 4: The systemServer process calls the activityPause thread to put the application's Activity into a paused state, such as when the user's finger leaves the screen and the click operation on the icon ends.

[0075] Step 5: The activity pause (activityPause) in the systemServer process calls the setReady method to set the application's Activity to the setReady state.

[0076] Step 6: The systemServer process calls the Traverser thread, which in turn calls the AppTransitionReady sub-thread to determine that the relevant resources for the application's startup animation are ready, and calls the performSurfacePlacement sub-thread to determine the display window layout for the application's startup animation.

[0077] Step 7: The systemServer process calls the animation processing thread (android.anim), and based on the android.anim thread, it calls the window management thread (wmshell.main, i.e., the wmshell thread) in the systemUI process to call the corresponding processing function to update the state and attributes of the display window.

[0078] Step 8: The wmshell thread in the systemServer process calls the animation loading thread (AnimationSinkUtil) in the launcher process to load the resources related to the application's startup animation.

[0079] Step 9: The animation loading thread (AnimationSinkUtil) in the launcher process calls the AGP service thread in the frame rate service process to determine the rendering frame rate of the application's startup animation.

[0080] Step 10: The launcher process calls the animation display thread (onAnimationStart) to display the application's startup animation on the screen, that is, to display the first frame image, the second frame image, etc. in the startup animation in sequence.

[0081] In some embodiments, when a user clicks on an application icon on a display screen, the software system in the electronic device can receive the corresponding click input event and classify these threads into native foreground process groups and background process groups based on the priority of the threads corresponding to the click input event. For example, some key threads in the foreground process and systemServer process corresponding to the click input event can be assigned to the foreground process group, such as the deliverinput thread. Subsequently, some key threads in the foreground process corresponding to the click input event, such as the deliverinput thread, can be reloaded to the high-level process group, i.e., a scheduling flag and a minimum delivery depth (e.g., 0) are set for these key threads to ensure that these threads have a high scheduling priority. As an example, the scheduling flag set for these key threads can be long-term.

[0082] Furthermore, the key threads corresponding to the aforementioned click input events within the advanced process group can be identified, and these key threads, which have dependencies and fixed thread names, can be further classified. Figure 4The `android.anim` and `wmshell.main` threads, as shown, are overloaded into a higher-level process group. This means that a scheduling flag and initial delivery depth (e.g., 0) are set for these dependent threads. It's understandable that some threads have fixed thread names, and each fixed name uniquely identifies a thread; therefore, different fixed thread names can be used to distinguish these threads. Specifically, the `android.anim` thread has the fixed thread name `SystemServer:android.anim`, and the `wmshell.main` thread has the fixed thread name `SystemUI:wmshell.main`. In this case, these threads can be identified by their thread names, and scheduling flags and delivery depths can be set for them. As an example, the scheduling flag set for these dependent threads with fixed thread names can be long-term.

[0083] In addition, some threads do not have fixed thread names, for example Figure 4 The AGP service thread and animation loading thread AnimationSinkUtil shown are unknown threads. These threads can have their scheduling flags and propagation depths passed by the calling thread when they are invoked, thus enabling the setting of these flags and depths. Furthermore, the scheduling flags set by these unknown threads can be short-lived; they are set when these threads are invoked and removed after the invocation is complete. Additionally, the propagation depth is less than or equal to a preset scheduling flag, such as 2, to limit the number of times the scheduling flag is propagated.

[0084] As an example, in Figure 4 In steps ⑦, ⑧, and ⑨ shown, after the wmshell thread of the systemUI process has its scheduling flag set and its pass depth set to 0, the wmshell thread can call the animation loading thread AnimationSinkUtil of the launcher process, passing the scheduling flag to AnimationSinkUtil and setting the corresponding pass depth to 1. Subsequently, when the animation loading thread AnimationSinkUtil of the launcher process calls the APG service thread, if it cannot pass the scheduling flag to the APG service thread, the APG service thread will become runnable, blocking critical threads such as the animation loading thread AnimationSinkUtil, thus resulting in a slow application startup speed.

[0085] Combination Figure 3The process of passing the scheduling identifier under the read-write lock type invocation method is explained. Specifically, for example, another process of the systemUI process has a VIP identifier and a passing depth (vip_depth) set to 0. When this other process calls the launcher process using the read-write lock type invocation method, it first enables the launcher process with `vip_enable` and sets the passing depth (vip_depth) to 1. Subsequently, when the launcher process calls the frame rate service process using the read-write lock type invocation method, it enables the frame rate service process with `vip_enable` and sets the frame rate service process with `vip_depth` to 2 at the beginning of the call; and at the end of the call, it disables the frame rate service process with `vip_disable` to remove the VIP identifier and `vip_depth`. In addition, when the launcher process call ends, the systemUI process can disable the launcher process with `vip_disable` to remove the VIP identifier and `vip_depth`.

[0086] As an example, combined Figure 4 The process shown in steps ⑦, ⑧, and ⑨, Figure 3 The call flow between the launcher process and other processes specifically includes the wmshell thread of the systemUI process calling the animation loading thread AnimationSinkUtil of the launcher process, and the animation loading thread AnimationSinkUtil of the launcher process calling the AGP service thread. Therefore, in steps ⑦, ⑧, and ⑨, the VIP identifier passing process includes: the systemUI process setting the VIP identifier and setting vip_depth = 0; passing it to the Launcher process, causing the Launcher process to set the VIP identifier and set vip_depth = 1; and passing it to the AGP service thread, causing the AGP service thread to set the VIP identifier and set vip_depth = 2.

[0087] When passing the VIP identifier (i.e., scheduling identifier) ​​using the SHORT call method, because the process call time is very short, such as 3ms, after enabling `vip_enable` on the thread, `vip_disable` is not performed. Therefore, the passing depth `vip_depth` of the called thread is still retained. As an example, combined with... Figure 3 and Figure 4 As the example shows, when a child thread of the launcher process executes a SHORT-type call, it may retain a pass depth of 1 or 2.

[0088] In some embodiments, when the launcher process is passed a scheduling flag by a SHORT-type invocation method with a passing depth of 1, if the initiating thread and the called thread do not meet the scheduling flag passing conditions, the launcher process cannot pass the scheduling flag to other processes or threads. Additionally, when the launcher process is passed a scheduling flag by a SHORT-type invocation method with a passing depth of 2, the launcher process cannot pass the scheduling flag to other processes or threads.

[0089] In some embodiments, the calling method of the thread or process in this application can be a specific thread or object. For example, the calling method of the lock type can be called a lock, and the calling method of the binder type can be called a binder object or thread.

[0090] Reference Figure 5 The diagram illustrates a thread call scenario using a SHORT-type call method. For example, thread B in the launcher process, such as the animation loading thread AnimationSinkUtil, might be called by thread A in another process via a lock. Thread A can send a lock acquisition request to thread B. Upon receiving a lock acquisition response from thread B, thread A determines that it has successfully acquired the lock (lockacquired) from thread B. Then, while thread A has acquired the lock from thread B, it can call thread B using a read-write lock type call (e.g., lock1) to enable thread B's scheduling flag (vip_enable). When thread A's call to thread B ends, i.e., when thread B finishes execution, thread A can disable thread B's scheduling flag (vip_disable) and send a lock release request to thread B. Upon receiving this lock release request, because thread B has not set a scheduling flag at this point, its scheduling priority may be low, potentially preventing thread B from scheduling processor resources to return a lock release response to thread A. Therefore, in order for thread A to receive the lock release response returned by thread B, after enabling the scheduling flag of thread B, thread A can call thread B again through the SHORT type method. This allows thread A to enable the scheduling flag of thread B again, so that thread B can quickly return the lock release response to thread A based on the higher scheduling priority, thus enabling thread A to release the lock on thread B.

[0091] Furthermore, this application is in Figure 5 In the example shown, when thread A schedules thread B using the SHORT type call method, when enabling the scheduling flag for thread B, it is possible to force thread B not to set a transit depth or to set the transit depth to the minimum transit depth, such as 0, while setting the scheduling flag for thread B.

[0092] Reference Figure 6 The diagram shown is a flowchart of a thread processing method provided in an embodiment of this application. The method includes the following steps:

[0093] S601: When the first thread calls the second thread through the first calling method, query the scheduling identifier and transit depth of the first thread and the scheduling identifier and transit depth of the second thread.

[0094] In some embodiments, when the first process receives a first input event from a user's finger on the icon of the first application displayed on the screen, it sets a scheduling flag for the critical thread used to process the first input event and sets the propagation depth to the minimum propagation depth, and the critical thread has the scheduling flag set for a long time.

[0095] The first thread is the critical thread, such as the window management thread WMshell during application startup. Alternatively, the first thread is a thread that has lock contention with the critical thread, such as thread A mentioned above.

[0096] In some embodiments, the second thread is a thread that depends on the critical thread, such as a thread related to the startup animation of the first application. For example, the second thread could be the animation loading thread AnimationSinkUtil in the launcher process or the display frame rate determination thread (i.e., the AGP service thread) in the frame rate service process.

[0097] S602: Determine whether the first thread and the second thread meet the conditions for passing the scheduling flag.

[0098] If it is determined that the conditions for transmitting the scheduling identifier are met, then proceed to S603.

[0099] If the scheduling flag passing condition is met, the process ends. It can be understood that if either the first thread or the second thread does not meet the scheduling flag passing condition, the scheduling flag and call depth of the second thread are not adjusted. In this case, the second thread waits for the scheduler's resources.

[0100] S603: When the scheduling identifier transmission condition is met, determine whether the type of the first invocation method is the first type.

[0101] If the type of the first invocation method is determined to be the first type, i.e., the SHORT type, then proceed to S604; if the type of the first invocation method is determined to be not the first type but the second type, such as the binder type, then proceed to S605.

[0102] S604: When the type of the first invocation method is determined to be the first type, set the scheduling flag for the second thread and prohibit setting the transit depth for the second thread or set the transit depth of the second thread to the minimum transit depth.

[0103] That is, it intercepts the calculation logic of the transmission depth of the scheduling identifier in the SHORT type call method.

[0104] S605: When it is determined that the type of the first invocation method is the second type, a scheduling flag is set for the second thread, and the transit depth of the second thread is adjusted according to the transit depth of the first thread.

[0105] In some embodiments, when the scheduling flag transmission condition is met, the process of adjusting the transmission depth of the second thread includes: if the second thread does not have a transmission depth set, then the transmission depth of the first thread is incremented by 1 to obtain a second depth value, and the transmission depth of the second thread is updated to the second depth value. For example, if it is found that the first thread has a scheduling flag set and a transmission depth of 1, and it is found that the second thread has a scheduling flag set but no transmission depth set, since the transmission depth of the first thread plus 1 equals 2, the transmission depth of the scheduling flag of the second thread can be set to 2.

[0106] In some embodiments, when the scheduling identifier transmission condition is met, the process of adjusting the transmission depth of the second thread includes: if the second thread has a transmission depth of a first depth value, then the transmission depth of the first thread is increased by 1 to obtain a second depth value, and the transmission depth of the second thread is updated to the maximum value between the first depth value and the second depth value. For example, after querying that the first thread has a scheduling identifier and a transmission depth of 1, and querying that the second thread has a scheduling identifier and a transmission depth of 1, since the sum of the transmission depths of the first thread plus 1 is 2, and this sum is greater than the queryed transmission depth of the second thread, the transmission depth of the scheduling identifier of the second thread can be set to this sum, i.e., 2.

[0107] In some embodiments, S603 to S605 described above can be a process of enabling a scheduling flag for the second thread. For example, this process can be performed by a scheduling flag enabling function (such as the vip_enable function).

[0108] In other embodiments, when the first thread calls the second thread through the first invocation method, the scheduling flag and propagation depth of the first thread can be queried first, and then it can be determined whether the first thread meets the scheduling flag propagation condition. That is, it can be determined whether the propagation depth corresponding to the scheduling flag set by the first thread is less than the maximum propagation depth, such as 2. After determining that the first thread meets the scheduling flag propagation condition, when the scheduling flag enable function is used, the scheduling flag and propagation depth of the second thread are queried again, and then the scheduling flag is enabled for the second thread.

[0109] S606: When the first thread finishes calling the second thread through the first call method of the second type, remove the scheduling flag and pass depth from the second thread.

[0110] In some embodiments, S606 described above can be a process of enabling the scheduling flag of the second thread. For example, this process can be performed by a scheduling flag de-enabling function (such as the vip_disable function).

[0111] In some embodiments, Figure 6 The thread processing method shown can be executed by the calling thread corresponding to the first calling method, such as the binder calling thread, but is not limited to this.

[0112] Thus, this application can correctly pass the scheduling flag and corresponding passing depth between threads when making thread calls under various types of calling methods, so as to ensure that the critical threads and related dependent threads in the application startup process can set the scheduling flag to set a higher scheduling priority, thereby helping to shorten the application startup response time.

[0113] Reference Figure 7 This section explains the process of thread invocation and scheduling flag passing for the binder type.

[0114] S701: The calling thread of type binder determines whether the thread initiating the call has set a scheduling flag.

[0115] This involves checking whether the current thread is a thread in a high-level process group.

[0116] If the thread initiating the call has a scheduling flag set, then proceed to S702.

[0117] If the thread initiating the call does not have a scheduling flag set, the process ends.

[0118] S702: The calling thread of the binder type determines whether the propagation depth of the thread initiating the call is less than the maximum propagation depth. That is, it determines whether the vip_depth of the thread is less than 2.

[0119] S703: The calling thread of type binder enables the scheduling flag of the called thread using the scheduling flag enable function.

[0120] As an example, the scheduling flag enable function can query the scheduling flag and pass depth of the called thread, such as the second thread, and query the type of the currently calling thread, such as the binder type, in order to adjust the scheduling flag and pass depth of the called thread.

[0121] It is understandable that during the process of passing the scheduling flag by the calling thread of the binder type, the calling thread (denoted as curr) sets the scheduling flag for the calling thread (denoted as target).

[0122] In some embodiments, when a Binder calling thread makes a thread call, the calling thread is variable; it could be the thread initiating the call or the thread being called. Therefore, there are cases where the calling thread (curr) and the called thread (target) of the Binder calling thread are the same, i.e., curr == target. It can be understood that in the Binder mechanism, if the client initiates a call and the server has no idle threads to handle it, the client thread will be added to the server-side thread pool. Therefore, the calling thread is also the called thread.

[0123] Specifically, when adjusting the pass depth, the maximum value between the pass depth of the called thread and the pass depth of the called thread plus 1 is taken as the pass depth of the called thread.

[0124] As an example, combined Figure 3 For example, when a thread in the launcher thread, such as the animation loading thread AnimationSinkUtil, has its scheduling flag set and its propagation depth set to 1 by a SHORT-type call, and the systemUI process calls the launcher process via the binder caller process (i.e., when the scheduling flag is passed through the binder scheduling thread), if it is determined that the caller thread and the callee thread are different (curr != target), then the propagation depth vip_depth of the child thread in the launcher process is set to 1; if it is determined that the caller thread and the callee thread are the same (curr == target), then the propagation depth vip_depth of the child thread in the launcher process is set to 2, and the scheduling flag of the child thread in the launcher process can no longer be propagated.

[0125] In addition, in some other embodiments, the following steps are included before S701: the binder calling thread executes the binder_transaction_priority method, executes the trace_android_vh_binder_set_priority method, and executes the binder_set_priority_hook method.

[0126] For example, the `binder_transaction_priority` method can be executed to obtain the priority of the thread that initiated the call, such as the first thread. It can be understood that the priority represented by the `binder_transaction_priority` method can indicate the priority of hardware resources such as scheduling processor resources.

[0127] For example, the `trace_android_vh_binder_set_priority` method can be executed to obtain a log record of the priority of the thread that initiated the call. This method can be used to obtain a trace point or log point for monitoring or recording operations related to binder priority settings in the Android virtual layer, thus helping developers or system analysts understand changes in binder priority.

[0128] For example, the binder calling thread uses the `binder_set_priority_hook` method to extend or modify the priority setting process of the initiating thread. This method is a hook function that allows developers or the system to insert custom logic during the binder priority setting process. Hook functions are typically used to extend or modify existing functionality without directly modifying the original code.

[0129] Reference Figure 8 The diagram shown is a flowchart illustrating the thread processing method during application startup provided in an embodiment of this application. This method combines... Figure 4 and Figure 5 This example illustrates the process of passing the scheduling identifier during application startup. The method includes the following steps:

[0130] S801: When the launcher process receives the first input event from the user's finger on the icon of the first application displayed on the screen, the scheduling flag is set for the critical thread used to handle the first input event and the delivery depth is set to the minimum delivery depth.

[0131] Among them, critical threads have a scheduling flag set for an extended period of time.

[0132] For example, the launcher process sets a long-term scheduling flag for the deliveryinput thread and sets the delivery depth to 0. For example, the first application is... Figure 1A In the browser shown, the click input event is the input interruption event corresponding to click operation 101.

[0133] S802: During the process of thread A in the systemUI process calling the animation loading thread AnimationSinkUtil in the launcher process through a lock-type call, it was found that thread A has set a scheduling flag and a propagation depth of 1, while it was found that the animation loading thread AnimationSinkUtil has not set a scheduling flag or a propagation depth.

[0134] S803: Determine that the scheduling flag transmission condition is met, set the scheduling flag for the animation loading thread AnimationSinkUtil, and set the transmission depth to 2.

[0135] Among them, the thread A that initiated the call has a transmission depth of 1, which is less than the maximum transmission depth of 2, and the AnimationSinkUtil that was called did not have a transmission depth set, so the condition for transmission of the scheduling identifier is met.

[0136] S804: When thread A finishes calling the animation loading thread AnimationSinkUtil, remove the scheduling flag and pass depth for the animation loading thread AnimationSinkUtil.

[0137] S805: During the process of thread A calling the animation loading thread AnimationSinkUtil in the launcher process via the SHORT type call method, it is found that thread A has set a scheduling flag and the passing depth is 0, while it is found that the animation loading thread AnimationSinkUtil has not set a scheduling flag and the passing depth.

[0138] S806: Determine that the scheduling flag transmission condition is met, set the scheduling flag for the animation loading thread AnimationSinkUtil, and set the transmission depth to 0.

[0139] S807: During the process of the window management thread wmshell in the systemUI process calling the animation loading thread AnimationSinkUtil in the launcher process through the binder type call method, it was found that the window management thread wmshell has a scheduling flag set and the propagation depth is 0, while the animation loading thread AnimationSinkUtil has no scheduling flag set and no propagation depth set.

[0140] S808: Determine that the scheduling flag transmission condition is met, set the scheduling flag for the animation loading thread AnimationSinkUtil, and set the transmission depth to 1.

[0141] S809: When the window management thread wmshell finishes calling the animation loading thread AnimationSinkUtil, remove the scheduling flag and pass depth for the animation loading thread AnimationSinkUtil.

[0142] S810: During the process of the launcher process's animation loading thread AnimationSinkUtil calling the AGP service thread in the frame rate service process via a binder-type call, it was found that the animation loading thread AnimationSinkUtil had a scheduling flag set and a pass depth of 1, while the AGP service thread had no scheduling flag set and no pass depth set.

[0143] S811: Determine that the conditions for passing the scheduling identifier are met, set the scheduling identifier for the AGP service thread, and set the passing depth to 2.

[0144] Among them, the transmission depth of the animation loading thread AnimationSinkUtil that initiated the call is depth 1, which is less than the maximum transmission depth 2, while the AGP service thread being called has no transmission depth set, thus satisfying the scheduling identifier transmission condition.

[0145] S812: When the AnimationSinkUtil thread finishes calling the AGP service thread, remove the scheduling flag and pass depth for the AGP service thread.

[0146] S813: The AnimationSinkUtil thread calls back the onAnimationStart thread to display the startup animation of the first application on the screen.

[0147] This ensures that during application startup, critical threads and dependent threads in the systemUI process, launcher process, and frame rate service process can set scheduling flags and propagation depths correctly, which helps improve application startup speed, specifically by improving the response speed of the first frame of the application's startup animation.

[0148] Furthermore, in some embodiments, the thread processing method described in this application can be applied to the user's response to other input events on the display screen, such as the response to an input event generated by clicking the HOME button. By setting scheduling flags and correct propagation depths for the critical thread and dependent thread corresponding to the input event, the scheduling priority of these threads can be increased, thereby shortening the response time.

[0149] In some embodiments, this application applies to electronic devices including displays. For example, such electronic devices include, but are not limited to, mobile stations (MS) and mobile terminals (MT). Examples of electronic devices include mobile phones, smart TVs, wearable devices, tablets, desktop computers, laptops, virtual reality (VR) devices, augmented reality (AR) devices, terminals in industrial control, self-driving, remote medical surgery, smart grids, transportation safety, smart cities, smart homes, and so on. This application does not limit the specific form of the electronic device.

[0150] Next, the hardware structure of the electronic device to which the thread processing method provided in the embodiments of this application is applicable will be described. Specifically, refer to... Figure 9 Taking a mobile phone as an example, this paper explains the hardware structure of electronic devices.

[0151] like Figure 9 As shown, the mobile phone 10 may include a processor 110, a power module 140, a memory 180, a mobile communication module 130, a wireless communication module 120, a sensor module 190, an audio module 150, a camera 170, an interface module 160, buttons 101, and a display screen 102, etc.

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

[0153] Processor 110 may include one or more processing units, such as processing modules or processing circuits of a central processing unit (CPU), graphics processing unit (GPU), digital signal processor (DSP), microprocessor (MCU), artificial intelligence (AI) processor, or field programmable gate array (FPGA). Different processing units may be independent devices or integrated within one or more processors. Processor 110 may include storage units for storing instructions and data. In some embodiments, the storage unit in processor 110 is a cache memory 180. For example, the cache memory 180 may be used to store data such as the application's startup animation. Specifically, in response to a user's click event on the application's icon, processor 110 may set scheduling flags and propagation depths for the critical thread and related dependent threads corresponding to the event.

[0154] The power module 140 may include a power supply, a power management component, etc. The power supply may be a battery. The power management component is used to manage the charging of the power supply and the power supply to other modules. In some embodiments, the power management component includes a charging management module and a power management module. The charging management module is used to receive charging input from a charger; the power management module is used to connect the power supply and the processor 110. The power management module receives input from the power supply and / or the charging management module to supply power to the processor 110, the display screen 102, the camera 170, and the wireless communication module 120, etc. For example, the display screen 102 is used to display the desktop interface and the application's startup animation and running interface, and the display screen 102 can receive user touch operations such as click operations and swipe operations.

[0155] The mobile communication module 130 may include, but is not limited to, an antenna, a power amplifier, a filter, and a low-noise amplifier (LNA). The mobile communication module 130 can provide wireless communication solutions, including 2G / 3G / 4G / 5G, for use on the mobile phone 10. The mobile communication module 130 can receive electromagnetic waves via the antenna, filter and amplify the received electromagnetic waves, and then transmit them to a modem processor for demodulation. The mobile communication module 130 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via the antenna. In some embodiments, at least some functional modules of the mobile communication module 130 may be housed in the processor 110. In some embodiments, at least some functional modules of the mobile communication module 130 and at least some modules of the processor 110 may be housed in the same device. Wireless communication technologies can include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wide Band Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Longer Mevolution (LTE), Bluetooth (BT), Global Navigation Satellite System (GNSS), Wireless Local Area Networks (WLAN), Near Field Communication (NFC), Frequency Modulation (FM) and / or Field Communication (NFC), Infrared (IR) technology, etc.The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0156] The wireless communication module 120 may include an antenna, which enables the transmission and reception of electromagnetic waves. The wireless communication module 120 can provide solutions for wireless communication applications on the mobile phone 10, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The mobile phone 10 can communicate with networks and other devices through wireless communication technologies.

[0157] In some embodiments, the mobile communication module 130 and the wireless communication module 120 of the mobile phone 10 may also be located in the same module.

[0158] The display screen 102 is used to display human-computer interaction interfaces, images, videos, etc. The display screen 102 includes a display panel. The display panel can be a liquid crystal display (LCD), an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a MiniLED, a MicroLED, a Micro-OLED, a quantum dot light-emitting diode (QLED), etc.

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

[0160] The audio module 150 is used to convert digital audio information into analog audio signals for output, or to convert analog audio input into digital audio signals. The audio module 150 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 150 may be located in the processor 110, or some functional modules of the audio module 150 may be located in the processor 110. In some embodiments, the audio module 150 may include a speaker, a handset, a microphone, and a headphone jack.

[0161] Camera 170 is used to capture still images or videos. An object passes through the lens to generate an optical image that is projected onto a photosensitive element. The photosensitive element converts the light signal into an electrical signal, which is then passed to image signal processing (ISP) to be converted into a digital image signal. Mobile phone 10 can achieve its shooting function through ISP, camera 170, video codec, graphics processing unit (GPU), display 102, and application processor.

[0162] Interface module 160 includes an external memory interface, a universal serial bus (USB) interface, and a subscriber identification module (SIM) card interface. The external memory interface can be used to connect an external memory card, such as a microSD card, to expand the storage capacity of the mobile phone 10. The external memory card communicates with the processor 110 through the external memory interface to perform data storage. The USB interface is used for communication between the mobile phone 10 and other electronic devices. The SIM card interface is used to communicate with the SIM card installed in the mobile phone 10, for example, to read or write phone numbers stored in the SIM card.

[0163] In some embodiments, the mobile phone 10 further includes buttons 101, a motor, and indicators. The buttons 101 may include volume buttons, a power button, etc. The motor is used to generate a vibration effect in the mobile phone 10, for example, vibrating when the user's mobile phone 10 is called to prompt the user to answer the call. The indicators may include laser indicators, radio frequency indicators, LED indicators, etc.

[0164] In some embodiments, this application provides a readable medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the thread processing method described above.

[0165] In some embodiments, this application provides an electronic device, including: a memory for storing instructions executed by one or more processors of the electronic device, and a processor, one of the processors of the electronic device, for executing the thread processing method described above.

[0166] In some embodiments, this application provides a computer program product including instructions for implementing the thread processing method described above.

[0167] The various embodiments of the mechanisms disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. Embodiments of this application can be implemented as computer programs or program code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0168] Program code can be applied to input instructions to execute the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0169] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this application are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0170] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored thereon on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other propagation signals. Therefore, machine-readable media include any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0171] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0172] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0173] It should be noted that in the examples and description of this patent, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0174] Although this application has been illustrated and described with reference to certain preferred embodiments thereof, those skilled in the art should understand that various changes in form and detail may be made thereto without departing from the spirit and scope of this application.

Claims

1. A thread processing method, characterized in that, Applied to electronic devices, the method includes: When the first thread calls the second thread through the first calling method, it is determined whether the first thread and the second thread meet the scheduling identifier passing condition, wherein the second thread is the thread related to the startup animation of the first application; When the scheduling identifier transmission condition is met, the type of the first invocation method is determined; When it is determined that the type of the first invocation method is the first type, a scheduling flag is set for the second thread, and setting the transit depth for the second thread is prohibited or the transit depth of the second thread is set to the minimum transit depth. When it is determined that the type of the first invocation method is the second type, a scheduling flag is set for the second thread, and the transit depth of the second thread is adjusted according to the transit depth of the first thread, wherein, The scheduling priority of a thread with the aforementioned scheduling flag is higher than that of a thread without the aforementioned scheduling flag.

2. The method according to claim 1, characterized in that, The conditions for passing the scheduling identifier include: the thread initiating the call has a scheduling identifier set, and the passing depth of the thread initiating the call is less than the maximum passing depth.

3. The method according to claim 2, characterized in that, The conditions for passing the scheduling identifier also include: the called thread has a scheduling identifier and a passing depth and the passing depth is less than the maximum passing depth, or the called thread has not set a scheduling identifier and a passing depth.

4. The method according to claim 1, characterized in that, The method further includes: If the first thread or the second thread does not meet the scheduling identifier passing condition, the scheduling identifier and passing depth of the second thread will not be adjusted.

5. The method according to claim 1, characterized in that, The step of adjusting the transmission depth of the second thread based on the transmission depth of the first thread includes: If the second thread does not have a propagation depth set, then the propagation depth of the first thread is incremented by 1 to obtain the second depth value, and the propagation depth of the second thread is updated to the second depth value. If the second thread has a transmission depth of a first depth value, then the transmission depth of the first thread is increased by 1 to obtain a second depth value, and the transmission depth of the second thread is updated to the maximum value between the first depth value and the second depth value, so that the transmission depth of the second thread is less than or equal to the maximum transmission depth.

6. The method according to claim 1, characterized in that, The method further includes: If the type of the first invocation method is the second type, when the second thread is finished being invoked by the first thread, remove the scheduling flag and transit depth of the second thread, or set the transit depth of the second thread to the minimum transit depth.

7. The method according to claim 1, characterized in that, The method further includes: When the first process receives the first input event, a scheduling flag is set for the critical thread used to process the first input event, and the propagation depth is set to the minimum propagation depth. The first input event is the input event corresponding to a user's touch operation on the icon of the first application displayed on the screen. The first thread is the critical thread, or the first thread is a thread that has lock contention with the critical thread; The second thread is a thread that has a dependency relationship with the key thread.

8. The method according to claim 7, characterized in that, The critical threads include at least one of the following: the animation processing thread in the system service process and the window management thread in the system user interface process; The second thread is the animation loading thread in the launcher process and the display frame rate determination thread in the frame rate service process.

9. The method according to claim 8, characterized in that, When the first thread is the window management thread, the second thread is the display resource loading thread; While the first thread is the display resource loading thread, the second thread is the display frame rate determination thread.

10. The method according to any one of claims 1 to 9, characterized in that, The first type is the SHORT type, and the duration of the thread call in the SHORT type is less than or equal to the preset duration; The second type includes at least one of the following: binder type, lock contention type.

11. The method according to any one of claims 1 to 10, characterized in that, The method further includes: When the second thread is finished being invoked by the first thread, if the type of the first invocation method is the second type, then the first thread invokes the second thread through the second invocation method and determines whether the first thread meets the scheduling identifier passing condition. When the first thread meets the scheduling identifier passing condition, the type of the second calling method is determined to be the first type, the scheduling identifier is set for the second thread, and the passing depth is not set for the second thread or the passing depth is set to the minimum passing depth.

12. The method according to claim 7, characterized in that, The step of setting a scheduling flag and setting the delivery depth to the minimum delivery depth for the key thread used to process the first input event includes: The threads corresponding to the first input event are divided into scheduling groups to obtain foreground process groups; A scheduling flag is set for each of the at least one third thread in the foreground process group that is used to execute the first input event, and the delivery depth is set to the minimum delivery depth, so as to add the at least one third thread to the advanced process group, wherein the scheduling priority of the threads in the advanced process group is higher than the scheduling priority of the threads in the foreground process group. Identify at least one fourth thread among the threads used to process the first input event that has a dependency relationship with the at least one third thread and has a fixed thread name. Set a scheduling flag for each of the at least one fourth thread and set the delivery depth to the minimum delivery depth to add the at least one fourth thread to the advanced process group.

13. A readable medium, characterized in that, The readable medium stores instructions that, when executed on an electronic device, cause the electronic device to perform the thread processing method according to any one of claims 1 to 12.

14. An electronic device, characterized in that, include: A memory for storing instructions executed by one or more processors of an electronic device, and a processor, one of the processors of the electronic device, for executing the thread processing method of any one of claims 1 to 12.

15. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to implement the thread processing method according to any one of claims 1 to 12.

Images