Thread identification method and apparatus, device, storage medium, and program product

Abstract

The present application relates to the technical field of communications, and discloses a thread identification method and apparatus, a device, a storage medium, and a program product. The method comprises: acquiring a first wake-up relationship between a plurality of threads and a first thread that are comprised in an application process; obtaining a relationship path of the first thread on the basis of the first thread and the first wake-up relationship, one node on the relationship path corresponding to a thread in the application process, a wake-up relationship existing between two adjacent nodes on the relationship path, and a head node and a tail node of the relationship path corresponding to the first thread; and identifying a second thread by means of the relationship path, the second thread being located on the relationship path and differing from the first thread. In the method, the relationship path in which both the head node and the tail node correspond to the first thread is obtained by means of the first wake-up relationship, so that the relationship path indicates a complete wake-up chain of the first thread from waking up other threads to being woken up. Therefore, the second thread identified by means of the relationship path is more comprehensive, improving the thread identification capability.

Description

Thread identification methods, devices, equipment, storage media, and program products

[0001] This application claims priority to Chinese Patent Application No. 202411530677.6, filed on October 30, 2024, entitled “Thread Identification Method, Apparatus, Device, Storage Medium and Program Product”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, and in particular to thread identification methods, apparatus, devices, storage media, and program products. Background Technology

[0003] In an operating system, an instance of a running application is a process, and a process includes one or more threads. Threads within the same process share the process's resources. The operating system allocates and schedules resources for each thread, and different threads within a process have dependencies on each other. Specifically, two threads may have a wake-up relationship. The execution of the first thread's task is determined by the second thread's execution result, and the first thread's task depends on the second thread's result. If the second thread fails to complete its task in time, the first thread will be blocked. Therefore, to ensure that the first thread does not become blocked, it is necessary to ensure that the second thread, on which the first thread depends, completes its task in a timely manner, which requires identifying the second thread. Summary of the Invention

[0004] This application provides a thread identification method, apparatus, device, storage medium, and program product for identifying a second thread on which a first thread depends.

[0005] In a first aspect, a thread identification method is provided, which includes: obtaining a first wake-up relationship and a first thread among multiple threads included in an application process, wherein the first thread is a thread in the application process; obtaining a relationship path of the first thread based on the first thread and the first wake-up relationship, wherein a node on the relationship path corresponds to a thread in the application process, a wake-up relationship exists between two adjacent nodes on the relationship path, and the head node and tail node of the relationship path correspond to the first thread; and identifying a second thread through the relationship path, wherein the second thread is located on the relationship path and is different from the first thread.

[0006] This method obtains a relationship path where both the head node and the tail node are the first thread through the first wake-up relationship. This relationship path indicates the complete wake-up chain from the first thread waking up other threads to being woken up. Therefore, the second thread identified through this relationship path is more comprehensive, improving the thread identification capability.

[0007] In one possible implementation, the multiple threads refer to all threads included in the application process, and the first wake-up relationship is determined by the wake-up event recorded by the application process upon completion. The method for obtaining the relationship path of the first thread based on the first thread and the first wake-up relationship can include: obtaining a wake-up relationship tree based on the first wake-up relationship, where the parent and child nodes in the wake-up relationship tree have a wake-up and being-wake-up relationship, and the root and leaf nodes of the wake-up relationship tree both correspond to the first thread; and on the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

[0008] Therefore, based on the wake-up events of all threads recorded when the application process completes, the wake-up relationships between all threads can be obtained. That is, the first wake-up relationship includes multiple wake-up relationships, each indicating the wake-up and being-wake-up relationship between any two threads. A complete wake-up relationship tree can be constructed through these relationships, with the first thread as the root node. Nodes connected to the root node are the threads woken up by the first thread, and so on, until the first thread is woken up again by another thread, making the first thread a leaf node again. At this point, the wake-up relationship tree construction ends. Therefore, the relationship path can be obtained by working backward from the leaf nodes of the wake-up relationship tree; the relationship path is the wake-up path from the first thread as the waker to the first thread being woken up again. Because this method obtains the wake-up relationships of all threads in the first wake-up relationship, a complete wake-up relationship tree can be quickly built based on the first wake-up relationship, and thus, the relationship path can be quickly obtained based on the wake-up tree.

[0009] In one possible implementation, the multiple threads are two threads of an application process, and the first wake-up relationship is determined by the wake-up event of the application process currently running. The relationship path of the first thread based on the first wake-up relationship includes, but is not limited to, the following two scenarios. Scenario 1: A first relationship tree is created based on the first wake-up relationship, where the parent and child nodes in the first relationship tree have a wake-up and woken-up relationship; a second wake-up relationship is obtained through the wake-up event of the application process's next run, and the first relationship tree is updated based on the second wake-up relationship, and so on, until a wake-up relationship tree is obtained. The root node and leaf nodes of the wake-up relationship tree both correspond to the first thread; on the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

[0010] Scenario 2: Update the second relationship tree based on the first wake-up relationship to obtain the first relationship tree. The second relationship tree is obtained based on the wake-up event of the application process's last run. The parent and child nodes in the second relationship tree have a wake-up and woken-up relationship. Obtain the wake-up relationship tree based on the first relationship tree. The root node and leaf nodes of the wake-up relationship tree both correspond to the first thread. On the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node. Optionally, the wake-up relationship tree can be obtained based on the first relationship tree in the following ways: if the first relationship tree is complete, determine that the first relationship tree is the wake-up relationship tree; if the first relationship tree is not complete, obtain the second wake-up relationship through the wake-up event of the application process's next run, update the first relationship tree based on the second wake-up relationship, and so on, until the wake-up relationship tree is obtained.

[0011] In this context, wake-up events during application process execution occur sequentially. Therefore, the next wake-up event for an application process is the next wake-up event after the current one, and the last wake-up event is the previous wake-up event before the current one. Since the first wake-up relationship only includes a single wake-up relationship corresponding to the currently running wake-up event, multiple wake-up relationships need to be acquired in real-time as the application process runs to construct a complete wake-up relationship tree. Because the wake-up relationship tree is constructed in real-time as the application process runs, it more closely reflects the actual running conditions of the application process and is more accurate.

[0012] In one possible implementation, regardless of whether scenario one or scenario two is adopted, and regardless of whether a wake-up relationship tree is constructed, in this online mode, it is also possible to identify whether the awakened thread in the first wake-up relationship is the second thread based on the dependency probability of the first wake-up relationship. The dependency probability indicates the probability that the path of the first wake-up relationship on the first relationship tree is a relationship path. Thus, it is possible to determine in real time whether the currently awakened thread is the second thread based on the dependency probability, thereby achieving real-time identification and real-time scheduling of the second thread.

[0013] In one possible implementation, the dependency probability can be the ratio of the first count to the second count, where the first count is the number of times the awakened thread in the first wake-up relationship has historically appeared on the relationship path, and the second count is the number of times the wake-up event corresponding to the first wake-up relationship has historically run. Therefore, by statistically analyzing the number of wake-ups and the number of times the thread appears on the relationship path, the dependency probability can be accurately predicted.

[0014] In one possible implementation, after obtaining the relationship path, the method of identifying the second thread through the relationship path includes: determining a third thread on the relationship path other than the first thread; and identifying whether the third thread is the second thread based on the frequency of its appearance on the relationship path. Thus, the identification of the second thread considers not only whether it is on the relationship path but also the frequency of its appearance on the relationship path, improving the accuracy of the identification.

[0015] The frequency can be defined as the average number of times the third thread appears on the relationship path per unit of time; or, the frequency can be the ratio of the number of times the third thread appears on the relationship path to the total number of times the third thread appears on the wake-up relationship tree. Optionally, the method for identifying whether the third thread is the second thread based on the frequency of the third thread appearing on the relationship path can include: identifying the third thread as the second thread if the frequency of the third thread appearing on the relationship path is greater than a frequency threshold; and identifying the third thread as not the second thread if the frequency of the third thread appearing on the relationship path is less than or equal to the frequency threshold. The frequency threshold can be set empirically or flexibly adjusted according to the application scenario.

[0016] In one possible implementation, in identifying whether a third thread is a second thread, in addition to considering the frequency of the third thread appearing on the relational path, relevant indicators can also be considered. That is, the identification of whether a third thread is a second thread can be based on the frequency of the third thread appearing on the relational path and relevant indicators. For example, relevant indicators include one or more of the following: the average priority, average blocking duration, total number, or average runtime of the third thread. Thus, the accuracy of identifying the second thread can be further improved by using relevant indicators.

[0017] In one possible implementation, after identifying the second thread, if the first thread is a critical thread (i.e., a thread related to user interaction), the execution priority of the second thread in the application process is increased; if the first thread is not a critical thread, the execution priority of the second thread in the application process is decreased; if the first thread is not a critical thread, the second thread is a thread that a non-critical thread depends on. Thus, by increasing the execution priority of threads that critical threads depend on, their tasks are guaranteed to execute first, ensuring timely completion and reducing the probability of the critical thread entering a blocked state due to the second thread's failure to complete in time, thereby improving the user experience. By decreasing the execution priority of threads that non-critical threads depend on, their execution is restricted, allowing the saved resources to be used by the critical thread and its dependent threads, indirectly reducing the probability of the critical thread entering a blocked state.

[0018] In one possible implementation, the execution priority includes one or more of scheduling priority or allocation priority, where allocation priority indicates the performance priority of resource allocation. Therefore, the priority execution of the second thread can be guaranteed flexibly by prioritizing scheduling the second thread for execution or prioritizing the allocation of high-performance resources to the second thread.

[0019] In one possible implementation, methods to increase the execution priority of the second thread in the application process include, but are not limited to: configuring the second thread as a real-time thread, where the execution priority of a real-time thread is higher than that of a non-real-time thread; or, adding the second thread to a high-priority policy in the application process's configuration file, where the high-priority policy is used to increase the execution priority of threads in the policy list under the runtime environment corresponding to the configuration file; or, adding the second thread to a high-priority scheduling group corresponding to the application process, where the high-priority scheduling group is used to increase the execution priority of threads within the high-priority scheduling group. Thus, by utilizing existing priority boosting mechanisms, the execution priority of the second thread can be increased simply and flexibly.

[0020] Secondly, a thread identification device is provided for executing the method in the first aspect or any possible implementation thereof. Specifically, the thread identification device includes a module for executing the method in the first aspect or any possible implementation thereof.

[0021] In one possible implementation, the thread identification device includes: a first acquisition module, configured to acquire a first wake-up relationship and a first thread among multiple threads included in an application process, wherein the first thread is a thread in the application process; a second acquisition module, configured to acquire a relationship path of the first thread based on the first thread and the first wake-up relationship, wherein a node on the relationship path corresponds to a thread in the application process, a wake-up relationship exists between two adjacent nodes on the relationship path, and the head node and tail node of the relationship path correspond to the first thread; and an identification module, configured to identify a second thread through the relationship path, wherein the second thread is located on the relationship path and is different from the first thread.

[0022] In one possible implementation, the multiple threads are all the threads included in the application process. The first wake-up relationship is determined by the wake-up event recorded by the application process when it is completed. The second acquisition module is used to acquire a wake-up relationship tree based on the first wake-up relationship. The parent node and child node in the wake-up relationship tree are in a wake-up and wake-up relationship. The root node and leaf node of the wake-up relationship tree both correspond to the first thread. On the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

[0023] In one possible implementation, the multiple threads are two threads of the application process. The first wake-up relationship is determined by the wake-up event of the application process currently running. The second acquisition module is used to create a first relationship tree based on the first wake-up relationship, where the parent and child nodes in the first relationship tree are in a wake-up and woken-up relationship. The second wake-up relationship is obtained by the wake-up event of the next run of the application process. The first relationship tree is updated based on the second wake-up relationship, and so on, until the wake-up relationship tree is obtained. The root node and leaf node of the wake-up relationship tree both correspond to the first thread. On the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

[0024] In one possible implementation, the multiple threads are two threads of the application process. The first wake-up relationship is determined by the wake-up event of the application process currently running. The second acquisition module is used to update the second relationship tree based on the first wake-up relationship to obtain the first relationship tree. The second relationship tree is obtained based on the wake-up event of the application process last running. The parent node and child node in the second relationship tree are in a wake-up and wake-up relationship. The wake-up relationship tree is obtained based on the first relationship tree. The root node and leaf node of the wake-up relationship tree both correspond to the first thread. On the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

[0025] In one possible implementation, the identification module is further configured to identify whether the awakened thread in the first wake-up relationship is a second thread based on the dependency probability of the first wake-up relationship, wherein the dependency probability indicates the probability that the path of the first wake-up relationship on the first relationship tree is a relationship path.

[0026] In one possible implementation, the dependency probability is the ratio of the first number to the second number, where the first number is the number of times the woken thread in the first wake-up relationship has historically appeared on the relationship path, and the second number is the number of times the wake-up event corresponding to the first wake-up relationship has historically run.

[0027] In one possible implementation, the identification module is used to determine a third thread on the relationship path other than the first thread; and to identify whether the third thread is the second thread based on the frequency with which the third thread appears on the relationship path.

[0028] In one possible implementation, the identification module is used to identify whether the third thread is the second thread based on the frequency of the third thread appearing on the relationship path and related indicators, including one or more of the third thread's average priority, average blocking time, total number, or average runtime.

[0029] In one possible implementation, the device further includes: an adjustment module, configured to increase the execution priority of a second thread in the application process when the first thread is a critical thread, the critical thread being a thread related to user interaction; and to decrease the execution priority of the second thread in the application process when the first thread is not a critical thread.

[0030] In one possible implementation, the execution priority includes one or more of scheduling priority or allocation priority, with allocation priority indicating the performance priority of resource allocation.

[0031] In one possible implementation, the adjustment module is used to configure the second thread as a real-time thread, where the execution priority of the real-time thread is higher than that of the non-real-time thread; or, to add the second thread to the high-priority policy in the configuration file corresponding to the application process, where the high-priority policy is used to increase the execution priority of threads in the policy list in the runtime environment corresponding to the configuration file; or, to add the second thread to the high-priority scheduling group corresponding to the application process, where the high-priority scheduling group is used to increase the execution priority of threads in the high-priority scheduling group.

[0032] In one possible implementation, the first thread is a thread related to user interaction.

[0033] Thirdly, a computer device is provided, comprising: a processor coupled to a memory, the memory storing at least one program instruction or code, the at least one program instruction or code being loaded and executed by the processor to enable the computer device to implement the thread identification method as described in any of the first aspects above.

[0034] Optionally, the processor may be one or more, and the memory may be one or more.

[0035] Optionally, the memory may be integrated with the processor, or the memory may be separated from the processor.

[0036] In the specific implementation process, the memory can be a non-transitory memory, such as read-only memory (ROM), which can be integrated with the processor on the same chip or set on different chips. This application does not limit the type of memory or the way the memory and processor are set.

[0037] Fourthly, a computer-readable storage medium is provided, wherein at least one instruction is stored therein, the instruction being loaded and executed by a processor to enable a computer to implement the thread identification method of the first aspect or any possible implementation thereof.

[0038] Fifthly, a computer program (product) is provided, the computer program (product) comprising: computer program code, which, when executed by a computer, causes the computer to perform the thread identification method of the first aspect or any possible implementation thereof.

[0039] In a sixth aspect, a chip is provided, including a processor for retrieving and executing instructions stored in a memory, causing a communication device on which the chip is mounted to perform the thread identification method of the first aspect or any possible implementation thereof.

[0040] In a seventh aspect, another chip is provided, comprising: an input interface, an output interface, a processor, and a memory, wherein the input interface, the output interface, the processor, and the memory are connected via an internal connection path, and the processor is used to execute code in the memory, wherein when the code is executed, the processor is used to execute the thread identification method in the first aspect or any possible implementation thereof.

[0041] It should be understood that the beneficial effects achieved by the technical solutions of the second to seventh aspects of this application and their corresponding possible implementations can be found in the technical effects of the first aspect and its corresponding possible implementations described above, and will not be repeated here. Furthermore, the thread identification device mentioned in the second aspect may be the chip mentioned in the sixth or seventh aspect, or the thread identification device may also be the device mentioned in the third aspect. Attached Figure Description

[0042] Figure 1 is a schematic diagram of a wake-up relationship tree provided in an embodiment of this application;

[0043] Figure 2 is a schematic diagram of the implementation environment of a thread identification method provided in an embodiment of this application;

[0044] Figure 3 is a flowchart of a thread identification method provided in an embodiment of this application;

[0045] Figure 4 is a deployment diagram of a thread identification method in offline mode provided by an embodiment of this application;

[0046] Figure 5 is a schematic diagram of the algorithm execution logic of an offline mode functional module provided in an embodiment of this application;

[0047] Figure 6 is a deployment diagram of a thread identification method in online mode provided by an embodiment of this application;

[0048] Figure 7 is a schematic diagram of the algorithm execution logic of an online mode functional module provided in an embodiment of this application;

[0049] Figure 8 is a schematic diagram of an application operation process provided in an embodiment of this application;

[0050] Figure 9 is a schematic diagram of the structure of a thread identification device provided in an embodiment of this application;

[0051] Figure 10 is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0053] In operating systems, threads and processes are core concepts for implementing concurrent and parallel computing. A process is an instance of a running program, responsible for resource allocation and scheduling, and possessing its own address space and other auxiliary data. A thread is the execution unit within a process, the smallest unit of program execution, and the core of the operating system kernel is the overall scheduling of resources for thread tasks. A process can contain multiple threads, and multiple threads belonging to the same process share the resources of that process, making the context switching overhead between threads relatively small, thereby improving the efficiency of handling complex tasks.

[0054] In a multithreaded environment, thread scheduling is crucial due to the inherent execution order among threads. One key aspect is the wake-up relationship between threads, where one thread is awakened by another to execute a task. For example, in the wake-up relationship between thread 1 and thread 2, thread 1 wakes up thread 2; thread 1 is the waker (the awakening thread), and thread 2 is the awakened thread. In some cases, the awakened thread may depend on the waker's execution result. If the waker fails to complete its task promptly—for example, due to insufficient scheduling priority or improper resource allocation—the awakened thread will be forced to wait, becoming blocked, which may further block other related threads.

[0055] For critical threads related to user interaction, their execution status is highly perceptible to users, so task blocking can severely impact the user experience. For example, if the critical thread is a rendering thread, and the critical thread depends on a computation thread, and the computation thread fails to complete its calculations in time, causing the rendering thread to become blocked, users may experience noticeable screen stuttering and latency when using the application. Therefore, it is necessary to identify the threads that critical threads depend on, and then accurately schedule and allocate resources to ensure that these threads complete in a timely manner, thereby reducing the probability of critical threads becoming blocked.

[0056] For example, referring to the schematic diagram of the wake-up relationship tree shown in Figure 1, the wake-up relationship tree refers to the wake-up relationship tree formed by key threads through wake-up events starting from the wake-up cycle. A wake-up event refers to an event that causes a thread to transition from a waiting state to a running state. For example, a thread transitions from a waiting state to a running state due to the operation of another thread; that is, a thread is woken up and executed by another thread. As shown in Figure 1, the historical thread sequence includes {x} i (t), i = 1, 2, 3, ...}; the key thread identifier includes {k1, ...}, for example, if x1 is a key thread, then k1 can be the key thread x1; the thread wake-up relationship includes {(x1, x2), (x1, x3) ...}, where (x1, x2) represents x1 waking up x2, which is represented in Figure 1 as the arrow of the connecting line between x1 and the woken-up x2 points to x2.

[0057] Taking the critical thread x1 in Figure 1 as an example, the critical path includes {x1, x2, x4, x′1}. The critical path refers to the path in the wake-up relationship tree from the critical thread to the re-wake-up of that critical thread; that is, the path from critical thread x1 through threads x2 and x4 to the re-wake-up of critical thread x′1. Critical thread x′1 is the re-wake-up critical thread x1. Threads on the critical path have dependencies. The threads that a critical thread depends on can be determined based on threads other than the critical thread on the critical path, such as threads x2 and x4 on the critical path in Figure 1. In this case, if the threads that the critical thread depends on are not identified in time, it may lead to insufficient scheduling priority or resource allocation for the threads that depend on it, preventing them from obtaining the resources required for task execution. This can result in a series of blocking problems, affecting the responsiveness of the entire system. Therefore, identifying the threads that the critical thread depends on from the exponential wake-up relationship is crucial for optimizing thread scheduling.

[0058] In related technologies, during the application's cold start process, multiple child threads that wake up the application's main thread are acquired. For each of these child threads, information such as waiting time, occurrence frequency, and runtime is collected. By sorting the information or setting a threshold, the target thread that has a significant impact on the main thread's execution is identified among the multiple child threads. The scheduling priority of the target thread is increased to ensure that it can complete in a timely manner, thereby ensuring that the main thread is not blocked. Here, cold start refers to the operating system creating a new process for the application when there are no background processes running the application.

[0059] However, the methods in related technologies only identify threads through a single-level wake-up relationship, failing to identify the higher-level threads that affect the execution of child threads. This means their identification capability is poor and incomplete. Consequently, threads affecting the execution of child threads may still fail to complete in a timely manner, leading to delays in child thread completion and potentially causing the main thread to block. Furthermore, these methods are limited to application cold start scenarios.

[0060] This application provides a thread identification method for identifying a second thread that a first thread depends on through a multi-level wake-up relationship. Referring to Figure 2, Figure 2 is a schematic diagram of the implementation environment for the thread identification method provided in this application. As shown in Figure 2, the implementation environment includes a computer device 201, which has an operating system (OS) installed and running. The operating system is used to manage and control the hardware and software resources of the computer device 201, including functions such as resource management, program control, user interface, and system services. The kernel is the core part of the operating system; as a bridge between hardware and software, the kernel manages applications upwards and schedules hardware resources downwards.

[0061] In one possible implementation, the computer device 201 can be a terminal. The terminal can be any electronic product that can interact with the user through one or more means such as a keyboard, touchpad, touch screen, remote control, voice interaction or handwriting device, such as a personal computer (PC), smartphone, personal digital assistant (PDA), wearable device, pocket PC (PPC), tablet computer, virtual reality (VR) terminal, augmented reality (AR) terminal or Internet of Things terminal, etc.

[0062] Those skilled in the art should understand that the computer device 201 described above is merely an example, and other existing or future computer devices may also be applicable to this application and should be included within the scope of protection of this application, and are hereby incorporated by reference.

[0063] Referring to Figure 3, which is a flowchart of a thread identification method provided in an embodiment of this application, this method can be applied to the implementation environment shown in Figure 2 above, for example, to computer device 201, which can be a terminal; this embodiment of the application does not limit this. As shown in Figure 3, the thread identification method includes, but is not limited to, the following steps 301-303.

[0064] Step 301: Obtain the first wake-up relationship and the first thread among the multiple threads included in the application process. The first thread is a thread in the application process.

[0065] In this embodiment, an application process refers to a running instance of an application. The application type can be any type of communication software, game software, shopping software, or browser software, etc., and each application's operation corresponds to an independent application process. An application process includes many threads, and a wake-up mechanism exists during multi-threaded task execution. For example, in a producer-consumer model, after a producer thread produces data, it wakes up one or more consumer threads to process the data. That is, there is a wake-up relationship between producer threads and consumer threads, and consumer threads depend on the data produced by producer threads.

[0066] Optionally, the methods for obtaining the first wake-up relationship include, but are not limited to, offline mode and online mode. Offline mode refers to executing the thread identification method provided in this application embodiment when the application process is not running, while online mode refers to executing the thread identification method provided in this application embodiment when the application process is running.

[0067] In offline mode, the first wake-up relationship can be determined by the wake-up events recorded by the application process upon completion of its execution. This means the application process has completed its execution in the historical timeframe and recorded all wake-up events during its historical execution. A wake-up event indicates that one thread wakes up one or more other threads to begin execution, and the awakened thread's thread state changes from waiting to running. Therefore, based on the wake-up events of all threads recorded in the application process's historical execution, the wake-up relationships between all threads can be obtained; that is, the first wake-up relationship between multiple threads refers to the wake-up relationship between all threads included in the application process. Alternatively, depending on the application scenario, the first wake-up relationship between multiple threads refers to the wake-up relationship between all threads in the application scenario corresponding to the application process. For example, the first wake-up relationship includes multiple wake-up relationships, each indicating the wake-up and being-wake-up relationship between every two threads. For instance, as shown in Figure 1, the multiple wake-up relationships in the first wake-up relationship include {(x1,x2),(x1,x3),(x2,x4),(x4,x′1)…}.

[0068] In online mode, the first wake-up relationship can be determined by the wake-up event currently running in the application process. Therefore, the first wake-up relationship only includes a single wake-up relationship corresponding to the currently running wake-up event. That is, the first wake-up relationship between multiple threads refers to the wake-up relationship between two threads of the application process. The two threads in this first wake-up relationship may or may not include the first thread.

[0069] Optionally, this application embodiment does not limit the first thread; the first thread can be any thread in the application process. For example, the first thread may be a critical thread; or, the first thread may be a non-critical thread, which is any thread in the application process other than the critical thread, i.e., the first thread is not a critical thread. Here, a critical thread is a thread related to user interaction, which refers to a thread that is highly perceived by the user, or a thread that affects the user experience. User interaction includes, but is not limited to, visual, auditory, and tactile interactions. Visual interaction may include a user interface (UI), images, or videos; auditory interaction may include voice or audio; and tactile interaction may include vibration or force.

[0070] The number of first threads is not limited in this embodiment and can be one or more. The method for identifying the second threads that any first thread depends on is the same; this embodiment uses one first thread as an example. When there are multiple first threads, all of them can be critical threads, all can be non-critical threads, or some can be critical threads and others non-critical threads. In this embodiment, different threads are distinguished by an identifier; obtaining a first thread can refer to obtaining its identifier. For example, the identifier of a first thread can include one or more of the following: the first thread's name, serial number, or identity document (ID).

[0071] Step 302: Obtain the relationship path of the first thread based on the first thread and the first wake-up relationship. A node on the relationship path corresponds to a thread in the application process. There is a wake-up relationship between two adjacent nodes on the relationship path. The head node and tail node of the relationship path correspond to the first thread.

[0072] In this embodiment, the relationship path is a unidirectional path including multiple nodes, each node corresponding to a thread, where the head node and tail node correspond to the same first thread. For example, taking thread 1 as the first thread, the relationship path of the first thread can be thread 1 waking up thread 2, thread 2 waking up thread 3, and thread 3 waking up thread 1 again. Therefore, the relationship path of the first thread is the wake-up path from the first thread acting as the waker to the first thread being woken up again. When the first thread is a critical thread, the relationship path can be called the critical path. Optionally, the method of obtaining the relationship path varies depending on the different methods of obtaining the first wake-up relationship described above.

[0073] For offline mode, the method of obtaining the relationship path of the first thread based on the first thread and the first wake-up relationship includes: obtaining a wake-up relationship tree based on the first wake-up relationship; and on the wake-up relationship tree, tracing the relationship path backward from the leaf node corresponding to the first thread to the root node. Specifically, the method of establishing the relationship tree based on the wake-up relationship can be to determine the parent and child nodes in the relationship tree based on the wake-up and woken-up relationship. For example, if thread 1 wakes up thread 2, then the parent node is thread 1, and the child node is thread 2. In this application embodiment, the complete relationship tree established based on the wake-up relationship is referred to as the wake-up relationship tree, which is a relationship tree where both the root node and leaf nodes correspond to the first thread.

[0074] Since the first wake-up relationship obtained in offline mode includes wake-up relationships between all threads, a complete wake-up relationship tree can be constructed using these relationships. This wake-up relationship tree is built with the first thread as the root node. Following the order of wake-up events, child nodes connected to the root node are generated based on the threads woken up by the first thread, and so on, until the first thread is woken up again by another thread, making the first thread a leaf node again. At this point, the wake-up relationship tree construction ends. Therefore, the relationship path can be obtained by working backward from the leaf nodes of the wake-up relationship tree. Because this method obtains the first wake-up relationship for all threads, a complete wake-up relationship tree can be quickly built based on the first wake-up relationship, and thus, the relationship path can be quickly obtained based on the wake-up relationship tree.

[0075] For online mode, obtaining the relationship path of the first thread based on the first thread and the first wake-up relationship includes, but is not limited to, the following two scenarios. Scenario 1: Create a first relationship tree based on the first wake-up relationship, where the parent and child nodes in the first relationship tree are in a wake-up and woken-up relationship; obtain the second wake-up relationship through the wake-up event of the application process's next run, update the first relationship tree based on the second wake-up relationship, and so on, until the wake-up relationship tree is obtained; on the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

[0076] Scenario 2: Update the second relationship tree based on the first wake-up relationship to obtain the first relationship tree. The second relationship tree is obtained based on the wake-up event of the application process's last run. The parent and child nodes in the second relationship tree have a wake-up and woken-up relationship. Obtain the wake-up relationship tree based on the first relationship tree. On the wake-up relationship tree, deduce the relationship path from the leaf node corresponding to the first thread back to the root node. Optionally, the wake-up relationship tree can be obtained based on the first relationship tree in the following ways: if the first relationship tree is complete, determine that the first relationship tree is the wake-up relationship tree; if the first relationship tree is not complete, obtain the second wake-up relationship through the wake-up event of the application process's next run, update the first relationship tree based on the second wake-up relationship, and so on, until the wake-up relationship tree is obtained.

[0077] In this application process, wake-up events occur sequentially during runtime. Therefore, the next wake-up event for the application process refers to the next wake-up event after the current wake-up event has finished running, and the last wake-up event refers to the previous wake-up event before the current wake-up event. Since the first wake-up relationship in online mode only includes a single wake-up relationship corresponding to the currently running wake-up event, multiple wake-up relationships need to be acquired in real-time as the application process runs to construct a complete wake-up relationship tree. Because the wake-up relationship tree is constructed in real-time as the application process runs, it better reflects the actual running situation of the application process and has higher accuracy. This application does not limit the type of wake-up relationship tree; for example, the type of wake-up relationship tree can be a directed acyclic graph (DAG).

[0078] In one possible implementation, regardless of whether scenario one or scenario two is adopted, and regardless of whether a wake-up relationship tree is constructed, in this online mode, it is also possible to identify whether the awakened thread in the first wake-up relationship is the second thread based on the dependency probability of the first wake-up relationship. The dependency probability indicates the probability that the path of the first wake-up relationship on the first relationship tree is a relationship path. For example, the dependency probability can be determined based on the ratio of the first number to the second number. Here, the first number is the number of times the awakened thread in the first wake-up relationship has historically appeared on the relationship path, and the second number is the number of times the wake-up event corresponding to the first wake-up relationship has historically run. Thus, by statistically analyzing the number of wake-ups and the number of times they appear on the relationship path, the dependency probability can be accurately predicted.

[0079] Step 303: Identify the second thread through the relationship path. The second thread is located on the relationship path and is different from the first thread.

[0080] In one possible implementation, after obtaining the relationship path, identifying the second thread through the relationship path includes: determining a third thread on the relationship path other than the first thread; using the third thread as the second thread, or simplifying the third thread and using the simplified third thread as the second thread. Optionally, simplifying the third thread may include identifying whether the third thread is the second thread based on the frequency with which it appears on the relationship path. Therefore, the identification of the second thread considers not only whether it is on the relationship path but also the frequency of its appearance on the relationship path, improving the accuracy of the identification.

[0081] The frequency can be defined as the average number of times the third thread appears on the relationship path per unit of time; or, the frequency can be the ratio of the number of times the third thread appears on the relationship path to the total number of times the third thread appears on the wake-up relationship tree. For example, identifying whether a third thread is the second thread based on its frequency on the relationship path can include: identifying the third thread as the second thread if its frequency on the relationship path is greater than a frequency threshold; and identifying the third thread as not the second thread if its frequency on the relationship path is less than or equal to the frequency threshold. The frequency threshold can be set empirically or flexibly adjusted according to the application scenario.

[0082] In one possible implementation, in the simplification process of identifying whether a third thread is a second thread, in addition to considering the frequency of the third thread appearing on the relational path, relevant indicators can also be considered. That is, the identification of whether a third thread is a second thread can be based on the frequency of the third thread appearing on the relational path and relevant indicators. For example, relevant indicators include one or more of the following: the average priority, average blocking duration, total number, or average runtime of the third thread. Thus, the accuracy of identifying the second thread can be further improved by using relevant indicators.

[0083] For example, taking the first thread as the critical thread, if the average priority of the third thread is higher than the priority threshold, the third thread is identified as not being the second thread because it already has a high priority and does not need to be prioritized again. If the average blocking time of the third thread is less than the first duration threshold, the third thread is identified as not being the second thread because it usually does not block, and therefore does not need to be prioritized again. If the number of third threads exceeds the quantity threshold, the third threads are streamlined; otherwise, the third thread is directly treated as the second thread without further streamlining, ensuring that there are not too many protected second threads. If the average runtime of the third thread is lower than the second duration threshold, the third thread is identified as not being the second thread because the probability of a shorter runtime third thread blocking is low, and therefore it does not need to be prioritized again. The priority threshold, the first duration threshold, the quantity threshold, and the second duration threshold can all be flexibly set based on experience; for example, the priority threshold can be the execution priority of the second thread.

[0084] In online mode, since the second thread, on which the first thread depends, is dynamically identified, the identified second thread can be dynamically updated in real time or periodically. Optionally, if the first thread is a critical thread, the identified second thread is stored in a protected thread list, which represents threads that need to be guaranteed priority for execution. If the first thread is a non-critical thread, the identified second thread is stored in a restricted thread list, which represents threads that need to have their execution restricted, such as limiting frequency, limiting runtime, or lowering priority.

[0085] Taking the protected thread list as an example, the protected thread list is dynamically updated based on the second thread identified dynamically. For instance, if a second thread not currently in the protected thread list is identified, it is added to the list; if a second thread already in the list is identified, the list is not updated. For protected threads already in the list, if a change in the relationship path is detected, the protected threads under the previous relationship path are replaced with those under the new relationship path.

[0086] In this embodiment, if the first thread is a critical thread and the identified second thread is a thread that the critical thread depends on, then the execution priority of the second thread in the application process is increased to ensure that the thread that the critical thread depends on executes first, reducing the probability of the critical thread entering a blocked state. If the first thread is not a critical thread and the identified second thread is a thread that a non-critical thread depends on, then the execution priority of the second thread in the application process is decreased to restrict the execution of the non-critical thread, allowing the saved resources to be used by the critical thread, thereby indirectly reducing the probability of the critical thread entering a blocked state.

[0087] In this embodiment, the execution priority includes one or more of scheduling priority or allocation priority, with allocation priority indicating the performance priority of resource allocation. Therefore, it is possible to flexibly ensure the priority execution of the second thread's tasks by prioritizing scheduling the second thread's tasks or prioritizing the allocation of high-performance resources to the second thread.

[0088] Optionally, the execution priority of the second thread can be increased in ways including but not limited to the following three. Method 1: Configure the second thread as a real-time (RT) thread, where the execution priority of an RT thread is higher than that of a non-real-time thread. For example, the operating system configures thread priorities for multithreading, with lower priority values ​​resulting in higher execution priority. Taking a thread priority system with 140 levels as an example, the priority range for RT threads is [0, 99], while the priority range for non-real-time threads is [100, 139]. Therefore, configuring the second thread as an RT thread makes its priority range [0, 99], thus allowing it to execute before non-real-time threads.

[0089] Method two involves adding the second thread to the high-priority policy list in the application process's configuration file. High-priority policies are used to increase the execution priority of threads within the policy list in the corresponding runtime environment. In other words, the application process's configuration file contains high-priority policies, which are used to increase the execution priority of threads within the policy list in the corresponding runtime environment. For example, a high-priority policy might add threads within the policy list to a high-priority thread queue. Therefore, after adding the second thread to the policy list, in the runtime environment corresponding to the configuration file, the second thread within the policy list will be placed in the high-priority thread queue and executed with priority due to the high-priority policy.

[0090] In one possible scenario, the configuration file can be an Extensible Markup Language (XML) file, and the high-priority strategy can be a static VIP (static_vip) strategy. Therefore, by utilizing the existing priority-boosting mechanism of the static_vip strategy, it is possible to simply and flexibly increase the execution priority of the second thread.

[0091] Method 3: Add the second thread to the high-priority scheduling group corresponding to the application process. The high-priority scheduling group is used to increase the execution priority of threads within the group. In one possible scenario, the high-priority scheduling group can be a related thread group (RTG). Therefore, by utilizing the existing priority-boosting mechanism of the RTG, the execution priority of the second thread can be increased simply and flexibly.

[0092] For example, the RTG priority boosting mechanism includes functions such as group management, resource optimization, and dynamic adjustment. Group management is used to group related threads into the same group to ensure they can share resources; resource optimization is used to optimize resource allocation to ensure that threads in the same group can use resources efficiently; dynamic adjustment is used to dynamically adjust the resource allocation of each group according to the system's running status to ensure that the system is always in an optimal state. Therefore, in this embodiment of the application, an RTG group can be determined for the second thread that the first thread depends on, and the dynamically identified second thread can be added to the RTG group in real time. Threads in the RTG group share priority scheduling or share allocated high-performance resources.

[0093] Optionally, the execution priority of the second thread can be reduced by directly reducing the thread priority of the second thread; or by configuring the second thread as a non-real-time thread; or by adding the second thread to a reverse suppression group, which is used to limit the frequency supply of threads in the reverse suppression group or reduce the runtime slice of threads in the reverse suppression group.

[0094] The method provided in this application embodiment obtains a relationship path where both the head node and the tail node are the first thread through a first wake-up relationship. This relationship path indicates the complete wake-up chain from the first thread waking up other threads to being woken up. Therefore, the second thread identified through this relationship path is more comprehensive, improving the thread identification capability.

[0095] The following describes the method provided in this application embodiment, taking the first thread as the key thread as an example, and illustrates the method in both offline and online modes. For example, refer to Figure 4, which shows the deployment diagram of the thread identification method in offline mode. The thread identification method provided in this application embodiment is executed by an offline mode function module, which is deployed outside the operating system kernel. The inputs of the offline mode function module include a trace file and a list of key threads corresponding to the application scenario, and the output is a list of protected threads.

[0096] The trace file is used to record wake-up events during the application process's execution. Once the application process has finished running, the trace file contains all wake-up events. As shown in Figure 4, the application issues system call instructions based on user actions, which are received and executed by the kernel. The kernel has a function trace (ftrace) module, which tracks wake-up events during kernel execution. After the application process finishes running, the ftrace module outputs the trace file. The critical thread list includes identifiers for all critical threads in the application process. These critical thread lists may vary depending on the application scenario, including but not limited to sliding the interface, clicking on a message list, or zooming the interface. Different application scenarios may correspond to different critical thread lists.

[0097] The list of protected threads includes identifiers for the protected threads, which correspond to the second thread mentioned above, i.e., the thread on which the critical thread depends. After the offline mode function module outputs the list of protected threads, the corresponding configuration file can be modified based on this list, for example, adding the protected threads to the high-priority policy list in the configuration file. A scheduler is also deployed in the kernel, which performs thread scheduling based on a priority-boosting mechanism of the high-priority policy. This mechanism is used to increase the priority of threads within the policy list. Therefore, the scheduling supply of protected threads is guaranteed.

[0098] In this embodiment, the algorithm execution logic of the offline mode functional module can be as shown in Figure 5. The offline mode functional module includes a trace analysis module, a statistical integration module, and an intelligent selection module. The trace analysis module receives the trace file and a list of key threads; it constructs a tree model, i.e., a wake-up relationship tree, based on the full wake-up events in the trace file or the wake-up events corresponding to the application scenario. The wake-up relationship tree includes the links between wake-up relationships; and the key path is derived by back-tracing from the leaf nodes in the wake-up relationship tree.

[0099] The statistics integration module integrates and analyzes wake-up paths and critical paths, outputting a total list of relevant threads. This list includes the names of all critical path threads except the critical thread itself. For example, the module counts the first frequency of a critical path thread on the critical path and the second frequency of a critical path thread on the wake-up path. Critical path threads whose ratio of first frequency to second frequency is greater than a frequency threshold are added to the total list of relevant threads. Alternatively, the module sorts the critical path threads according to the ratio of first frequency to second frequency, adding the top N critical path threads to the total list. Here, N is any positive integer. The intelligent selection module intelligently filters out protected threads from the total list of relevant threads. For example, it filters based on the aforementioned key indicators and outputs a list of protected threads.

[0100] For the online mode, refer to Figure 6 for a deployment diagram of the thread identification method in the online mode. The thread identification method provided in this embodiment is executed by the online mode functional module, which is deployed within the operating system kernel. The online mode functional module performs real-time thread identification during application process execution. Taking the currently running wake-up event as an example, the input of the online mode functional module includes the currently running single wake-up event and the list of key threads corresponding to the application scenario, and the output is whether the currently woken thread is a protected thread. Optionally, the online mode functional module also periodically outputs a list of protected threads to update the list in real time. For example, the list of protected threads is updated once every time one or more key paths are obtained; or, the list of protected threads is updated every time period, and the time period can be flexibly adjusted according to the application scenario.

[0101] Each time the kernel receives and executes a wake-up event, the ftrace module can track and record it, and then send the real-time recorded wake-up event to the online mode function module. Therefore, the online mode function module can obtain wake-up events during the application process in real time, and the list of key threads corresponding to the application scenario only needs to be entered once when the application process starts running.

[0102] If the online mode module outputs that the currently awakened thread is a protected thread, or if the online mode module updates the protected thread list, the high-priority scheduling group is updated according to the currently awakened thread or the updated protected thread list. For example, the name of the currently awakened thread or the name of a thread in the updated protected thread list is added to the high-priority scheduling group. However, if any protected thread is already included in the high-priority scheduling group, it does not need to be added again. The kernel scheduler performs thread scheduling based on the priority boosting mechanism of the high-priority scheduling group, which is used to increase the priority of threads within the high-priority scheduling group. This ensures a guaranteed supply of scheduling opportunities for protected threads.

[0103] In this embodiment, the algorithm execution logic of the online mode functional module can be as shown in Figure 7. During the initialization phase, the online mode functional module inputs a list of key threads and initializes the wake-up path transition matrix and the critical path transition matrix. After initialization, it outputs a single wake-up event. The online mode functional module obtains a single wake-up relationship based on this single wake-up event and then obtains a tree model based on this single wake-up relationship, corresponding to the aforementioned first relationship tree. For example, the online mode functional module determines whether a tree is being built. If not, it creates a new tree based on the single wake-up relationship; if a tree is being built, it updates the tree based on the single wake-up relationship to obtain the tree model. It then determines whether the current tree is fully established. A fully established tree indicates that the current tree is a wake-up relationship tree. If the current tree is fully established, the critical path is derived from the leaf nodes in the wake-up relationship tree. Optionally, the fully established wake-up relationship tree in the tree model is deleted, and a new tree is rebuilt with the input of new wake-up events.

[0104] Regardless of whether a tree is being built, the online mode module updates the wake-up path transition matrix based on the single wake-up relationship. After reversing to obtain the critical path, the critical path transition matrix can be updated based on the critical path. The wake-up path transition matrix records the number of times the wake-up event corresponding to each wake-up relationship runs, while the critical path transition matrix records the number of times the woken-up thread of each wake-up relationship appears on the critical path. Furthermore, after reversing to obtain the critical path, a list of protected threads can be output based on the critical path. The output method can be seen in the offline mode module shown in Figure 5, and will not be elaborated further here.

[0105] For example, the wake-up path transition matrix can be as shown in Formula 1, where rows represent wake-up threads and columns represent wake-up threads. Each time a new thread appears, the wake-up path transition matrix adds one column and one row. The number of rows and columns in the wake-up path transition matrix is ​​the same, and the first row and first column represent the same thread, for example, thread x1; the second row and second column represent the same thread, for example, thread x2; and so on, with the nth row and nth column representing the same thread, for example, thread x... n Let n be a positive integer greater than 2. Then, in Formula 1, it means that the wake-up event of thread x1 waking up thread x2 occurs once, the wake-up event of thread x1 waking up thread x3 occurs once, the wake-up event of thread x2 waking up thread x1 occurs twice, and so on. n The wake-up event for thread x1 occurs once, while all other wake-up events occur zero times. Similarly, the critical path transition matrix can be represented as shown in Table 1. The data in Table 1 indicates that the wake-up event for thread x1 to wake up thread x2 occurs once on the critical path, meaning that thread x2 appears once on the critical path.

[0106] Therefore, based on the wake-up path transition matrix and the critical path transition matrix, it is possible to determine whether the currently woken-up thread is a protected thread. For example, for the currently woken-up thread, the critical path transition matrix determines the first number of times the currently woken-up thread has appeared on the critical path in history, and the wake-up path transition matrix determines the second number of times the currently woken-up thread has been woken up in history. It is then determined whether the ratio of the first number to the second number is greater than a second threshold. If it is greater than the second threshold, the output is 1, indicating that the currently woken-up thread is a protected thread; if it is not greater than the second threshold, the output is 0, indicating that the currently woken-up thread is not a protected thread. Optionally, it is also determined whether the second number exceeds a third threshold. If the ratio of the first number to the second number is greater than the second threshold and the second number exceeds the third threshold, the output is 1, indicating that the currently woken-up thread is a protected thread; if the ratio of the first number to the second number is not greater than the second threshold, or if the second number does not exceed the third threshold, the output is 0, indicating that the currently woken-up thread is not a protected thread. Both the second and third thresholds can be flexibly adjusted according to the application scenario.

[0107] Taking thread identification using both offline and online modes as an example, refer to Figure 8 for a schematic diagram of the application's execution process. In response to user actions, the application issues a system call instruction, the system invokes the request, and the request enters the kernel. The kernel receives the request and allocates resources for the corresponding thread to create it. The created thread enters the thread queue to wait for execution; at this time, the thread is in a waiting state. Before the application issues the system call instruction, the offline mode module initializes a list of protected threads based on historical records. After the application issues the system call instruction, the online mode module dynamically determines in real time whether the currently running thread is a protected thread and updates the list of protected threads dynamically in real time, for example, by adding or deleting protected threads. This ensures that the list of protected threads includes comprehensive and accurate protected threads.

[0108] The kernel schedules threads in the thread queue through the scheduler. The scheduler rearranges the thread queue according to the protected threads, moving protected threads (shown as shaded in Figure 8) forward in the queue to prioritize their execution. After a thread starts executing its task, it is in a running state. Once the thread completes its task, its state is updated to "completed," and the user perceives the operation response. For example, if the user's operation is a screen swipe, the user perceives the page swipe as smooth. Experiments have shown that the thread identification method provided in this application achieves an accuracy rate of up to 95%. By prioritizing the execution of the identified protected threads, it can effectively improve the average frame rate of the screen display, reduce the number of stutters, and decrease latency.

[0109] Therefore, after applying the thread identification method provided in this application embodiment, by analyzing the wake-up events in the output trace files, it can be found that the execution priority of the critical path thread is increased or periodically increased over a period of time. For example, if thread B1 is first constructed as a thread on the critical path, and then thread B1 is constructed as not on the critical path, after thread scheduling in this application embodiment, in the multiple output trace files, the execution priority of thread B1 in the preceding trace file is high priority, and the execution priority of thread B1 in the subsequent trace file is low priority.

[0110] In summary, the embodiments of this application utilize the wake-up relationship tree to start from the key thread K. i From the awakener to itself as the awakened (in the case of K′) i The path (represented by) is unique, denoted as: P(K) i ,K′ i )={K i ,v1,v2,…,v k ,K′ i}, where v1, v2, ..., vk The thread on which the critical thread depends. This is determined by solving the critical path P(K) defined above. i ,K′ i This method aims to uncover the complete dependency chain, thereby identifying accurate and comprehensive protected threads. Furthermore, this application provides two main functional modules: offline mode and online mode. By analyzing the key thread identifiers input by the application, the historical thread sequence, wake-up relationships, and the current thread queue input by the system, these two modules output a list of protected threads. Subsequently, by increasing the execution priority of the protected thread list, the scheduler rearranges the thread queue to output an optimized thread queue, effectively ensuring that protected threads can complete their tasks in a timely manner. Therefore, this method optimizes resource allocation, improves the execution efficiency of thread tasks, minimizes the overall task completion time, enhances the responsiveness of applications that rely on concurrent processing, and ensures smooth user interaction.

[0111] The thread identification method of this application embodiment has been described above. Corresponding to the above method, this application embodiment also provides a thread identification device. Figure 9 is a schematic diagram of the structure of a thread identification device provided in this application embodiment. Based on the multiple modules shown in Figure 9, the thread identification device shown in Figure 9 can perform all or part of the operations performed in the above method embodiments. It should be understood that the device may include more additional modules than the modules shown or omit some of the modules shown, and this application embodiment does not limit this. As shown in Figure 9, the device includes, but is not limited to: a first acquisition module 901, a second acquisition module 902, and an identification module 903.

[0112] In one possible implementation, the first acquisition module 901 is used to acquire a first wake-up relationship and a first thread among multiple threads included in the application process, wherein the first thread is a thread in the application process; the second acquisition module 902 is used to acquire a relationship path of the first thread based on the first thread and the first wake-up relationship, wherein a node on the relationship path corresponds to a thread in the application process, there is a wake-up relationship between two adjacent nodes on the relationship path, and the head node and tail node of the relationship path correspond to the first thread; the identification module 903 is used to identify a second thread through the relationship path, wherein the second thread is located on the relationship path and is different from the first thread.

[0113] In one possible implementation, the multiple threads are all the threads included in the application process, and the first wake-up relationship is determined by the wake-up event recorded by the application process when it is completed. The second acquisition module 902 is used to acquire a wake-up relationship tree based on the first wake-up relationship. The parent node and child node in the wake-up relationship tree are in a wake-up and wake-up relationship. The root node and leaf node of the wake-up relationship tree both correspond to the first thread. On the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

[0114] In one possible implementation, the multiple threads are two threads of the application process. The first wake-up relationship is determined by the wake-up event of the application process currently running. The second acquisition module 902 is used to create a first relationship tree based on the first wake-up relationship, where the parent node and child node in the first relationship tree are in a wake-up and wake-up relationship. The second wake-up relationship is obtained by the wake-up event of the next run of the application process. The first relationship tree is updated based on the second wake-up relationship, and so on, until the wake-up relationship tree is obtained. The root node and leaf node of the wake-up relationship tree both correspond to the first thread. On the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

[0115] In one possible implementation, the multiple threads are two threads of the application process. The first wake-up relationship is determined by the wake-up event of the application process currently running. The second acquisition module 902 is used to update the second relationship tree based on the first wake-up relationship to obtain the first relationship tree. The second relationship tree is obtained based on the wake-up event of the application process last running. The parent node and child node in the second relationship tree are in a wake-up and wake-up relationship. The wake-up relationship tree is obtained based on the first relationship tree. The root node and leaf node of the wake-up relationship tree both correspond to the first thread. On the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

[0116] In one possible implementation, the identification module 903 is further configured to identify whether the awakened thread in the first wake-up relationship is a second thread based on the dependency probability of the first wake-up relationship, wherein the dependency probability indicates the probability that the path of the first wake-up relationship on the first relationship tree is a relationship path.

[0117] In one possible implementation, the dependency probability is the ratio of the first number to the second number, where the first number is the number of times the woken thread in the first wake-up relationship has historically appeared on the relationship path, and the second number is the number of times the wake-up event corresponding to the first wake-up relationship has historically run.

[0118] In one possible implementation, the identification module 903 is used to determine a third thread on the relationship path other than the first thread; and to identify whether the third thread is the second thread based on the frequency of the third thread appearing on the relationship path.

[0119] In one possible implementation, the identification module 903 is used to identify whether the third thread is the second thread based on the frequency of the third thread appearing on the relationship path and related indicators, including one or more of the third thread's average priority, average blocking time, total number, or average runtime.

[0120] In one possible implementation, the device further includes: an adjustment module, configured to increase the execution priority of a second thread in the application process when the first thread is a critical thread, the critical thread being a thread related to user interaction; and to decrease the execution priority of the second thread in the application process when the first thread is not a critical thread.

[0121] In one possible implementation, the execution priority includes one or more of scheduling priority or allocation priority, with allocation priority indicating the performance priority of resource allocation.

[0122] In one possible implementation, the adjustment module is used to configure the second thread as a real-time thread, where the execution priority of the real-time thread is higher than that of the non-real-time thread; or, to add the second thread to the high-priority policy in the configuration file corresponding to the application process, where the high-priority policy is used to increase the execution priority of threads in the policy list in the runtime environment corresponding to the configuration file; or, to add the second thread to the high-priority scheduling group corresponding to the application process, where the high-priority scheduling group is used to increase the execution priority of threads in the high-priority scheduling group.

[0123] It should be understood that the device shown in Figure 9 above is only illustrated by the division of the above-described functional modules. In practical applications, the 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. Furthermore, the device and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process and beneficial effects are detailed in the method embodiments, and will not be repeated here.

[0124] Referring to Figure 10, Figure 10 shows a schematic diagram of the structure of a computer device 2000 provided in an exemplary embodiment of this application. The computer device 2000 shown in Figure 10 is used to perform the operations involved in the thread identification method shown in Figure 3 above. The computer device 2000 is, for example, a terminal such as a tablet computer or a mobile phone, and can be implemented using a general bus architecture.

[0125] As shown in Figure 10, the computer device 2000 includes at least one processor 2001, a memory 2003, and at least one communication interface 2004.

[0126] Processor 2001 may be, for example, a general-purpose central processing unit (CPU), a digital signal processor (DSP), a network processor (NP), a graphics processing unit (GPU), a neural-network processing unit (NPU), a data processing unit (DPU), a microprocessor, or one or more integrated circuits for implementing the embodiments of this application. For example, processor 2001 includes application-specific integrated circuits (ASICs), programmable logic devices (PLDs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A PLD may be, for example, a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof. It can implement or execute the various logic blocks, modules, and circuits described in connection with the embodiments of this invention. A processor may also be a combination that implements computational functions, such as a combination of one or more microprocessors, a combination of a DSP and a microprocessor, etc. A processor can have multiple cores, each of which is a complete computing engine, thereby improving the computer's computing speed.

[0127] Optionally, the computer device 2000 also includes a bus. The bus is used to transfer information between the components of the computer device 2000. The bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 10, but this does not indicate that there is only one bus or one type of bus.

[0128] Memory 2003 may be, for example, read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions; random access memory (RAM) or other types of dynamic storage devices capable of storing information and instructions; electrically erasable programmable read-only memory (EEPROM); compact disc read-only memory (CD-ROM) or other optical disc storage; optical disc storage (including compressed discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.); magnetic disk storage media or other magnetic storage devices; or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory 2003 may exist independently and be connected to processor 2001 via a bus. Memory 2003 may also be integrated with processor 2001.

[0129] The communication interface 2004 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), or wireless local area networks (WLAN). The communication interface 2004 can include wired and wireless communication interfaces. Specifically, the communication interface 2004 can be an Ethernet interface, a Fast Ethernet (FE) interface, a Gigabit Ethernet (GE) interface, an Asynchronous Transfer Mode (ATM) interface, a WLAN interface, a cellular network communication interface, or a combination thereof. The Ethernet interface can be an optical interface, an electrical interface, or a combination thereof. In this embodiment, the communication interface 2004 can be used by the computer device 2000 to communicate with other devices.

[0130] In a specific implementation, as one embodiment, processor 2001 may include one or more CPUs, such as CPU0 and CPU1 shown in FIG10. Each of these processors may be a single-core CPU processor or a multi-core CPU processor. Here, processor may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0131] In a specific implementation, as one example, the computer device 2000 may include multiple processors, such as processor 2001 and processor 2005 as shown in FIG10. Each of these processors may be a single-core CPU or a multi-core CPU. Here, a processor may refer to one or more devices, circuits, and / or processing cores used to process data (such as computer program instructions).

[0132] In a specific implementation, as one example, the computer device 2000 may further include output devices and input devices. The output device communicates with the processor 2001 and can display information in various ways. For example, the output device may be a liquid crystal display (LCD), a light-emitting diode (LED) display device, a cathode ray tube (CRT) display device, or a projector, etc. The input device communicates with the processor 2001 and can receive user input in various ways. For example, the input device may be a mouse, keyboard, touchscreen device, or sensor device, etc.

[0133] In some embodiments, the memory 2003 stores program code 2010 for executing the solution of this application, and the processor 2001 can execute the program code 2010 stored in the memory 2003. That is, the computer device 2000 can implement the thread identification method provided in the method embodiment through the processor 2001 and the program code 2010 in the memory 2003. The program code 2010 may include one or more software modules. Optionally, the processor 2001 itself may also store program code or instructions for executing the solution of this application.

[0134] In a specific embodiment, the computer device 2000 of this application embodiment may correspond to the computer device in the above-described method embodiments. The processor 2001 in the computer device 2000 reads the instructions in the memory 2003, so that the computer device 2000 shown in FIG10 can perform all or part of the operations performed by the computer device.

[0135] In one possible implementation, the processor 2001 is used to obtain a first wake-up relationship and a first thread among multiple threads included in the application process, wherein the first thread is a thread in the application process; based on the first thread and the first wake-up relationship, obtain a relationship path of the first thread, wherein a node on the relationship path corresponds to a thread in the application process, there is a wake-up relationship between two adjacent nodes on the relationship path, and the head node and tail node of the relationship path correspond to the first thread; identify a second thread through the relationship path, wherein the second thread is located on the relationship path and is different from the first thread.

[0136] Other alternative implementation methods are described in the above method embodiments and will not be repeated here.

[0137] The computer device 2000 can also correspond to the thread identification device shown in Figure 9 above, where each functional module is implemented in software by the computer device 2000. In other words, the functional modules included in the thread identification device are generated by the processor 2001 of the computer device 2000 reading the program code 2010 stored in the memory 2003.

[0138] In the thread identification method shown in Figure 3, each step is completed through the integrated logic circuitry of the processor in the computer device 2000 or through software instructions. The steps of the method disclosed in this application can be directly implemented by the hardware processor, or by a combination of hardware and software modules within the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. Since this storage medium is located in memory, the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method; to avoid repetition, these will not be described in detail here.

[0139] It should be understood that the aforementioned processor can be a CPU, or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting the Advanced Reduced Instruction Set Computing (RISC) machine (ARM) architecture.

[0140] Furthermore, in an alternative embodiment, the memory described above may include read-only memory and random access memory, and provide instructions and data to the processor. The memory may also include non-volatile random access memory. For example, the memory may also store device type information.

[0141] The memory can be volatile or non-volatile, or may include both. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which serves as an external cache. Many forms of RAM are available by way of example, but not limitation. Examples include static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).

[0142] This application also provides a computer-readable storage medium storing at least one instruction, which is loaded and executed by a processor to enable the computer to implement any of the thread identification methods described above.

[0143] This application also provides a computer program (product) that, when executed by a computer, causes the processor or computer to perform the corresponding steps and / or processes in the above method embodiments.

[0144] This application also provides a chip, including a processor, for calling and executing instructions stored in a memory, causing a communication device with the chip installed to execute any of the above thread identification methods.

[0145] This application embodiment also provides another chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute any of the above thread identification methods.

[0146] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to this application are generated, in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk), etc.

[0147] Those skilled in the art will recognize that the method steps and modules described in conjunction with the embodiments disclosed herein can be implemented in software, hardware, firmware, or any combination thereof. To clearly illustrate the interchangeability of hardware and software, the steps and components of each embodiment have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0148] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0149] When implemented using software, it can be implemented wholly or partially as a computer program product. This computer program product includes one or more computer program instructions. As an example, the methods of this application embodiment can be described in the context of machine-executable instructions, such as program modules that execute on a device on a real or virtual processor of the target. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc., which perform specific tasks or implement specific abstract data structures. In various embodiments, the functionality of program modules can be combined or divided among the described program modules. The machine-executable instructions for the program modules can execute within a local or distributed device. In a distributed device, the program modules can reside on both local and remote storage media.

[0150] Computer program code used to implement the methods of the embodiments of this application may be written in one or more programming languages. This computer program code may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus, such that when executed by the computer or other programmable data processing apparatus, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a computer, partially on a computer, as a standalone software package, partially on a computer and partially on a remote computer, or entirely on a remote computer or server.

[0151] In the context of the embodiments of this application, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, etc.

[0152] Examples of signals may include electrical, optical, radio, sound, or other forms of propagation signals, such as carrier waves, infrared signals, etc.

[0153] A machine-readable medium can be any tangible medium that contains or stores programs for or relating to an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. More detailed examples of machine-readable storage media include electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0154] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be found in the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

[0156] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0157] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0158] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or other computer equipment, etc.) to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0159] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items that have substantially the same function and purpose. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor does it limit the quantity or order of execution. It should also be understood that although the following description uses the terms "first," "second," etc., to describe various elements, these elements should not be limited by the terms. These terms are merely used to distinguish one element from another. For example, without departing from the scope of various examples, a first image can be referred to as a second image, and similarly, a second image can be referred to as a first image. Both the first image and the second image can be images, and in some cases, they can be separate and distinct images.

[0160] It should also be understood that, in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0161] In this application, the term "at least one" means one or more, and the term "multiple" means two or more. For example, multiple second messages refer to two or more second messages. The terms "system" and "network" are often used interchangeably in this document.

[0162] It should be understood that the terminology used in the description of the various examples herein is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.

[0163] It should also be understood that the term "and / or" as used herein refers to and covers any and all possible combinations of one or more of the associated listed items. The term "and / or" describes an association between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " in this application generally indicates that the preceding and following related objects are in an "or" relationship.

[0164] It should also be understood that the term “comprising” (also referred to as “includes”, “including”, “comprises” and / or “comprising”) as used in this specification specifies the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0165] It should also be understood that the terms “if” and “if” can be interpreted as meaning “when” or “upon”, or “in response to determination” or “in response to detection”. Similarly, depending on the context, the phrases “if determination…” or “if detection [the stated condition or event]” can be interpreted as meaning “when determination…”, or “in response to determination…”, or “when detection [the stated condition or event]” or “in response to detection [the stated condition or event]”.

[0166] It should be understood that determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information.

[0167] It should also be understood that the phrases "an embodiment," "an embodiment," and "a possible implementation" used throughout the specification mean that a specific feature, structure, or characteristic related to an embodiment or implementation is included in at least one embodiment of this application. Therefore, the phrases "in an embodiment," "an embodiment," or "a possible implementation" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0168] The above description is only an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A thread identification method, characterized in that, The method includes: Obtain the first wake-up relationship and the first thread among multiple threads included in the application process, wherein the first thread is a thread in the application process; The relationship path of the first thread is obtained based on the first thread and the first wake-up relationship. A node on the relationship path corresponds to a thread in the application process. There is a wake-up relationship between two adjacent nodes on the relationship path. The head node and the tail node of the relationship path correspond to the first thread. The second thread is identified through the relationship path, and the second thread is located on the relationship path and is different from the first thread.

2. The method according to claim 1, characterized in that, The plurality of threads refers to all threads included in the application process, and the first wake-up relationship is determined by the wake-up events recorded by the application process when it has completed running; The step of obtaining the relationship path of the first thread based on the first thread and the first wake-up relationship includes: A wake-up relationship tree is obtained based on the first wake-up relationship. The parent node and child node in the wake-up relationship tree are in a wake-up and being woken up relationship. The root node and leaf node of the wake-up relationship tree both correspond to the first thread. On the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

3. The method according to claim 1, characterized in that, The plurality of threads are two threads of the application process, and the first wake-up relationship is determined by the wake-up event currently running in the application process; The step of obtaining the relationship path of the first thread based on the first thread and the first wake-up relationship includes: A first relation tree is created based on the first wake-up relationship, where the parent node and child node in the first relation tree have a wake-up and wake-up relationship. The second wake-up relationship is obtained by the wake-up event of the next run of the application process. The first relationship tree is updated based on the second wake-up relationship. This process is repeated until the wake-up relationship tree is obtained. The root node and leaf node of the wake-up relationship tree both correspond to the first thread. On the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

4. The method according to claim 1, characterized in that, The plurality of threads are two threads of the application process, and the first wake-up relationship is determined by the wake-up event currently running in the application process; The step of obtaining the relationship path of the first thread based on the first thread and the first wake-up relationship includes: The second relationship tree is updated based on the first wake-up relationship to obtain the first relationship tree. The second relationship tree is obtained based on the wake-up event of the last run of the application process. The parent node and child node in the second relationship tree are wake-up and wake-up relationship. A wake-up relationship tree is obtained based on the first relationship tree, wherein the root node and leaf node of the wake-up relationship tree both correspond to the first thread; On the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

5. The method according to claim 3 or 4, characterized in that, The method further includes: Based on the dependency probability of the first wake-up relationship, it is identified whether the woken-up thread in the first wake-up relationship is the second thread, and the dependency probability indicates the probability that the path of the first wake-up relationship on the first relationship tree is the relationship path.

6. The method according to claim 5, characterized in that, The dependency probability is the ratio of the first count to the second count. The first count is the number of times the awakened thread in the first wake-up relationship has appeared on the relationship path in history, and the second count is the number of times the wake-up event corresponding to the first wake-up relationship has run in history.

7. The method according to any one of claims 1-6, characterized in that, The process of identifying the second thread through the relationship path includes: Identify the third thread on the relationship path, excluding the first thread; Based on the frequency with which the third thread appears on the relational path, identify whether the third thread is the second thread.

8. The method according to claim 7, characterized in that, The step of identifying whether the third thread is the second thread based on the frequency of the third thread appearing on the relationship path includes: Based on the frequency of the third thread appearing on the relationship path and related indicators, it is determined whether the third thread is the second thread. The related indicators include one or more of the third thread's average priority, average blocking time, total number, or average runtime.

9. The method according to any one of claims 1-8, characterized in that, After identifying the second thread through the relationship path, the process further includes: If the first thread is a critical thread, the execution priority of the second thread in the application process is increased, where the critical thread is a thread related to user interaction. If the first thread is not the critical thread, reduce the execution priority of the second thread in the application process.

10. The method according to claim 9, characterized in that, The execution priority includes one or more of scheduling priority or allocation priority, wherein the allocation priority indicates the performance priority of resource allocation.

11. The method according to claim 9 or 10, characterized in that, Increasing the execution priority of the second thread in the application process includes: Configure the second thread as a real-time thread, with the execution priority of the real-time thread being higher than that of the non-real-time thread; or, The second thread is added to the list of high-priority policies in the configuration file corresponding to the application process. The high-priority policies are used to increase the execution priority of the threads in the policy list in the runtime environment corresponding to the configuration file. Alternatively, the second thread can be added to the high-priority scheduling group corresponding to the application process, whereby the high-priority scheduling group is used to increase the execution priority of threads within the high-priority scheduling group.

12. A thread identification device, characterized in that, The device includes: The first acquisition module is used to acquire the first wake-up relationship and the first thread among multiple threads included in the application process, wherein the first thread is a thread in the application process; The second acquisition module is used to acquire the relationship path of the first thread based on the first thread and the first wake-up relationship. A node on the relationship path corresponds to a thread in the application process. There is a wake-up relationship between two adjacent nodes on the relationship path. The head node and the tail node of the relationship path correspond to the first thread. An identification module is used to identify a second thread through the relationship path, wherein the second thread is located on the relationship path and is different from the first thread.

13. The apparatus according to claim 12, characterized in that, The plurality of threads refers to all threads included in the application process, and the first wake-up relationship is determined by the wake-up events recorded by the application process when it has completed running; The second acquisition module is used to acquire a wake-up relationship tree based on the first wake-up relationship, wherein the parent node and child node in the wake-up relationship tree are in a wake-up and being woken up relationship, and the root node and leaf node of the wake-up relationship tree both correspond to the first thread; on the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

14. The apparatus according to claim 12, characterized in that, The plurality of threads are two threads of the application process, and the first wake-up relationship is determined by the wake-up event currently running in the application process; The second acquisition module is used to create a first relationship tree based on the first wake-up relationship, wherein the parent node and child node in the first relationship tree are in a wake-up and wake-up relationship; The second wake-up relationship is obtained by the wake-up event of the next run of the application process. The first relationship tree is updated based on the second wake-up relationship, and so on, until the wake-up relationship tree is updated. The root node and leaf node of the wake-up relationship tree both correspond to the first thread. On the wake-up relationship tree, the relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node.

15. The apparatus according to claim 12, characterized in that, The plurality of threads are two threads of the application process, and the first wake-up relationship is determined by the wake-up event currently running in the application process; The second acquisition module is used to update the second relationship tree based on the first wake-up relationship to obtain the first relationship tree. The second relationship tree is obtained based on the wake-up event of the last run of the application process. The parent node and child node in the second relationship tree are in a wake-up and being woken up relationship. The wake-up relationship tree is obtained based on the first relationship tree. The root node and leaf node of the wake-up relationship tree both correspond to the first thread. The relationship path is obtained by tracing back from the leaf node corresponding to the first thread to the root node in the wake-up relationship tree.

16. The apparatus according to claim 14 or 15, characterized in that, The identification module is further configured to identify whether the awakened thread in the first wake-up relationship is a second thread based on the dependency probability of the first wake-up relationship, wherein the dependency probability indicates the probability that the path of the first wake-up relationship on the first relationship tree is the relationship path.

17. The apparatus according to claim 16, characterized in that, The dependency probability is the ratio of the first count to the second count. The first count is the number of times the awakened thread in the first wake-up relationship has appeared on the relationship path in history, and the second count is the number of times the wake-up event corresponding to the first wake-up relationship has run in history.

18. The apparatus according to any one of claims 12-17, characterized in that, The identification module is used to determine a third thread on the relationship path other than the first thread; and to identify whether the third thread is the second thread based on the frequency of the third thread appearing on the relationship path.

19. The apparatus according to claim 18, characterized in that, The identification module is used to identify whether the third thread is the second thread based on the frequency of the third thread appearing on the relationship path and related indicators. The related indicators include one or more of the third thread's average priority, average blocking time, total number, or average runtime.

20. The apparatus according to any one of claims 12-19, characterized in that, The device further includes: An adjustment module is used to increase the execution priority of the second thread in the application process when the first thread is a critical thread, wherein the critical thread is a thread related to user interaction; and to decrease the execution priority of the second thread in the application process when the first thread is not the critical thread.

21. The apparatus according to claim 20, characterized in that, The execution priority includes one or more of scheduling priority or allocation priority, wherein the allocation priority indicates the performance priority of resource allocation.

22. The apparatus according to claim 20 or 21, characterized in that, The adjustment module is used to configure the second thread as a real-time thread, wherein the execution priority of the real-time thread is higher than that of the non-real-time thread; or, to add the second thread to the high-priority policy in the configuration file corresponding to the application process, wherein the high-priority policy is used to increase the execution priority of the threads in the policy list in the runtime environment corresponding to the configuration file; or, to add the second thread to the high-priority scheduling group corresponding to the application process, wherein the high-priority scheduling group is used to increase the execution priority of the threads in the high-priority scheduling group.

23. A computer device, characterized in that, The computer device includes: a processor coupled to a memory, the memory storing at least one program instruction or code, the at least one program instruction or code being loaded and executed by the processor to enable the computer device to implement the thread identification method according to any one of claims 1-11.

24. A computer-readable storage medium, characterized in that, The computer storage medium stores at least one instruction, which is loaded and executed by a processor to enable the computer to implement the thread identification method as described in any one of claims 1-11.

25. A computer program product, characterized in that, The computer program product includes: computer program code, which is loaded and executed by a computer to enable the computer to implement the thread identification method according to any one of claims 1-11.

Images