Abnormality detection method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses an anomaly detection method and device, electronic equipment and a storage medium, and the method comprises the steps: firstly detecting the refresh time of each application frame in the operation process of a to-be-detected target application, the method comprises the steps that a target application is obtained, multiple abnormal performance events occurring in the running process of the target application and the occurrence time of each abnormal performance event are obtained, then, a target abnormal performance event corresponding to each application frame is searched for from the multiple abnormal performance events, and the refresh time of each application frame is matched with the occurrence time of the target abnormal performance event; and performing anomaly detection according to the target anomaly performance event corresponding to each application frame. According to the technical scheme of the embodiment of the invention, the abnormal detection data volume can be reduced, and the detection efficiency and accuracy can be improved.

Description

Technical Field

[0001] The present application relates to the field of computers, and more specifically, to an anomaly detection method and device, an electronic device, a storage medium, and a program product. Background Art

[0002] In order to facilitate people's life and work, more and more applications are being developed, and users can download various applications according to their own needs. As the functions of applications become more and more powerful, more and more CPU (Central Processing Unit Processor) resources and GPU (Graphics Processing Unit) resources are required during the operation of applications, which makes it easy for applications to freeze and have other problems.

[0003] In the related art, data is usually collected during the entire operation process of the application, and anomaly detection is performed based on the data, which results in a large amount of data processing, low anomaly detection efficiency and low accuracy. Summary of the invention

[0004] The embodiments of the present application provide an anomaly detection method and device, an electronic device, a storage medium, and a program product, which can reduce the amount of anomaly detection data and improve detection efficiency and accuracy.

[0005] According to one aspect of an embodiment of the present application, a method for detecting anomalies is provided, the method comprising:

[0006] Detect the refresh time of each application frame during the operation of the target application to be detected;

[0007] Acquire multiple abnormal performance events that occur during the operation of the target application and the occurrence time of each abnormal performance event;

[0008] From the multiple abnormal performance events, searching for a target abnormal performance event corresponding to each application frame; wherein the refresh time of each application frame matches the occurrence time of the target abnormal performance event;

[0009] Anomaly detection is performed according to the target abnormal performance event corresponding to each application frame.

[0010] According to one aspect of an embodiment of the present application, there is provided an abnormality detection device, the device comprising:

[0011] A detection module, configured to detect the refresh time of each application frame during the operation of the target application to be detected;

[0012] An acquisition module configured to acquire a plurality of abnormal performance events occurring during the operation of the target application and the occurrence time of each abnormal performance event;

[0013] A search module configured to search for a target abnormal performance event corresponding to each application frame from the multiple abnormal performance events; wherein the refresh time of each application frame matches the occurrence time of the target abnormal performance event;

[0014] The processing module is configured to perform anomaly detection according to the target abnormal performance event corresponding to each application frame.

[0015] In an exemplary embodiment, based on the aforementioned scheme, the detection module is specifically configured as follows: injecting a set time acquisition function into the process of the target application; during the running of the target application, if the frame loop function in the target application is called to refresh each application frame, the first calling time point of the frame loop function is acquired through the time acquisition function; if the frame loop function is called to refresh the next application frame of each application frame, the second calling time point of the frame loop function is acquired through the time acquisition function; and based on the first calling time point and the second calling time point, the refresh time of each application frame is calculated.

[0016] In an exemplary embodiment, based on the aforementioned scheme, the processing module is specifically configured as follows: from the target abnormal performance event, obtain stack data during the occurrence of the target abnormal performance event; the stack data contains information of multiple program units and the calling relationship between the multiple program units; obtain the execution time of the multiple program units during the refresh process of each application frame, and fuse the obtained execution time into the stack data to obtain fused stack data; perform anomaly detection based on the fused stack data.

[0017] In an exemplary embodiment, based on the aforementioned scheme, the processing module is specifically configured as follows: selecting multiple merged application frames from the application frames included in the target application, and segmenting the fused stack data corresponding to each merged application frame according to a set data volume to obtain multiple sub-data sets; wherein the data volume of each sub-data set matches the set data volume; merging the sub-data sets corresponding to the multiple merged application frames in turn to obtain merged stack data corresponding to the multiple merged application frames; and performing anomaly detection based on the merged stack data.

[0018] In an exemplary embodiment, based on the aforementioned scheme, the processing module is specifically configured as follows: obtaining the calling level of each program unit in the fused stack data corresponding to each merged application frame in the corresponding calling relationship; dividing the information of multiple program units contained in the fused stack data corresponding to each merged application frame according to the set data volume and the calling level of each program unit to obtain multiple sub-data sets; merging the sub-data sets corresponding to the multiple merged application frames in order from low to high according to the corresponding calling levels to obtain the merged stack data corresponding to the multiple merged application frames.

[0019] In an exemplary embodiment, based on the aforementioned scheme, the processing module is specifically configured as follows: searching for a program unit whose corresponding execution time is less than or equal to a set time threshold from the fused stack data corresponding to each merged application frame; deleting information corresponding to the found program unit from the fused stack data corresponding to each merged application frame; and segmenting the fused stack data after deletion according to the set data volume to obtain multiple sub-data sets.

[0020] In an exemplary embodiment, based on the aforementioned scheme, the processing module is specifically configured as follows: calculating the refresh duration of each application frame according to the refresh time of each application frame, and displaying a duration display interface; wherein the duration display interface includes the refresh durations corresponding to multiple application frames of the target application; in response to a selection operation based on the duration display interface, determining the target application frame selected by the selection operation; displaying an anomaly detection chart generated according to the fusion stack data corresponding to the target application frame; wherein the anomaly detection chart corresponding to the target application frame includes the calling relationship between the program units corresponding to the target application frame and the execution duration of each program unit during the refresh process of the target application frame.

[0021] In an exemplary embodiment, based on the aforementioned scheme, the processing module is specifically configured as follows: if the number of the target application frames is multiple, the fusion stack data of the multiple target application frames are merged; an anomaly detection chart corresponding to the multiple target application frames is generated based on the merged data; wherein the anomaly detection chart includes the calling relationship between the program units corresponding to the multiple target application frames and the total execution time of each program unit during the refresh process of the multiple target application frames; and the anomaly detection chart corresponding to the multiple target application frames is displayed.

[0022] In an exemplary embodiment, based on the aforementioned scheme, the processing module is specifically configured as follows: obtaining application frames respectively included in multiple versions of target applications, and obtaining a reference program unit from the fused stack data corresponding to the application frames included in each version of the target application; calculating the execution time of the reference program unit in each version of the target application according to the fused stack data corresponding to the application frames included in each version of the target application; and performing anomaly detection according to the execution time of the reference program unit in the multiple versions of the target application.

[0023] In an exemplary embodiment, based on the aforementioned scheme, the acquisition module is specifically configured as follows: during the operation of the target application, performance detection is performed on the operating system; if an abnormal performance event is detected, the detected abnormal performance event and the time of occurrence of the abnormal performance event are stored in a set storage area; and according to the detected abnormal performance event, the storage capacity of the set storage area is adjusted.

[0024] In an exemplary embodiment, based on the aforementioned scheme, the acquisition module is specifically configured as follows: if the occupied storage capacity in the set storage area is greater than or equal to the set capacity upper limit threshold, then the occurrence frequency of abnormal performance events is calculated based on the detected abnormal performance events; the storage capacity of the storage area is increased based on the occurrence frequency; wherein the occurrence frequency is positively correlated with the increased storage capacity.

[0025] According to one aspect of an embodiment of the present application, there is provided an electronic device, including:

[0026] one or more processors;

[0027] A storage device is used to store one or more computer programs. When the one or more computer programs are executed by the one or more processors, the electronic device implements the anomaly detection method as described above.

[0028] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor of an electronic device, the electronic device implements the anomaly detection method as described above.

[0029] According to one aspect of an embodiment of the present application, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the anomaly detection method as described above is implemented.

[0030] In the technical solution provided in the embodiments of the present application, the refresh time of each application frame during the operation of the target application to be detected is first detected, and multiple abnormal performance events occurring during the operation of the target application and the occurrence time of each abnormal performance event are obtained. Then, the target abnormal performance event corresponding to each application frame is searched from the multiple abnormal performance events, wherein the refresh time of each application frame matches the occurrence time of the target abnormal performance event; anomaly detection is performed according to the target abnormal performance event corresponding to each application frame, thereby reducing the amount of anomaly detection data and improving detection efficiency. Moreover, anomaly detection is performed according to the target abnormal performance event corresponding to each application frame, which can reduce the detection granularity, realize frame-level detection, and improve detection accuracy.

[0031] It should be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 is a schematic diagram of an implementation environment shown in an exemplary embodiment of the present application;

[0033] Figure 2 is a flow chart of an abnormality detection method shown in an exemplary embodiment of the present application;

[0034] Figure 3 is a schematic diagram of an application frame and an abnormal performance event shown in an exemplary embodiment of the present application;

[0035] Figure 4 is a flow chart of an abnormality detection method shown in another exemplary embodiment of the present application;

[0036] Figure 5 is a flow chart of an abnormality detection method shown in another exemplary embodiment of the present application;

[0037] Figure 6 is a flow chart of an abnormality detection method shown in another exemplary embodiment of the present application;

[0038] Figure 7 is a flow chart of an abnormality detection method shown in another exemplary embodiment of the present application;

[0039] Figure 8 is a schematic diagram of a stack data merging process shown in an exemplary embodiment of the present application;

[0040] Fig. 9 is a flow chart of an abnormality detection method shown in another exemplary embodiment of the present application;

[0041] Fig.10 is a flow chart of an abnormality detection method shown in another exemplary embodiment of the present application;

[0042] Fig.11 is a schematic diagram of a duration display chart shown in an exemplary embodiment of the present application;

[0043] Fig.12 is a schematic diagram of an anomaly detection chart shown in an exemplary embodiment of the present application;

[0044] Fig.13 is a schematic diagram of a flame graph shown in an exemplary embodiment of the present application;

[0045] Fig.14 is a flow chart of an abnormality detection method shown in another exemplary embodiment of the present application;

[0046] Fig.15A is a schematic diagram of a duration display chart shown in another exemplary embodiment of the present application;

[0047] Fig. 15B is a schematic diagram of an anomaly detection chart shown in another exemplary embodiment of the present application;

[0048] Fig. 15C is a schematic diagram of a flame graph shown in another exemplary embodiment of the present application;

[0049] Fig.16 is a flow chart of an abnormality detection method shown in another exemplary embodiment of the present application;

[0050] Fig.17 is a schematic diagram of an execution time comparison chart shown in an exemplary embodiment of the present application;

[0051] Fig.18 is a flow chart of an abnormality detection method shown in another exemplary embodiment of the present application;

[0052] Fig.19 is a flow chart of an abnormality detection method shown in another exemplary embodiment of the present application;

[0053] Fig. 20 is a block diagram of an abnormality detection method shown in an exemplary embodiment of the present application;

[0054] Fig.21 is a block diagram of an event collection process shown in an exemplary embodiment of the present application;

[0055] Fig. 22 is a schematic diagram of an abnormality detection device shown in an exemplary embodiment of the present application;

[0056] Fig.23 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown. DETAILED DESCRIPTION

[0057] Here, exemplary embodiments will be described in detail, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are only examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0058] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities may be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0059] The flowcharts shown in the accompanying drawings are only exemplary and do not necessarily include all the contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to actual conditions.

[0060] It should also be noted that the "multiple" mentioned in this application refers to two or more than two. "And / or" describes the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship.

[0061] The following is a detailed introduction to the technical solutions of the embodiments of the present application:

[0062] In the related art, data is usually collected during the entire operation process of the application, and anomaly detection is performed based on this data, which results in a large amount of data processing, low anomaly detection efficiency, and large detection granularity, which makes it impossible to accurately locate anomalies and has low detection accuracy. Based on this, the embodiments of the present application provide an anomaly detection method and device, electronic device, storage medium, and program product, which can reduce the amount of anomaly detection data and improve detection efficiency and accuracy.

[0063] See also Figure 1 , Figure 1 1 is a schematic diagram of an implementation environment involved in the present application, which includes a terminal device 110 and a server 120. The terminal device 110 and the server 120 communicate with each other through a wired or wireless network, and the terminal device 110 can upload its own data to the server 120 or obtain data from the server 120.

[0064] Among them, the terminal device 110 may include but is not limited to smart phones, tablets, laptops, computers, intelligent voice interaction devices, smart home appliances, vehicle-mounted terminals, aircraft, remote driving terminals, etc.; the server 120 may be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network) and big data and artificial intelligence platforms. The specific forms of terminal devices and servers are not restricted here.

[0065] It should be noted that Figure 1 The number of terminal devices 110 and servers 120 in the figure is only for illustration, and any number of terminal devices 110 and servers 120 may be provided according to actual needs.

[0066] In an exemplary embodiment, the anomaly detection method provided by the embodiment of the present application can be executed by the terminal device 110. Exemplarily, the terminal device 110 can first detect the refresh time of each application frame during the operation of the target application to be detected, and obtain multiple abnormal performance events occurring during the operation of the target application and the occurrence time of each abnormal performance event, and then, from the multiple abnormal performance events, find the target abnormal performance event corresponding to each application frame, wherein the refresh time of each application frame matches the occurrence time of the target abnormal performance event; perform anomaly detection according to the target abnormal performance event corresponding to each application frame, thereby reducing the amount of anomaly detection data and improving detection efficiency, and perform anomaly detection according to the target abnormal performance event corresponding to each application frame, which can reduce the detection granularity, realize frame-level detection, and improve detection accuracy.

[0067] In another exemplary embodiment, the server 120 may have similar functions to the terminal device 110, so as to execute the anomaly detection method provided in the embodiment of the present application. Exemplarily, the server 120 may first detect the refresh time of each application frame during the operation of the target application to be detected, and obtain multiple abnormal performance events that occur during the operation of the target application and the occurrence time of each abnormal performance event, and then, from the multiple abnormal performance events, find the target abnormal performance event corresponding to each application frame, wherein the refresh time of each application frame matches the occurrence time of the target abnormal performance event; so as to perform anomaly detection according to the target abnormal performance event corresponding to each application frame.

[0068] In another exemplary embodiment, the terminal device 110 and the server 120 may also jointly execute the anomaly detection method provided by the embodiment of the present application. Exemplarily, the terminal device 110 may detect the refresh time of each application frame during the operation of the target application to be detected, and obtain multiple abnormal performance events and the occurrence time of each abnormal performance event that occur during the operation of the target application, and then send the refresh time of each application frame, multiple abnormal performance events, and the occurrence time of each abnormal performance event to the server 120; the server 120 searches for the target abnormal performance event corresponding to each application frame from the multiple abnormal performance events, wherein the refresh time of each application frame matches the occurrence time of the target abnormal performance event; and performs anomaly detection according to the target abnormal performance event corresponding to each application frame.

[0069] The anomaly detection method in the embodiments of the present application can be applied to various scenarios where anomaly detection of applications is required, for example, it can be used for anomaly detection in the application development process, and it can also be applied to anomaly detection of online applications, which can be any type of application, for example, game applications, etc. The embodiments of the present application involve user-related data such as the refresh time of the application frame. When the method of the present application is applied to a specific product or technology, it is all with the permission or consent of the user, and the extraction, use and processing of the relevant data comply with local safety standards and local laws and regulations.

[0070] See also Figure 2 , Figure 2 is a flowchart of an abnormality detection method shown in an exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The terminal device 110 in the implementation environment shown in the figure may also be executed by Figure 1 The server 120 in the implementation environment shown in the figure may also execute the command. Figure 1 The terminal device 110 and the server 120 in the illustrated implementation environment execute together.

[0071] like Figure 2 As shown, in an exemplary embodiment, the abnormality detection method may include steps S210 to S240, which are described in detail as follows:

[0072] Step S210 , detecting the refresh time of each application frame during the running process of the target application to be detected.

[0073] First of all, it should be noted that the target application refers to any application that needs to be performance tested. According to its corresponding operating environment, the types of target applications include but are not limited to web applications (web app), native applications (Native App), mini-programs, hybrid applications (Hybrid App), etc., among which native applications refer to applications that can be directly run on a certain operating system (for example, Android system, iOS system); web applications refer to web applications that need to be run in browser components, such as H5 (html5, hypertext markup language, a language description method for building Web content) applications; mini-programs are applications that can be used without downloading and installing; hybrid applications refer to applications that are developed by mixing web and native. According to the services it provides, the types of target applications include but are not limited to video applications, audio applications, social applications, e-commerce applications, game applications, etc.

[0074] The application logic corresponding to the target application runs once, which is called an application frame, that is, a frame cycle is completed. The frame cycle can be implemented by a frame cycle function, which can be a main cycle function included in the target application. For example, for a game application, running the game logic once becomes a game frame, and the game logic can be implemented by the main cycle function included in the game application. The time taken for the application logic corresponding to the target application to run once is called the refresh time of the application frame. The refresh time of the application frame is a time period, including a start time point and an end time point.

[0075] During the operation of the target application, in order to determine whether the target application is abnormal (for example, whether a freeze occurs, etc.), the refresh time of each application frame in the target application can be obtained. The specific method of obtaining the refresh time of each application frame can be flexibly set according to actual needs. Optionally, since the frame cycle function is used to refresh the application frame, the running time of each running of the frame cycle function can be obtained, and the running time of a single running of the frame cycle function is used as the refresh time of the corresponding application frame.

[0076] Step S220, obtaining multiple abnormal performance events that occur during the running process of the target application and the occurrence time of each abnormal performance event.

[0077] An abnormal performance event refers to an abnormal performance parameter. Performance parameters include, but are not limited to, parameters related to the performance of the operating system to which the application belongs, including, but not limited to, performance parameters corresponding to the hardware (e.g., CPU, memory controller, cache, etc.) functions and software (e.g., software counters, etc.) functions of the operating system, such as instruction counts, cache misses, events, etc. The occurrence time of an abnormal performance event refers to the time when the abnormal performance event occurs, which can be a time period or a moment.

[0078] The performance of the operating system (for example, the CPU) will affect the frame cycle of the target application. Therefore, during the operation of the target application, the performance of the operating system can be detected to determine whether an abnormality occurs, and when an abnormality occurs, relevant data is collected to generate an abnormal performance event, so that the target application can be detected for abnormalities based on the abnormal performance event, which not only reduces the amount of data processing, but also can detect abnormalities of the target application from the bottom of the system, thereby improving the detection accuracy. Among them, the collected data includes the occurrence time of the abnormal performance event, which can be reflected as a timestamp to determine the occurrence order of the event and the direct relationship between the events through the occurrence time. Optionally, the collected data may also include but is not limited to at least one of the following data: event type, ID (Identity document) of the process and thread to which the event belongs when the event occurs, the address of the instruction executed when the event occurs, and stack data. Among them, the event type refers to the performance parameters corresponding to the abnormal performance event, such as clock cycle, number of instructions, cache miss or branch error, etc.; the ID of the process and thread to which the event belongs when it occurs can map the event back to the specific process or thread; the address of the instruction executed when the event occurs helps to map the event to a specific code location, which can be collected through the program counter; the stack data contains information on multiple program units during the event occurrence process and the calling relationship between multiple program units. For the specific introduction of the corresponding stack data, please refer to the subsequent records and will not be repeated here.

[0079] In an optional implementation, the performance of the operating system can be detected by a system performance analysis tool, which includes hardware performance counters, which can be directly associated with hardware components, thereby improving the accuracy of performance detection. System performance analysis tools include but are not limited to perf tools. Since the perf tool has a wide range of applications, it can improve the scope of use of abnormal detection. Among them, the perf tool is a Linux performance analysis tool that provides a performance analysis framework. Through perf, applications can use performance counters in PMU (performance monitor unit), tracepoint and kernel to perform performance detection. When a performance event occurs during the operation of the operating system, the performance counter corresponding to the performance event will increase its value. When the counter value reaches a predetermined threshold, the operating system kernel will trigger an interrupt and generate an abnormal performance event. The perf tool can analyze the abnormal performance event. The perf tool can not only analyze the performance problems of the specified application (per thread), but also be used to analyze the performance problems of the kernel. Of course, it can also analyze the application and the kernel at the same time, so as to fully understand the performance bottlenecks in the application. Among them, PMU is used to detect and count some low-level hardware events in the system, such as CPU-related events (number of executed instructions, number of captured exceptions, number of clock cycles, etc.), cache-related events (number of cache accesses, number of misses, etc.), etc. These events reflect the behavior of the application during operation, which is conducive to analyzing and tuning the application. Tracepoint is a hard-coded detection point placed in a more important position in the kernel code.

[0080] Step S230, searching for a target abnormal performance event corresponding to each application frame from a plurality of abnormal performance events; wherein the refresh time of each application frame matches the occurrence time of the target abnormal performance event.

[0081] The target abnormal performance event corresponding to each application frame refers to the abnormal performance event whose corresponding occurrence time matches the refresh time of the application frame. After obtaining multiple abnormal performance events, the application frame to which each abnormal performance event belongs can be found according to the occurrence time of each abnormal performance event, thereby determining the target abnormal performance event corresponding to each application frame. For example, see Figure 3As shown, the circles in the figure represent abnormal performance events. Multiple abnormal performance events may occur within the refresh time of each application frame. Therefore, the application frame to which each abnormal performance event belongs can be found according to the occurrence time of each abnormal performance event, so as to obtain the abnormal performance event corresponding to each application frame. Among them, the occurrence time matches the refresh time, which means that the occurrence time belongs to the refresh time. For example, assuming that the occurrence time of an abnormal performance event is 12:00:00-12:00:01, the refresh time of application frame 1 is 11:59:56-11:59:58, and the refresh time of application frame 2 is 11:59:59-12:00:02, then the abnormal performance event belongs to application frame 2.

[0082] Optionally, in order to improve the search accuracy, before step S230, the refresh time and the occurrence time can be calibrated according to the same time reference, and then based on the calibrated refresh time and occurrence time, the target abnormal performance event corresponding to each application frame can be determined, wherein the calibrated refresh time corresponding to each application frame matches the calibrated occurrence time corresponding to the target abnormal performance event.

[0083] Step S240, performing anomaly detection according to the target abnormal performance event corresponding to each application frame.

[0084] After obtaining the target abnormal performance event corresponding to each application frame, anomaly detection can be performed based on the target abnormal performance event corresponding to each application frame. For example, anomaly detection can be performed based on the abnormal performance event corresponding to each application frame to obtain the abnormal detection result of each application frame, thereby realizing frame-level anomaly detection. Alternatively, anomaly detection results corresponding to multiple application frames can be generated based on the abnormal performance events corresponding to multiple application frames.

[0085] exist Figure 2 In the illustrated embodiment, the refresh time of each application frame during the operation of the target application to be detected is first detected, and multiple abnormal performance events occurring during the operation of the target application and the occurrence time of each abnormal performance event are obtained. Then, the target abnormal performance event corresponding to each application frame is searched from the multiple abnormal performance events, wherein the refresh time of each application frame matches the occurrence time of the target abnormal performance event. Anomaly detection is performed based on the target abnormal performance event corresponding to each application frame, thereby reducing the amount of anomaly detection data and improving detection efficiency. At the same time, anomaly detection is performed based on the target abnormal performance event corresponding to each application frame, which can not only reduce the detection granularity, realize frame-level detection, and improve the detection accuracy, but also locate the anomaly before the jamming occurs, thereby avoiding the jamming of the application and improving the smoothness of the application operation.

[0086] In an exemplary embodiment, see Figure 4 , Figure 4is a flowchart of an abnormality detection method shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The terminal device 110 in the implementation environment shown in the figure may also be executed by Figure 1 The server 120 in the implementation environment shown in the figure may also execute the command. Figure 1 The terminal device 110 and the server 120 in the illustrated implementation environment execute together.

[0087] like Figure 4 As shown, the method includes steps S410 to S440, and steps S220 to S240, wherein steps S410 to S440 are described in detail as follows:

[0088] Step S410: injecting the set time collection function into the process of the target application.

[0089] The time acquisition function is a pre-developed function used to acquire time. In order to improve the accuracy of the calling time point of the frame loop function and the refresh time of the application frame, the time acquisition function can be injected into the process of the target application.

[0090] Step S420: During the running of the target application, if the frame cycle function in the target application is called to refresh each application frame, the first calling time point of the frame cycle function is collected by the time collection function.

[0091] During the operation of the target application, the frame loop function in the target application will be called and executed to refresh the application frame. After the time acquisition function is injected into the process of the target application, during the operation of the target application, if the process of the target application calls the frame loop function to refresh each application frame, the time acquisition function can detect this call and collect the calling time point of the frame loop function to obtain the first calling time point.

[0092] Step S430: If the frame cycle function is called to refresh the next application frame of each application frame, the second calling time point of the frame cycle function is collected by the time collection function.

[0093] For each application frame, after it is detected that the frame loop function is called to refresh the application frame and the frame loop function is executed, if it is detected that the frame loop function is called again to refresh the next application frame of the application frame, the time point when the frame loop function is called this time is collected through the time acquisition function to obtain the second calling time point.

[0094] Step S440, calculating the refresh time of each application frame according to the first calling time point and the second calling time point.

[0095] Based on the first calling time point and the second calling time point, the refresh time of each application frame can be calculated, wherein the first calling time point can be used as the starting time point in the refresh time, and the second calling time point can be used as the ending time point in the refresh time, that is, the time interval between two adjacent calls of the frame loop function is used as the refresh time of the application frame.

[0096] Optionally, the time acquisition function can also be used to calculate the refresh time of each application frame according to the first call time point and the second call time point. The acquisition method of the second call time point is similar to the acquisition method of the first call time point, which will not be repeated here.

[0097] In order to improve the accuracy of the calling time point of the frame loop function, the time acquisition function is injected into the process of the target application, and the time acquisition function can be associated with the frame loop function. In an optional implementation, the time acquisition function can be injected into the process of the target application based on the hook technology, so as to hook the frame loop function through the time acquisition function, that is, the time acquisition function is a hook function, which can hook the frame loop function, so that before the process of the target application calls the frame loop function, the hook function will first capture the call, thereby collecting the calling time point, and then calling the frame loop function for execution. Among them, hook technology is a technology that can replace a certain function of a process (i.e., the hooked function) with one executed in a custom function (i.e., the hook function). Generally speaking, the hook function can be added before and after the original function, so that before calling the original function, the hook function first captures the message, thereby obtaining control and achieving the function of modifying the execution logic of the original function. During the hook process, a custom hook function can be written for the hooked function, and then the custom hook function can be compiled into a dynamic database, and then the dynamic database can be injected into the process, and the injected dynamic database can take effect after the process is restarted.

[0098] In an optional example, if the target application is developed based on the Java language, the hook frame loop function can be implemented through JDWP, where JDWP is a Java platform debugging architecture; the process of implementing the hook frame loop function through JDWP can include the following steps 1.1 to 1.3, which are described in detail as follows:

[0099] Step 1.1, write SO (shared object, shared dynamic link) library

[0100] Among them, the SO library can be written in C language or C++ language, and the hook framework to be used is compiled and linked to the SO library to obtain the hook function, that is, the hook function is compiled into the SO library. Among them, the SO library refers to a binary program, which needs to be loaded by the executable program before the code contained in it can be executed. The hook framework will provide an interface to indicate the hooked function. The types of hook frameworks include but are not limited to Andhook, Substrate and other similar frameworks, among which Andhook is a lightweight hook framework, and Substrate is a code modification framework based on hook.

[0101] Step 1.2, write the Java loader

[0102] Write a Java class loader for loading the SO library and declare native JNI (Java Native Interface, Java Native Interface writing program) functions in the Java loader.

[0103] Step 1.3, inject the SO library

[0104] During the injection process, the process of the target application is connected through JDWP; the frame loop function is found in the process of the target application and the injection position is determined according to the frame loop function, the SO library is loaded to the injection position through the local JNI function in the Java loader, and the SO library calls the frame loop function.

[0105] After the injection is completed, when the target process has been debugged and suspended, the Events of the JDWP protocol can be used to request the Java loader, that is, the Loader.hookMainLoop function, so as to call the hook function, initialize the hook framework, find and hook the frame loop function. In hooked_main_loop_function (i.e., hook function), the call time will be collected before each call to the frame loop function.

[0106] It should be noted that Figure 4 The specific implementation details of steps S220 to S240 shown in FIG. Figure 2 Steps S220 to S240 shown are not repeated here.

[0107] exist Figure 4In the illustrated embodiment, the time interval between two adjacent calls of the frame loop function is used as the refresh time of the application frame, so that the accuracy of the refresh time can be improved. Moreover, by injecting a time acquisition function into the process of the target application to acquire the time point when the frame loop function is called through the time acquisition function, the accuracy of the calling time point can be improved, thereby improving the accuracy of the refresh time of the application frame.

[0108] In an exemplary embodiment, see Figure 5 , Figure 5 is a flowchart of an abnormality detection method shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The terminal device 110 in the implementation environment shown in the figure may also be executed by Figure 1 The server 120 in the implementation environment shown in the figure may also execute the command. Figure 1 The terminal device 110 and the server 120 in the illustrated implementation environment execute together.

[0109] like Figure 5 As shown, the method includes steps S210 to S230, and steps S510 to S530, wherein steps S510 to S530 are described in detail as follows:

[0110] Step S510, obtaining stack data during the occurrence of the target abnormal performance event from the target abnormal performance event; the stack data includes information of multiple program units and calling relationships between the multiple program units.

[0111] A program unit refers to a section of a program used to implement a certain function, and its types include but are not limited to functions, threads, processes, etc. During the execution of a program unit, other program units will be called, and the calling relationship will be recorded in the stack data. In order to reduce the amount of data for performance analysis, the target abnormal performance event contains the stack data during the occurrence of the target abnormal performance event. The stack data contains information about multiple program units and the calling relationship between multiple program units. That is to say, after an abnormal performance event is detected, the stack data during the occurrence of the abnormal performance event can be collected and added to the abnormal performance event.

[0112] The information of the program unit includes but is not limited to at least one of the data related to the program unit, such as the address, name, and return value during execution of the program unit.

[0113] Step S520 , obtaining the execution durations of the plurality of program units in the refresh process of each application frame, and fusing the obtained execution durations into the stack data to obtain the fused stack data.

[0114] The execution time of the program unit will affect the refresh time of the application frame. Therefore, in order to locate the abnormal program unit when the refresh of the application frame is abnormal, the execution time of each program unit in the refresh process of each application frame can be obtained, and the obtained execution time can be fused into the stack data to obtain the fused stack data.

[0115] Among them, the specific method of obtaining the execution time of each program unit in the refresh process of each application frame can be flexibly set according to actual needs. In an optional implementation, the execution time corresponding to each program unit can be collected by injecting a collection function in the process of the target application, so as to calculate the execution time of the program unit in the refresh process of each application frame according to the execution time. The specific method is similar to the aforementioned method of collecting the execution time of the program unit through the time collection function, which will not be repeated here. In another optional implementation, the abnormal performance events associated with the program unit can be found from the target abnormal performance events corresponding to each application frame, and the execution time of the program unit in the refresh process of each application frame can be calculated according to the number of abnormal performance events found, wherein the number of abnormal performance events found is positively correlated with the execution time, that is, the more abnormal performance events are found, the longer the execution time is. In other words, in the refresh process of a certain application frame, the more abnormal performance events associated with the program unit are, the longer its execution time in the refresh process of the application frame is, and the longer the CPU resources are occupied.

[0116] After obtaining the execution time of multiple program units in the refresh process of each application frame, the execution time is merged into the stack data to obtain fused stack data, that is, the fused stack data contains information of multiple program units and the calling relationship between the multiple program units, wherein the information of the program unit contains the execution time corresponding to the program unit; in the fusion process, the program unit corresponding to each execution time can be found from the stack data, and the execution time can be updated to the information of the corresponding program unit to associate the execution time with the corresponding program unit.

[0117] Optionally, in order to reduce the amount of data processing, the target program unit can be set in advance, so that only the execution time of the target program unit in the refresh process of each application frame is obtained, wherein the target program unit can be a program unit with a relatively high execution time. Optionally, the target program unit can be a logical thread, a rendering thread (for example, RenderThread), etc. of the target application. For example, if the target application is a game application, the logical thread can include GameThread (game thread) or UnityMainThread (main thread).

[0118] Step S530: performing anomaly detection based on the fused stack data.

[0119] After the fused stack data is obtained, performance analysis may be performed based on the fused stack data to obtain a performance analysis result.

[0120] In an optional implementation, an abnormal application frame can be found from the application frame of the target application, and the corresponding program unit with a longer execution time can be found from the fusion stack data corresponding to the abnormal application frame, so as to determine the program unit that causes the abnormal refresh of the abnormal application frame. Among them, since the longer the refresh time of the application frame, the higher the probability of freezes and the like during the refresh process of the application frame, therefore, it is possible to determine whether the application frame is an abnormal application frame based on the refresh time of the application frame, and the specific determination method can be flexibly set according to actual needs. In an optional example, the application frame whose corresponding refresh time is greater than or equal to the set abnormal time threshold can be regarded as an abnormal application frame, wherein the value of the abnormal time threshold can be set according to experience, etc., and the refresh time of the application frame can be calculated according to the refresh time; in another optional example, an application frame whose refresh time has a larger difference with the refresh time of other application frames can also be found from the application frame of the target application, and the found application frame can be regarded as an abnormal application frame.

[0121] It should be noted that Figure 5 The specific implementation details of steps S210 to S230 shown in FIG. Figure 2 Steps S210 to S230 shown are not repeated here.

[0122] exist Figure 5 In the illustrated embodiment, stack data is obtained during the occurrence of a target abnormal performance event, and the stack data includes information about multiple program units and the calling relationship between the multiple program units. The execution durations of the multiple program units during the refresh process of each application frame are fused into the stack data, thereby obtaining fused stack data including the calling relationship between the multiple program units and the execution durations corresponding to the multiple program units. Exception detection is performed based on the stack data to improve detection accuracy.

[0123] In an exemplary embodiment, see Figure 6 , Figure 6 is a flowchart of an abnormality detection method shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The terminal device 110 in the implementation environment shown in the figure may also be executed by Figure 1 The server 120 in the implementation environment shown in the figure may also execute the command. Figure 1 The terminal device 110 and the server 120 in the illustrated implementation environment execute together.

[0124] like Figure 6 As shown, the method includes steps S210 to S230, steps S510 to S520, and steps S610 to S630, wherein steps S610 to S630 are described in detail as follows:

[0125] Step S610, selecting multiple merged application frames from the application frames included in the target application, and segmenting the fused stack data corresponding to each merged application frame according to a set data volume to obtain multiple sub-data sets; wherein the data volume of each sub-data set matches the set data volume.

[0126] A merged application frame refers to an application frame whose corresponding fused stack data needs to be merged with the fused stack data corresponding to other application frames. The merged application frame may be selected by the user, or the merged application frame may be an abnormal application frame; the frame numbers corresponding to multiple merged application frames (the numbers used to characterize the order of refresh) may not be continuous, or the frame numbers corresponding to multiple merged application frames may be continuous. In an optional example, under the condition that any application frame is determined to be an abnormal application frame, other abnormal application frames with continuous frame numbers with any application frame can be searched, so that any application frame and other abnormal application frames can be used as merged application frames, so as to merge the fused stack data corresponding to these multiple merged application frames and perform exception detection. In this way, merging the stack data for application frames with longer refresh times can facilitate more accurate finding of program units with longer execution times based on the merged data, thereby locating the cause of the exception.

[0127] After selecting multiple merged application frames, since different fused stack data may contain some data that can be merged, for example, the same program units may exist in the calling relationships in different fused stack data, in order to improve the accuracy of performance analysis, the fused stack data corresponding to these multiple merged application frames may be merged.

[0128] Since the data volume of each fused stack data is large, in order to improve the merging efficiency, a set data volume can be set. The specific value of the set data volume can be flexibly set according to actual needs. For example, it can be set to 10M, 20M, etc. In the merging process, for the stack data corresponding to each application frame, it can be first divided according to the set data volume, so as to obtain multiple sub-data sets, so that the data volume of each sub-data set matches the set data volume. Among them, the data volume of each sub-data set matches the set data volume can mean that the data volume of the sub-data set is the same or similar to the set data volume. Optionally, if the data volume of any fused stack data matches the set data volume, the fused stack data may not be divided.

[0129] Step S620 , merging the sub-data sets corresponding to the multiple merged application frames in sequence to obtain merged stack data corresponding to the multiple merged application frames.

[0130] After the stack data corresponding to each merged application frame is segmented, the multiple sub-data sets obtained by the segmentation can be merged in sequence to obtain the merged stack data corresponding to the multiple merged application frames. That is to say, firstly, 2 sub-data sets are extracted from the multiple sub-data sets, and the extracted sub-data sets are merged to obtain candidate merged stack data; then, another sub-data set is extracted from the multiple sub-data sets, and the extracted sub-data set is merged with the candidate merged stack data to obtain updated candidate merged stack data, and so on, until the last sub-data set in the multiple sub-data is merged with the candidate merged stack data to obtain the merged stack data. Among them, the merging order of the multiple sub-data sets can be random, or the multiple sub-data sets can be merged in sequence according to the order of the acquisition time of the sub-data sets from front to back.

[0131] Optionally, since the fused stack data contains the calling relationship between program units, the corresponding sub-data sets obtained by segmentation also contain the calling relationship between program units. Therefore, in the merging process, multiple sub-data sets can be merged in turn according to the calling relationship contained in each sub-data set, so as to merge the calling relationships in different fused stack data. For example, assuming that the calling relationship contained in the fused stack data corresponding to the first merged application frame is: program unit A calls program unit B, program unit B calls program unit C, and it is split into two sub-data sets, the first sub-data set contains program unit A calling program unit B, and the second sub-data set contains program unit B calling program unit C; the calling relationship contained in the fused stack data corresponding to the second merged application frame is: program unit A calls program unit D, program unit D calls program unit E, and it is split into two sub-data sets, the first sub-data set contains program unit A calling program unit D, and the second sub-data set contains program unit D calling program unit E. After these four sub-data sets are merged in turn, the merged stack data contains program unit A calling program unit B and program unit D, program unit B calling program unit C, and program unit D calling program unit E. Since the fused stack data of each application frame includes the execution time of the program unit during the refresh process of the application frame, the execution time of the same program unit in different fused stack data can also be merged during the merging process to obtain the total execution time of the program unit during the refresh process of multiple merged application frames. For example, assuming that there are 2 merged application frames, the execution time of a program unit during the refresh process of these 2 merged application frames is 10 milliseconds and 20 milliseconds respectively, then after the merging, the total execution time of the program unit is 30 milliseconds.

[0132] Step S630: performing anomaly detection based on the merged stack data.

[0133] After obtaining the merged stack data corresponding to the multiple merged application frames, an exception detection may be performed. For example, a program unit whose corresponding total execution time exceeds a corresponding threshold may be found from the merged application frames, thereby determining that the cause of the exception is the program unit.

[0134] It should be noted that Figure 6 The specific implementation details of steps S210 to S230 shown in FIG. Figure 2 Steps S210 to S230 are shown. Figure 6 The specific implementation details of steps S510 to S520 shown in FIG. Figure 5 Steps S510 to S520 shown are not repeated here.

[0135] exist Figure 6 In the illustrated embodiment, the fused stack data corresponding to each merged application frame is segmented according to a set data volume to obtain a plurality of sub-data sets, and then the sub-data sets corresponding to the plurality of merged application frames are merged in turn to obtain merged stack data corresponding to the plurality of merged application frames, thereby limiting the amount of data merged each time and improving the merging efficiency.

[0136] In an exemplary embodiment, see Figure 7 , Figure 7 is a flowchart of an abnormality detection method shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The terminal device 110 in the implementation environment shown in the figure may also be executed by Figure 1 The server 120 in the implementation environment shown in the figure may also execute the command. Figure 1 The terminal device 110 and the server 120 in the illustrated implementation environment execute together.

[0137] like Figure 7 As shown, the method includes steps S210 to S230, steps S510 to S520, steps S710 to S730, and step S630, wherein steps S710 to S730 are described in detail as follows:

[0138] Step S710 , selecting a plurality of merged application frames from the application frames included in the target application, and obtaining the calling level of each program unit in the fusion stack data corresponding to each merged application frame in the corresponding calling relationship.

[0139] It should be noted that the calling level of a program unit refers to its position in the calling relationship. The higher the calling level, the more program units it calls. The program unit with the lowest calling level does not call other program units. For example, assuming that in the calling relationship, program unit A calls program unit B, and program unit B calls program unit C, then program unit A has the highest calling level, which is the first level, and program unit C has the lowest calling level, which is the third level.

[0140] In order to improve the merging efficiency, the program units may be merged according to their calling levels. Therefore, for each merged application frame, each program unit may be obtained from its corresponding fusion stack data, and the calling level of each program unit in the corresponding calling relationship may be found.

[0141] Step S720 , segmenting the information of multiple program units contained in the fused stack data corresponding to each merged application frame according to the set data volume and the calling level of each program unit to obtain multiple sub-data sets.

[0142] After determining the calling level of each program unit, for the fused stack data corresponding to each merged application frame, during the segmentation process, the information of program units belonging to the same calling level can be divided into the same sub-data set according to the calling level of the program units, or the information of multiple program units with adjacent calling levels can be divided into the same sub-data set, so that each sub-data set contains information of program units belonging to the same calling level or adjacent calling levels, and the data volume of each sub-data set matches the set data volume. Among them, the information of program units belonging to the same calling level can be divided into the same sub-data set, so that the information of multiple program units contained in each sub-data set belongs to the same calling level; if there are many program units belonging to the same calling level, the information of program units belonging to the same calling level can also be divided into multiple sub-data sets, so that the data volume of each sub-data set matches the set data volume.

[0143] Step S730 , merging the sub-data sets corresponding to the plurality of merged application frames in order from low to high in the order of the corresponding call levels, to obtain merged stack data corresponding to the plurality of merged application frames.

[0144] After obtaining the sub-datasets corresponding to the multiple merged application frames, since each sub-dataset contains information of program units belonging to the same call level or adjacent call levels, in order to improve the merging efficiency, the multiple sub-datasets can be merged in order from low to high in the order of the call levels corresponding to the program units contained in each sub-dataset. That is to say, first extract the two sub-datasets with the lowest call level from the multiple sub-datasets, and merge the two sub-datasets to obtain candidate merged stack data, and then extract the sub-dataset with the lowest call level from the multiple sub-datasets, and merge the extracted sub-dataset with the candidate merged stack data to update the candidate merged stack data; after the update, extract the sub-dataset with the lowest call level from the multiple sub-datasets again, and so on, until the last sub-dataset is extracted from the multiple sub-datasets, and merge the sub-dataset with the candidate merged stack data to obtain the merged stack data. For example, see Figure 8 As shown, the fused stack data 810 of the first merged application frame is split into sub-datasets 811 and 812 according to the calling level and the set data volume, and the fused stack data 820 of the second merged application frame is split into sub-datasets 821 and 822. Since the calling levels corresponding to sub-datasets 811 and 821 are the lowest, sub-datasets 811 and 821 are merged first, the merged data is merged with sub-dataset 812, and finally sub-dataset 822 is merged.

[0145] It should be noted that Figure 7 The specific implementation details of steps S210 to S230 shown in FIG. Figure 2 Steps S210 to S230 are shown. Figure 7 The specific implementation details of steps S510 to S520 shown in FIG. Figure 5 Steps S510 to S520 are shown. Figure 7 The specific implementation details of step S610 shown can be referred to Figure 6 The step S610 shown is not repeated here.

[0146] exist Figure 7 In the embodiment shown, according to the set data volume and the call level of each program unit, the information of multiple program units contained in the fused stack data corresponding to each merged application frame is segmented to obtain multiple sub-data sets, and the sub-data sets corresponding to the multiple merged application frames are merged in order from low to high in the corresponding call level, so as to improve the merging efficiency by merging through the improved recursive algorithm. For example, as shown in Table 1 below, based on Figure 7The improved recursive algorithm provided by the illustrated embodiment merges the fused stack data corresponding to n application frames. Compared with merging by Divide and Conquer (divide and conquer algorithm) and Naive Brute-Force (brute force algorithm), the time complexity (Time Complexity) and space complexity (Space Complexity) are greatly reduced, and the merging efficiency is high.

[0147]

[0148] Table 1

[0149] In an exemplary embodiment, see Fig. 9 , Fig. 9 is a flowchart of an abnormality detection method shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The terminal device 110 in the implementation environment shown in the figure may also be executed by Figure 1 The server 120 in the implementation environment shown in the figure may also execute the command. Figure 1 The terminal device 110 and the server 120 in the illustrated implementation environment execute together.

[0150] like Fig. 9 As shown, the method includes steps S210 to S230, steps S510 to S520, steps S910 to S930, and steps S620 to S630, wherein steps S910 to S930 are described in detail as follows:

[0151] Step S910 , selecting a plurality of merged application frames from the application frames included in the target application, and searching for a program unit whose corresponding execution time is less than or equal to a set time threshold from the fusion stack data corresponding to each merged application frame.

[0152] Since the probability of causing refresh jamming is relatively small for program units with shorter execution time, before merging the fused stack data corresponding to the multiple merged application frames, the information of the corresponding program units with shorter execution time can be filtered out first. Correspondingly, a time threshold can be set, and the time threshold is used to determine whether to filter out the information of the program unit. If the execution time of the program unit is less than or equal to the set time threshold, the information of the program unit is filtered out. The specific value of the time threshold can be flexibly set according to actual needs. In an optional embodiment, the time threshold can be positively correlated with the refresh time of the application frame to which the fused stack data belongs, that is, the longer the refresh time, the higher the time threshold. For example, the time threshold can be set to 50%, 40%, etc. of the refresh time of the application frame; or, the multiple program units contained in each fused stack data can be sorted in order of the corresponding execution time from low to high, and the execution time of the specified number of program units is used as the time threshold, so as to filter out the information of the specified number of program units with lower execution time, wherein the specified number can be pre-set, for example, set to 10, 20, etc.

[0153] In order to filter out information of program units with shorter execution time, for each merged application frame, the corresponding program units with execution time less than or equal to the set time threshold may be searched from the fusion stack data.

[0154] Step S920: deleting the information corresponding to the found program unit from the fusion stack data corresponding to each merged application frame.

[0155] From the fusion stack data corresponding to each merged application frame, the information corresponding to the program unit with a shorter execution time is deleted, thereby reducing the amount of data in the performance analysis process.

[0156] Step S930 , dividing the fused stack data after the deletion process according to the set data volume to obtain a plurality of sub-data sets.

[0157] After deleting information of program units with shorter execution time from the fused stack data of each application frame, the fused stack data is segmented according to a set data volume to obtain a plurality of sub-data sets.

[0158] It should be noted that Fig. 9 The specific implementation details of steps S210 to S230 shown in FIG. Figure 2 Steps S210 to S230 are shown. Fig. 9 The specific implementation details of steps S510 to S520 shown in FIG. Figure 5 Steps S510 to S520 are shown. Fig. 9The specific implementation details of steps S620 to S630 shown in FIG. Figure 6 Steps S620 to S630 shown are not repeated here.

[0159] exist Fig. 9 In the illustrated embodiment, information corresponding to program units whose execution duration is less than or equal to a set duration threshold is deleted from the fused stack data corresponding to each merged application frame, and then the fused stack data is split and merged. This can filter out invalid data, reduce the amount of data in the merging process, and improve merging efficiency.

[0160] In an exemplary embodiment, see Fig.10 , Fig.10 is a flowchart of an abnormality detection method shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The terminal device 110 in the implementation environment shown in the figure may also be executed by Figure 1 The server 120 in the implementation environment shown in the figure may also execute the command. Figure 1 The terminal device 110 and the server 120 in the illustrated implementation environment execute together.

[0161] like Fig.10 As shown, the method includes steps S210 to S230, steps S510 to S520, and steps S1010 to S1030, wherein steps S1010 to S1030 are described in detail as follows:

[0162] Step S1010, calculating the refresh duration of each application frame according to the refresh time of each application frame, and displaying a duration display interface; wherein the duration display interface includes the refresh durations corresponding to the multiple application frames of the target application.

[0163] In order to determine whether the refresh of the application frame is abnormal, the refresh duration of each application frame may be calculated, and the refresh durations corresponding to the multiple application frames included in the target application may be displayed in the duration display interface.

[0164] Among them, the specific display method of the refresh durations corresponding to the multiple application frames can be flexibly set according to actual needs. In an optional implementation, in order to facilitate observation by testers, etc., a duration chart can be generated according to the refresh durations corresponding to the multiple application frames, and the duration chart can be displayed in the duration display interface. In the chart, the refresh durations of the multiple application frames are arranged in order from small to large according to the frame sequence number. The chart can be a bar chart, a line chart, etc.

[0165] Optionally, the duration display interface may also include the execution duration of the target program unit in the refresh time of multiple application frames. Fig.11 As shown, Fig.11 It is an exemplary duration chart, in which the horizontal axis represents the frame sequence number and the vertical axis represents the duration, wherein line 1101 represents the refresh duration of the application frame, line 1102 represents the execution duration of the rendering function in the refresh time of the application frame, and line 1103 represents the execution duration of the main function in the refresh time of the application frame.

[0166] Step S1020 , in response to a selection operation based on the duration display interface, determining a target application frame selected by the selection operation.

[0167] The user can make a selection based on the duration display interface, so that the selected application frame, ie, the target application frame, is determined according to the user's selection operation.

[0168] Step S1030, displaying an exception detection chart generated according to the fusion stack data corresponding to the target application frame; wherein the exception detection chart corresponding to the target application frame includes the calling relationship between the program units corresponding to the target application frame and the execution time of each program unit during the refresh process of the target application frame.

[0169] An anomaly detection chart can be generated and displayed based on the fused stack data of the target application frame. The anomaly detection chart contains the calling relationship between the program units corresponding to the target application frame and the execution time of each program unit during the refresh process of the target application frame. Among them, the anomaly detection chart includes but is not limited to at least one of the forms such as tables and flame charts. Optionally, the anomaly detection chart can be displayed on the anomaly detection interface, and the anomaly detection interface and the duration display interface can be the same interface; or, the anomaly detection interface and the duration display interface may not be the same interface. Under this condition, the anomaly detection interface can be displayed suspended on the duration display interface, or, it can also be displayed in other ways.

[0170] Among them, if the number of target application frames is one, it is possible to perform analysis based only on the fusion stack data of the target application frame to generate an anomaly detection chart corresponding to the target application frame to implement frame-level analysis, wherein the chart includes the calling relationship between the program units corresponding to the target application frame, and the execution time of each program unit during the refresh process of the target application frame. Optionally, the anomaly detection chart may also include the percentage between the execution time of each program unit and the refresh time of the target application frame. In an optional example, if the user selects an application frame, its corresponding anomaly detection chart may be as follows: Fig.12 , Fig.13 As shown, Fig.12 is an anomaly detection chart in tabular form, Fig.13It is a flame graph, and the characters in the graph are function names.

[0171] It should be noted that Fig.10 The specific implementation details of steps S210 to S230 shown in FIG. Figure 2 Steps S210 to S230 are shown. Fig.10 The specific implementation details of steps S510 to S520 shown in FIG. Figure 5 Steps S510 to S520 shown are not repeated here.

[0172] exist Fig.10 In the illustrated embodiment, a duration display interface including refresh durations of multiple application frames is first displayed, thereby allowing the user to more intuitively observe the refresh duration of each application frame and thereby determine whether there is an application frame with a freeze. Then, the user can make a selection in the duration display interface to view an anomaly detection chart corresponding to the selected target application frame. The anomaly detection chart includes a calling relationship between multiple program units corresponding to the target application frame and the execution duration of each program unit during the refresh process of the target application frame. This allows the user to more intuitively understand the execution duration of each program unit during the refresh process of the target application frame, facilitates the user to locate the anomaly, and improves the convenience of anomaly location.

[0173] In an exemplary embodiment, see Fig.14 , Fig.14 is a flowchart of an abnormality detection method shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The terminal device 110 in the implementation environment shown in the figure may also be executed by Figure 1 The server 140 in the implementation environment shown in the figure may also execute the command. Figure 1 The terminal device 110 and the server 140 in the illustrated implementation environment execute together.

[0174] like Fig.14 As shown, the method includes steps S210 to S230, steps S510 to S520, steps S1010 to S1020, and steps S1410 to S1430, wherein steps S1410 to S1430 are described in detail as follows:

[0175] Step S1410 : if there are multiple target application frames, merge the fused stack data of the multiple target application frames.

[0176] The user can also select multiple application frames to obtain multiple target application frames, and merge the fused stack data corresponding to the multiple target application frames. The specific merging method can refer to the above-mentioned method of merging the fused stack data corresponding to the multiple merged application frames, which will not be repeated here.

[0177] Optionally, if each target application frame corresponds to a plurality of fused stack data, the fused stack data respectively corresponding to the plurality of target application frames may be merged.

[0178] Step S1420, generating an anomaly detection chart corresponding to multiple target application frames based on the merged data; wherein the anomaly detection chart includes the calling relationship between multiple program units corresponding to the multiple target application frames and the total execution time of each program unit during the refresh process of the multiple target application frames.

[0179] After merging the fusion stack data corresponding to the multiple target application frames, an anomaly detection chart corresponding to the multiple target application frames is generated according to the merged data, wherein the anomaly detection chart may include the calling relationship between the program units corresponding to the multiple target application frames and the total execution time of each program unit during the refresh process of the multiple target application frames. For example, see Fig.15A As shown, if the user selects multiple application frames (the application frames circled in the box in the figure) in the duration display interface, refer to Fig. 15B , Fig. 15C As shown, Fig. 15B The anomaly detection chart in tabular form corresponding to these multiple application frames is: Fig. 15C The flame graphs corresponding to these multiple application frames.

[0180] Step S1430 , displaying anomaly detection charts corresponding to multiple target application frames.

[0181] After obtaining the anomaly detection charts corresponding to the multiple target application frames, the anomaly detection charts may be displayed.

[0182] It should be noted that Fig.14 The specific implementation details of steps S210 to S230 shown in FIG. Figure 2 Steps S210 to S230 are shown. Fig.14 The specific implementation details of steps S510 to S520 shown in FIG. Figure 5 Steps S510 to S520 are shown. Fig.14 The specific implementation details of steps S1010 to S1020 shown in FIG. Fig.10 Steps S1010 to S1020 shown are not repeated here.

[0183] exist Fig.14In the illustrated embodiment, if there are multiple target application frames, the fusion stack data of the multiple target application frames are merged, and anomaly detection charts corresponding to the multiple target application frames are generated based on the merged data; wherein the anomaly detection chart includes the calling relationship between the program units corresponding to the multiple target application frames and the total execution time of each program unit during the refresh process of the multiple target application frames, and the anomaly detection charts corresponding to the multiple target application frames are displayed, so that the user can locate the anomaly based on the anomaly detection charts corresponding to the multiple target application frames.

[0184] In an exemplary embodiment, see Fig.16 , Fig.16 is a flowchart of an abnormality detection method shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The terminal device 110 in the implementation environment shown in the figure may also be executed by Figure 1 The server 160 in the implementation environment shown in the figure may also be executed by Figure 1 The terminal device 110 and the server 160 in the illustrated implementation environment execute together.

[0185] like Fig.16 As shown, the method includes steps S210 to S230, steps S510 to S520, and steps S1610 to S1630, wherein steps S1610 to S1630 are described in detail as follows:

[0186] Step S1610 , obtaining application frames respectively included in multiple versions of target applications, and obtaining reference program units from fusion stack data corresponding to the application frames included in each version of the target application.

[0187] For the target application, it may include different versions. For example, during the development process of the target application, the target application will be continuously optimized, and multiple versions of the target application will be generated during this process. In order to improve the accuracy of anomaly detection and thus optimize the target application, for each version of the target application, the application frames contained therein can be obtained. Optionally, in order to improve comparability, the application frames contained in the multiple versions of the target application obtained belong to the same application scenario, and the multiple versions of the target application can be tested separately through the same test case, and the application frames of each version of the target application during the test process can be obtained.

[0188] After obtaining the application frame contained in each version of the target application, the reference program unit can be obtained from the fusion stack data corresponding to the application frame. Among them, the reference program unit is a program unit used for subsequent comparison to determine whether it is abnormal. In order to ensure that multiple versions of target applications are involved in the comparison, the reference program unit can be a program unit included in the fusion stack data corresponding to each version of the target application. For example, assuming that there are 2 versions of program units, the fusion stack data corresponding to the first version of the target application contains program units A, B, and C; the fusion stack data corresponding to the second version of the target application contains program units A, B, and D, then the reference program unit contains program units A and B.

[0189] Step S1620 , calculating the execution time of the reference program unit in each version of the target application according to the fusion stack data corresponding to the application frame included in each version of the target application.

[0190] The fusion stack data corresponding to the application frame contained in each version of the target application contains the execution time of the reference program unit during the refresh process of the application frame. Therefore, the execution time of the reference program unit in the target application of this version can be calculated based on the execution time. Among them, for each version of the target application, if only one application frame contained in it is obtained, the execution time of the reference program unit in the refresh process of the application frame can be directly used as the execution time of the reference program unit in the target application of this version; if multiple application frames contained in it are obtained, the maximum value, minimum value, average value, etc. can be selected from the execution time of the reference program unit in the refresh process of these multiple application frames as the execution time of the reference program unit in the target application of this version. For example, assuming that 3 application frames are obtained for a certain version of the target application, the execution time of the reference program unit in the refresh process of these 3 application frames is 10 milliseconds, 11 milliseconds, and 15 milliseconds respectively, then the average value of 12 milliseconds is used as the execution time of the reference program unit in the target application of this version.

[0191] Step S1630 , performing anomaly detection based on the execution time of the reference program unit in the target application of multiple versions.

[0192] Anomaly detection can be performed based on the execution time of the reference program unit in multiple versions of the target application.

[0193] In an optional implementation, an execution time comparison chart can be generated and displayed based on the execution time of the reference program unit in multiple versions of the target application. The execution time comparison chart includes the execution time of the reference program unit in multiple versions of the target application, so that the user can locate the abnormality based on the execution time comparison chart; wherein the execution time comparison chart can be a line chart, a bar chart, a table, etc. For example, see Fig.17 As shown, Fig.17 In the figure, the horizontal axis represents the version number, the vertical axis represents the execution time, different broken lines represent different reference program units, and different points on the same broken line represent the execution time of the reference program unit in different versions of the target application. According to this figure, the fluctuation of the execution time of each program unit in different versions of the target application can be intuitively seen.

[0194] In another optional implementation, if there are multiple reference program units, the fluctuation range of the execution time of each program unit can be calculated based on the execution time of each reference program unit in multiple versions of the target application, and the program unit with a fluctuation range exceeding the threshold among the multiple reference program units is regarded as an abnormal program unit, and repair is performed based on the abnormal program unit. In other words, the execution time of each program unit of different versions can be compared to locate the program unit with abnormally increased execution time, so as to quickly discover the jamming problem, locate the abnormal program unit, and quickly solve the jamming problem.

[0195] It should be noted that Fig.16 The specific implementation details of steps S210 to S230 shown in FIG. Figure 2 Steps S210 to S230 are shown. Fig.16 The specific implementation details of steps S510 to S520 shown in FIG. Figure 5 Steps S510 to S520 shown are not repeated here.

[0196] exist Fig.16 In the illustrated embodiment, fusion stack data of different versions of target applications can be combined to perform anomaly detection based on execution time of reference program units in different versions of target applications, thereby improving anomaly detection accuracy and optimizing the target application.

[0197] In an exemplary embodiment, see Fig.18 , Fig.18 is a flowchart of an abnormality detection method shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1 The terminal device 110 in the implementation environment shown in the figure may also be executed by Figure 1The server 120 in the implementation environment shown in the figure may also execute the command. Figure 1 The terminal device 110 and the server 120 in the illustrated implementation environment execute together.

[0198] like Fig.18 As shown, the method includes step S210, step S1810-step S1830, and step S230-step S240, wherein the detailed description of step S1810-step S1830 is as follows:

[0199] Step S1810: During the operation of the target application, a performance test is performed on the operating system.

[0200] The specific detection method can be found in the description of the aforementioned embodiment and will not be described in detail here.

[0201] Step S1820: If an abnormal performance event is detected, the detected abnormal performance event and the occurrence time of the abnormal performance event are stored in a set storage area.

[0202] The set storage area refers to a storage area used to store detected abnormal performance events. Therefore, after an abnormal performance event is detected, the abnormal performance event and the occurrence time of the abnormal performance event can be stored in the set storage area.

[0203] The type of the set storage area may be a data buffer, a shared memory, or the like.

[0204] Step S1830: adjusting the storage capacity of the set storage area according to the detected abnormal performance event.

[0205] In order to avoid the situation where abnormal performance events cannot be stored in the set storage area, the storage capacity of the set storage area can be dynamically adjusted according to the detected abnormal performance events. The storage capacity of the set storage area can be adjusted in real time or periodically according to the detected abnormal performance events.

[0206] It should be noted that the specific method of adjusting the storage capacity of the set storage area can be flexibly set according to actual needs. In an optional implementation, since the detected abnormal performance events are stored in the set storage area, the occupied storage capacity in the set storage area can be obtained. If the occupied storage capacity is greater than or equal to the set capacity upper limit threshold, the storage capacity of the set storage area is increased, so that when the occupied storage capacity in the set storage area is large, the set storage area is automatically expanded; wherein, the capacity upper limit threshold is used to determine whether to increase the storage capacity of the set storage area, and its specific value can be flexibly set according to actual needs. Optionally, the capacity upper limit threshold can be positively correlated with the storage capacity of the set storage area, that is, the higher the storage capacity of the set storage area, the higher the capacity upper limit threshold. For example, the capacity upper limit threshold can be set to 80%, 60%, etc. of the storage capacity of the set storage area. In an optional implementation, if the occupied storage capacity is less than or equal to the set capacity lower limit threshold, the storage capacity of the set storage area is reduced, that is, when the occupied storage capacity in the set storage area is small, the set storage area is automatically reduced, wherein the capacity lower limit threshold is used to determine whether to reduce the storage capacity of the set storage area, the capacity lower limit threshold is less than the capacity upper limit threshold, and its specific value can be flexible according to actual needs, for example, it can be set to 180% of the storage capacity of the set storage area. In order to improve the control accuracy, the storage capacity of the set storage area can be reduced only when the occupied storage capacity is less than or equal to the set capacity lower limit threshold, and the duration of this state is greater than or equal to the set duration threshold; or, the storage capacity of the set storage area can be reduced when the occupied storage capacity is less than or equal to the set capacity lower limit threshold, and the duration of no abnormal performance event being detected is greater than or equal to the set duration threshold.

[0207] It should be noted that Fig.18 The specific implementation details of steps S210, S230-S240 shown in FIG. Figure 2 Steps S210, S230-S240 shown are not repeated here.

[0208] exist Fig.18 In the illustrated embodiment, the storage capacity of the set storage area is dynamically adjusted based on the detected abnormal performance events, thereby avoiding the situation where the abnormal performance events cannot be stored and the abnormal performance events are missed.

[0209] In an exemplary embodiment, see Fig.19 , Fig.19 is a flowchart of an abnormality detection method shown in another exemplary embodiment of the present application. The method can be applied to Figure 1 The implementation environment shown, which can be Figure 1The terminal device 110 in the implementation environment shown in the figure may also be executed by Figure 1 The server 120 in the implementation environment shown in the figure may also execute the command. Figure 1 The terminal device 110 and the server 120 in the illustrated implementation environment execute together.

[0210] like Fig.19 As shown, the method includes step S210, step S1810-step S1820, step S1910-step S1920, and step S230-step S240, wherein step S1910-step S1930 are described in detail as follows:

[0211] Step S1910: If the occupied storage capacity in the set storage area is greater than or equal to the set capacity upper limit threshold, the occurrence frequency of abnormal performance events is calculated based on the detected abnormal performance events.

[0212] If the occupied storage capacity in the set storage area is greater than or equal to the set capacity upper limit threshold, the capacity of the set storage area needs to be increased. In order to improve the accuracy, the frequency of occurrence of abnormal performance events can be calculated based on the detected abnormal performance events.

[0213] Optionally, in order to improve the real-time nature of the occurrence frequency, the sending frequency of abnormal performance events may be calculated periodically, and the occurrence frequency of abnormal performance events may be calculated based on the abnormal performance events detected within the corresponding calculation period.

[0214] Step S1920, increasing the storage capacity of the storage area according to the occurrence frequency; wherein the occurrence frequency is positively correlated with the increased storage capacity.

[0215] The higher the frequency of abnormal performance events, the larger the amount of data that needs to be stored in the set storage area. Therefore, the storage capacity of the storage area can be increased according to the frequency of occurrence, and the frequency of occurrence is positively correlated with the increased storage capacity. That is, the higher the frequency of occurrence, the higher the increased storage capacity. For example, assuming the frequency of occurrence is 10 times / minute, then increase 10M, if the frequency of occurrence is 20 times / minute, then increase 30M.

[0216] In other optional implementation modes, the storage capacity of the set storage area may be increased under the condition that the frequency of occurrence of abnormal performance events is greater than or equal to a frequency threshold.

[0217] It should be noted that Fig.19 The specific implementation details of steps S210, S230-S240 shown in FIG. Figure 2 Steps S210, S230-S240 shown, Fig.19The specific implementation details of steps S1810 to S1820 shown in FIG. Fig.18 Steps S1810 to S1820 shown are not repeated here.

[0218] exist Fig.19 In the illustrated embodiment, if the occupied storage capacity in the set storage area is greater than or equal to the set capacity upper limit threshold, the frequency of occurrence of abnormal performance events is calculated based on the detected abnormal performance events; the storage capacity of the storage area is increased based on the frequency of occurrence; wherein the frequency of occurrence is positively correlated with the increased storage capacity, thereby reasonably increasing the storage capacity of the set storage area so that the abnormal performance events that occur can be stored in the set storage area.

[0219] In order to better understand the present invention, a game application is used as an example for explanation. Fig. 20 As shown, the anomaly detection method includes:

[0220] 1. Customize initialization parameters.

[0221] Among them, you can customize the target thread, event collection frequency and other parameters in the game application. The freeze of the game application is usually caused by CPU bottleneck and GPU bottleneck. The GPU bottleneck is mainly caused by serious time-consuming operations in the GPU rendering process, such as too many drawcalls, shadow surfaces, too many triangles, bandwidth limitations, etc. Therefore, the target thread can be GameThread or UnityMainThread, which are threads that take a long time in the rendering process.

[0222] 2. Collect the refresh time of the application frame and the execution time of the target thread.

[0223] Among them, a hook function can be injected into the process of the game application based on jdwp, and during the running process of the game application, the refresh time of each application frame and the execution time of the target thread during the refresh process of each application frame are collected through the hook function. For details, please refer to the records of the above embodiments, which will not be repeated here.

[0224] 3. Collect abnormal performance events.

[0225] Optionally, abnormal performance events can be collected through perf-event (a core mechanism in the kernel for detecting events). The collection process can be as follows: Fig.21As shown: first define the configuration (such as time collection frequency, etc.) and open perf-event, set the memory cache area for storing abnormal performance events, and if an abnormal performance event is detected, record the abnormal performance event, and when the abnormal performance event ends, stop event recording and save the recorded data. Since the freeze of game applications is usually caused by CPU bottlenecks, abnormal performance events corresponding to CPU performance can be collected.

[0226] 4. Parse stack data based on frame alignment.

[0227] Among them, frame alignment means: according to the refresh time of the application frame and the occurrence time of the abnormal performance event, the application frame to which each abnormal performance event belongs is searched from the detected application frame sequence, so as to align the abnormal performance event with the corresponding application frame.

[0228] Each abnormal performance event includes stack data, from which the stack data can be parsed and the execution time of the target thread during the refresh process of each application frame can be merged into the corresponding stack data.

[0229] 5. Merge stack data.

[0230] In order to improve the accuracy of anomaly detection, the stack data corresponding to multiple application frames may be merged. The specific merging process can be referred to the aforementioned embodiment and will not be described again here.

[0231] 6. Visual interactive interface displays data.

[0232] The refresh time of the acquired application frame, the function call relationship contained in the stack data, the function running time and other data can be displayed through a visual interactive interface, wherein the acquired data can be displayed in the form of charts and the like.

[0233] 7. Generate anomaly detection report.

[0234] Among them, the cause of the exception can be determined based on the displayed data and the data obtained in the aforementioned process, so as to generate an exception detection report based on the cause of the exception, for example, determining the exception cause frame and the exception function corresponding to the exception cause frame, etc. Among them, the exception detection report corresponding to each application frame can be generated based on the stack data corresponding to each application frame, so as to optimize the performance bottleneck, problems, etc.; of course, the stack data of multiple application frames can also be merged, and the exception detection reports corresponding to multiple application frames can be generated based on the merged data.

[0235] Optionally, the data obtained in the aforementioned process can be used to automatically reproduce the jamming scenario, and an anomaly detection report can be generated based on the reproduction situation.

[0236] Fig. 20In the illustrated embodiment, two powerful tools, perf and JDWP, are integrated to accurately associate abnormal performance events with application frame sequences, enabling more accurate detection and analysis of application performance, anomalies, etc. In addition, the solution collects stack data from the bottom layer of the system through perf, and can be applied to more applications and has a wide range of uses.

[0237] See also Fig. 22 , Fig. 22 FIG. 1 is a block diagram of an abnormality detection device shown in an exemplary embodiment of the present application. Fig. 22 As shown, the device comprises:

[0238] The detection module 2201 is configured to detect the refresh time of each application frame during the operation of the target application to be detected;

[0239] An acquisition module 2202 is configured to acquire multiple abnormal performance events occurring during the operation of the target application and the occurrence time of each abnormal performance event;

[0240] The search module 2203 is configured to search for a target abnormal performance event corresponding to each application frame from the plurality of abnormal performance events; wherein the refresh time of each application frame matches the occurrence time of the target abnormal performance event;

[0241] The processing module 2204 is configured to perform anomaly detection according to the target abnormal performance event corresponding to each application frame.

[0242] In an exemplary embodiment, based on the aforementioned scheme, the detection module 2201 is specifically configured as follows: injecting a set time acquisition function into the process of the target application; during the running of the target application, if the frame loop function in the target application is called to refresh each application frame, the first calling time point of the frame loop function is acquired through the time acquisition function; if the frame loop function is called to refresh the next application frame of each application frame, the second calling time point of the frame loop function is acquired through the time acquisition function; and the refresh time of each application frame is calculated based on the first calling time point and the second calling time point.

[0243] In an exemplary embodiment, based on the aforementioned scheme, the processing module 2204 is specifically configured as follows: from the target abnormal performance event, obtain the stack data during the occurrence of the target abnormal performance event; the stack data contains information of multiple program units and the calling relationship between the multiple program units; obtain the execution time of the multiple program units during the refresh process of each application frame, and fuse the obtained execution time into the stack data to obtain fused stack data; perform anomaly detection based on the fused stack data.

[0244] In an exemplary embodiment, based on the aforementioned scheme, the processing module 2204 is specifically configured as follows: selecting multiple merged application frames from the application frames included in the target application, and segmenting the fused stack data corresponding to each merged application frame according to a set data volume to obtain multiple sub-data sets; wherein the data volume of each sub-data set matches the set data volume; merging the sub-data sets corresponding to the multiple merged application frames in turn to obtain merged stack data corresponding to the multiple merged application frames; and performing anomaly detection based on the merged stack data.

[0245] In an exemplary embodiment, based on the aforementioned scheme, the processing module 2204 is specifically configured as follows: obtaining the calling level of each program unit in the fused stack data corresponding to each merged application frame in the corresponding calling relationship; dividing the information of multiple program units contained in the fused stack data corresponding to each merged application frame according to the set data volume and the calling level of each program unit to obtain multiple sub-data sets; merging the sub-data sets corresponding to the multiple merged application frames in order from low to high according to the corresponding calling levels to obtain the merged stack data corresponding to the multiple merged application frames.

[0246] In an exemplary embodiment, based on the aforementioned scheme, the processing module 2204 is specifically configured as follows: searching for a program unit whose corresponding execution time is less than or equal to a set time threshold from the fused stack data corresponding to each merged application frame; deleting the information corresponding to the found program unit from the fused stack data corresponding to each merged application frame; and segmenting the fused stack data after deletion according to a set data volume to obtain multiple sub-data sets.

[0247] In an exemplary embodiment, based on the aforementioned scheme, the processing module 2204 is specifically configured as follows: calculating the refresh duration of each application frame according to the refresh time of each application frame, and displaying a duration display interface; wherein the duration display interface includes the refresh durations corresponding to multiple application frames of the target application; in response to a selection operation based on the duration display interface, determining the target application frame selected by the selection operation; displaying an anomaly detection chart generated according to the fusion stack data corresponding to the target application frame; wherein the anomaly detection chart corresponding to the target application frame includes the calling relationship between the program units corresponding to the target application frame and the execution duration of each program unit during the refresh process of the target application frame.

[0248] In an exemplary embodiment, based on the aforementioned scheme, the processing module 2204 is specifically configured as follows: if there are multiple target application frames, the fusion stack data of the multiple target application frames are merged; an anomaly detection chart corresponding to the multiple target application frames is generated based on the merged data; wherein the anomaly detection chart includes the calling relationship between the program units corresponding to the multiple target application frames and the total execution time of each program unit during the refresh process of the multiple target application frames; and the anomaly detection chart corresponding to the multiple target application frames is displayed.

[0249] In an exemplary embodiment, based on the aforementioned scheme, the processing module 2204 is specifically configured as follows: obtaining application frames respectively included in multiple versions of the target application, and obtaining a reference program unit from the fused stack data corresponding to the application frames included in each version of the target application; calculating the execution time of the reference program unit in each version of the target application according to the fused stack data corresponding to the application frames included in each version of the target application; and performing anomaly detection according to the execution time of the reference program unit in multiple versions of the target application.

[0250] In an exemplary embodiment, based on the aforementioned scheme, the acquisition module 2202 is specifically configured as follows: during the operation of the target application, performance detection is performed on the operating system; if an abnormal performance event is detected, the detected abnormal performance event and the time of occurrence of the abnormal performance event are stored in a set storage area; according to the detected abnormal performance event, the storage capacity of the set storage area is adjusted.

[0251] In an exemplary embodiment, based on the aforementioned scheme, the acquisition module 2202 is specifically configured as follows: if the occupied storage capacity in the set storage area is greater than or equal to the set capacity upper limit threshold, then the occurrence frequency of abnormal performance events is calculated based on the detected abnormal performance events; the storage capacity of the storage area is increased based on the occurrence frequency; wherein the occurrence frequency is positively correlated with the increased storage capacity.

[0252] It should be noted that the anomaly detection device provided in the above embodiment and the anomaly detection method provided in the above embodiment belong to the same concept, wherein the specific manner in which each module and unit performs operations has been described in detail in the method embodiment and will not be repeated here.

[0253] An embodiment of the present application also provides an electronic device, comprising: one or more processors; a storage device for storing one or more computer programs, when the one or more computer programs are executed by one or more processors, the electronic device implements the anomaly detection method provided in the above-mentioned embodiments.

[0254] Fig.23 A schematic diagram of the structure of a computer system suitable for implementing an electronic device of an embodiment of the present application is shown.

[0255] It should be noted that Fig.23 The computer system 2300 of 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 application.

[0256] like Fig.23 As shown, the computer system 2300 includes a central processing unit (CPU) 2301, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 2302 or a computer program loaded from a storage part 2308 to a random access memory (RAM) 2303, such as executing the abnormality detection method in the above embodiment. In RAM 2303, various computer programs and data required for system operation are also stored. CPU 2301, ROM 2302 and RAM 2303 are connected to each other via a bus 2304. An input / output (I / O) interface 2303 is also connected to the bus 2304.

[0257] In some embodiments, the following components are connected to the I / O interface 2303: an input section 2306 including a keyboard, a mouse, etc.; an output section 2307 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker; a storage section 2308 including a hard disk, etc.; and a communication section 2309 including a network interface card such as a LAN (Local Area Network) card, a modem, etc. The communication section 2309 performs communication processing via a network such as the Internet. A drive 2310 is also connected to the I / O interface 2303 as needed. A removable medium 2311, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 2310 as needed so that a computer program read therefrom is installed into the storage section 2308 as needed.

[0258] In particular, according to an embodiment of the present application, a computer program for implementing the anomaly detection method may be carried on a computer-readable medium, and the computer program may be downloaded and installed from a network through the communication part 2309 , and / or installed from a removable medium 2311 .

[0259] It should be noted that the computer-readable medium shown in the embodiment of the present application 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, 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), a 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 application, a computer-readable storage medium may be any tangible medium containing or storing a computer program, which may be used by an instruction execution system, device or device or used in combination with it. The computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, wherein a computer-readable computer program is carried, and the 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 program contained in the computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wired, etc., or any suitable combination of the foregoing.

[0260] The flowchart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present application. Wherein, each box in the flowchart or block diagram can represent a module, a program segment, or a part of the code, and the above-mentioned module, 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 alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two 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 box in the block diagram or flowchart, and the combination of the boxes in the block diagram or flowchart 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 a computer program.

[0261] The units involved in the embodiments described in this application may be implemented by software or hardware, and the units described may also be set in a processor. The names of these units do not, in some cases, constitute limitations on the units themselves.

[0262] Another aspect of the present application further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor of an electronic device, enables the electronic device to implement the above-mentioned abnormality detection method. The computer-readable storage medium may be included in the electronic device described in the above embodiment, or may exist independently without being assembled into the electronic device.

[0263] Another aspect of the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the anomaly detection method provided in each of the above embodiments. Among them, the computer program can be stored in a computer-readable storage medium. The computer program product can be a computer program as a product, for example, an APP (Application, mobile application software), a web page, a small program, etc.; or, the computer program product can also be a storage medium, a device, a terminal, a virtual machine, etc. containing a computer program.

[0264] The above content is only a preferred exemplary embodiment of the present application and is not intended to limit the implementation scheme of the present application. A person skilled in the art can easily make corresponding changes or modifications based on the main concept and spirit of the present application. Therefore, the scope of protection of the present application shall be based on the scope of protection required by the claims.

Claims

1. An anomaly detection method, characterized in that: The method comprises: Detect the refresh time of each application frame during the operation of the target application to be detected; Acquire multiple abnormal performance events that occur during the operation of the target application and the occurrence time of each abnormal performance event; From the multiple abnormal performance events, searching for a target abnormal performance event corresponding to each application frame; wherein the refresh time of each application frame matches the occurrence time of the target abnormal performance event; Anomaly detection is performed according to the target abnormal performance event corresponding to each application frame.

2. The method according to claim 1, characterized in that The refresh time of each application frame during the operation of the target application to be detected includes: Injecting a set time acquisition function into the process of the target application; During the running of the target application, if a frame cycle function in the target application is called to refresh each application frame, a first calling time point of the frame cycle function is collected by the time collection function; If the frame cycle function is called to refresh the next application frame of each application frame, then the second calling time point of the frame cycle function is collected by the time collection function; The refresh time of each application frame is calculated according to the first calling time point and the second calling time point.

3. The method according to claim 1, characterized in that The performing anomaly detection according to the target abnormal performance event corresponding to each application frame includes: From the target abnormal performance event, obtain stack data during the occurrence of the target abnormal performance event; the stack data includes information of multiple program units and call relationships between the multiple program units; Acquire the execution durations of the plurality of program units in the refresh process of each application frame, respectively, and fuse the acquired execution durations into the stack data to obtain fused stack data; Anomaly detection is performed based on the fused stack data.

4. The method according to claim 3, characterized in that The performing anomaly detection according to the fused stack data comprises: Selecting a plurality of merged application frames from the application frames included in the target application, and segmenting the fused stack data corresponding to each merged application frame according to a set data volume to obtain a plurality of sub-data sets; wherein the data volume of each sub-data set matches the set data volume; Merging the sub-data sets respectively corresponding to the multiple merged application frames in sequence to obtain merged stack data corresponding to the multiple merged application frames; Anomaly detection is performed based on the merged stack data.

5. The method according to claim 4, characterized in that The step of sequentially merging the sub-data sets respectively corresponding to the multiple merged application frames to obtain merged stack data corresponding to the multiple merged application frames includes: Obtaining the calling level of each program unit in the fusion stack data corresponding to each merged application frame in the corresponding calling relationship; According to the set data volume and the calling level of each program unit, information of multiple program units contained in the fused stack data corresponding to each merged application frame is segmented to obtain multiple sub-data sets; The step of sequentially merging the sub-data sets respectively corresponding to the multiple merged application frames to obtain merged stack data corresponding to the multiple merged application frames includes: The sub-data sets respectively corresponding to the plurality of merged application frames are merged in sequence according to the corresponding call levels from low to high, so as to obtain merged stack data corresponding to the plurality of merged application frames.

6. The method according to claim 4, characterized in that The fused stack data corresponding to each merged application frame is segmented according to the set data amount to obtain multiple sub-data sets, including: Searching, from the fusion stack data corresponding to each merged application frame, a program unit whose corresponding execution time is less than or equal to a set time threshold; Deleting information corresponding to the found program unit from the fusion stack data corresponding to each merged application frame; According to the set data amount, the fused stack data after the deletion process is divided to obtain a plurality of sub-data sets.

7. The method according to claim 3, characterized in that The performing anomaly detection according to the fused stack data comprises: Calculating the refresh duration of each application frame according to the refresh time of each application frame, and displaying a duration display interface; wherein the duration display interface includes the refresh durations corresponding to the multiple application frames of the target application; In response to a selection operation based on the duration display interface, determining a target application frame selected by the selection operation; An exception detection chart generated according to the fusion stack data corresponding to the target application frame is displayed; wherein the exception detection chart corresponding to the target application frame includes the calling relationship between the program units corresponding to the target application frame and the execution time of each program unit during the refresh process of the target application frame.

8. The method according to claim 7, characterized in that The displaying of an anomaly detection chart generated according to the fused stack data corresponding to the target application frame includes: If the number of the target application frames is multiple, merging the fused stack data of the multiple target application frames; Generate an anomaly detection chart corresponding to the multiple target application frames according to the merged data; wherein the anomaly detection chart includes the calling relationship between the program units corresponding to the multiple target application frames and the total execution time of each program unit during the refresh process of the multiple target application frames; Anomaly detection charts corresponding to the multiple target application frames are displayed.

9. The method according to claim 3, characterized in that The performing anomaly detection according to the fused stack data comprises: Acquire application frames respectively included in the target application of multiple versions, and acquire reference program units from fused stack data corresponding to the application frames included in each version of the target application; Calculating the execution time of the reference program unit in each version of the target application according to the fusion stack data corresponding to the application frame included in each version of the target application; Anomaly detection is performed according to the execution times of the reference program units in the target applications of the multiple versions respectively.

10. The method according to claim 1, characterized in that The obtaining of multiple abnormal performance events occurring during the running of the target application and the occurrence time of each abnormal performance event includes: During the operation of the target application, performing performance testing on the operating system; If an abnormal performance event is detected, the detected abnormal performance event and the time of occurrence of the abnormal performance event are stored in a set storage area; The storage capacity of the set storage area is adjusted according to the detected abnormal performance event.

11. The method according to claim 10, characterized in that The step of adjusting the storage capacity of the set storage area according to the detected abnormal performance event includes: If the occupied storage capacity in the set storage area is greater than or equal to the set capacity upper limit threshold, the occurrence frequency of the abnormal performance event is calculated according to the detected abnormal performance event; The storage capacity of the storage area is increased according to the occurrence frequency; wherein the occurrence frequency is positively correlated with the increased storage capacity.

12. An abnormality detection device, characterized in that: The device comprises: A detection module, configured to detect the refresh time of each application frame during the operation of the target application to be detected; An acquisition module configured to acquire a plurality of abnormal performance events occurring during the operation of the target application and the occurrence time of each abnormal performance event; A search module configured to search for a target abnormal performance event corresponding to each application frame from the multiple abnormal performance events; wherein the refresh time of each application frame matches the occurrence time of the target abnormal performance event; The processing module is configured to perform anomaly detection according to the target abnormal performance event corresponding to each application frame.

13. An electronic device, characterized in that: include: one or more processors; A storage device for storing one or more computer programs, which, when executed by the one or more processors, enables the electronic device to implement the method described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and when the computer program is executed by a processor of an electronic device, the electronic device is enabled to implement the method described in any one of claims 1 to 11.

15. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 11 when being executed by a processor.

Images