Method, device and equipment for processing non-response of application program

Abstract

The embodiment of the invention provides an application non-response processing method, device and equipment, and the method comprises the steps: obtaining a current task which is being executed by a main thread of an application and a historical task sequence in response to the detection of the application non-response of the application, the historical task sequence comprises a plurality of historical tasks which are executed by the main thread, the plurality of historical tasks are arranged according to execution time; based on the current task and the delay duration of a plurality of historical tasks in the historical task sequence, a time-consuming task set corresponding to the non-response of the application program is determined, and the delay duration of the tasks is determined by the actual execution time and the preset execution time of the tasks. The time-consuming task set causing no response of the application program is determined according to the delay duration of the multiple historical tasks including the current task, the task range causing no response of the application program can be accurately obtained, and then the cause reason can be analyzed so as to improve the performance of the application program.

Description

Technical Field

[0001] The embodiments of the present disclosure relate to the field of computer technology, and more particularly to a method, device, and apparatus for processing an unresponsive application. Background Art

[0002] In the operating system, some messages in the main thread of the application need to be completed within a predetermined time. If they are not processed beyond the predetermined time, the system will determine that the application is unresponsive (Application Not Responding, ANR). When the application is unresponsive, the user will be given the choice of continuing to wait or forcibly closing it.

[0003] Currently, when an application becomes unresponsive, it is impossible to accurately locate the task that causes the application to become unresponsive, and thus the analysis of the cause of the application becoming unresponsive is also inaccurate. Summary of the invention

[0004] The embodiments of the present disclosure provide a method, apparatus and device for processing an unresponsive application.

[0005] In a first aspect, an embodiment of the present disclosure provides a method for processing an application that is unresponsive, comprising: in response to detecting that an application is unresponsive, obtaining a current task being executed by a main thread of the application and a historical task sequence, wherein the historical task sequence includes a plurality of historical tasks that have been executed by the main thread, and the plurality of historical tasks are arranged according to execution time;

[0006] Based on the delay durations of the current task and multiple historical tasks in the historical task sequence, a set of time-consuming tasks corresponding to the unresponsiveness of the application is determined, wherein the delay duration of the task is determined by the actual execution time and the scheduled execution time of the task.

[0007] In a second aspect, an embodiment of the present disclosure provides a device for processing an application program that is unresponsive, including:

[0008] an acquisition unit, configured to acquire, in response to detecting that an application is unresponsive, a current task being executed by a main thread of the application and a historical task sequence, wherein the historical task sequence includes a plurality of historical tasks executed by the main thread, and the plurality of historical tasks are arranged according to execution time;

[0009] The first determination unit is used to determine a set of time-consuming tasks corresponding to the unresponsiveness of the application based on the delay durations of the current task and multiple historical tasks in the historical task sequence, wherein the delay duration of the task is determined by the actual execution time and the scheduled execution time of the task.

[0010] In a third aspect, an embodiment of the present disclosure provides an electronic device, including: a processor and a memory;

[0011] The memory stores computer-executable instructions;

[0012] The processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the method described in the first aspect and various possible designs of the first aspect.

[0013] In a fourth aspect, an embodiment of the present disclosure provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer execution instructions. When a processor executes the computer execution instructions, the method described in the first aspect and various possible designs of the first aspect are implemented.

[0014] In a fifth aspect, an embodiment of the present disclosure provides a computer program product, including a computer program, which, when executed by a processor, implements the method described in the first aspect and various possible designs of the first aspect.

[0015] The present embodiment provides a method, apparatus and device for processing application unresponsiveness. The method obtains the current task being executed by the main thread of the application and a historical task sequence in response to detecting that the application is unresponsive, wherein the historical task sequence includes multiple historical tasks that have been executed by the main thread, and the multiple historical tasks are arranged according to execution time; based on the current task and the delay duration of multiple historical tasks in the historical task sequence, a time-consuming task set corresponding to the application unresponsiveness is determined, wherein the delay duration of the task is determined by the actual execution time and the scheduled execution time of the task, thereby realizing the determination of the time-consuming task set causing the application unresponsiveness based on the delay duration of multiple historical tasks including the current task, so as to obtain a more accurate range of tasks causing the application unresponsiveness, which is helpful to analyze the cause so as to improve the performance of the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0017] Figure 1 Schematic diagram of the process of processing the unresponsive application provided in the embodiment of the present disclosure Figure 1 ;

[0018] Figure 2Schematic diagram of the process of processing the unresponsive application provided in the embodiment of the present disclosure Figure 2 ;

[0019] Figure 3 A schematic diagram for determining the first boundary of a set of time-consuming tasks;

[0020] Figure 4 A schematic diagram for determining the second boundary of the set of time-consuming tasks;

[0021] Figure 5 A structural block diagram of a device for processing an unresponsive application provided by an embodiment of the present disclosure;

[0022] Figure 6 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solution and advantages of the embodiments of the present disclosure clearer, the technical solution in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present disclosure.

[0024] One or more applications can be installed in the terminal device, and the operating system creates the main thread of each application when the application is running. The main thread of the application is usually responsible for processing tasks related to user interface interaction. The main thread can correspond to a message queue, which can store tasks to be processed. The above-mentioned tasks to be processed can come from events caused by user input (keyboard events, mouse events), from system events (such as window manager events, timer events), from internal events of the application (such as data update notifications, task completion notifications), or from network events, etc.

[0025] The main thread will periodically check the message queue, take out tasks from the message queue and process them in a certain order (such as first-in-first-out order). After a task is processed, the main thread will continue to check the next task in the message queue.

[0026] The message queue may include multiple task messages, each of which corresponds to an execution time (i.e., a scheduled execution time), and the execution time of the task message refers to the time when the task message is executed. The execution time may be an absolute time, such as the time measured from the time zero of the electronic device.

[0027] For each task message, the execution time corresponding to the task message indicates when the task message should be executed. Multiple task messages in the message queue are arranged in the order of execution time.

[0028] The above-mentioned multiple task messages include one or more critical task messages. The operating system of the terminal device can monitor the execution of the critical task messages in the message queue by the main thread. If the main thread of the application does not process the task indicated by the critical task message at the execution time corresponding to the critical message, or the task indicated by the critical task message is not completed, the operating system will determine that the application is unresponsive, that is, the application ANR occurs. The operating system will prompt the user when it detects that the application is unresponsive.

[0029] In order to solve the ANR problem of the application and ensure the normal operation of the application, it is necessary to locate the task message that causes the ANR and analyze the cause of the ANR based on the location result.

[0030] However, there are many reasons for the timeout of pending messages. It may be that the pending message itself takes too long to be completed within the corresponding time, or there are too many messages before the pending message, or the messages before the pending message take too long to be processed. Currently, the location of the task message that causes the timeout is not accurate enough, so the accuracy of the analysis result of the cause of ANR is not high.

[0031] The embodiments of the present disclosure provide a method, device and apparatus for processing an unresponsive application program to solve the above-mentioned problem.

[0032] refer to Figure 1 , Figure 1 Schematic diagram of the process of processing the unresponsive application provided in the embodiment of the present disclosure Figure 1 The method of this embodiment can be applied in an electronic device, and the method includes:

[0033] S101: In response to detecting that an application is unresponsive, obtaining a current task being executed by a main thread of the application and a historical task sequence, wherein the historical task sequence includes a plurality of historical tasks that have been executed by the main thread, and the plurality of historical tasks are arranged according to execution time.

[0034] The execution subject of the method for processing application non-response can be various types of electronic devices, such as various terminal devices or servers. One or more applications can be run in the electronic device.

[0035] The above application program may be any one of a plurality of application programs running in the electronic device.

[0036] The main thread of an application can handle tasks related to the application's user interface, such as creating and displaying forms, processing user input, and updating the user interface.

[0037] Application unresponsiveness means that the application interface is unresponsive, the application cannot be operated, the application cannot be closed, etc. The operating system can detect application unresponsiveness, for example, the operating system can use a timeout mechanism to detect application unresponsiveness. For example, a scheduled execution time is set for a key task executed by the main thread. If the above key task is not executed within the scheduled execution time, that is, the timeout occurs, it can be considered that the application is unresponsive.

[0038] When it is detected that the application is unresponsive, the operating system may read the task information of the currently executing task from the main thread, and obtain a historical task sequence consisting of multiple historical tasks that have been completed. The execution time of the historical task may include the actual start execution time and the execution end time of the historical task.

[0039] It should be noted that the scheduled execution time, actual execution start time, and execution end time in the present disclosure may be absolute time.

[0040] S102: Determine a set of time-consuming tasks corresponding to the unresponsiveness of the application program based on the delay duration of the current task and multiple tasks in the historical task sequence, wherein the delay duration of the task is determined by the actual start execution time and the scheduled execution time of the task.

[0041] The delay time of each task can be determined by the time difference between the actual start execution time and the scheduled execution time of the task. For example, if the actual start execution time of the current task is Ts1 and the scheduled execution time of the current task is Tp1, then the delay time of the current task is Td=Ts1-Tp1.

[0042] The time-consuming tasks that cause the application to be unresponsive can be located based on the delay of the task. If the delay of a task is large, it can be considered that there is a long-time task before the task. If the delay of a task is small, it is possible that the time-consuming task is generated after the task. Therefore, the time-consuming task set can be determined starting from the current task based on the size of the delay.

[0043] In one example, the delay duration of the current task can be determined, as well as the delay duration of multiple historical tasks in the historical task sequence. The current task and one of the multiple historical tasks whose delay duration is greater than the timeout duration threshold are taken as the first boundary of the time-consuming set; and one of the multiple historical tasks whose delay duration is less than the first duration threshold is taken as the second boundary. If the execution time of the second boundary is earlier than the execution time of the first boundary, the first boundary, the second boundary, and one or more tasks therebetween are taken as the time-consuming task set. If the execution time of the second boundary is later than the first boundary, the second boundary is re-determined from the above multiple historical tasks.

[0044] In this embodiment, in response to detecting that an application is unresponsive, the current task being executed by the main thread of the application and a historical task sequence are obtained, the historical task sequence includes multiple historical tasks that have been executed by the main thread, and the multiple historical tasks are arranged according to execution time; based on the delay duration of the current task and multiple historical tasks in the historical task sequence, a time-consuming task set corresponding to the unresponsiveness of the application is determined, wherein the delay duration of the task is determined by the actual execution time and the scheduled execution time of the task, thereby realizing the determination of the time-consuming task set that causes the unresponsiveness of the application based on the delay duration of multiple historical tasks including the current task, so that a more accurate range of tasks that cause the unresponsiveness of the application can be obtained, which in turn helps to analyze the causes in order to improve the performance of the application.

[0045] In some embodiments, the above step S102 includes:

[0046] First, the delay durations corresponding to the multiple historical tasks are obtained from the historical task message queue, wherein the historical task message queue is used to store the first task information of the tasks completed by the main thread, and the first task information includes the delay duration.

[0047] Secondly, based on the delay duration of the current task and multiple historical tasks, the time-consuming task set is determined.

[0048] In these embodiments, a historical task message queue may be created in advance, and the historical task message queue is used to store the first task information of the tasks completed by the main thread.

[0049] For each historical task, the actual start execution time and the execution end time of the historical task can be recorded, and then the first task information of the historical task can be determined according to one or more of the actual start execution time and the execution end time of each historical task.

[0050] For each historical task, the first task information of the historical task may include a task identifier and a task delay duration. That is, for each historical task, the delay duration of the historical task may be calculated based on the actual start execution time and the scheduled execution time of the historical task.

[0051] In addition, the first task information of the historical task may also include the execution time of the task. For each historical task, the execution time of the historical task is equal to the time difference between the execution end time of the historical task and the actual execution start time of the historical task.

[0052] Illustratively, the first task information of the historical task B can be represented as follows: Task B {task identifier B, delay duration Td11, execution duration Te12}.

[0053] The above execution subject can obtain the delay duration of each of the multiple historical tasks from the historical task message queue.

[0054] In the historical task message queue, the first task information corresponding to each of the multiple historical tasks can be arranged according to their respective scheduled execution times, for example, in the order of execution time from the beginning to the end, that is, in the historical task message queue, the first task information of the historical task with the later scheduled execution time is located after the first task information of the historical task with the earlier scheduled execution time.

[0055] It should be noted that obtaining the historical task sequence in the above step S101 may include obtaining the historical task sequence from the above historical task message queue.

[0056] In these embodiments, by creating a historical task message queue for the tasks executed by the main thread, and storing the first task information corresponding to each history in the historical task message queue in sequence, it is helpful to quickly determine the time-consuming task set when the application becomes unresponsive.

[0057] In some embodiments, the method for processing an application being unresponsive further includes the following steps:

[0058] First, in response to any task being completed by the main thread, the start execution time of the task is obtained.

[0059] Secondly, the scheduled execution time of the task is obtained from the pending task message queue, and the delay duration of the task is determined according to the scheduled execution time and the start execution time; wherein the pending task message queue stores the second task information of each of the multiple pending tasks, and the second task information includes the scheduled execution time of the task.

[0060] Finally, the first task information of the task including the delay duration of the task is written to the end of the historical task message queue.

[0061] In these embodiments, a pending task message queue can be created for multiple pending tasks of the main thread. The pending task message queue can store the second task messages corresponding to each of the multiple pending tasks. The second task message of each pending task can include a task identifier and a scheduled execution time. Schematically, the second task information of a pending message A is as follows: pending message A {identifier A, scheduled execution time Ts21}.

[0062] After the main thread completes the execution of each task, the execution subject can obtain the second task information corresponding to the task from the pending task message queue according to the task identifier, and calculate the delay duration according to the actual start execution time and the scheduled execution time of the task. Then, the first task information of the task including the delay duration and execution duration is generated, and the first task information of the task is stored at the end of the historical task message queue.

[0063] In some application scenarios, the main thread of the application can obtain the task from the head of the queue of the pending task message queue and execute it.

[0064] In some application scenarios, if the pending task corresponding to the head of the above-mentioned pending task message queue is executed, the pending task is a historical task, and after the first task information of the historical task is generated, the second task information of the pending task can be removed from the pending task message queue, thereby obtaining an updated pending task message queue.

[0065] In these embodiments, a pending task message queue is created for multiple pending tasks corresponding to the main thread, and the second task information of each pending task is stored in the pending task message queue in order from the front to the back according to the scheduled execution time. On the one hand, it helps to schedule the execution of each task, and on the other hand, it provides data support for determining the first task information of the task that has been executed.

[0066] refer to Figure 2 , Figure 2 Schematic diagram of the process of processing the unresponsive application provided in the embodiment of the present disclosure Figure 2 The method of this embodiment can be applied in an electronic device, and the method includes:

[0067] S201: In response to detecting that the application is unresponsive, obtaining a current task being executed by a main thread of the application and a historical task sequence, wherein the historical task sequence includes a plurality of historical tasks that have been executed by the main thread, and the plurality of historical tasks are arranged according to execution time.

[0068] The specific implementation of the above step S201 can refer to Figure 1The description of step S101 of the illustrated embodiment is not repeated here.

[0069] S202: In response to the delay duration of the current task being greater than or equal to a preset timeout duration, determining that the current task is a first boundary of a set of time-consuming tasks.

[0070] In some embodiments, the preset timeout period here may be the timeout period corresponding to the key task to be executed by the main thread. The above timeout period may vary depending on the key task. As an illustrative example, the timeout period of the above key task may be, for example, 5 seconds.

[0071] In one example, when a critical task is created and stored in a pending task message queue, a clock for timing can be created. The timing duration of the clock is the time difference between the creation time and the scheduled execution time. After the above clock timing time is equal to the above time difference, an event can be triggered to the operating system, and the operating system detects whether the critical task has been executed based on the event. If it has been executed, the application is not unresponsive; if it has not been executed, the application is unresponsive. The operating system can obtain the start execution time of the current task from the main thread, and obtain the scheduled execution time of the current task from the pending task message queue, and calculate the delay duration of the current task based on the start execution time and the scheduled execution time.

[0072] Then, it is detected whether the delay duration of the current task is greater than the preset timeout duration. If the delay duration of the current task is greater than or equal to the preset timeout duration, it is determined that the task causing the application to be unresponsive is before the current task (including the current task). The current task can be used as the first boundary of the time-consuming task set.

[0073] S203: In response to the delay duration of the current task being less than the preset timeout duration, determine the first historical task whose delay duration is greater than or equal to the preset timeout duration from the historical task sequence in order from back to front, and use the historical task as the first boundary of the time-consuming set.

[0074] In step S202, if it is determined that the delay duration of the current task is less than the preset timeout duration, it can be considered that the time-consuming task causing the application to be unresponsive is before the current task.

[0075] Whether the delay time of each historical task in the historical task sequence is greater than the preset timeout time can be determined in order from back to front. The first historical task whose delay time is greater than the preset timeout time determined in the above manner is used as the first boundary.

[0076] Please refer to Figure 3 , Figure 3A schematic diagram for determining the first boundary of a set of time-consuming tasks. When the main thread of the application is executing each task in the pending task message queue, if the key task among the above multiple tasks does not respond in time, it is determined that the application ANR occurs. The process of the operating system detecting the ANR, sending the ANR signal, receiving the signal, and then obtaining the information of the task being executed from the main thread is performed in parallel with the execution of the task by the main thread of the application. If the above process takes a long time, the main thread may have executed several tasks in the process. Therefore, the current task or the last historical task in the historical task sequence cannot be directly used as the first boundary. The first boundary needs to be determined based on the delay duration of the current task or each historical task. For example Figure 3 In the example, it is assumed that task 16 is a critical task, which is not executed at the specified execution time, and the operating system triggers ANR based on this. In the process of triggering ANR, sending ANR signal, receiving ANR signal and obtaining information about the executing task from the main thread, the main thread does not stop executing the task. Therefore, the executing thread obtained from the main thread may be the task after the task where ANR occurs.

[0077] like Figure 3 As shown, the historical task sequence of the historical tasks executed by the main thread of the application includes historical tasks 1, 2, ... 21 arranged from the beginning to the end according to the execution time. The operating system detects that an ANR occurs (assuming Figure 3 The task that has ANR is task 16, but the operating system cannot directly know that task 16 has ANR, and the main thread has executed multiple tasks after task 16 is completed), and the current task is detected as task 22 from the task information currently executed by the main thread. The pending tasks of the main thread include tasks 23, 24, etc. The operating system can determine the delay duration of the current task 22. If the delay duration is less than the preset timeout duration, it starts from the last one of the historical task sequence, that is, historical task 21, and obtains the delay duration corresponding to each historical task in the above historical task sequence from back to front. Assuming that the preset timeout period is 5000ms, the delay period Td of historical task 21 is 1000ms, the delay period Td of historical task 20 is 2000ms, and the delay period Td of historical task 19 is 6000ms. Since historical task 19 is the first historical task with a delay period greater than the preset timeout period of 5000ms obtained by detecting the historical task sequence from back to front, historical task 19 can be used as the first boundary of the time-consuming task set.

[0078] In the above steps S202 and S203, if the delay duration of the current task is greater than or equal to the preset timeout duration, the current task is the first boundary. If the delay duration of the current task is less than the preset timeout duration, the first task with a delay duration greater than the preset timeout duration determined from the back to the front in the historical task sequence is taken as the first boundary, so that a more accurate first boundary can be obtained.

[0079] S204: Determine, in order from back to front, at least one first historical task whose delay duration is less than a first duration threshold from the historical task sequence.

[0080] In order to determine the second boundary of the time-consuming task set corresponding to the ANR, we can start from the last task in the historical task sequence and obtain the delay duration of each historical task in sequence. Then, we check whether the delay duration of each task is less than the first duration threshold. If the delay duration of a task is less than the first duration threshold, the task is the first historical task.

[0081] The first duration threshold may be a relatively short duration, such as 200 ms. If the delay duration of a task is less than 200 ms, it may be considered that the task has no delay.

[0082] At least one first historical task can be determined through the above operations.

[0083] S205: Determine a second boundary of the time-consuming task set from at least one first historical task.

[0084] A first historical task may be determined from at least one first historical task according to a preset selection rule as the second boundary of the time-consuming task set.

[0085] In some implementations, the above step S205 includes the following steps:

[0086] First, the time difference between the preset timeout duration and the execution time of the current task is determined.

[0087] Secondly, according to the time difference and the execution time of each historical task, at least one second historical task is determined from the historical task sequence in a preset order, and the timeout interval is composed of the at least one second historical task.

[0088] The above preset order may be an order from back to front.

[0089] Finally, a first historical task whose execution time is earlier than any second historical task in the timeout interval and which is closest to the timeout interval is used as the second boundary.

[0090] Combine the following Figure 4 To explain, Figure 4A schematic diagram for determining the second boundary of the time-consuming task set. Assume that the current task being processed by the operating system from the main thread of the application is task 16. The time when the operating system detects ANR is T current , the current task starts execution at T before , we can determine that the execution time of the current task is T current With T before The time difference between: T' = T current -T before .

[0091] Starting from the last historical task 15 in the historical task sequence, the execution time of each historical task is accumulated from the back to the front (from left to right in the figure). The multiple historical tasks covered by the above time difference are regarded as multiple second historical tasks.

[0092] Specifically, one or more second historical tasks may be determined based on the following formulas (1) and (2):

[0093]

[0094] Among them, D ANR is the preset timeout duration, n is an integer less than or equal to 15. x is an integer less than 15 and greater than or equal to 1. n is the execution time of the nth historical task; the execution time of each of the historical tasks 15, 14, ..., 1 can be substituted into the above formulas (1) and (2), and x is determined to be 10 through the above formula.

[0095] It can be understood that the above 15 may be the identifier of the last task in the historical task sequence, and actually n may be any integer representing the last historical task in the historical task sequence.

[0096] The timeout interval may be composed of one or more second historical tasks determined from the historical task sequence. Figure 4 The left endpoint of the timeout interval is task 15, and the right endpoint is task 10. Multiple historical tasks between the left endpoint and the right endpoint (including the left endpoint and the right endpoint) constitute the timeout interval.

[0097] After the timeout interval is determined, a first historical task whose execution time is earlier than any second historical task in the timeout interval and is closest to the timeout interval is used as the second boundary of the time-consuming task set.

[0098] like Figure 4In the figure, the delay duration Td of task 9 is 100ms, the delay duration Td of task 8 is 500ms, the delay duration Td of task 7 is 210ms, the delay duration Td of task 6 is 20ms, and the delay duration Td of task 5 is 4ms. The delay durations of task 6 and task 5 are less than the first preset duration threshold, and both are first historical tasks. However, since task 6 is closest to the timeout interval, task 6 can be the second boundary of the time-consuming set. In other words, it can be considered that task 6 and task 5 have nothing to do with the ANR triggered this time. Since task 6 is closest to this ANR, the time-consuming task that causes the ANR is after task 6, and therefore, task 6 is used as the second boundary.

[0099] In the above implementation, the timeout interval is determined from the historical task sequence based on the difference between the preset timeout duration and the execution duration of the current task, as well as the execution duration of multiple historical tasks. Then, a first historical task whose execution time is earlier than any task in the timeout interval and is closest to the timeout interval is used as the second boundary. The above second boundary can be determined more accurately.

[0100] S206: assembling a time-consuming task set according to the first boundary and the second boundary and a plurality of historical tasks between the first boundary and the second boundary.

[0101] That is, the time-consuming task set includes the first boundary, the second boundary, and the historical tasks between the first boundary and the second boundary.

[0102] In this embodiment, the determination of the first boundary and the second boundary of the time-consuming task set and the details of determining the time-consuming task set based on the above-mentioned first boundary and the second boundary are described, so that a more precise time-consuming task set is determined by a more precise first boundary and the second boundary, providing an accurate range for locating the problem of unresponsive application.

[0103] exist Figure 1 and Figure 2 In some optional implementations of the illustrated embodiment, the method for processing the application being unresponsive further includes the following steps:

[0104] From the time-consuming task set, determine the target task that causes the application to become unresponsive according to the execution time of each task.

[0105] The execution time of each task in the time-consuming task set can be obtained from the historical task message queue to determine whether the execution time of each task is greater than a preset second time threshold. In some examples, the second time threshold can be equal to a preset timeout time.

[0106] One or more tasks in the time-consuming task set whose execution duration is greater than a preset second duration threshold may be used as target tasks.

[0107] The target task here can be the task that caused the application to become unresponsive.

[0108] After determining the target task, the hardware environment information of the electronic device, such as the CPU and memory, can be obtained according to the execution period corresponding to the target task, and the cause of the unresponsiveness of the application can be analyzed based on the above hardware environment information.

[0109] In these implementations, by determining the target task in the time-consuming task set according to the task execution time, the scope of tasks causing the application to be unresponsive can be further located, which helps to reduce the amount of calculation for analyzing the cause of the application to be unresponsive and reduce resource consumption.

[0110] Corresponding to the method for processing the unresponsive application in the above embodiment, Figure 5 A structural block diagram of a device for processing an application that is unresponsive provided by an embodiment of the present disclosure. For ease of explanation, only the parts related to the embodiment of the present disclosure are shown. Figure 5 The device 50 includes: an acquisition unit 501 and a first determination unit 502.

[0111] An acquisition unit 501 is used for acquiring, in response to detecting that the application is unresponsive, a current task being executed by a main thread of the application and a historical task sequence, wherein the historical task sequence includes a plurality of historical tasks that have been executed by the main thread, and the plurality of historical tasks are arranged according to execution time;

[0112] The first determination unit 502 is used to determine a set of time-consuming tasks corresponding to the unresponsiveness of the application program based on the delay durations of the current task and multiple historical tasks in the historical task sequence, wherein the delay duration of the task is determined by the actual execution time and the scheduled execution time of the task.

[0113] In some embodiments, the first determining unit 502 is further used to: obtain the delay durations corresponding to the plurality of historical tasks from the historical task message queue, wherein the historical task message queue is used to store first task information of the tasks completed by the main thread, and the first task information includes the delay duration;

[0114] Based on the delay duration of the current task and multiple historical tasks, a set of time-consuming tasks is determined.

[0115] In some embodiments, the device further includes a task adding unit (not shown in the figure), which is used to:

[0116] In response to any task being completed by the main thread, obtaining the start execution time of the task;

[0117] Obtaining the scheduled execution time of the task from the pending task message queue, and determining the delay duration of the task according to the scheduled execution time and the start execution time; wherein the pending task message queue stores the second task information of each of the plurality of tasks, and the second task information includes the scheduled execution time of the task;

[0118] The first task information of the task including the delay duration of the task is written to the end of the historical task message queue.

[0119] In some embodiments, the first determining unit 502 is further configured to:

[0120] In response to the delay duration of the current task being greater than or equal to the preset timeout duration, determining that the current task is a first boundary of the time-consuming task set;

[0121] In response to the delay of the current task being less than the preset timeout, the first historical task with a delay greater than or equal to the preset timeout is determined from the historical task sequence in order from back to front, and the historical task is used as the first boundary of the time-consuming set.

[0122] In some embodiments, the first determining unit 502 is further configured to:

[0123] Determine, from the historical task sequence in a backward order, at least one first historical task whose delay duration is less than a first duration threshold;

[0124] Determining a second boundary of the time-consuming task set from at least one first historical task;

[0125] A time-consuming task set is formed according to the first boundary and the second boundary and a plurality of historical tasks between the first boundary and the second boundary.

[0126] In some embodiments, the first determining unit 502 is further configured to:

[0127] Determine the time difference between the preset timeout duration and the execution time of the current task;

[0128] According to the time difference and the execution time of each historical task, at least one second historical task is determined from the historical task sequence in a preset order, and the at least one second historical task constitutes a timeout interval;

[0129] A first historical task whose execution time is earlier than any second historical task in the timeout interval and which is closest to the timeout interval is used as the second boundary.

[0130] In some embodiments, the apparatus 50 further includes a second determining unit (not shown in the figure), the second determining unit being configured to:

[0131] From the time-consuming task set, determine the target task that causes the application to become unresponsive according to the execution time of each task.

[0132] In order to implement the above embodiment, the embodiment of the present disclosure also provides an electronic device.

[0133] refer to Figure 6 , which shows a schematic diagram of the structure of an electronic device 600 suitable for implementing the embodiment of the present disclosure, and the electronic device 600 may be a terminal device or a server. The terminal device may include but is not limited to mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, personal digital assistants (PDAs), tablet computers, portable multimedia players (PMPs), vehicle terminals (such as vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0134] like Figure 6 As shown, the electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 to a random access memory (RAM) 603. Various programs and data required for the operation of the electronic device 600 are also stored in the RAM 603. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0135] Typically, the following devices may be connected to the I / O interface 605: input devices 606 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; output devices 607 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 608 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 609. The communication device 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 6 The electronic device 600 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead.

[0136] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

[0137] It should be noted that the computer-readable medium disclosed above may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that may be used by or in combination with an instruction execution system, device or device. In the present disclosure, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. This propagated data signal may take a variety of forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination of the above. The computer readable signal medium may also be any computer readable medium other than a computer readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0138] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device.

[0139] The computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device executes the method shown in the above embodiment.

[0140] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0141] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0142] The units involved in the embodiments described in the present disclosure may be implemented by software or hardware. The name of a unit does not limit the unit itself in some cases. For example, the first acquisition unit may also be described as a "unit for acquiring at least two Internet Protocol addresses".

[0143] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0144] In a first aspect, according to one or more embodiments of the present disclosure, a method for processing an unresponsive application is provided, comprising:

[0145] In response to detecting that the application is unresponsive, obtaining a current task being executed by a main thread of the application and a historical task sequence, wherein the historical task sequence includes a plurality of historical tasks that have been executed by the main thread, and the plurality of historical tasks are arranged according to execution time;

[0146] Based on the delay durations of the current task and multiple historical tasks in the historical task sequence, a set of time-consuming tasks corresponding to the unresponsiveness of the application is determined, wherein the delay duration of the task is determined by the actual execution time and the scheduled execution time of the task.

[0147] According to one or more embodiments of the present disclosure, based on the delay duration of the current task and multiple historical tasks in the historical task sequence, determining a set of time-consuming tasks corresponding to the unresponsive application includes:

[0148] Obtaining the delay durations corresponding to the multiple historical tasks from the historical task message queue, wherein the historical task message queue is used to store the first task information of the tasks completed by the main thread, and the first task information includes the delay duration;

[0149] Based on the delay duration of the current task and multiple historical tasks, a set of time-consuming tasks is determined.

[0150] According to one or more embodiments of the present disclosure, the method further includes:

[0151] In response to any task being completed by the main thread, obtaining the start execution time of the task;

[0152] Obtaining the scheduled execution time of the task from the pending task message queue, and determining the delay duration of the task according to the scheduled execution time and the start execution time; wherein the pending task message queue stores the second task information of each of the plurality of tasks, and the second task information includes the scheduled execution time of the task;

[0153] The first task information of the task including the delay duration of the task is written to the end of the historical task message queue.

[0154] According to one or more embodiments of the present disclosure, based on the delay duration of the current task and multiple historical tasks in the historical task sequence, determining a set of time-consuming tasks corresponding to the unresponsive application includes:

[0155] In response to the delay duration of the current task being greater than or equal to the preset timeout duration, determining that the current task is a first boundary of the time-consuming task set;

[0156] In response to the delay of the current task being less than the preset timeout, the first historical task with a delay greater than or equal to the preset timeout is determined from the historical task sequence in order from back to front, and the historical task is used as the first boundary of the time-consuming set.

[0157] According to one or more embodiments of the present disclosure, the method further includes:

[0158] Determine, from the historical task sequence in a backward order, at least one first historical task whose delay duration is less than a first duration threshold;

[0159] Determining a second boundary of the time-consuming task set from at least one first historical task;

[0160] A time-consuming task set is formed according to the first boundary and the second boundary and a plurality of historical tasks between the first boundary and the second boundary.

[0161] According to one or more embodiments of the present disclosure, determining a second boundary of a time-consuming task set from at least one first historical task includes:

[0162] Determine the time difference between the preset timeout duration and the execution time of the current task;

[0163] According to the time difference and the execution time of each historical task, at least one second historical task is determined from the historical task sequence in a preset order, and the at least one second historical task constitutes a timeout interval;

[0164] A first historical task whose execution time is earlier than any second historical task in the timeout interval and which is closest to the timeout interval is used as the second boundary.

[0165] According to one or more embodiments of the present disclosure, the method further includes:

[0166] From the time-consuming task set, determine the target task that causes the application to become unresponsive according to the execution time of each task.

[0167] In a second aspect, according to one or more embodiments of the present disclosure, a device for processing an application being unresponsive is provided, comprising:

[0168] an acquisition unit, configured to acquire, in response to detecting that the application is unresponsive, a current task being executed by a main thread of the application and a historical task sequence, wherein the historical task sequence includes a plurality of historical tasks that have been executed by the main thread, and the plurality of historical tasks are arranged according to execution time;

[0169] The first determination unit is used to determine a set of time-consuming tasks corresponding to the unresponsiveness of the application program based on the delay durations of the current task and multiple historical tasks in the historical task sequence, wherein the delay duration of the task is determined by the actual execution time and the scheduled execution time of the task.

[0170] According to one or more embodiments of the present disclosure, the first determining unit is further used to: obtain the delay durations corresponding to the plurality of historical tasks from the historical task message queue, wherein the historical task message queue is used to store the first task information of the task completed by the main thread, and the first task information includes the delay duration;

[0171] Based on the delay duration of the current task and multiple historical tasks, a set of time-consuming tasks is determined.

[0172] According to one or more embodiments of the present disclosure, the device further includes a task adding unit, which is used to:

[0173] In response to any task being completed by the main thread, obtaining the start execution time of the task;

[0174] Obtaining the scheduled execution time of the task from the pending task message queue, and determining the delay duration of the task according to the scheduled execution time and the start execution time; wherein the pending task message queue stores the second task information of each of the plurality of tasks, and the second task information includes the scheduled execution time of the task;

[0175] The first task information of the task including the delay duration of the task is written to the end of the historical task message queue.

[0176] According to one or more embodiments of the present disclosure, the first determining unit is further configured to: in response to a delay duration of the current task being greater than or equal to a preset timeout duration, determine that the current task is a first boundary of the time-consuming task set;

[0177] In response to the delay of the current task being less than the preset timeout, the first historical task with a delay greater than or equal to the preset timeout is determined from the historical task sequence in order from back to front, and the historical task is used as the first boundary of the time-consuming set.

[0178] According to one or more embodiments of the present disclosure, the first determining unit is further configured to:

[0179] Determine, from the historical task sequence in a backward order, at least one first historical task whose delay duration is less than a first duration threshold;

[0180] Determining a second boundary of the time-consuming task set from at least one first historical task;

[0181] A time-consuming task set is formed according to the first boundary and the second boundary and a plurality of historical tasks between the first boundary and the second boundary.

[0182] According to one or more embodiments of the present disclosure, the first determining unit is further configured to:

[0183] Determine the time difference between the preset timeout duration and the execution time of the current task;

[0184] According to the time difference and the execution time of each historical task, at least one second historical task is determined from the historical task sequence in a preset order, and the at least one second historical task constitutes a timeout interval;

[0185] A first historical task whose execution time is earlier than any second historical task in the timeout interval and which is closest to the timeout interval is used as the second boundary.

[0186] According to one or more embodiments of the present disclosure, the apparatus further includes a second determining unit, and the second determining unit is configured to:

[0187] From the time-consuming task set, determine the target task that causes the application to become unresponsive according to the execution time of each task.

[0188] In a third aspect, according to one or more embodiments of the present disclosure, there is provided an electronic device, comprising: at least one processor and a memory;

[0189] Memory stores computer-executable instructions;

[0190] At least one processor executes the computer-executable instructions stored in the memory, so that the at least one processor executes the method for processing application unresponsiveness as described in the first aspect and various possible designs of the first aspect.

[0191] In a fourth aspect, according to one or more embodiments of the present disclosure, a computer-readable storage medium is provided, in which computer execution instructions are stored. When a processor executes the computer execution instructions, the method for processing an unresponsive application as described in the first aspect and various possible designs of the first aspect is implemented.

[0192] In a fifth aspect, according to one or more embodiments of the present disclosure, a computer program product is provided, including a computer program, which, when executed by a processor, implements the method for processing an unresponsive application as described in the first aspect and various possible designs of the first aspect.

[0193] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above disclosed concept. For example, the above features are replaced with the technical features with similar functions disclosed in the present disclosure (but not limited to) by each other to form a technical solution.

[0194] In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

[0195] Although the subject matter has been described in language specific to structural features and / or methodological logical actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. On the contrary, the specific features and actions described above are merely example forms of implementing the claims.

Claims

1. A method for processing an unresponsive application, comprising: In response to detecting that the application is unresponsive, obtaining a current task being executed by a main thread of the application and a historical task sequence, the historical task sequence including a plurality of historical tasks executed by the main thread, the plurality of historical tasks being arranged according to execution time; Based on the delay durations of the current task and multiple historical tasks in the historical task sequence, a set of time-consuming tasks corresponding to the application being unresponsive is determined, wherein the delay duration of the task is determined by the actual execution time and the scheduled execution time of the task.

2. The method according to claim 1, characterized in that The determining, based on the current task and the delay durations of multiple historical tasks in the historical task sequence, a set of time-consuming tasks corresponding to the application being unresponsive, includes: Obtaining the delay durations corresponding to the respective historical tasks from a historical task message queue, wherein the historical task message queue is used to store first task information of tasks completed by the main thread, the first task information including the delay duration; The time-consuming task set is determined based on the delay durations of the current task and the multiple historical tasks.

3. The method according to claim 2, characterized in that The method further comprises: In response to any task being completed by the main thread, the start execution time of the task is obtained; Obtaining a scheduled execution time of the task from a pending task message queue, and determining a delay duration of the task based on the scheduled execution time and the start execution time; wherein the pending task message queue stores second task information of each of a plurality of tasks, the second task information including the scheduled execution time of the task; The first task information of the task including the delay duration of the task is written to the end of the historical task message queue.

4. The method according to claim 1, wherein The determining, based on the current task and the delay durations of multiple historical tasks in the historical task sequence, a set of time-consuming tasks corresponding to the application being unresponsive, includes: In response to a delay duration of the current task being greater than or equal to a preset timeout duration, determining that the current task is a first boundary of a set of time-consuming tasks; In response to the delay duration of the current task being less than the preset timeout duration, the first historical task with a delay duration greater than or equal to the preset timeout duration is determined from the historical task sequence in order from back to front, and the historical task is used as the first boundary of the time-consuming set.

5. The method according to claim 4, characterized in that The method further comprises: Determine, from the historical task sequence in a backward order, at least one first historical task whose delay duration is less than a first duration threshold; determining a second boundary of the time-consuming task set from the at least one first historical task; The time-consuming task set is composed according to the first boundary, the second boundary, and a plurality of historical tasks between the first boundary and the second boundary.

6. The method according to claim 5, characterized in that Determining the second boundary of the time-consuming task set from the at least one first historical task includes: Determine the time difference between the preset timeout duration and the execution time of the current task; Determining at least one second historical task from the historical task sequence according to the time difference and the execution time of each historical task in a preset order, and forming a timeout interval by the at least one second historical task; The first historical task whose execution time is earlier than any second historical task in the timeout interval and which is closest to the timeout interval is used as the second boundary.

7. The method according to any one of claims 1 to 6, characterized in that The method further comprises: A target task causing the application to become unresponsive is determined from the set of time-consuming tasks according to the execution time of each task.

8. A device for processing an unresponsive application, comprising: an acquiring unit, configured to acquire, in response to detecting that an application is unresponsive, a current task being executed by a main thread of the application and a historical task sequence, wherein the historical task sequence includes a plurality of historical tasks executed by the main thread, and the plurality of historical tasks are arranged according to execution time; The first determination unit is used to determine a set of time-consuming tasks corresponding to the unresponsiveness of the application based on the delay duration of the current task and multiple historical tasks in the historical task sequence, wherein the delay duration of the task is determined by the actual execution time and the scheduled execution time of the task.

9. An electronic device, characterized in that: include: processor and memory; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions. When a processor executes the computer-executable instructions, the method according to any one of claims 1 to 7 is implemented.

11. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images