Degradation detection method and device of application program, electronic equipment and storage medium

Abstract

The embodiment of the invention provides an application degradation detection method and device, electronic equipment and a storage medium. The method comprises the following steps: determining target running state information when a target application program runs, wherein the target running state information is used for indicating CPU time consumption, function calling times and a CPU utilization rate of a background thread corresponding to the target application program when the target application program performs function calling in different detection stages; determining a fluency detection result of the target application program according to the target running state information; and performing deterioration detection on the target application program according to the fluency detection result of the target application program. According to the scheme, the checking range of online index degradation can be effectively narrowed, the degradation reason is helped to be positioned to ensure that the fluency condition of the target application program is found and processed more accurately, and then whether the target application program is degraded or not is judged in time.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to the field of computer application technologies, and in particular, to a method, apparatus, electronic device, and storage medium for detecting degradation of an application program. Background Art

[0002] The fluency of an application program is related to the user experience of the application program. Especially for Android applications, the fluency of the application program usually needs to be detected when the application program is released.

[0003] In the related technical solutions, the main index for measuring the fluency of Android applications is FPS. FPS is a relatively comprehensive index, and there are many reasons affecting the change of the FPS index. From a technical perspective, it includes slow functions, background threads, memory, etc.; from a business perspective, different card types in the data stream or the same card type but different data will affect the FPS index, and it is not easy to perceive some subtle degradations of the fluency of the application program, resulting in a very low accuracy rate of the FPS and other indexes in the process of offline testing the application program. Summary of the Invention

[0004] The present disclosure provides a method, apparatus, electronic device, and storage medium for detecting degradation of an application program, so as to more accurately detect and process the degradation of the fluency of the application program.

[0005] In a first aspect, an embodiment of the present disclosure provides a method for detecting degradation of an application program, the method including:

[0006] Determine target running state information when the target application program is running, where the target running state information is used to indicate the CPU time consumption, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application program when the target application program makes function calls in different detection stages;

[0007] Determine the fluency detection result of the target application program according to the target running state information;

[0008] Detect degradation of the target application program according to the fluency detection result of the target application program.

[0009] In a second aspect, an embodiment of the present disclosure further provides a device for detecting degradation of an application program, the device including:

[0010] A first determination module, configured to determine target running state information when the target application program is running, where the target running state information is used to indicate the CPU time consumption, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application program when the target application program makes function calls in different detection stages;

[0011] A second determination module, configured to determine a fluency detection result of a target application according to the target running state information;

[0012] A detection module, configured to perform degradation detection on the target application according to the fluency detection result of the target application.

[0013] In a third aspect, an electronic device is further provided in the embodiments of the present disclosure. The electronic device includes:

[0014] At least one processor; and

[0015] A memory communicatively connected to the at least one processor; wherein,

[0016] The memory stores a computer program executable by the at least one processor. When the computer program is executed by the at least one processor, the at least one processor is enabled to execute the degradation detection method of the application program according to any one of the above embodiments.

[0017] In a fourth aspect, a computer-readable medium is further provided in the embodiments of the present disclosure. The computer-readable medium stores computer instructions for causing a processor to implement the degradation detection method of the application program according to any one of the above embodiments when executed.

[0018] In the embodiments of the present disclosure, after starting to run a target application, the target running state information during the running of the target application will be determined in real time. The target running state information is used to indicate the CPU time consumption, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application when the target application makes function calls in different detection stages. Furthermore, the fluency detection result of the target application is determined by using the target running state information, and it is determined whether the target application deteriorates based on the fluency detection result of the target application. This solution establishes a new anti-degradation idea for the fluency index by combining the CPU time consumption of function calls, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application during the running of the target application. Moreover, through the changes in the CPU time consumption of function calls, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application in different detection stages, the troubleshooting scope of the degradation of the online index can be effectively reduced, helping to locate the cause of degradation to ensure more accurately discovering and handling the fluency situation of the target application, and then timely determining whether the target application deteriorates.

[0019] It should be understood that the content described in this part is not intended to identify the key or important features of the embodiments of the present disclosure, nor is it used to limit the scope of the present disclosure. Other features of the present disclosure will become easily understandable through the following description. Description of the Drawings

[0020] In combination with the accompanying drawings and with reference to the following specific embodiments, the above and other features, advantages, and aspects of the embodiments of the present disclosure will become more apparent. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the original elements and components are not necessarily drawn to scale.

[0021] Figure 1 is a schematic flowchart of a method for detecting the degradation of an application program provided by an embodiment of the present disclosure;

[0022] Figure 2 is a schematic diagram for calculating the difference in function execution records by splitting stages during the degradation detection of an application program provided by an embodiment of the present disclosure;

[0023] Figure 3 is a schematic comparison diagram of a first refresh scenario and a smoothness scenario provided by an embodiment of the present disclosure;

[0024] Figure 4 is a schematic diagram for finely splitting the main thread during the degradation detection of an application program provided by an embodiment of the present disclosure;

[0025] Figure 5 is a schematic comparison diagram after finely splitting the main thread during the degradation detection of an application program provided by an embodiment of the present disclosure;

[0026] Figure 6 is a schematic diagram of the details of layout loading during the degradation detection of an application program provided by an embodiment of the present disclosure;

[0027] Figure 7 is a schematic diagram of the stack of the main thread during the degradation detection of an application program provided by an embodiment of the present disclosure;

[0028] Figure 8 is a schematic diagram of the stack function merging of the main thread during the degradation detection of an application program provided by an embodiment of the present disclosure;

[0029] Figure 9 is a schematic diagram for calculating the difference in function execution records of the main thread during the degradation detection of an application program provided by an embodiment of the present disclosure;

[0030] Figure 10 is a schematic diagram of function calls in units of page layouts during the degradation detection of an application program provided by an embodiment of the present disclosure;

[0031] Figure 11 is a schematic diagram of function calls of the main thread during the degradation detection of an application program provided by an embodiment of the present disclosure;

[0032] Figure 12It is a schematic diagram of the CPU time-consuming merging of function calls in the main thread during the degradation detection of an application provided by an embodiment of the present disclosure;

[0033] Figure 13 It is a schematic diagram of the CPU time-consuming of function calls in units of page layout during the degradation detection of an application provided by an embodiment of the present disclosure;

[0034] Figure 14 It is a detection schematic diagram of the CPU time-consuming of function calls in the rendering thread during the degradation detection of an application provided by an embodiment of the present disclosure;

[0035] Figure 15 It is a schematic diagram of function calls for animation rendering during the degradation detection of an application provided by an embodiment of the present disclosure;

[0036] Figure 16 It is a schematic diagram of splitting function calls for animation rendering during the degradation detection of an application provided by an embodiment of the present disclosure;

[0037] Figure 17 It is a detection schematic diagram of new messages during the degradation detection of an application provided by an embodiment of the present disclosure;

[0038] Figure 18 It is a schematic diagram of the difference calculation of new messages during the degradation detection of an application provided by an embodiment of the present disclosure;

[0039] Figure 19 It is a schematic diagram of the structure of a degradation detection device for an application provided by an embodiment of the present disclosure;

[0040] Figure 20 It is a schematic diagram of the structure of an electronic device for implementing a method for detecting the degradation of an application provided by an embodiment of the present disclosure. Detailed implementation manners

[0041] Hereinafter, embodiments of the present disclosure will be described in more detail with reference to the accompanying drawings. Although some embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. On the contrary, these embodiments are provided to more thoroughly and completely understand the present disclosure. It should be understood that the accompanying drawings and embodiments of the present disclosure are only for exemplary purposes and are not used to limit the protection scope of the present disclosure.

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

[0043] As used herein, the term "including" and its variations are open-ended, that is, "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". The relevant definitions of other terms will be given in the following description.

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

[0045] It should be noted that the modifications of "one" and "multiple" mentioned in this disclosure are illustrative rather than restrictive. Those skilled in the art should understand that unless clearly specified otherwise in the context, it should be understood as "one or more".

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

[0047] Figure 1 The flowchart of a method for detecting degradation of an application program provided by an embodiment of this disclosure is applicable to the situation of detecting degradation of a target application program during the operation of the target application program. This method can be executed by a degradation detection device of the application program. The degradation detection device of the application program can be implemented in the form of software and / or hardware, and is generally integrated on any electronic device with network communication functions. The electronic device can be a mobile terminal, a PC or a server, etc.

[0048] As Figure 1 shown, the method for detecting degradation of the application program in the embodiment of this disclosure may include the following processes:

[0049] S110. Determine the target running state information when the target application program is running. The target running state information is used to indicate the CPU time consumption, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application program when the target application program makes function calls in different detection stages.

[0050] The fluency scenario of an application is more sensitive to the deterioration of function execution time compared to scenarios such as the cold start of an application. This requires building a more precise ability to intercept smaller deteriorations. Due to the limitations of the offline test environment, although hardware and software means have been adopted to ensure environmental consistency, the fluctuations in function execution time are still relatively large. To more accurately detect the deterioration problems of an application in the fluency scenario, the function call situation of the application during runtime can be considered. For example, when new messages, animations, layouts, etc. are added during a sliding operation, the corresponding function call results can be directly obtained from the function call stack information.

[0051] At the same time, when analyzing the target runtime state information of the target application during runtime, it is necessary to analyze the target application in divided stages. Splitting the stages to implement the analysis of the runtime state of the application is very necessary for attributing the deterioration of the fluency of the application in online analysis. By analyzing the changes in CPU execution time, the number of function calls, and the CPU usage rate of the corresponding background threads of the target application when the target application makes function calls after stage splitting, the scope of investigation for attributing the deterioration of the fluency of the application can be effectively narrowed, helping to locate the cause of the deterioration.

[0052] As an optional but non-limiting implementation, the target runtime state information is used to indicate the CPU execution time, the number of function calls, and the CPU usage rate of the corresponding background threads of the target application when making function calls in at least two detection stages. Among them, the at least two detection stages may include the following detection stages: the main thread processing function call stage of the first type of thread during the runtime of the target application, the rendering thread processing function call stage of the second type of thread during the runtime of the target application, the main thread processing function call stage related to messages in the first type of thread during the runtime of the target application, and the function call stages of the third type of thread and the fourth type of thread during the runtime of the target application.

[0053] Among them, the first type of thread is the main thread of the application that is used to centrally process the interface interaction logic and business logic during view drawing operations. The second type of thread is the rendering thread of the application that is used to perform page rendering during view drawing operations. The third type of thread is the original background thread in the target application other than the first type of thread and the second type of thread during the runtime of the target application. The fourth type of thread is the newly added background thread in the target application other than the first type of thread and the second type of thread during the runtime of the target application. The main thread processing function call stage of the first type of thread during the runtime of the target application can be further divided into the following detection stages: the stage of touching and dragging during the sliding operation process corresponding to the view drawing operation, the stage of inertial rebound or sliding after stopping touching during the sliding operation process corresponding to the view drawing operation, and the stage of starting to bind data after the sliding stops.

[0054] What is the significance of splitting the detection stages for offline degradation detection of application programs? Offline has rich function stack information. Simply using the function dimension for offline degradation detection of application programs will surely have a better degradation attribution effect than that from different detection stage dimensions after stage splitting. Therefore, it is necessary to clarify the significance of detection stage splitting for offline degradation detection of application programs first. Regarding the results of splitting the sliding operation stage in the view drawing operation during the running of the application program, it is mainly divided into the following three detection stages: stage_drag, stage_settle, and stage_idle. Among them, stage_drag is the dragging stage, that is, the stage of touching and dragging during the sliding operation corresponding to the view drawing operation, corresponding to SCROLL_STATE_DRAGGING, touching and dragging a certain distance; stage_settle is the sliding stage, that is, the stage of inertial rebound or sliding after stopping touching in the sliding operation corresponding to the view drawing operation, corresponding to SCROLL_STATE_SETTLING, releasing the hand and inertial rebounding or sliding to the next page; stage_idle is the end of sliding, that is, the stage of starting to bind data after the sliding stops in the sliding operation corresponding to the view drawing operation, corresponding to SCROLL_STATE_IDLE. Bind data starts after the sliding ends.

[0055] The granularity of the above three sliding stages is still too large. Therefore, according to the differences in business logic, the key logic in the three detection stages corresponding to the above three sliding operation processes is refined into several core detection stages with finer granularity. For example, for the detection stage corresponding to the stage_drag operation process, the key functions can be divided into core stages such as stage_drag_1 and stage_drag_2 according to business logic.

[0056] The idea of splitting detection stages adopted in the above solution can achieve more accurate performance evaluation: finer test partitioning can help evaluate the performance of each core stage more accurately, which can more effectively discover and solve potential performance problems; it can reduce problem complexity: dividing complex sliding scenarios into multiple simple detection stages can also reduce problem complexity, making the performance anti-degradation work more manageable; it can obtain more stable performance metrics: because small-scale changes are less likely to be overwhelmed by other factors, more stable and reliable performance metric data may be obtained by measuring performance in a small range.

[0057] See Figure 2, which shows the optimization of the core stage of the application's fluency scenario. The running state of the target application during different detection stages can be analyzed from different detection stages, and the degradation attribution is calculated according to the difference in the running state of the application during different detection stages compared with that of the previous version. However, simply detecting the core stage information is not enough. The fluency detection scenario of the application is different from the detection scenario of the first refresh rendering. The core stages in the fluency scenario are often scattered, unlike the core stages of the first rendering that are connected end to end and comprehensively covered. From Figure 3 It can be seen that various main thread messages and view drawing operations are intertwined in the core stage of the fluency scenario.

[0058] Previously, the reason why the accuracy of the fluency scenario was low and it was difficult to find problems was mainly because the view drawing operations and a vast number of messages could not be split into detection stages. Instead, the problem became more complicated after stack aggregation. The aggregated stack information erased the information of the view drawing operations and messages as individual entities. Therefore, in the fluency scenario, simply dividing different detection stages still needs to be improved, so a more comprehensive method is needed to detect and evaluate the performance of these view drawing operations and messages.

[0059] For this reason, referring to Figure 4 , the view drawing operations can be further decomposed. The main links of concern are UIThread (UIThread is the main application thread used to centrally handle interface interaction logic and business logic) and RenderThread (RenderThread is the application rendering thread used for page rendering in the view drawing operation), that is, DoFrame (which can be regarded as the main thread processing function) and DrawFrame (which can be regarded as the rendering thread processing function). These two parts are directly affected by the application's own logic in terms of the length of time consumed. The remaining operations belong to the system level, and it is generally difficult for the application itself to interfere. Below, the target running state information of the target application during runtime will be described in detail from DoFrame and DrawFrame corresponding to UIThread and RenderThread further subdivided respectively.

[0060] As an optional but non-limiting implementation manner, determining the target running state information of the target application during runtime includes the following steps A1 - A2:

[0061] Step A1: Determine at least two execution records of the first functions corresponding to the first type of thread during the runtime of the target application. The first type of thread is the main application thread used to centrally handle interface interaction logic and business logic in the view drawing operation, and the first function execution record is the tracking or recording during the execution of the main thread processing function called by the first type of thread.

[0062] Step A2: Determine the target running state information of the target application during runtime based on at least two first function execution records. The target running state information includes the cumulative average CPU time consumed when each main thread processing function is called multiple times by the first type of threads when calling different main thread processing functions, the number of calls of each main thread processing function called by each page layout corresponding to the first type of threads, and / or the cumulative CPU time consumed by each main thread processing function called by each page layout corresponding to the first type of threads.

[0063] See Figure 5 , for the analysis of the UIThread thread, after analyzing doFrame in the view drawing operation, the calls to the main thread processing function doFrame can also be divided into three detection stages: stage_drag, stage_settle, and stage_idle. Stage_drag is the dragging stage, that is, the stage of touching and dragging during the sliding operation process corresponding to the view drawing operation. During the dragging stage, the prominent feature of the doFrame operation is frequent repeated execution, such as continuously performing input processing, animations, and drawing operations. Therefore, in this stage_drag detection stage, the cumulative average CPU time consumed when each main thread processing function is called multiple times by the first type of threads can be analyzed to obtain the target running state information of the target application during runtime in the stage_drag detection stage.

[0064] At the same time, stage_settle is the sliding stage, that is, the stage of inertial rebound or sliding after stopping touching in the sliding operation process corresponding to the view drawing operation. After the dragging process ends, due to animations such as inertia or smooth scrolling, the view continues to scroll, there is no input input, and there is no high-frequency characteristic; stage_idle is the end of sliding, that is, the stage of binding data after the sliding stops in the sliding operation process corresponding to the view drawing operation. When the sliding ends, a large number of measurement measure and layout layout operations will occur, but this stage does not have the high-frequency characteristic of the dragging stage. Therefore, in these two detection stages of stage_settle and stage_idle, it is not suitable to use a similar idea as the stage_drag detection stage to analyze the target running state information of the target application during runtime.

[0065] Based on the above situation, see Figure 6, in the latest RheaTrace 2.0, the ability to monitor rendering is newly added. Therefore, it is possible to know the details of each layout loaded during each DrawFrames in the RenderThread, and the details of the layout rhea.sample.android.app.MainActivity can be known. Since Doframe and DrawFrame always appear in pairs, using this ability, the layout can be successfully bound to specific operations such as input and measure in doFrame.

[0066] In addition, operations such as input, animation, and measure in doFrame involved in the view drawing operation process have clear boundary attributes. This provides a theoretical basis for the idea of detecting degradation by analyzing the target running state information during the operation of the target application by counting the execution times of operations such as input and animation in terms of layout units, and also makes it possible to aggregate the stacks of operations such as input and measure in terms of layout units. For this reason, in the two detection stages of stage_settle and stage_idle, the number of calls of each main thread processing function called by each page layout corresponding to the first type of thread and / or the cumulative CPU time consumption of each main thread processing function called by each page layout corresponding to the first type of thread can be analyzed and obtained in terms of page layout dimension, so as to obtain the target running state information during the operation of the target application in the two detection stages of stage_settle and stage_idle.

[0067] As an optional but non-limiting implementation manner, to determine the target running state information during the operation of the target application based on at least two first function execution records, the following steps A21 - A22 are included:

[0068] Step A21: From at least two first function execution records, determine at least two first stage function execution records corresponding to the first type of thread. The first stage function record is the first function execution record called by the main thread processing function in the first type of thread during the first stage. The first stage is the stage of touching and dragging during the sliding operation process corresponding to the view drawing operation.

[0069] Step A22: Traverse each first stage function execution record, determine the cumulative average value of the CPU time consumption when the same main thread processing function is called, so as to obtain the cumulative average value of the CPU time consumption of each main thread processing function, and thereby determine the target running state information during the operation of the target application.

[0070] For the analysis of the UIThread thread, since the detection stage of stage_drag has significantly different characteristics from the two detection stages of stage_settle and stage_idle, the detection stage of stage_drag is analyzed separately. See Figure 7 , which shows a stack screenshot of doFrame in the sliding stage of the view drawing operation, with high-frequency repetition characteristics. Therefore, when performing the degradation detection analysis of doFrame in the sliding stage, the detection stage of stage_drag is mainly used to calculate the difference in the running state information.

[0071] Since the call of the main thread processing function doFrame is divided into three detection stages: stage_drag, stage_settle, and stage_idle, it is necessary to extract the execution records of the first functions called by the main thread processing function in the first stage from at least two first function execution records. The function execution records can be represented by Trace. The first stage is the stage of touching and dragging during the sliding operation process corresponding to the view drawing operation, that is, the execution records of the first functions called by the main thread processing function in the first class of threads during the detection stage of stage_drag when the target application is running.

[0072] See Figure 8 , for at least two first stage function execution records (Trace1, Trace2,..., TraceN) extracted from at least two first function execution records, traverse each Trace, merge the same main thread processing functions together, and then accumulate and average the CPU time consumption when the main thread processing function is called. The advantage of this is to reduce the impact of the time consumption fluctuation when the main thread processing function is called, so as to finally analyze the fluency by comparing the change in the cumulative average value of the CPU time consumption of each main thread processing function in the application programs of the previous and subsequent versions, and then determine whether doFrame in the sliding stage of the view drawing operation process deteriorates. See Figure 9 .

[0073] As an optional but non-limiting implementation manner, according to at least two first function execution records, determine the target running state information of the target application during operation, including the following steps A23 - A24:

[0074] Step A23: From at least two first function execution records, determine at least two second stage function execution records corresponding to the first class of threads. The first stage function record is the execution record of the first function called by the main thread processing function in the first class of threads during the second stage. The second stage is the stage of inertial rebound or sliding after stopping touching and the stage of starting to bind data after the sliding stops in the sliding operation process corresponding to the view drawing operation.

[0075] Step A24: Traverse each execution record of the second-stage function, determine the call count and the cumulative CPU time consumption of the main-thread processing function associated with each page layout in the view drawing operation, so as to determine the target running status information of the target application during operation.

[0076] See Figure 5 , for the analysis of the UIThread thread, the doFrame stack data in the two detection stages of stage_settle and stage_idle do not have the characteristic of high-frequency repetition, and the method of merging the same main-thread processing functions in at least two execution records of the second-stage function in the stage_drag detection stage cannot be applied to improve the accuracy. Because many function class names and method names under the doFrame call chain may be the same, but they belong to different layouts. If the Trace is forcibly merged, a lot of call information such as measure and layout will be erased, resulting in missing the forest for the trees, and some newly added layout refresh logics that are easy to discover will be ignored. Therefore, on the basis of the original ability to calculate the time-consuming difference, a new index of frame call statistics is added to measure the call count of measure, layout, animation, etc. in doFrame, and to assist in discovering the degradation problems of doFrame in the two detection stages of stage_settle and stage_idle during the operation of the application.

[0077] See Figure 10 , taking the application programs of the comparison package and the baseline package as an example, for at least two execution records of the second-stage function corresponding to the first type of thread during the operation of the application programs of the baseline package and the comparison package, taking the page layout as the unit, settle whether there are new calls to the main-thread processing function in view drawing operations such as measure and layout, so as to clarify whether the drawn page layout has deteriorated. If the call count of the main-thread processing function of measure and layout is increased, then regardless of the time consumption, it will definitely affect the stages of inertial rebound or sliding after stopping touching and the stage of starting to bind data in the sliding operation process corresponding to the view drawing operation. Then even if the specific degradation is discovered. It can be seen that in the first type of thread, starting directly from the perspective of the call count of the main-thread processing function corresponding to the view drawing operation in the second stage, whether the page layout has deteriorated can be discovered. This index will not fluctuate and can accurately discover the degradation point.

[0078] Regarding the analysis of the UIThread thread, if the call data of the main thread processing functions related to view drawing operations such as measure and layout does not deteriorate, then it is necessary to analyze the Trace data before and after the modification of functions such as measure. However, as follows Figure 11 As shown, most of the function calls in the view drawing operation process are for androidx or custom pages, and there are basically no business characteristics in them. Therefore, when calculating and analyzing the difference in function call time consumption, the hierarchical relationship information of the page layout is erased after merging the same main thread processing functions in the execution records of at least two second-stage functions. All the information related to view drawing operations is aggregated together. Then, just because the merged view drawing operation does not deteriorate does not mean the deterioration situation of the main thread processing functions related to individual view drawing operations such as measure or layout. As follows Figure 12 As shown, for the execution records of two second-stage functions (Trace1 and Trace2) extracted, an operation B is removed in one measure, and an operation B is added in another Trace. This situation is obviously a deterioration of the rendering process of Trace 1, but it is ignored.

[0079] Therefore, referring to Figure 13 , taking the comparison of two versions of the application program, the target version and the benchmark version, for example, for at least two second-stage function execution records (Trace1, Trace2,..., TraceM) extracted from at least two first function execution records, the main thread processing functions related to view drawing operations such as measure and layout can be aggregated in units of page layout. The main thread processing functions called in association with the same page layout are merged together, and then the cumulative CPU time consumption when the main thread processing functions called in association with the same page layout are calculated, so as to finally analyze the smoothness by comparing the change in the average value of the cumulative CPU time consumption of the main thread processing functions of the same page layout in the application programs of the two versions before and after, and then find out the newly added time-consuming points to determine whether the doFrame in the sliding stage of the view drawing operation process deteriorates.

[0080] As an optional but non-limiting implementation manner, determining the target running state information of the target application program during operation includes the following steps B1 - B2:

[0081] Step B1: Determine the page layout loading details of at least one page layout corresponding to the second type of thread during the operation of the target application program. The second type of thread is the application rendering thread used for page rendering in the view drawing operation. The page layout loading details indicate the views drawn by the rendering thread processing functions called in the second type of thread of the view drawing operation and the dependency relationship between the drawn views.

[0082] Step B2. Determine the target running status information during the running of the target application based on the page layout loading details of at least one page layout. The target running status information includes the complexity of each page layout loaded by the second type of thread calling different rendering thread processing functions and the CPU time consumption of each page layout.

[0083] As an optional but non-limiting implementation manner, determining the target running status information during the running of the target application based on the page layout loading details of at least one page layout includes the following steps B21 - B22:

[0084] Step B21. Determine the complexity of each page layout loaded by the second type of thread calling different rendering thread processing functions according to the page layout loading details of each page layout. Among them, the complexity of each page layout is determined based on the depth of the view hierarchy in the page layout, the page layout type, the number of views in the page layout, and / or whether the page layout includes a specified type of view.

[0085] Step B22. Determine the CPU time consumption of each page layout loaded by the second type of thread calling different rendering thread processing functions according to the page layout loading details of each page layout, so as to determine the target running status information during the running of the target application. Among them, the CPU time consumption of each page layout is determined based on the cumulative CPU time consumption when the second type of thread calls the rendering thread processing function associated with each page layout to load each page layout.

[0086] Regarding the analysis of the RenderThread thread, the RenderThread thread enables the work of UI rendering to be carried out outside the UIThread thread. The UIThread thread can concentrate on handling UI interactions and business logics. The RenderThread thread reduces the burden on the UIThread thread and also improves the drawing efficiency and smoothness, bringing a better experience to users. And for the RenderThread thread, a series of solutions have also been made to facilitate the degradation monitoring of the smoothness scenario, which will be introduced in detail as follows.

[0087] In RheaTrace 2.0, the ability of rendering monitoring is newly added, enabling the details of each page layout loading in the RenderThread to be known, so as to know whether there is a newly added view in the current layout before and after the code change, such as Figure 6As shown, the detailed situation of the page layout of rhea.sample.android.app.MainActivity can be known. With the details of the loading of each page layout in the RenderThread, it is possible to directly analyze whether the layout is increased or decreased from the level of function execution records. The complexity of each specific page layout is analyzed in detail from the aspects of the depth of the view hierarchy, the type of page layout, the number of views in the page layout, and / or whether the page layout includes views of a specified type.

[0088] Among them, the depth of the view hierarchy: The depth of the view hierarchy is one of the important indicators of layout complexity. More levels mean an increase in the workload of measurement, layout, and drawing, which may affect performance. Layout type: Using some complex layouts (such as RelativeLayout, ConstraintLayout) usually takes more time than using linear layouts or frame layouts, which also increases the complexity of the layout. The number of views: The number of views contained in a view group also affects the layout complexity. A large number of views will increase the workload of layout, measurement, and drawing. Whether it includes custom views of a specified type: Custom views may contain complex measurement or layout logic, which may lead to an increase in layout complexity. By performing weighted averages of the above influencing factors in each dimension, the complexity of each page layout loaded can be known, so as to finally compare the complexity differences of each page layout in the application programs of the previous and subsequent versions to determine whether there is deterioration in DrawFrame (which can be recorded as the rendering thread processing function) in the view drawing operation process.

[0089] See Figure 14 , the rendering optimization and deterioration of the RenderThread are mainly detected from the perspective of the CPU time consumption of the rendering thread processing function DrawFrames in the RenderThread. The specific DrawFrames are all bound to the corresponding layouts. If the same page layout corresponds to multiple DrawFrames functions, the influence of time consumption fluctuations is reduced by merging the function execution records. Because even for the same page layout, due to different sizes of the loaded pictures, the CPU time consumption of calling the rendering thread processing function DrawFrames is also different. Therefore, it is necessary to use the CPU time consumption required to call the rendering thread processing function DrawFrames in each page layout. In this way, the difference in the CPU time consumption required to call the rendering thread processing function DrawFrames for each page layout in the application programs of the previous and subsequent versions can be compared to determine whether there is deterioration in DrawFrame in the view drawing operation process.

[0090] As an optional but non-limiting implementation, determining the target running state information during the running of the target application includes the following steps C1 - C2:

[0091] Step C1: Determine at least one execution record of a second function corresponding to the first type of thread during the running of the target application. The first type of thread is the main application thread used to centrally process the interface interaction logic and business logic during the view drawing operation. The execution record of the second function is the tracking or recording during the execution of the reference function called by the first type of thread. The reference function is the main thread processing function related to animation rendering.

[0092] Step C2: Based on each execution record of the second function, determine each animation drawn by the first type of thread when calling each reference function and use it as the target running state information.

[0093] See Figure 15 , for the analysis of the UIThread thread, the reason for separating the animation rendering here is that the animation is special. It doesn't have a complex hierarchical call structure like scenarios such as measure and layout. No matter how many animations are executing on the current page, usually only one function call of animation can be seen in the function execution record. As follows Figure 16 shown: Then for the animation scenario, it needs to be split, and an animation function is disassembled into different animations in execution, so as to analyze each animation drawn by the main thread processing function related to animation rendering and use it as the target running state information, in order to compare the animation differences drawn by the main thread processing function related to animation rendering during the animation rendering process in the application programs of the previous and subsequent versions, that is, by detecting whether there are new animations under animation subsequently, it can be determined whether the DoFrame corresponding to the UIThread thread in the view drawing operation process deteriorates.

[0094] As an optional but non-limiting implementation, determining the target running state information during the running of the target application includes the following steps D1 - D2:

[0095] Step D1: Determine the message tracking record corresponding to the first type of thread during the running of the target application. The message tracking information is the tracking information of the message scheduling between the system service layer and the local service layer in the first type of thread. The first type of thread is the main application thread used to centrally process the interface interaction logic and business logic during the view drawing operation.

[0096] Step D2: Based on the message tracking record corresponding to the first type of thread, determine the target running state information during the running of the target application. The target running state information includes the messages sent by calling the main thread processing function in the first type of thread and the CPU time consumption when each message is sent by calling the main thread processing function.

[0097] During the sliding phase of the view drawing operation, the messages of the UIThread are relatively scattered, and the stack during the drawing phase is more traceable. However, RheaTrace 2.0 newly introduces the tracking information of message scheduling between the system service layer (Java layer) and the native service layer (Native layer) in the UIThread. It can accurately identify the boundaries of each message. At the same time, combined with information such as the class name of the message and Message, it can add message identifiers to each message. With this ability, on the one hand, we can start from monitoring the newly added messages, and on the other hand, start from the refined message difference calculation ability, following the processing flow of the drawing phase.

[0098] In the UIThread, since each message sent by calling the main thread processing function (DoFrame) will add a new message identifier according to the name of the main thread processing function called, it is possible to directly determine whether there are newly added messages at the message level. As Figure 17 shown, taking the application programs of the comparison package and the baseline package as an example, it is possible to determine whether new messages are added by observing the increase or decrease of the message identifiers of the messages sent by calling the main thread processing function in the UIThread. Finally, by comparing the changes in the message identifiers of the messages sent by calling the main thread processing function in the UIThread of the application programs of the two versions before and after, the fluency can be analyzed, and then it can be determined whether the messages sent by the UIThread in the view drawing operation process deteriorate.

[0099] See Figure 18 , for the scenario of internal logic changes in the message, we can focus on the internal stack changes of the specific message without aggregating all messages to a root node, which may lead to the complication of the problem. Therefore, we can focus on independent messages and their internal logic as needed, making the problem analysis more direct and simple. In other words, taking the application programs of the comparison package and the baseline package as an example, analyze the CPU time consumption when each message sent by calling the main thread processing function in the first type of thread. Finally, compare the differences in the CPU time consumption occupied by the messages sent by calling each main thread processing function in the UIThread of the application programs of the two versions before and after, so as to determine whether the messages sent by the UIThread in the view drawing operation process deteriorate.

[0100] As an optional but non-limiting implementation manner, determining the target running state information during the running of the target application program includes the following steps E1 - E2:

[0101] Step E1: Determine the CPU usage rate of the third type of threads during the runtime of the target application. The third type of threads are the original background threads in the target application other than the first type of threads and the second type of threads during the runtime of the target application. The first type of threads are the main application threads used to centrally process the interface interaction logic and business logic in the view drawing operation. The second type of threads are the application rendering threads used to perform page rendering in the view drawing operation.

[0102] Step E2: Determine the CPU usage rate of the fourth type of threads during the runtime of the target application. The fourth type of threads are the newly added background threads in the target application other than the first type of threads and the second type of threads during the runtime of the target application.

[0103] For the situation of background thread degradation in the smoothness scenario, in addition to using the differential calculation ability of function execution records, it is also possible to accurately locate the newly added background threads with greater impact by combining the two factors of the CPU usage rate of the original background threads and the newly added background threads. CPU usage rate of the original background threads: The CPU usage rate of the original background threads is a key indicator to measure the thread resource consumption. When a thread is executing a task and consumes too much CPU resources, it may affect other threads, or even the main thread, resulting in a decrease in the smoothness of the application. When detecting background threads, the CPU usage rate of the threads can be measured and recorded regularly. If the CPU usage rate of a certain thread rises rapidly within a short period of time, or remains at a high level, then this thread needs to be concerned. Newly added background threads: During the execution of the application, new background threads may be created. These threads may be used to handle certain background tasks, such as IO operations, database queries, or network requests, etc., and thus will occupy a large amount of CPU resources.

[0104] S120: Determine the smoothness detection result of the target application based on the target running state information.

[0105] As an optional but non-limiting implementation, determining the smoothness detection result of the target application based on the target running state information includes the following steps F1 - F2:

[0106] Step F1: Determine the reference running state information during the runtime of the reference application. The target application is obtained by adjusting the application version of the reference application. The reference running state information is used to indicate the CPU time consumption, the number of function calls, and the CPU usage rate of the background threads corresponding to the reference application when the reference application makes function calls.

[0107] Step F2: Determine the change in the smoothness difference between the target application and the reference application based on the target running state information and the reference running state information.

[0108] Optionally, based on the target running state information and the reference running state information, determine the change in the fluency difference between the target application and the reference application, including: determining the difference detection result between the running state information of the same dimension in the target running state information and the reference running state information, where the difference detection result includes the difference in CPU time consumption during function calls, the difference in the number of function calls, and the difference in the CPU usage rate of background threads; based on the difference detection result between the running state information of the same dimension, determine the change in the fluency difference between the target application and the reference application. Among them, the change in the fluency difference between the target application and the reference application includes: the fluency of the target application during operation is greater than or equal to the fluency of the reference application during operation, and the fluency of the target application during operation is less than the fluency of the reference application during operation.

[0109] Optionally, the difference detection result can specifically be the difference between the cumulative average CPU time consumption of each main thread processing function called multiple times when the first type of thread in the target running state information calls different main thread processing functions and the cumulative average CPU time consumption of each main thread processing function called multiple times when the first type of thread in the reference running state information calls different main thread processing functions, the difference between the number of calls of each main thread processing function called by each page layout corresponding to the first type of thread in the target running state information and the number of calls of each main thread processing function called by each page layout corresponding to the first type of thread in the reference running state information, and the difference between the cumulative CPU time consumption of each main thread processing function called by each page layout corresponding to the first type of thread in the target running state information and the cumulative CPU time consumption of each main thread processing function called by each page layout corresponding to the first type of thread in the reference running state information.

[0110] Optionally, the difference detection result can specifically be the difference between the complexity of each page layout loaded when the second type of thread in the target running state information calls different rendering thread processing functions and the complexity of each page layout loaded when the second type of thread in the reference running state information calls different rendering thread processing functions, and the difference between the CPU time consumption of each page layout loaded when the second type of thread in the target running state information calls different rendering thread processing functions and the CPU time consumption of each page layout loaded when the second type of thread in the reference running state information calls different rendering thread processing functions.

[0111] Optionally, the difference detection result can specifically be the difference between each animation drawn when the first type of thread in the target running state information calls each reference function and each animation drawn when the first type of thread in the reference running state information calls each reference function.

[0112] Optionally, the difference detection result may specifically be the difference between the messages sent by the first type of threads in the target running state information when calling the main thread processing function and the messages sent by the first type of threads in the reference running state information when calling the main thread processing function; and, the difference between the CPU time consumption when each message is sent by the first type of threads in the target running state information when calling the main thread processing function and the CPU time consumption when each message is sent by the first type of threads in the reference running state information when calling the main thread processing function.

[0113] Optionally, the difference detection result may specifically be the difference between the CPU usage rate of the third type of threads in the target running state information and the CPU usage rate of the third type of threads in the reference running state information; and the difference between the CPU usage rate of the fourth type of threads in the target running state information and the CPU usage rate of the fourth type of threads in the reference running state information.

[0114] As an optional but non-limiting implementation manner, determining the fluency detection result of the target application according to the target running state information includes the following steps:

[0115] If it is detected that the CPU usage rate of the third type of threads during the running of the target application is greater than the preset CPU usage rate threshold and the CPU usage rate of the fourth type of threads is not zero, then determine that the fluency detection result of the target application during running is that the fluency during the running of the target application has decreased.

[0116] S130. Perform degradation detection on the target application according to the fluency detection result of the target application.

[0117] For two versions of the application (including the target application and the reference application), determine the running state information during the running of each version of the application. According to the running state information of the two versions of the application, determine the fluency difference between the two versions of the application, and then perform degradation detection on the two versions of the application according to the fluency difference between the two versions of the application. If the fluency of the target application is lower than that of the reference application, then the target application has degraded relative to the reference application. If the fluency of the target application is not lower than that of the reference application, then the target application has not degraded relative to the reference application.

[0118] In an embodiment of the present disclosure, after the target application is started and run, the target running state information during the running of the target application is determined in real time. The target running state information is used to indicate the CPU time consumption, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application when the target application makes function calls in different detection stages. Furthermore, the smoothness detection result of the target application is determined by using the target running state information, and it is determined whether the target application deteriorates based on the smoothness detection result of the target application. By combining the information of the CPU time consumption of function calls, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application during the running of the target application, this solution establishes a new idea for preventing deterioration of the smoothness index. Moreover, through the changes in the CPU time consumption of function calls, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application in different detection stages, the scope of investigation for deterioration of online metrics can be effectively narrowed, helping to locate the cause of deterioration to ensure more accurately discovering and handling the smoothness situation of the target application, and then timely determining whether the target application deteriorates.

[0119] Figure 19 FIG. 4 is a schematic structural diagram of a deterioration detection device for an application program provided by an embodiment of the present disclosure. The embodiment of the present disclosure is applicable to the situation of detecting deterioration of a target application during the running of the target application. The deterioration detection device of the application program can be implemented in the form of software and / or hardware, and is generally integrated on any electronic device with network communication functions. The electronic device can be a mobile terminal, a PC, a server, etc.

[0120] As Figure 19 shown, the deterioration detection device of the application program in the embodiment of the present disclosure may include:

[0121] A first determination module 1910, configured to determine the target running state information during the running of the target application, where the target running state information is used to indicate the CPU time consumption, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application when the target application makes function calls in different detection stages;

[0122] A second determination module 1920, configured to determine the smoothness detection result of the target application according to the target running state information;

[0123] A detection module 1930, configured to perform deterioration detection on the target application according to the smoothness detection result of the target application.

[0124] Based on the technical solution of the above embodiment, optionally, determining the target running state information during the running of the target application includes:

[0125] Determine at least two first function execution records corresponding to the first type of threads during the operation of the target application. The first type of threads is the main application thread used to centrally process the interface interaction logic and business logic during the view drawing operation. The first function execution record is the tracking or recording during the execution of the main thread processing function called by the first type of threads;

[0126] Based on the at least two first function execution records, determine the target running state information during the operation of the target application. The target running state information includes the cumulative average CPU time consumed when each main thread processing function is called multiple times when the first type of threads calls different main thread processing functions, the number of calls of each main thread processing function called by each page layout corresponding to the first type of threads, and / or the cumulative CPU time consumed by each main thread processing function called by each page layout corresponding to the first type of threads.

[0127] On the basis of the technical solution of the above embodiment, optionally, determining the target running state information during the operation of the target application according to the at least two first function execution records includes:

[0128] From the at least two first function execution records, determine at least two first-stage function execution records corresponding to the first type of threads. The first-stage function record is the first function execution record called by the main thread processing function in the first type of threads during the first stage. The first stage is the stage of touching and dragging during the sliding operation process corresponding to the view drawing operation;

[0129] Traverse each first-stage function execution record, and determine the cumulative average CPU time consumed when the same main thread processing function is called, so as to obtain the cumulative average CPU time consumed by each main thread processing function.

[0130] On the basis of the technical solution of the above embodiment, optionally, determining the target running state information during the operation of the target application according to the at least two first function execution records includes:

[0131] From the at least two first function execution records, determine at least two second-stage function execution records corresponding to the first type of threads. The first-stage function record is the first function execution record called by the main thread processing function in the first type of threads during the second stage. The second stage is the stage of inertial rebound or sliding after stopping touching and the stage of starting to bind data after the sliding stops during the sliding operation process corresponding to the view drawing operation;

[0132] Traverse each second-stage function execution record, and determine the number of calls of the main thread processing function associated with each page layout in the view drawing operation and the corresponding cumulative CPU time consumed.

[0133] Based on the technical solution of the above embodiment, optionally, determining the target running state information when the target application is running includes:

[0134] Determining the page layout loading details of at least one page layout corresponding to the second type of thread when the target application is running, where the second type of thread is the application rendering thread used for page rendering in the view drawing operation, and the page layout loading details indicate the views drawn by calling the rendering thread processing function in the second type of thread of the view drawing operation and the dependency relationship between the drawn views;

[0135] Based on the page layout loading details of at least one page layout, determining the target running state information when the target application is running, where the target running state information includes the complexity of each page layout loaded by the second type of thread calling different rendering thread processing functions and the CPU time consumption of each page layout.

[0136] Based on the technical solution of the above embodiment, optionally, based on the page layout loading details of at least one page layout, determining the target running state information when the target application is running includes:

[0137] According to the page layout loading details of each page layout, determining the complexity of each page layout loaded by the second type of thread calling different rendering thread processing functions, where the complexity of each page layout is determined based on the view hierarchy depth in the page layout, the page layout type, the number of views in the page layout, and / or whether the page layout includes a specified type of view;

[0138] According to the page layout loading details of each page layout, determining the CPU time consumption of each page layout loaded by the second type of thread calling different rendering thread processing functions, where the CPU time consumption of each page layout is determined based on the cumulative CPU time consumption when the second type of thread calls the rendering thread processing function associated with each page layout to load each page layout.

[0139] Based on the technical solution of the above embodiment, optionally, determining the target running state information when the target application is running includes:

[0140] Determining at least one second function execution record corresponding to the first type of thread when the target application is running, where the first type of thread is the application main thread used for centralized processing of interface interaction logic and business logic in the view drawing operation, and the second function execution record is the tracking or recording during the execution of the reference function called by the first type of thread, and the reference function is the main thread processing function related to animation rendering;

[0141] Determine each animation drawn by the first type of thread calling each reference function according to each execution record of the second function, and use it as the target running state information.

[0142] Based on the technical solution of the above embodiment, optionally, determining the target running state information when the target application is running includes:

[0143] Determine the message tracking record corresponding to the first type of thread when the target application is running. The message tracking information is the tracking information of the message scheduling between the system service layer and the local service layer in the first type of thread. The first type of thread is the main application thread used to centrally process the interface interaction logic and business logic in the view drawing operation;

[0144] Based on the message tracking record corresponding to the first type of thread, determine the target running state information when the target application is running. The target running state information includes the messages sent by calling the main thread processing function in the first type of thread and the CPU time consumption when each message is sent by calling the main thread processing function.

[0145] Based on the technical solution of the above embodiment, optionally, determining the target running state information when the target application is running includes:

[0146] Determine the CPU usage rate of the third type of thread when the target application is running. The third type of thread is the original background thread in the target application other than the first type of thread and the second type of thread when the target application is running. The first type of thread is the main application thread used to centrally process the interface interaction logic and business logic in the view drawing operation, and the second type of thread is the application rendering thread used to perform page rendering in the view drawing operation;

[0147] Determine the CPU usage rate of the fourth type of thread when the target application is running. The fourth type of thread is the newly added background thread in the target application other than the first type of thread and the second type of thread when the target application is running.

[0148] Based on the technical solution of the above embodiment, optionally, determining the smoothness detection result of the target application according to the target running state information includes:

[0149] Determine the reference running state information when the reference application is running. The target application is obtained by adjusting the application version of the reference application. The reference running state information is used to indicate the CPU time consumption, the number of function calls when the reference application makes function calls, and the CPU usage rate of the background thread corresponding to the reference application;

[0150] Determine the change in the fluency difference between the target application and the reference application based on the target running state information and the reference running state information.

[0151] Based on the technical solution of the above embodiment, optionally, determining the change in the fluency difference between the target application and the reference application based on the target running state information and the reference running state information includes:

[0152] Determine the difference detection result between the running state information of the same dimension in the target running state information and the reference running state information. The difference detection result includes the difference in CPU time consumption during function calls, the difference in the number of function calls, and the difference in the CPU usage rate of background threads.

[0153] Based on the difference detection result between the running state information of the same dimension, determine the change in the fluency difference between the target application and the reference application.

[0154] Based on the technical solution of the above embodiment, optionally, determining the fluency detection result of the target application based on the target running state information includes:

[0155] If it is detected that the CPU usage rate of the third type of thread during the running of the target application is greater than the preset CPU usage rate threshold, and the CPU usage rate of the fourth type of thread is not zero, then determine that the fluency detection result of the target application is that the fluency during the running of the target application decreases.

[0156] After starting and running the target application, the technical solution provided by the embodiments of the present disclosure will determine the target running state information during the running of the target application in real time. The target running state information is used to indicate the CPU time consumption, the number of function calls, and the CPU usage rate of the background threads corresponding to the target application during function calls in different detection stages. Then, the fluency detection result of the target application is determined using the target running state information, and it is determined whether the target application deteriorates based on the fluency detection result of the target application. This solution establishes a new idea for preventing deterioration of the fluency index by combining the information on the CPU time consumption of function calls, the number of function calls, and the CPU usage rate of the background threads corresponding to the target application during the running of the target application. Moreover, through the changes in the CPU time consumption of function calls, the number of function calls, and the CPU usage rate of the background threads corresponding to the target application in different detection stages, it is possible to effectively narrow the scope of investigation for deterioration of online indicators, help locate the cause of deterioration to ensure more accurately discovering and handling the fluency situation of the target application, and then timely determine whether the target application deteriorates.

[0157] The deterioration detection device of the application program provided by the embodiments of the present disclosure can execute the deterioration detection method of the application program provided by any embodiment of the present disclosure, and has corresponding functional modules and beneficial effects for executing the deterioration detection method of the application program.

[0158] It should be noted that the various units and modules included in the above device are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be realized; in addition, the specific names of the functional units are only for the convenience of mutual distinction and are not used to limit the protection scope of the embodiments of the present disclosure.

[0159] Figure 20 It is a schematic structural diagram of an electronic device provided by an embodiment of the present disclosure. Referring below to Figure 20 , which shows a schematic structural diagram of an electronic device 2000 suitable for implementing the embodiments of the present disclosure (such as Figure 20 the terminal device or server in). The terminal device in the embodiments of the present disclosure may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (such as in-vehicle navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 20 The electronic device shown is only an example and should not bring any limitation to the functions and usage scope of the embodiments of the present disclosure.

[0160] As Figure 20 shown, the electronic device 2000 may include a processing device (such as a central processing unit, a graphics processing unit, etc.) 2001, which may perform various appropriate actions and processes according to the programs stored in the read-only memory (ROM) 2002 or the programs loaded from the storage device 2008 into the random access memory (RAM) 2003. In the RAM 2003, various programs and data required for the operation of the electronic device 2000 are also stored. The processing device 2001, the ROM 2002, and the RAM 2003 are connected to each other through a bus 2004. The editing / output (I / O) interface 2005 is also connected to the bus 2004.

[0161] Generally, the following devices may be connected to the I / O interface 2005: an input device 2006 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 2007 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 2008 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 2009. The communication device 2009 may allow the electronic device 2000 to communicate with other devices wirelessly or wiredly to exchange data. Although Figure 20An electronic device 2000 is shown with various devices, but it should be understood that it is not required to implement or have all the shown devices. Instead, more or fewer devices may be implemented or had.

[0162] In particular, according to an embodiment of the present disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, an embodiment of the present disclosure includes a computer program product that includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program codes for executing the deterioration detection method of the application program shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through the communication device 2009, or installed from the storage device 2008, or installed from the ROM 2002. When the computer program is executed by the processing device 2001, the above functions defined in the deterioration detection method of the application program of the embodiment of the present disclosure are executed.

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

[0164] The electronic device provided by the embodiment of the present disclosure and the deterioration detection method of the application program provided by the above embodiment belong to the same inventive concept. Technical details not described in detail in this embodiment can be referred to the above embodiment, and this embodiment has the same beneficial effects as the above embodiment.

[0165] The embodiment of the present disclosure provides a computer storage medium, on which a computer program is stored, and when the program is executed by a processor, the deterioration detection method of the application program provided by the above embodiment is implemented.

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

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

[0168] The above-mentioned computer-readable medium can be included in the above-mentioned electronic device; it can also exist separately and not be assembled into the electronic device.

[0169] The above computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: determine the target running state information when the target application program is running, where the target running state information is used to indicate the CPU time consumption, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application program during function calls in different detection stages; determine the fluency detection result of the target application program according to the target running state information; and perform a degradation detection on the target application program according to the fluency detection result of the target application program.

[0170] Computer program code for performing the operations of the present disclosure may be written in one or more programming languages or combinations thereof. The programming languages include, but are not limited to, object-oriented programming languages such as Java, Smalltalk, C++, and also include conventional procedural programming languages such as the "C" language or similar programming languages. The program code may execute entirely on the user's computer, partially on the user's computer, execute as a stand-alone software package, execute partially on the user's computer and partially on a remote computer, or execute entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (for example, by using an Internet service provider to connect through the Internet).

[0171] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code that contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and the combination of blocks in the block diagram and / or flowchart, may be implemented by a dedicated hardware-based system for performing the specified functions or operations, or may be implemented by a combination of dedicated hardware and computer instructions.

[0172] The units involved in the embodiments of the present disclosure can be implemented in software or in hardware. Among them, the name of the unit does not constitute a limitation to the unit itself in some cases. For example, the first acquisition unit can also be described as "the unit for acquiring at least two Internet protocol addresses".

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

[0174] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

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

[0176] In addition, although the operations are depicted in a particular order, this should not be construed as requiring that the operations be performed in the particular order shown or in sequential order. In certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the foregoing discussion, these should not be construed as limitations on the scope of the present disclosure. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented separately or in any suitable sub-combination in multiple embodiments.

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

Claims

1. A method for detecting the degradation of an application program, characterized in that, the method includes: determining target runtime status information of a target application program, where the target runtime status information is used to indicate the CPU time consumption, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application program when the target application program makes function calls in different detection phases; determining a fluency detection result of the target application program according to the target runtime status information; performing degradation detection on the target application program according to the fluency detection result of the target application program.

2. The method according to claim 1, characterized in that, determining the target runtime status information of the target application program includes: determining at least two first function execution records corresponding to the first type of thread during the running of the target application program, where the first type of thread is the main application thread used to centrally process the interface interaction logic and business logic in the view drawing operation, and the first function execution record is the tracking or recording during the execution of the main thread processing function called by the first type of thread; determining the target runtime status information of the target application program according to the at least two first function execution records, where the target runtime status information includes the cumulative average CPU time consumption of each main thread processing function called multiple times when the first type of thread calls different main thread processing functions, the number of calls of each main thread processing function called by each page layout corresponding to the first type of thread, and / or the cumulative CPU time consumption of each main thread processing function called by each page layout corresponding to the first type of thread.

3. The method according to claim 2, characterized in that, determining the target runtime status information of the target application program according to the at least two first function execution records includes: determining at least two first-stage function execution records corresponding to the first type of thread from the at least two first function execution records, where the first-stage function record is the first function execution record called by the main thread processing function in the first type of thread during the first stage, and the first stage is the stage of touching and dragging during the sliding operation process corresponding to the view drawing operation; traversing each first-stage function execution record to determine the cumulative average CPU time consumption when the same main thread processing function is called, so as to obtain the cumulative average CPU time consumption of each main thread processing function.

4. The method according to claim 2, characterized in that, determining the target runtime status information of the target application program according to the at least two first function execution records includes: determining at least two second-stage function execution records corresponding to the first type of thread from the at least two first function execution records, where the first-stage function record is the first function execution record called by the main thread processing function in the first type of thread during the second stage, and the second stage is the stage of inertial rebound or sliding after stopping touching and the stage of starting to bind data after the sliding stops in the sliding operation process corresponding to the view drawing operation; Traverse each execution record of the second-stage function, and determine the call count of the main-thread processing function associated with each page layout in the view drawing operation and the cumulative CPU time consumption corresponding thereto.

5. The method according to claim 1, wherein, determine the target running state information when the target application is running, including: determine the page layout loading details of at least one page layout corresponding to the second type of thread when the target application is running, where the second type of thread is the application rendering thread used for page rendering in the view drawing operation, and the page layout loading details indicate the views drawn by calling the rendering thread processing function in the second type of thread of the view drawing operation and the dependency relationship between the drawn views; Based on the page layout loading details of at least one page layout, determine the target running state information when the target application is running, where the target running state information includes the complexity of each page layout loaded by the second type of thread calling different rendering thread processing functions and the CPU time consumption of each page layout.

6. The method according to claim 5, wherein, Based on the page layout loading details of at least one page layout, determine the target running state information when the target application is running, including: According to the page layout loading details of each page layout, determine the complexity of each page layout loaded by the second type of thread calling different rendering thread processing functions, where the complexity of each page layout is determined based on the view hierarchy depth in the page layout, the page layout type, the number of views in the page layout, and / or whether the page layout includes a specified type of view; According to the page layout loading details of each page layout, determine the CPU time consumption of each page layout loaded by the second type of thread calling different rendering thread processing functions, where the CPU time consumption of each page layout is determined based on the cumulative CPU time consumption when the second type of thread calls the rendering thread processing function associated with each page layout to load each page layout.

7. The method according to claim 1, wherein, determine the target running state information when the target application is running, including: determine at least one second function execution record corresponding to the first type of thread when the target application is running, where the first type of thread is the application main thread used for centralized processing of interface interaction logic and business logic in the view drawing operation, and the second function execution record is the tracking or recording during the execution of the reference function called by the first type of thread, and the reference function is the main-thread processing function related to animation rendering; According to each second function execution record, determine each animation drawn by the first type of thread calling each reference function and use it as the target running state information.

8. The method according to claim 1, wherein, determine the target running state information when the target application is running, including: Determine the message trace record corresponding to the first type of thread during the running of the target application. The message trace information is the trace information of the message scheduling between the system service layer and the local service layer in the first type of thread. The first type of thread is the main application thread used to centrally process the interface interaction logic and business logic during the view drawing operation; Based on the message trace record corresponding to the first type of thread, determine the target running status information during the running of the target application. The target running status information includes the messages sent by calling the main thread processing function in the first type of thread and the CPU time consumption when each message is sent by calling the main thread processing function.

9. The method according to claim 1, characterized in that, determining the target running status information during the running of the target application includes: Determine the CPU usage rate of the third type of thread during the running of the target application. The third type of thread is the original background thread in the target application other than the first type of thread and the second type of thread during the running of the target application. The first type of thread is the main application thread used to centrally process the interface interaction logic and business logic during the view drawing operation, and the second type of thread is the application rendering thread used to perform page rendering during the view drawing operation; Determine the CPU usage rate of the fourth type of thread during the running of the target application. The fourth type of thread is the newly added background thread in the target application other than the first type of thread and the second type of thread during the running of the target application.

10. The method according to any one of claims 1 to 9, characterized in that, Determining the fluency detection result of the target application based on the target running status information includes: Determine the reference running status information during the running of the reference application. The target application is obtained by adjusting the application version of the reference application. The reference running status information is used to indicate the CPU time consumption, the number of function calls, and the CPU usage rate of the background thread corresponding to the reference application when the reference application makes function calls; Based on the target running status information and the reference running status information, determine the change in the fluency difference between the target application and the reference application.

11. The method according to claim 10, characterized in that, Based on the target running status information and the reference running status information, determining the change in the fluency difference between the target application and the reference application includes: Determine the difference detection result between the running status information of the same dimension in the target running status information and the reference running status information. The difference detection result includes the difference in CPU time consumption during function calls, the difference in the number of function calls, and the difference in the CPU usage rate of the background thread; Based on the difference detection result between the running status information of the same dimension, determine the change in the fluency difference between the target application and the reference application.

12. The method according to claim 9, characterized in that, Determining the fluency detection result of the target application based on the target running status information includes: If it is detected that the CPU usage rate of the third type of thread during the running of the target application is greater than the preset CPU usage rate threshold, and the CPU usage rate of the fourth type of thread is not zero, then it is determined that the fluency detection result of the target application is that the fluency during the running of the target application decreases.

13. A device for detecting the deterioration of an application Characterized in that The device includes: A first determination module, configured to determine the target running state information during the running of the target application, where the target running state information is used to indicate the CPU consumption, the number of function calls, and the CPU usage rate of the background thread corresponding to the target application when the target application makes function calls in different detection stages; A second determination module, configured to determine the fluency detection result of the target application according to the target running state information; A detection module, configured to perform deterioration detection on the target application according to the fluency detection result of the target application.

14. An electronic device Characterized in that The electronic device includes: One or more processors; A storage device, configured to store one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method for detecting the deterioration of an application according to any one of claims 1-12.

15. A storage medium containing computer-executable instructions Characterized in that The computer-executable instructions are used to execute the method for detecting the deterioration of an application according to any one of claims 1-12 when executed by a computer processor.

Images