Application program exception determination method and device, medium, equipment and program product

Abstract

The invention relates to an exception determination method and device of an application program, a medium, equipment and a program product, and particularly relates to the technical field of communication. According to the method, a call stack corresponding to a non-response event of the application program is obtained, and according to the obtaining time corresponding to the call stack, the event information generated in the recorded application program running process is obtained; determining a target event message matched with the acquisition time, determining whether a call stack is related to an application non-response event or not according to the execution time consumption of the target event message, and determining the cause of the application non-response event according to the call stack related to the application non-response event, the accuracy of determining the reason of the application program no-response event of the application program through the call stack can be improved.

Description

Technical Field

[0001] The present disclosure relates to the field of communication technology, and in particular, to a method, apparatus, medium, device, and program product for determining an abnormality of an application program. Background Art

[0002] Some events in the main thread of the application need to be completed within a certain period of time. If they are not processed within the predetermined period of time, the system will determine that the application is unresponsive (Application Not Responding, ANR).

[0003] In the related art, when the system receives an application unresponsive event, it will capture the call stack corresponding to the application unresponsive event and determine the cause of the application exception through the captured call stack. However, the captured call stack can only represent the running state of the application at a specific moment, and the behavior of capturing the call stack has a lag, resulting in the captured call stack being unable to accurately reflect the cause corresponding to the application unresponsive event. Summary of the invention

[0004] This summary is provided to introduce concepts in a brief form that will be described in detail in the detailed description below. This summary is not intended to identify key features or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0005] In a first aspect, the present disclosure provides a method for determining an abnormality of an application program, comprising: In response to an application unresponsiveness event, obtaining a call stack corresponding to the application unresponsiveness event; According to the acquisition time corresponding to the call stack, determining a target event message matching the acquisition time from the event messages recorded during the running of the application program; Determining whether the call stack is related to the application unresponsive event according to the execution time of the target event message; The reason why the application program unresponsiveness event occurs in the application program is determined according to the call stack related to the application program unresponsiveness event.

[0006] In a second aspect, the present disclosure provides an abnormality determination device for an application program, comprising: An acquisition module is configured to, in response to an application unresponsiveness event, acquire a call stack corresponding to the application unresponsiveness event; A first determination module is configured to determine, according to the acquisition time corresponding to the call stack, a target event message matching the acquisition time from the event messages recorded during the running process of the application program; A second determination module is configured to determine whether the call stack is related to the application unresponsive event according to the execution time of the target event message; The third determination module is configured to determine the reason why the application program unresponsiveness event occurs in the application program according to the call stack related to the application program unresponsiveness event.

[0007] In a third aspect, the present disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the method described in the first aspect.

[0008] In a fourth aspect, the present disclosure provides an electronic device, including: a storage device having a computer program stored thereon; A processing device is used to execute the computer program in the storage device to implement the steps of the method described in the first aspect.

[0009] In a fifth aspect, the present disclosure provides a computer program product, including a computer program, which implements the steps of the method described in the first aspect when executed by a processor.

[0010] Based on the above technical solution, by obtaining the call stack corresponding to the application unresponsive event, determining the target event message that matches the acquisition time from the event messages generated during the recorded application running process according to the acquisition time corresponding to the call stack, and determining whether the call stack is related to the application unresponsive event according to the execution time of the target event message, and determining the reason why the application unresponsive event occurs in the application based on the call stack related to the application unresponsive event, the accuracy of determining the reason why the application unresponsive event occurs in the application through the call stack can be improved.

[0011] Other features and advantages of the present disclosure will be described in detail in the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and the originals and elements are not necessarily drawn to scale. In the drawings: Figure 1 The present invention is a flowchart of a method for determining an abnormality of an application program according to some embodiments.

[0013] Figure 2 is a schematic diagram showing an event of triggering an application becoming unresponsive according to some embodiments.

[0014] Figure 3 is a schematic diagram showing an execution start time and an execution end time according to some embodiments.

[0015] Figure 4 It is a schematic diagram of the structure of an abnormality determination device for an application program according to some embodiments.

[0016] Figure 5 is a schematic diagram of the structure of an electronic device according to some embodiments. DETAILED DESCRIPTION

[0017] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments described herein, which are instead provided for a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0018] It should be understood that the various steps described in the method embodiments of the present disclosure may be performed in different orders and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0019] The term "including" and its variations used herein are open inclusions, i.e., "including but not limited to". The term "based on" means "based at least in part on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

[0020] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0021] It should be noted that the modifications of "one" and "plurality" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, it should be understood as "one or more".

[0022] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0023] It is understandable that before using the technical solutions disclosed in the embodiments of the present disclosure, the types, scope of use, usage scenarios, etc. of the personal information involved in the present disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0024] For example, in response to receiving an active request from a user, a prompt message is sent to the user to clearly prompt the user that the operation requested to be performed will require obtaining and using the user's personal information. Thus, the user can autonomously choose whether to provide personal information to software or hardware such as an electronic device, application, server, or storage medium that performs the operation of the technical solution of the present disclosure according to the prompt message.

[0025] As an optional but non-limiting implementation, in response to receiving an active request from the user, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. In addition, the pop-up window may also carry a selection control for the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0026] It is understandable that the above notification and the process of obtaining user authorization are merely illustrative and do not constitute a limitation on the implementation of the present disclosure. Other methods that meet the relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0027] At the same time, it is understandable that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and relevant provisions.

[0028] Figure 1 FIG. 1 is a flowchart of a method for determining an abnormality of an application program according to some embodiments. Figure 1 As shown, the embodiment of the present disclosure provides a method for determining an abnormality of an application program, which can be executed by an electronic device, and specifically can be executed by an abnormality determination device for an application program, which can be implemented by software and / or hardware and configured in the electronic device. Figure 1 As shown, the method may include the following steps.

[0029] In step 110, in response to an application unresponsive event, a call stack corresponding to the application unresponsive event is obtained.

[0030] Here, application unresponsiveness can also be called application unresponsiveness. Application unresponsiveness means that after a request or instruction is entered in the application, there is no application response within a specific period of time or the application cannot be completed. For example, in the Android system, if a foreground application has an application unresponsiveness, the system will pop up a dialog box to inform the user that the foreground application has not responded, allowing the user to choose to continue waiting or force close.

[0031] Figure 2 FIG. 1 is a schematic diagram showing a triggering event of an application program not responding according to some embodiments. Figure 2 As shown, the system sets a timeout and sends an event to the application, and the application processes the event. If the application fails to process the event and send a receipt to the system within the specified time, the system triggers a timeout, determines that the application is in an unresponsive exception, and generates an application unresponsive event.

[0032] When the system detects an application unresponsive event, the system can send a special signal SIGQUIT to the application. The application detects the SIGQUIT signal and triggers an exception process after receiving the SIGQUIT signal. In the exception process, the application captures the call stack corresponding to the application unresponsive event.

[0033] It should be understood that the call stack is a list of a series of function calls when the application is executed. The call stack can show at which point the application is unresponsive. In other words, the call stack can show the current running status of the thread and the relevant information of the specific business. When multiple exceptions occur, the call stack can distinguish different exceptions.

[0034] In step 120, according to the acquisition time corresponding to the call stack, a target event message matching the acquisition time is determined from the event messages recorded during the running process of the application program.

[0035] Here, the acquisition time corresponding to the call stack refers to the time when the call stack is captured. The event message generated during the application running process is a signal generated by the system, user or other application. The event message notifies the application that a specific action or change has occurred. The application needs to respond to the event message and perform the corresponding action.

[0036] It should be understood that the electronic device can record every event message generated during the operation of the application. When an application unresponsive event is detected, the electronic device searches for the target event message that matches the acquisition time from the recorded event messages through the acquisition time of the call stack.

[0037] It should be noted that the event messages generated during the running of the application are executed sequentially. By obtaining the time, the event message being executed at the time of obtaining can be found from the recorded event messages, and the event message can be determined as the target event message.

[0038] It is worth noting that the target event message matching the acquisition time can be understood as the event message that is in progress at the moment corresponding to the acquisition time.

[0039] In some embodiments, event messages generated during the running of the application can be acquired and recorded by monitoring the message queue of the main thread of the application.

[0040] In step 130, it is determined whether the call stack is related to the application unresponsiveness event according to the execution time of the target event message.

[0041] Here, the execution time of the target event message refers to the processing time required for the target event message from the start to the end of execution. After finding the target event message that matches the acquisition time of the call stack, the electronic device determines whether the acquired call stack is related to the application unresponsive event by the execution time of the target event message.

[0042] It is worth noting that in the process of acquiring the call stack, due to delays, the call stack acquired after the application unresponsiveness event may not be the accurate call stack when the application unresponsiveness event occurs, resulting in the use of an incorrect call stack to analyze the cause of the application unresponsiveness event. In the embodiment of the present disclosure, the execution time of the target event message can be used to determine whether the acquired call stack is related to the application unresponsiveness event. In other words, the execution time of the target event message can be used to determine whether the acquired call stack is valid, so that the correct call stack can be used when analyzing the cause of the application unresponsiveness event to avoid errors.

[0043] In step 140, the reason why the application program unresponsiveness event occurs in the application program is determined based on the call stack related to the application program unresponsiveness event.

[0044] Here, when it is determined that the acquired call stack is related to the application unresponsiveness event, the reason why the application unresponsiveness event occurs in the application can be analyzed based on the call stack.

[0045] In some application scenarios, a single call stack associated with an application unresponsiveness event may be used to determine a cause of the corresponding application unresponsiveness event.

[0046] In some other scenarios, multiple call stacks related to the application unresponsiveness event can be used to determine the cause of the application unresponsiveness event. For example, multiple call stacks related to the application unresponsiveness event can be aggregated to obtain the number of various causes that cause the application unresponsiveness event to occur, so that developers can understand the probability of each type of problem causing the application unresponsiveness event to occur.

[0047] Therefore, by obtaining the call stack corresponding to the application unresponsive event, determining the target event message that matches the acquisition time from the event messages generated during the recorded application running process according to the acquisition time corresponding to the call stack, and determining whether the call stack is related to the application unresponsive event according to the execution time of the target event message, and determining the reason why the application unresponsive event occurs in the application based on the call stack related to the application unresponsive event, the accuracy of determining the reason why the application unresponsive event occurs in the application through the call stack can be improved.

[0048] In some feasible implementations, in step 120, based on the acquisition time corresponding to the call stack, the execution start time and the execution end time of the recorded event message, an event message whose acquisition time is between the corresponding execution start time and the execution end time can be determined as the target event message.

[0049] Here, the recorded execution start time and execution end time of the event message refer to the start time and end time of executing the event message. When recording event messages generated during the running of the application, the electronic device will record the execution start time and execution end time corresponding to each event message.

[0050] It should be understood that the execution start time and the execution end time are both a time point, the execution start time indicates the time point when the corresponding event starts to be executed, and the execution end time indicates the time point when the corresponding event ends execution.

[0051] When the call stack is obtained, the acquisition time corresponding to the call stack is matched with the execution start time and execution end time of the recorded event message, and the event message with the acquisition time between the corresponding execution start time and execution end time is determined as the target event message.

[0052] That is to say, the event messages recorded, whose acquisition time is less than the execution end time and whose acquisition time is greater than the execution start time, are determined as target event messages. For example, assuming that the acquisition time of the call stack is Tstack, if Tstack is between the execution start time and the execution end time of a certain event message, then the event message is the target event message.

[0053] It is worth noting that the target event message can be understood as the event message being executed at the time when the call stack is obtained. Accordingly, the application unresponsiveness event may be caused by the target event message being executed. At this time, the obtained call stack can reflect the running status of the application, so the cause of the application unresponsiveness event can be analyzed based on the obtained call stack.

[0054] Figure 3 FIG. 1 is a schematic diagram showing the execution start time and the execution end time according to some embodiments. Figure 3 As shown, the execution start time and execution end time corresponding to the event messages generated during the running of the application can be recorded through the timeline. Among them, the execution start time of the first event message handle (1) is T1 and the execution end time is T2, the execution start time of the second event message handle (2) is T3 and the execution end time is T4, the execution start time of the nth event message handle (n) is T2n-1 and the execution end time is T2n, and the execution start time of the n+1th event message handle (n+1) is T2n+1 and the execution end time is T2n+2.

[0055] Assuming that the acquisition time of the call stack is Tstack, since T2n-1<Tstack<T2n, the nth event message handle(n) is the target event message.

[0056] Therefore, through the above implementation, the target event message matching the acquisition time can be accurately found through the acquisition time and the execution start time and execution end time corresponding to the event message.

[0057] In some practicable implementations, the execution start time and execution end time corresponding to the event message generated during the running of the application can be determined and recorded through the message scheduling function of the application.

[0058] Here, the message dispatch function is a function used to process event messages in the main thread message queue of the application. The application runs in the main thread (Main Thread), which has a message queue. Events that need to be executed by the main thread will be packaged into a message and placed in the main thread's message queue. The main thread reads the messages in the message queue in an infinite loop.

[0059] The message dispatching function takes out the event message from the main thread's message queue and processes the event message taken out from the main thread's message queue.

[0060] For example, the code of the main thread may be as follows: void run() { while(true){ msg = Queue.next(); handle(msg); } } Among them, Queue is the message queue of the main thread. When there is an event message in the Queue (event messages are sorted by time), the first event message will be returned, and then the event corresponding to the event message will be executed. When the message queue is empty, it will be blocked in the message queue (blocking is the blocking of Java logic, and the main thread may also execute Native logic). handle(msg) is a message scheduling function. handle(msg) takes out the event message from the message queue of the main thread and processes the taken out event message. Correspondingly, the execution time of handle(msg) is the execution time corresponding to a certain event message.

[0061] By monitoring the message scheduling function of the application, you can obtain the execution start time and execution end time corresponding to each event message generated during the application running process, thereby recording the execution start time and execution end time corresponding to the event message generated during the application running process.

[0062] In some embodiments, a first detection function is inserted before the message scheduling function and a second detection function is inserted after the message scheduling function. The execution start time of the event message is determined according to the calling time of the first detection function, and the execution end time of the event message is determined according to the calling time of the second detection function.

[0063] Among them, when the message scheduling function starts to be called, the first detection function is triggered to be called, and when the message scheduling function ends to be called, the second detection function is triggered to be called.

[0064] Exemplarily, the positions of the first detection function and the second detection function may be as follows: void loop() { for(;;){ msg = Queue.next(); preHandle() handle(msg); postHandle(msg) } } Among them, preHandle() is the first detection function. When the message scheduling function handle(msg) starts to be called, the first detection function is triggered to be called. Correspondingly, the calling time of the first detection function is the execution start time of the event message. postHandle(msg) is the second detection function. When the message scheduling function handle(msg) ends to be called, the second detection function is triggered to be called. The calling time of the second detection function is the execution end time of the event message.

[0065] It is worth noting that the first detection function can be inserted before the message scheduling function and the second detection function can be inserted after the message scheduling function by hooking the key functions before and after the message scheduling function. For example, the first detection function and the second detection function can be inserted by hooking the Printer function. Of course, in other implementations, the first detection function and the second detection function can also be inserted through the Observer listening interface provided by the registration system.

[0066] It should be understood that when the message scheduling function handle(msg) is called, it will trigger the call of the first detection function preHandle(), thereby obtaining the execution start time of the event message. When the message scheduling function handle(msg) ends the call, it will trigger the call of the second detection function postHandle(msg), thereby obtaining the execution end time of the event message.

[0067] For example, Figure 3 As shown, for the first event message handle(1), the time in the first detection function preHandle() is T1, and the time in the second detection function postHandle(msg) is T2. For the second event message handle(2), the time in the first detection function preHandle() is T3, and the time in the second detection function postHandle(msg) is T4.

[0068] Therefore, by monitoring the message scheduling function, the execution start time and execution end time of each event message can be accurately obtained.

[0069] In some feasible implementations, in step 130, when the execution time of the target event message is greater than the first time threshold, it is determined that the call stack is related to the application unresponsive event; when the execution time of the target event message is not greater than the first time threshold, it is determined that the call stack is not related to the application unresponsive event.

[0070] Here, the execution time of the target event message refers to the time required for the target event message to be executed from the beginning to the end. Exemplarily, the execution time of the target event message can be determined according to the execution start time and execution end time of the target event message. For example, if the execution start time of the first event message handle(1) is T1 and the execution end time is T2, then the execution time of the first event message handle(1) is T2-T1.

[0071] The first time threshold may be a time value set by the user according to the needs. As some examples, a common first time threshold may be set for different types of event messages. As some other examples, different first time thresholds may be set for different types of event types. For example, the first time threshold corresponding to the first type of event message is 5 seconds, and the first time threshold corresponding to the second type of event message is 10 seconds.

[0072] It should be noted that the first time threshold actually means that an event message should be executed within the expected duration of the first time threshold. When the execution time of the target event message is greater than the first time threshold, it means that the execution time of the target event message exceeds the expected duration, indicating that an abnormality has occurred in the execution of the target event message. When the execution time of the target event message is not greater than the first time threshold, it means that the execution time of the target event message does not exceed the expected duration, indicating that there is no abnormality in the execution of the target event message.

[0073] Therefore, when the execution time of the target event message is greater than the first time threshold, it can be determined that the call stack is related to the application unresponsiveness event, and the cause of the application unresponsiveness event can be analyzed based on the call stack. When the execution time of the target event message is not greater than the first time threshold, it can be determined that the call stack is not related to the application unresponsiveness event that occurred this time, and the cause of the application unresponsiveness event that occurred in the application is no longer analyzed based on the call stack, but other methods are used to find the cause of the application unresponsiveness event that occurred this time.

[0074] Therefore, invalid call stacks can be filtered out by the execution time of the target event message, and the valid call stacks can be used to analyze the cause of the application unresponsiveness event, thereby improving the accuracy of determining the cause of the application unresponsiveness event through the call stack.

[0075] In some feasible implementations, event messages generated during the running of an application may be recorded in a ring buffer of a preset size, wherein in the ring buffer, event messages whose execution time is no longer than a second time threshold are packaged as one event message for storage, and the second time threshold is less than the first time threshold.

[0076] Here, the preset size of the ring buffer is related to the time length of the event message that needs to be stored before the application unresponsiveness event occurs and the time length of the event message that needs to be stored after the application unresponsiveness event occurs. In other words, the preset size of the ring buffer is related to the duration that needs to be recorded. For example, if the duration is 15 seconds, the preset size of the ring buffer needs to be able to record all event messages that occur in 15 seconds.

[0077] For example, if you need to store event messages 10 seconds before an application becomes unresponsive and 5 seconds after the application becomes unresponsive, the preset size of the ring buffer needs to be able to store event messages 10 seconds before an application becomes unresponsive and 5 seconds after the application becomes unresponsive.

[0078] In the process of storing the event message in the ring buffer, for the event message whose execution time is not greater than the second time threshold, all the event messages whose execution time is not greater than the second time threshold are packaged into one event message and stored in one buffer of the ring buffer. The second time threshold can be set according to actual conditions. For example, the second time threshold can be 200 milliseconds. That is, the event message whose execution time is less than or equal to 200 milliseconds is packaged and stored in one buffer of the ring buffer.

[0079] Taking 200 milliseconds as an example, if the preset ring buffer needs to store event messages generated in a time length of 15 seconds, only 15 / 0.2=75 buffers are needed. Therefore, the size of the ring buffer is related to the time length to be recorded and the second time threshold.

[0080] It should be understood that the number of event messages generated within a certain length of time is uncertain. For example, 1,000 event messages may be generated within 15 seconds, or 10,000 event messages may be generated. Accordingly, the size of the ring buffer cannot be determined. By packaging event messages that take no longer than the second time threshold to be executed as one event message for storage, the size of the ring buffer can be determined to store all event messages generated within a certain length of time.

[0081] It should be noted that event messages whose execution time is not greater than the second time threshold represent event messages whose execution time is relatively short. These event messages with short execution time do not need to be paid much attention to. Therefore, event messages whose execution time is not greater than the second time threshold can be packaged into one event message and stored in a ring buffer.

[0082] It is worth noting that the recorded event message generated during the running of the application should include the execution start time, execution end time and execution time corresponding to the event message.

[0083] Each time the message scheduling function is called, the execution start time of the event message is recorded. When the message scheduling function is finished, the execution end time of the event message is recorded, and the execution time of the event message is calculated by the execution start time and the execution end time, and this execution time is written into the ring buffer. When an application does not respond to an event, new event messages will continue to be written into the ring buffer, and the execution start time and the execution end time of the event message recorded in the ring buffer are used to determine the target event message that matches the acquisition time from the ring buffer.

[0084] Therefore, the event messages generated during the operation of the application are recorded through the ring buffer. Since the ring buffer is a continuously overwritten storage method, only the event messages generated within a period of time can be recorded cyclically instead of recording every event message all the time, thereby avoiding excessive memory occupation.

[0085] Figure 4 FIG. 1 is a schematic diagram of a structure of an apparatus for determining an abnormality of an application program according to some embodiments. Figure 4 As shown, the embodiment of the present disclosure provides an abnormality determination device 400 for an application program, and the abnormality determination device 400 for the application program includes: The acquisition module 401 is configured to, in response to an application unresponsive event, acquire a call stack corresponding to the application unresponsive event; The first determination module 402 is configured to determine, according to the acquisition time corresponding to the call stack, a target event message matching the acquisition time from the event messages recorded during the running process of the application program; A second determination module 403 is configured to determine whether the call stack is related to the application unresponsive event according to the execution time of the target event message; The third determination module 404 is configured to determine the reason why the application program unresponsiveness event occurs in the application program according to the call stack related to the application program unresponsiveness event.

[0086] Optionally, the first determining module 402 is specifically configured to: According to the acquisition time corresponding to the call stack, the recorded execution start time and execution end time of the event message, the event message whose acquisition time is between the corresponding execution start time and execution end time is determined as the target event message.

[0087] Optionally, the application program abnormality determination device 400 further includes: The first recording module is configured to determine and record the execution start time and execution end time corresponding to the event message generated during the running of the application through the message scheduling function of the application, wherein the message scheduling function is a function for processing the event message in the main thread message queue of the application.

[0088] Optionally, the recording module is specifically configured as follows: Inserting a first detection function before the message scheduling function and inserting a second detection function after the message scheduling function, wherein the first detection function is triggered to be called when the message scheduling function starts to be called, and the second detection function is triggered to be called when the message scheduling function ends to be called; The execution start time of the event message is determined according to the calling time of the first detection function, and the execution end time of the event message is determined according to the calling time of the second detection function.

[0089] Optionally, the second determining module 403 is specifically configured to: When the execution time of the target event message is greater than a first time threshold, determining that the call stack is related to the application program unresponsive event; When the execution time of the target event message is not greater than the first time threshold, it is determined that the call stack is not related to the application unresponsive event.

[0090] Optionally, the application program abnormality determination device 400 further includes: The second recording module is configured to record event messages generated during the running of the application through a ring buffer of a preset size, wherein, in the ring buffer, event messages whose execution time is not greater than a second time threshold are packaged as one event message for storage, and the second time threshold is less than the first time threshold.

[0091] The logic of the method executed by each functional module in the above-mentioned application abnormality determination device 400 can refer to the part of the method related to the above-mentioned embodiment, and will not be repeated here.

[0092] Reference below Figure 5 , which shows a schematic diagram of the structure of an electronic device (e.g., terminal device) 500 suitable for implementing the embodiments of the present disclosure. The terminal device in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, notebook computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle-mounted terminals (e.g., vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5The 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.

[0093] like Figure 5 As shown, the electronic device 500 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 to a random access memory (RAM) 503. In the RAM 503, various programs and data required for the operation of the electronic device 500 are also stored. The processing device 501, the ROM 502, and the RAM 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0094] Typically, the following devices may be connected to the I / O interface 505: an input device 506 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 507 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 508 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 509. The communication device 509 may allow the electronic device 500 to communicate with other devices wirelessly or by wire to exchange data. Although Figure 5 The electronic device 500 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.

[0095] 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 non-transitory 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 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by the processing device 501, the above-mentioned functions defined in the method of the embodiment of the present disclosure are executed.

[0096] It should be noted that the computer-readable medium mentioned above in the present disclosure 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 can 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, which carries a computer-readable program code. 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. Computer readable signal media may also be any computer readable medium other than computer readable storage media, 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 appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0097] In some embodiments, the electronic devices may communicate using any currently known or future developed network protocol such as HTTP (HyperText Transfer Protocol), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or future developed network.

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

[0099] The above-mentioned computer-readable medium carries one or more programs. When the above-mentioned one or more programs are executed by the electronic device, the electronic device: in response to an application unresponsive event, obtains a call stack corresponding to the application unresponsive event; determines, according to the acquisition time corresponding to the call stack, a target event message matching the acquisition time from the event messages generated during the operation of the application; determines, according to the execution time of the target event message, whether the call stack is related to the application unresponsive event; and determines, according to the call stack related to the application unresponsive event, the reason why the application unresponsive event occurs in the application.

[0100] 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, but not limited to, 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 a separate 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 through 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).

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

[0102] The modules involved in the embodiments described in the present disclosure may be implemented by software or hardware, wherein the name of a module does not, in some cases, limit the module itself.

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

[0104] In the context of the present disclosure, a machine-readable medium may be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or equipment. A machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, 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 foregoing.

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

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

[0107] Although the subject matter has been described in language specific to structural features and / or method logic 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. Regarding the device in the above embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.

Claims

1. A method for determining an abnormality of an application, characterized in that: include: In response to an application unresponsiveness event, obtaining a call stack corresponding to the application unresponsiveness event; According to the acquisition time corresponding to the call stack, determining a target event message matching the acquisition time from the event messages recorded during the running of the application program; Determining whether the call stack is related to the application unresponsive event according to the execution time of the target event message; The reason why the application program unresponsiveness event occurs in the application program is determined according to the call stack related to the application program unresponsiveness event.

2. The method according to claim 1, characterized in that The step of determining, according to the acquisition time corresponding to the call stack, a target event message matching the acquisition time from the event messages recorded during the running of the application program, includes: According to the acquisition time corresponding to the call stack, the recorded execution start time and execution end time of the event message, the event message whose acquisition time is between the corresponding execution start time and execution end time is determined as the target event message.

3. The method according to claim 2, characterized in that The method further comprises: The message scheduling function of the application is used to determine and record the execution start time and execution end time corresponding to the event message generated during the running of the application, wherein the message scheduling function is a function for processing the event message in the main thread message queue of the application.

4. The method according to claim 3, characterized in that The method of determining and recording the execution start time and execution end time corresponding to the event message generated during the running of the application program through the message scheduling function of the application program includes: Inserting a first detection function before the message scheduling function and inserting a second detection function after the message scheduling function, wherein the first detection function is triggered to be called when the message scheduling function starts to be called, and the second detection function is triggered to be called when the message scheduling function ends to be called; The execution start time of the event message is determined according to the calling time of the first detection function, and the execution end time of the event message is determined according to the calling time of the second detection function.

5. The method according to any one of claims 1 to 4, characterized in that The determining, according to the execution time of the target event message, whether the call stack is related to the application unresponsive event includes: When the execution time of the target event message is greater than a first time threshold, determining that the call stack is related to the application program unresponsive event; When the execution time of the target event message is not greater than the first time threshold, it is determined that the call stack is not related to the application unresponsive event.

6. The method according to claim 5, characterized in that The method further comprises: Event messages generated during the running of the application are recorded through a ring buffer of a preset size, wherein in the ring buffer, event messages whose execution time is not greater than a second time threshold are packaged into one event message for storage, and the second time threshold is less than the first time threshold.

7. A device for determining abnormality of an application, characterized in that: include: An acquisition module is configured to, in response to an application unresponsiveness event, acquire a call stack corresponding to the application unresponsiveness event; A first determination module is configured to determine, according to the acquisition time corresponding to the call stack, a target event message matching the acquisition time from the event messages recorded during the running process of the application program; A second determination module is configured to determine whether the call stack is related to the application unresponsive event according to the execution time of the target event message; The third determination module is configured to determine the reason why the application program unresponsiveness event occurs in the application program according to the call stack related to the application program unresponsiveness event.

8. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processing device, the steps of the method according to any one of claims 1 to 6 are implemented.

9. An electronic device, characterized in that: include: a storage device having a computer program stored thereon; A processing device, configured to execute the computer program in the storage device to implement the steps of the method according to any one of claims 1 to 6.

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

Images