Carton processing method and device, computer device and storage medium

Abstract

Embodiments of the application disclose a frame freezing processing method and device, computer equipment and a storage medium, and belong to the technical field of computers. The method comprises the following steps: acquiring frame freezing record information reported by an application program, wherein the frame freezing record information comprises a function call stack of a frame freezing frame; determining a core call stack corresponding to the function call stack, wherein the core call stack comprises a core function in the function call stack, a time consumption duration of the core function, and a call relationship between different core functions; clustering at least two determined core call stacks to obtain a clustering result, wherein the clustering result comprises a number of occurrences of each core call stack; and generating a frame freezing report of the application program based on the clustering result. The application reduces the complexity of the core call stack, reduces the processing amount, improves the processing efficiency, improves the accuracy of the frame freezing report, and saves the labor cost.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, and storage medium for handling lag. Background Technology

[0002] With the development of computer technology and the widespread use of various applications, application performance has become crucial. Lag within applications is a significant factor affecting performance, severely impacting normal user experience. Therefore, a method for handling application lag is urgently needed. Summary of the Invention

[0003] This application provides a method, apparatus, computer device, and storage medium for handling lag, which reduces the complexity of the core call stack, decreases processing load, improves processing efficiency, enhances the accuracy of lag reports, and saves labor costs. The technical solution is as follows:

[0004] On the one hand, a method for handling stuttering is provided, the method comprising:

[0005] Obtain the stuttering log information reported by the application. The stuttering log information includes the function call stack of the stuttering frame. The stuttering frame is the frame in which stuttering occurs in the application. The function call stack includes the functions called during the execution of the stuttering frame, the duration of the function, and the call relationship between different functions.

[0006] Determine the core call stack corresponding to the function call stack. The core call stack includes the core function in the function call stack, the execution time of the core function, and the call relationship between different core functions. The core function is a function that satisfies a first target condition, whereby the execution time of the function is greater than a first preset time.

[0007] Clustering is performed on at least two of the identified core call stacks to obtain clustering results, the clustering results including the number of occurrences of each core call stack;

[0008] Based on the clustering results, a lag report for the application is generated.

[0009] On the other hand, a method for handling stuttering is provided, the method comprising:

[0010] If it is determined that the frame running in the application is a stuttering frame, stuttering record information is obtained. The stuttering record information includes function call stacks, which include the functions called during the execution of the frame and the duration of the functions. The stuttering frame is the frame in the application where stuttering occurs.

[0011] Report the lag log information to the server;

[0012] The server is configured to: acquire the stuttering record information; determine the core call stack corresponding to the function call stack, wherein the core call stack includes the core function in the function call stack, the duration of the core function, and the call relationship between different core functions, wherein the core function is a function that satisfies a first target condition, the first target condition being that the duration of the function is greater than a first preset duration; cluster the at least two determined core call stacks to obtain a clustering result, wherein the clustering result includes the number of occurrences of each core call stack; and generate a stuttering report for the application based on the clustering result.

[0013] On the other hand, a stuttering processing device is provided, the device comprising:

[0014] The information acquisition module is used to acquire the stuttering record information reported by the application. The stuttering record information includes the function call stack of the stuttering frame. The stuttering frame is the frame in which stuttering occurs in the application. The function call stack includes the functions called during the execution of the stuttering frame, the duration of the function, and the call relationship between different functions.

[0015] The core determination module is used to determine the core call stack corresponding to the function call stack. The core call stack includes the core function in the function call stack, the time consumption of the core function, and the call relationship between different core functions. The core function is a function that satisfies a first target condition, whereby the time consumption of the function is greater than a first preset time.

[0016] A clustering module is used to cluster at least two identified core call stacks to obtain clustering results, the clustering results including the number of occurrences of each core call stack;

[0017] The report generation module is used to generate a lag report for the application based on the clustering results.

[0018] In one possible implementation, the core function includes: a root function that satisfies the first objective condition, and a non-root function that satisfies the first objective condition and the second objective condition;

[0019] Wherein, the root function refers to a function that is not called by other functions, and the non-root function refers to a function that is called by other functions; the second objective condition is that the difference in execution time between the non-root function and its parent function is less than a preset difference, and the parent function of the non-root function is the function that calls the non-root function.

[0020] In one possible implementation, the core determining module includes:

[0021] A multi-branch tree generation unit is used to generate a multi-branch tree corresponding to the function call stack, wherein each node in the multi-branch tree corresponds to a function in the function call stack, and the node corresponding to any function is a child node of the node corresponding to another function that calls the function;

[0022] A multi-branch tree processing unit is configured to, in response to the root function corresponding to the root node satisfying the first target condition, add the root function to the core call queue corresponding to the root node; add the non-root function corresponding to the target child node of the root node to the core call queue until the length of the core call queue reaches a preset length, or the target child node does not exist among the remaining child nodes of the root node; and determine the core call stack corresponding to the root node based on the core call queue.

[0023] The target child node refers to the child node of the corresponding non-root function that satisfies the first target condition and the second target condition.

[0024] In one possible implementation, the multi-branch tree processing unit is used for:

[0025] The multiple first child nodes are sorted in descending order of the execution time of the non-root functions corresponding to the multiple first child nodes; the first child node refers to the child node directly connected to the root node.

[0026] According to the sorting of the multiple first child nodes, traverse the branches to which the first child nodes belong, and add the non-root function corresponding to the target child node in the currently traversed branch to the core call queue;

[0027] When the length of the core call queue reaches the preset length, stop traversing the remaining child nodes in the branch and the remaining branches in the multi-branch tree, and determine the core call stack based on the core call queue;

[0028] Alternatively, if the length of the core call queue has not reached the preset length, and all child nodes of the branch have been traversed or the target child node is not found among the remaining child nodes of the branch, the branch to which the next first child node belongs is traversed according to the order of the plurality of first child nodes until the length of the core call queue reaches the preset length, or the target child node is not found among the remaining child nodes of the root node, and the core call stack is determined based on the core call queue.

[0029] In one possible implementation, the multi-branch tree processing unit is used for:

[0030] In response to the non-root function corresponding to the first child node in the branch satisfying the first objective condition and the second objective condition, the non-root function corresponding to the first child node is added to the core call queue;

[0031] If the length of the core call queue does not reach the preset length, in response to the non-root function corresponding to the next level child node of the first child node satisfying the first target condition and the second target condition, the next level child node is added to the core call queue until the length of the core call queue reaches the preset length, or all child nodes of the branch are traversed, or the target child node is not found among the remaining child nodes of the branch.

[0032] In one possible implementation, the core determining module further includes:

[0033] The filtering unit is used to filter the nodes corresponding to functions that meet the filtering conditions in the multi-branch tree after generating the multi-branch tree corresponding to the function call stack.

[0034] The filtering conditions include at least one of the following:

[0035] The function in question is a debugging function.

[0036] The time taken by the function is less than the second preset time, and the second preset time is less than the first preset time;

[0037] The time taken by the function is less than the product of the time taken by the parent function and a preset ratio, where the preset ratio is less than 100%.

[0038] In one possible implementation, the report generation module is used to select a first preset number of core call stacks from at least two core call stacks in descending order of the frequency of occurrence of each core call stack; and generate the stuttering report, which includes the selected core call stacks and the clustering results of the core call stacks.

[0039] In one possible implementation, the function call stack includes the function sequence number ID corresponding to the function, and the apparatus further includes:

[0040] The restoration module is used to restore the function ID corresponding to each function in each function call stack to the function name corresponding to each function based on the symbol table of the application. The symbol table includes at least one function ID and the function name corresponding to each function ID.

[0041] In one possible implementation, the stuttering frame is a frame in the application that meets the stuttering conditions;

[0042] The stuttering conditions include: the duration of the frame is greater than a third preset duration, and the duration of the frame is greater than a preset multiple of the average duration of the second preset number of preceding frames.

[0043] Wherein, the third preset duration is longer than the first preset duration, the preceding frame is another frame located before the frame, and the preset multiple is greater than 1.

[0044] On the other hand, a stuttering processing device is provided, the device comprising:

[0045] The information acquisition module is used to acquire stuttering record information when it is determined that the frame running in the application is a stuttering frame. The stuttering record information includes a function call stack, which includes the functions called during the execution of the frame and the duration of the functions. The stuttering frame is the frame in the application where stuttering occurs.

[0046] The reporting module is used to report the lag record information to the server;

[0047] The server is configured to: acquire the stuttering record information; determine the core call stack corresponding to the function call stack, wherein the core call stack includes the core function in the function call stack, the duration of the core function, and the call relationship between different core functions, wherein the core function is a function that satisfies a first target condition, the first target condition being that the duration of the function is greater than a first preset duration; cluster the at least two determined core call stacks to obtain a clustering result, wherein the clustering result includes the number of occurrences of each core call stack; and generate a stuttering report for the application based on the clustering result.

[0048] On the other hand, a computer device is provided, the computer device including a processor and a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to perform the operations performed by the stuttering handling method described above.

[0049] On the other hand, a computer-readable storage medium is provided that stores at least one computer program, which is loaded and executed by a processor to perform the operations performed by the stuttering handling method described above.

[0050] On the other hand, a computer program product is provided, including a computer program that is loaded and executed by a processor to perform the operations performed by the stuttering handling method described above.

[0051] The stuttering handling scheme provided in this application embodiment records the function call stacks of stuttering frames during application execution. It retains the core functions in the function call stacks and filters out non-core functions to determine the corresponding core call stacks. Furthermore, it clusters at least two core call stacks and generates a stuttering report based on the clustering results. By filtering the function call stacks, invalid information is removed, improving the relevance of the core call stacks, reducing their complexity, and increasing processing efficiency. Moreover, stack clustering ensures that the stuttering report accurately reflects the cause of the application stuttering, improving the accuracy of the report. It also eliminates the need for users to analyze duplicate core call stacks separately, saving manpower costs. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0053] Figure 1 This is a schematic diagram of a computer system provided in an embodiment of this application;

[0054] Figure 2 This is a flowchart of a stuttering handling method provided in an embodiment of this application;

[0055] Figure 3 This is a schematic diagram of a function call stack provided in an embodiment of this application;

[0056] Figure 4 This is a schematic diagram of preset task information provided in an embodiment of this application;

[0057] Figure 5 This is a schematic diagram of a stuttering recording information provided in an embodiment of this application;

[0058] Figure 6This is a schematic diagram of a symbol table provided in an embodiment of this application;

[0059] Figure 7 This is a schematic diagram of a function call stack after restoring the function name, provided in an embodiment of this application;

[0060] Figure 8 This is a flowchart of another lag handling method provided in the embodiments of this application;

[0061] Figure 9 This is a schematic diagram of a process for generating a stack diagram provided in an embodiment of this application;

[0062] Figure 10 This is a schematic diagram of a multi-branch tree provided in an embodiment of this application;

[0063] Figure 11 This is a schematic diagram of an operation flow for determining the core call stack provided in an embodiment of this application;

[0064] Figure 12 This is a schematic diagram of a stuttering report provided in an embodiment of this application;

[0065] Figure 13 This is a flowchart of another lag handling method provided in the embodiments of this application;

[0066] Figure 14 This is a schematic diagram of a method for recording cached data provided in an embodiment of this application;

[0067] Figure 15 This is a schematic diagram of the structure of a stuttering processing device provided in an embodiment of this application;

[0068] Figure 16 This is a schematic diagram of another stuttering processing device provided in an embodiment of this application;

[0069] Figure 17 This is a schematic diagram of another stuttering processing device provided in an embodiment of this application;

[0070] Figure 18 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application;

[0071] Figure 19 This is a schematic diagram of the structure of a server provided in an embodiment of this application. Detailed Implementation

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

[0073] It is understood that the terms "first," "second," etc., used in this application may be used to describe various concepts herein, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of this application, a first function may be referred to as a second function, and similarly, a second function may be referred to as a first function.

[0074] Here, "at least two" means two or more functions. For example, "at least two functions" can be any integer number of functions greater than or equal to two, such as two functions, three functions, etc. "Each" refers to each of the "at least two" functions. For example, "each function" refers to each of the "at least two" functions. If the "at least two" functions are three functions, then "each function" refers to each of the three functions.

[0075] It should be noted that all information (including but not limited to user equipment information, user personal information, etc.), documents (including but not limited to documents used for analysis, stored documents, displayed documents, etc.) and signals (including but not limited to signals transmitted between user terminals and other devices) involved in this application have been fully authorized by the user or relevant parties, and the collection, use and processing of relevant documents shall comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0076] Figure 1 This is a schematic diagram of a computer system provided in an embodiment of this application, such as... Figure 1 As shown, the computer system includes a terminal 101 and a server 102.

[0077] Optionally, the terminal 101 can be a smartphone, tablet, laptop, desktop computer, game console, etc., but is not limited to these. Optionally, the server 102 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The terminal 101 and the server 102 are directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0078] Those skilled in the art will understand that the number of terminals described above can be more or less. For example, there may be only one terminal, or there may be six, eight, or more terminals. This application does not limit the number of terminals or the type of device.

[0079] In this embodiment, terminal 101 runs application 111, while server 102 analyzes application 111. Application 111 can be a social application, a game application, a live streaming application, a video playback application, etc. This embodiment does not limit the type of application 111. For example, the application can be a game application generated using Unity, a game editor used to create game scenes or objects. The game application can use Python, an object-oriented interpreted computer programming language and a powerful and comprehensive general-purpose language.

[0080] In addition, server 102 can also be used to provide data storage, data processing and other functions for application 111. For example, server 102 can be a server owned by the developer of application 111, or a server owned by the maintainer of application 111, etc.

[0081] During the execution of application 111, one or more frames will be displayed, and one or more functions will be called during the execution of each frame. Once a stutter occurs in application 111, the currently running frame can be called a stutter frame. Application 111 can record stutter frames to obtain stutter recording information, which includes the function call stack of at least one stutter frame. This stutter recording information is then reported to server 102. Server 102 can analyze the stutter recording information and output a stutter report. The developers or maintainers of application 111 can view this stutter report to understand the stuttering situation of application 111, analyze the cause of the stuttering, and thus fix application 111 to reduce the possibility of stuttering. For example, suppose there is a bug (vulnerability) in application 111, which will cause the application 111 to freeze during operation. By reviewing the freeze report, the cause of the freeze in application 111 can be analyzed, the function that causes the freeze in application 111 can be found, and then the bug in the function can be found. Fixing the bug will solve the problem of application 111 freezing.

[0082] It should be noted that the above computer system is only an example, and the method provided in this application embodiment can also be executed in other computer systems. This application embodiment does not limit this.

[0083] Figure 2 This is a flowchart of a lag handling method provided in an embodiment of this application, which is executed by a server.

[0084] See Figure 2 The method includes:

[0085] 201. The server obtains the lag log information reported by the application.

[0086] The stuttering log information includes the function call stack of the stuttering frame. A stuttering frame is the frame in the application where stuttering occurs. The function call stack includes the functions called during the execution of the stuttering frame, the duration of each function call, and the call relationships between different functions. The call relationship between any two functions can represent the caller and callee in those two functions.

[0087] During the application's operation, if any frame experiences a stutter, that frame is identified as a stuttered frame, and stuttering log information is generated to record the specific circumstances of the stutter. This stuttering log information can then be reported to the server. The stuttering log information records the frame's execution status and may include the frame's function call stack, as well as other information about the frame; this embodiment does not limit this.

[0088] For example, the stuttering log information includes:

[0089] (1) The function call stack of a frame is a space that records the path and parameters of function calls during application execution, used to store relevant information about the called functions. The compiler allocates a function call stack for the current frame, and can release the function call stack when the current frame finishes running. However, in this embodiment, the function call stack is not released directly, but is recorded first for later use.

[0090] Optionally, the function call stack includes the frame sequence number, the total duration of the frame, the function IDs corresponding to the functions called during the frame's execution, the duration or time interval of each function, the number of function calls, the function ID of the caller, and the function depth. Additionally, the function call stack may include other information, which is not limited in this embodiment.

[0091] For example, the function call stack is as follows Figure 3 As shown, the "-" sign before the function ID indicates the function's depth. Figure 3 Of the four functions, the first function has a function ID of 100001 and a depth of 0, indicating that this function has not been called by any other function. The second function has a function ID of 100002 and a depth of 1, indicating that the second function was called by the first function. The third function has a function ID of 100003 and a depth of 2, indicating that the third function was called by the second function. The fourth function has a function ID of 100004 and a depth of 2, indicating that the fourth function was called by the second function.

[0092] (2) Preset task information corresponding to the preset tasks executed during frame execution. Preset tasks refer to pre-set tasks that have a long execution time, such as shader compilation tasks, synchronous loading tasks, and garbage collection tasks. Preset tasks can also be called heavy tasks. Executing a preset task requires a long time and may take multiple frames to complete.

[0093] For example, the application retrieves preset task information for three preset tasks, and the retrieved preset task information is as follows: Figure 4 As shown, the preset task information includes the execution time of the Shader compilation task, synchronous loading task, and garbage collection task, as well as the frame number and task name of the frame running at that execution time. Based on this preset task information, it can be determined which frames' execution processes the preset tasks were executed during.

[0094] (3) Account information, which may include the account used to log in to the application, the location coordinates of the virtual character in the virtual scene, the orientation of the virtual character in the virtual scene, the game mode entered by the virtual character, and the virtual map where the virtual character is located.

[0095] (4) Application information, which may include the platform type of the device on which the application is located, the geographical region to which the application is located, the version number of the application, the update time of the application, the server to which the application is located, and the download address of the application's installation package, etc.

[0096] (5) Device information, which may include the device name, device model, and model of the chip configured in the device, such as the model of the GPU (Graphics Processing Unit).

[0097] For example, stuttering log information may include Figure 5 The information shown.

[0098] In this embodiment of the application, the lag recording information may include the function call stack mentioned above, and may also include at least one of preset task information, account information, application information and device information. This embodiment of the application does not limit the detailed content of the lag recording information.

[0099] Optionally, a stuttering frame is a frame in the application that meets stuttering conditions. These conditions include: the frame's duration being greater than a third preset duration, and the frame's duration being greater than a preset multiple of the average duration of a second preset number of preceding frames. Therefore, after any frame in the application finishes running, it can be determined whether the frame is a stuttering frame based on its duration and the duration of the second preset number of preceding frames. If the frame is determined to be a stuttering frame, stuttering record information is generated.

[0100] The first preset duration is used to indicate whether the function's duration is the cause of frame stuttering. That is, if the function's duration is longer than the first preset duration, it can be considered that the function's duration is too long and that the function may be the cause of frame stuttering. The third preset duration is used to indicate whether frame stuttering occurs. The third preset duration is longer than the first preset duration. For example, the first preset duration is 16 milliseconds and the third preset duration is 84 milliseconds.

[0101] The preceding frame is any other frame that precedes this frame. The preset multiplier is greater than 1. The second preset number can be any number set by the server. For example, if the second preset number is 3 and the preset multiplier is 2, then the frame will be identified as a stuttering frame if the frame's duration is greater than the third preset duration and the frame's duration is more than twice the average duration of the three frames preceding it.

[0102] The stuttering conditions adopted in this application embodiment not only consider the duration of the frame itself, but also the relationship between the duration of the frame and the average duration of the second preset number of preceding frames. This can accurately measure the running status of multiple frames in the application, thereby determining the accurate stuttering frames and avoiding the situation where multiple consecutive frames with large durations are misjudged as stuttering frames, thus improving the accuracy of stuttering frames.

[0103] Optionally, the application caches the function call stack corresponding to the currently running frame in real time. Upon determining that any frame is a stuttering frame, it retrieves the function call stack, and may also retrieve at least one of the following: preset task information, account information, application information, and device information, thereby generating a stuttering record. This stuttering record can then be reported to the server immediately. Alternatively, the stuttering record can be cached first, and then one or more collected stuttering records can be reported to the server after a period of time.

[0104] Optionally, the application uploads the lag log information collected within the first cycle duration to the server every first cycle duration. The server receives and stores this lag log information. Then, every second cycle duration, the server retrieves the stored lag log information and processes it using steps 202-204. The second cycle duration can be equal to or greater than the first cycle duration, for example, it can be an integer multiple of the first cycle duration. The server can collect lag log information according to the second cycle duration, thereby centrally processing the collected lag log information.

[0105] 202. The server determines the core call stack corresponding to the function call stack. The core call stack includes the core functions in the function call stack, the duration of the core functions, and the call relationships between different core functions. The core functions are functions that satisfy the first target condition, which is that the duration of the function is greater than the first preset duration.

[0106] The function call stack contains a wealth of information, comprehensively reflecting the execution of stuttering frames. However, the function call stack includes a large number of functions, many of which have short execution times and are not the primary cause of stuttering. Direct analysis based solely on the function call stack lacks specificity and struggles to pinpoint the core cause of stuttering. Therefore, to accurately analyze the cause of stuttering, the server filters the functions in the function call stack, retaining core functions and discarding non-core functions. Thus, after filtering out non-core functions, the core call stack can be determined; the core call stack contains fewer than or equal to the number of functions in the function call stack.

[0107] Among them, the time taken by the core function is greater than the first preset time, which means that the core function takes a long time and is likely the cause of the stuttering frame. The time taken by the non-core function is no greater than the first preset time, which means that the non-core function has little impact on the time taken by the stuttering frame and can be ignored.

[0108] Optionally, the function call stack includes the function ID (Identity, sequence number) corresponding to each function. Before executing step 202, the method further includes: based on the application's symbol table, restoring the function ID corresponding to each function in each function call stack to the function name corresponding to each function. The symbol table includes at least one function ID and the function name corresponding to each function ID. This symbol table can be set by the application developer and can be stored on a server. By restoring the function ID to the function name, the function called during the frame's execution can be represented by the function name in the core call stack and the generated stuttering report, improving visibility and facilitating timely analysis of the function represented by the function name to accurately determine the cause of application stuttering.

[0109] For example, symbol tables such as Figure 6 As shown, based on Figure 6 The symbol table shown can be used to... Figure 3 The function IDs in the function call stack shown are restored to their corresponding function names, thus obtaining... Figure 7 The function call stack is shown.

[0110] 203. The server clusters at least two identified core call stacks to obtain clustering results, which include the number of occurrences of each core call stack.

[0111] For at least two function call stacks, the server can identify at least two corresponding core call stacks. Each core call stack represents the function that caused the application to lag. By clustering the at least two core call stacks, the server can group the same or similar core call stacks into one cluster and the dissimilar core call stacks into different clusters. The server can also determine the frequency of each type of core call stack.

[0112] For any kernel call stack, the more frequently it appears, the more likely it is to be the cause of application lag. Conversely, the fewer frequently it appears, the less likely it is to be the cause of application lag.

[0113] It should be noted that the server can retrieve one stuttering record at a time to determine a core call stack, which is then stored in the database. Subsequently, at least two core call stacks can be retrieved from the database and clustered to obtain the clustering result. Alternatively, at least two stuttering records can be retrieved at once to determine at least two core call stacks, which are then clustered to obtain the clustering result.

[0114] 204. The server generates an application lag report based on the clustering results.

[0115] Each time the server obtains a clustering result, it can generate a lag report based on the obtained clustering result, or it can save the obtained clustering result in the database, and subsequently read one or more clustering results from the database and generate a lag report based on the one or more clustering results. This application embodiment does not limit this.

[0116] The stuttering report is associated with the clustering results of at least two core call stacks, which can reflect the clustering results of the at least two core call stacks. Therefore, users who view the stuttering report can analyze the cause of the application stuttering based on the stuttering report, and thus fix the application to reduce the possibility of application stuttering.

[0117] Optionally, the stuttering report includes the clustering results of the at least two core call stacks. Alternatively, the server analyzes the clustering results of the at least two core call stacks to obtain analysis results, and the stuttering report includes these analysis results. This application embodiment does not limit the specific association between the stuttering report and the clustering results.

[0118] In related technologies, even if an application experiences occasional lag, the application developer cannot know the specific situation or accurately reproduce the lag scenario. Furthermore, users who encounter lag issues rarely report them to the application developer, leading to the lag problems being ignored and unresolved.

[0119] The stuttering handling method provided in this application records the function call stacks of stuttering frames during application execution, retains the core functions in the function call stacks and filters out non-core functions to determine the core call stacks corresponding to the function call stacks, and clusters at least two core call stacks, generating a stuttering report based on the clustering results. By filtering the function call stacks, invalid information is removed, the relevance of the core call stacks is improved, the complexity of the core call stacks is reduced, and processing efficiency is improved. Moreover, through stack clustering, the stuttering report ensures that it accurately reflects the cause of application stuttering, improving the accuracy of the stuttering report, and eliminating the need for users to analyze duplicate core call stacks separately, saving manpower costs.

[0120] In the above embodiment, the core function is a function that satisfies the first objective condition. In another possible implementation, the core function includes: a root function that satisfies the first objective condition, and a non-root function that satisfies the first objective condition and the second objective condition.

[0121] Here, a root function is a function that is not called by other functions, and a non-root function is a function that is called by other functions; the second objective condition is that the difference in execution time between a non-root function and its parent function is less than a preset difference, and the parent function of a non-root function is the function that calls the non-root function.

[0122] First, the root function is executed during the execution of the stuttering frame. The duration of the root function will affect the overall duration of the stuttering frame. If the duration of the root function is longer than the first preset duration, it means that the duration of the root function is relatively long, and the stuttering frame is likely caused by the execution of the root function. Therefore, the root function that meets the first target condition needs to be saved in the kernel call stack so that it can be determined later whether the stuttering is caused by the root function.

[0123] Secondly, during the execution of the stuttering frame, a root function is run, which in turn calls other functions. These called functions are non-root functions, and the root function that calls these non-root functions is called their parent function. The execution time of the non-root functions affects the execution time of their parent functions, which in turn affects the execution time of the stuttering frame. Therefore, for a non-root function, if its execution time is not greater than a first preset time, it indicates that its execution time is relatively short, which may be the cause of the stuttering frame. Therefore, this non-root function can be filtered out.

[0124] If the duration of the non-root function exceeds the first preset duration, and the difference in duration between the non-root function and the parent function is not less than the preset difference, although this indicates that the duration of the non-root function is large, it also indicates that the large duration of the parent function is due to calling other functions, not the non-root function. In other words, the non-root function is very likely not the cause of the large duration of the parent function, and it is also very likely not the cause of the stuttering frames. Therefore, there is no need to keep the non-root function; it can be filtered out.

[0125] If the duration of the non-root function is greater than the first preset duration, and the difference in duration between the non-root function and the parent function is less than the preset difference, it indicates that the duration of the non-root function is relatively long, and the large duration of the parent function is mainly due to the call to the non-root function. In other words, the non-root function is very likely the reason for the large duration of the parent function, and it is also very likely the reason for the stuttering frames. Therefore, the non-root function is retained.

[0126] Taking function A calling functions B and C as an example, function A is the root function, and functions B and C are non-root functions. The execution time of function A is t1, the execution time of function B is t2, and the execution time of function C is t3. During the execution of function A, it will call functions B and C, and may also execute other instructions inside function A. Therefore, t1 is greater than or equal to the sum of t2 and t3.

[0127] If t1 is greater than the first preset duration, then function A is identified as the core function. If t2 and t3 are also greater than the first preset duration, where the difference between t1 and t2 is less than the preset difference, and the difference between t1 and t3 is greater than the preset difference, it indicates that function B is the main reason for the longer execution time of function A, while function C is not the main reason for the longer execution time of function A. Therefore, function B is identified as the core function, and function C is filtered out. Thus, the identified core call stack will include function A, the execution time t1 of function A, function B, and the execution time t2 of function B, and will also indicate that the function call relationship is: function A calls function B.

[0128] In this embodiment, a first target condition and a second target condition are introduced as criteria for filtering core functions. These criteria consider not only whether the function's own execution time exceeds a first preset time, but also whether the difference in execution time between the called function and its parent function is less than a preset difference. This allows for the filtering of root functions whose execution time exceeds the first preset time, as well as non-root functions whose execution time exceeds the first preset time but whose difference in execution time with its parent function is less than the preset difference. Non-root functions whose execution time exceeds the first preset time but whose difference in execution time with its parent function is not less than the preset difference are filtered out. Therefore, different criteria are used for filtering root functions and non-root functions, refining the granularity of the filtering functions and more accurately filtering out functions that are not the cause of the stuttering frames. This further removes invalid information from the core call stack and saves manpower costs.

[0129] Based on the above embodiments, this application also provides another method for handling stuttering. Figure 8 This is a flowchart of another lag handling method provided in this application embodiment, which is executed by the server. See also... Figure 8 The method includes:

[0130] 801. The server obtains the lag log information reported by the application.

[0131] The stuttering log information includes the function call stack of the stuttering frame. The stuttering frame is the frame in the application where stuttering occurs. The function call stack includes the functions called during the execution of the stuttering frame, the duration of each function, and the call relationship between different functions.

[0132] Step 801 is similar to step 201, and will not be repeated here.

[0133] 802. The server generates a multi-branch tree corresponding to the function call stack.

[0134] In a multi-branch tree, each node corresponds to a function in the function call stack, and the node corresponding to any function is a child node of the node corresponding to another function that called that function. Therefore, a multi-branch tree includes multiple levels, each level containing at least one node. If a node in the upper level is connected to a node in the lower level, it means that the node in the upper level is the parent node and the node in the lower level is the child node, which reflects that the function corresponding to the parent node called the function corresponding to the child node.

[0135] Optionally, the function call stack includes the function ID, depth, and time interval for each function corresponding to the same frame number. The server, based on a symbol table (which includes at least one function ID and the corresponding function name), restores each function ID to its corresponding function name. Then, based on the depth of each function, functions with the same depth and function name are summed, and the summation count represents the number of times that function has been called. Furthermore, each function is plotted on the stack graph according to its corresponding depth and time interval, thus generating a stack graph. The horizontal axis of this stack graph represents time, and the vertical axis represents the function depth. The stack graph displays the functions called at different depths and within different time intervals, illustrating the call relationships between different functions. The server can then generate a multi-branch tree based on the positional relationships of each function in the stack graph.

[0136] For example, if function A calls functions B0 and B1, and function B0 calls function C, then the stack diagram generated based on the function call stack would be as follows: Figure 9 As shown, the generated multi-way tree is as follows Figure 10 As shown.

[0137] Optionally, after generating the multi-branch tree corresponding to the function call stack, the nodes corresponding to functions that meet the filtering conditions in the multi-branch tree are filtered; wherein the filtering conditions include at least one of the following:

[0138] (1) The function belongs to the debugging function.

[0139] Debugging functions are functions used to debug the application. These functions can include logging functions, GM (Game Master) tools, scene switching functions, etc. These debugging functions are generally not the cause of application lag and can therefore be filtered out.

[0140] (2) The time taken by the function is less than the second preset time, and the second preset time is less than the first preset time.

[0141] For example, the first preset duration is 16 milliseconds, while the second preset duration is 1 millisecond. If the function's duration is less than the second preset duration, it means the function's duration is too short, and this function is unlikely to be the cause of the stuttering frames. Therefore, this function can be filtered out.

[0142] (3) The time taken by the function is less than the product of the time taken by the parent function and the preset ratio, and the preset ratio is less than 100%.

[0143] The preset ratio can be a small value such as 1% or 2%. If the execution time of a function is less than the product of the execution time of the parent function and the preset ratio, it means that the execution time of this function accounts for a very small proportion of the execution time of the parent function. This function is unlikely to be the reason for the long execution time of the parent function, so it is filtered out.

[0144] It should be noted that filtering a node in a multi-way tree means either deleting the node from the multi-way tree or adding a filter flag to the node in the multi-way tree to indicate that the node does not need to be processed.

[0145] In this embodiment, after generating the multi-branch tree corresponding to the function call stack, before analyzing the multi-branch tree, the child nodes corresponding to functions that cannot be core functions in the multi-branch tree are filtered out in advance. This effectively reduces the complexity of the multi-branch tree, reduces the amount of processing required for the multi-branch tree, improves processing efficiency, and saves processing time.

[0146] 803. For each root node in a multi-way tree, in response to the root function corresponding to the root node satisfying the first objective condition, the server adds the root function to the core call queue.

[0147] Starting from the root node in the multi-branch tree, if the root function corresponding to the root node satisfies the first objective condition, i.e., the execution time of the root function is greater than the first preset duration, then the root function is added to the core call queue. This core call queue is used to store core functions in the function call stack. Then, step 804 is executed to process the child nodes of the root node.

[0148] In another embodiment, if the root function corresponding to the root node does not meet the first target condition, that is, the time taken by the root function is not greater than the first preset time, it means that the root function is not the cause of the stuttering frame, and the other functions called by the root function are not the cause of the stuttering frame. Therefore, the root node is filtered, and the child nodes of the root node are also filtered, thereby achieving the filtering of the root function corresponding to the root node and each function called by the root function.

[0149] 804. The server adds the non-root function corresponding to the target child node of the root node to the core call queue until the length of the core call queue reaches the preset length, or there is no target child node among the remaining child nodes of the root node. Based on the core call queue, the core call stack corresponding to the root node is determined.

[0150] Here, the target child node refers to the child node of the corresponding non-root function that satisfies the first target condition and the second target condition.

[0151] The preset length refers to the maximum length of the core call queue. The length of the core call queue refers to the number of core functions contained in the core call queue. The server requires that the length of the core call queue must not exceed the preset length. This ensures that the number of core functions identified for the same root function does not exceed the preset length, effectively limiting the number of core functions and avoiding stuttering caused by inaccurate positioning due to an excessive number of core functions.

[0152] Once the core call queue is determined, the core call stack can be determined based on the core call queue. That is, based on the core functions in the core call queue, information such as the execution time of the core function and the call relationships related to the core function can be obtained from the function call stack, thereby creating the core call stack.

[0153] Optionally, step 804 may include: in response to any non-root function corresponding to a child node of the root node satisfying the first target condition and the second target condition, the server adds the non-root function to the core call queue until the length of the core call queue reaches a preset length, or the non-root functions corresponding to the remaining child nodes of the root node do not satisfy at least one of the first target condition and the second target condition, and determines the core call stack corresponding to the root node based on the current core call queue.

[0154] In other words, if any non-root function corresponding to a child node of the root node satisfies the first and second objective conditions, then that non-root function is added to the core call queue. Then, the process continues to determine whether the non-root function corresponding to the next child node of the root node satisfies the first and second objective conditions. This continues until the core call queue reaches a preset length, or the remaining non-root functions corresponding to the child nodes of the root node fail to satisfy at least one of the first and second objective conditions.

[0155] Optionally, step 804 may include steps 8041 and 8042, and further include any one of steps 8043 and 8044:

[0156] 8041. Sort the multiple first child nodes in descending order of the execution time of the non-root functions corresponding to the multiple first child nodes.

[0157] The first child node refers to the child node directly connected to the root node. In other words, if the root node includes multiple first child nodes, they can be sorted in descending order of time taken.

[0158] 8042. According to the sorting of multiple first child nodes, traverse the branches to which the first child node belongs, and add the non-root function corresponding to the target child node in the currently traversed branch to the core call queue.

[0159] In a multi-branch tree, multiple first child nodes form multiple branches. Each branch can include one first child node and at least one child node of that first child node. The server first traverses to the branch to which the first child node belongs and adds the non-root function corresponding to the target child node in the currently traversed branch to the core call queue. If the length of the core call queue reaches the preset length, then step 8043 is executed. If the length of the core call queue does not reach the preset length, then the server continues to traverse other child nodes in the branch until all child nodes of the branch have been traversed, or until the target child node is no longer present among the remaining child nodes of the branch.

[0160] Optionally, step 8042 includes: in response to the non-root function corresponding to the first child node in the branch satisfying the first target condition and the second target condition, adding the non-root function corresponding to the first child node to the core call queue; if the length of the core call queue has not reached the preset length, in response to the non-root function corresponding to the next level child node of the first child node satisfying the first target condition and the second target condition, adding the next level child node to the core call queue, and so on, until the length of the core call queue reaches the preset length, or all child nodes of the branch have been traversed, or there is no target child node among the remaining child nodes of the branch.

[0161] For example, the next level child node of the first child node is called the second child node. If the first child node in the branch also includes multiple second child nodes, the multiple second child nodes are sorted in descending order of the execution time of the non-root functions corresponding to the multiple second child nodes. According to the sorting of the multiple second child nodes, the branch to which the first second child node belongs is traversed, and the non-root function corresponding to the target child node in the currently traversed branch is added to the core call queue. If the length of the core call queue reaches the preset length, then step 8043 is executed. If the length of the core call queue does not reach the preset length, then the other child nodes in the branch to which the second child node belongs are traversed until all child nodes in the branch have been traversed, or until there is no target child node among the remaining child nodes in the branch. Then, according to the sorting of the multiple second child nodes, the branch to which the next second child node belongs is traversed. Similarly, for each level of child nodes, a similar traversal method as the first or second child node described above can be used to determine the core call queue as quickly as possible.

[0162] It should be noted that this embodiment only uses multiple second child nodes corresponding to the same first child node as an example. In fact, the same steps can be used to process multiple child nodes at the next level for any child node in a multi-way tree. Since multiple child nodes at the next level for the same upper-level child node are arranged in descending order of their respective time consumption, the server will traverse the branches to which the child nodes belong in order of their sorting. Once a non-root function corresponding to a child node does not satisfy at least one of the first and second objective conditions, it indicates that other child nodes after that child node will also not satisfy at least one of the first and second objective conditions. Therefore, traversing the branches to which other child nodes after that child node belongs can be stopped without further processing of these branches. This effectively reduces the processing load and saves processing time.

[0163] 8043. When the length of the core call queue reaches the preset length, stop traversing the remaining child nodes in the branch and the remaining branches in the multi-branch tree, and determine the core call stack based on the core call queue.

[0164] 8044. If the length of the core call queue has not reached the preset length, and all child nodes of the branch have been traversed or there is no target child node among the remaining child nodes of the branch, traverse the branch to which the next first child node belongs according to the sorting of multiple first child nodes until the length of the core call queue reaches the preset length, or there is no target child node among the remaining child nodes of the root node, and determine the core call stack based on the core call queue.

[0165] After the branch to which the first child node belongs has been traversed, since the length of the core call queue has not yet reached the preset length, the branch to which the second child node belongs can continue to be traversed. The processing of the branch to which the second child node belongs is the same as the processing of the branch to which the first child node belongs in step 8042 above, and will not be repeated here.

[0166] Since the multiple first child nodes are arranged in descending order of their respective execution times, the server traverses the branches to which the first child nodes belong in sequence according to their order. If a non-root function corresponding to a first child node fails to satisfy at least one of the first and second objective conditions, it indicates that the other first child nodes following that first child node also fail to satisfy at least one of the first and second objective conditions. Therefore, traversing the branches to which the other first child nodes following that first child node belong can be stopped, without further processing of those branches. This effectively reduces the processing load and saves processing time.

[0167] See Figure 10 Assuming that root node A satisfies the first objective condition, and function A corresponding to root node A has been added to the core call queue, and root node A includes two first child nodes: B0 and B1, the execution time of B0 is greater than the execution time of B1, then the order of the two first child nodes is: B0 > B1.

[0168] First, iterate through the branches belonging to the first child node B0, checking if the function B0 corresponding to the first child node B0 satisfies the first and second objective conditions. If so, add function B0 to the core call queue. If the core call queue length has not yet reached the preset length, then check if the function C corresponding to the second child node C satisfies the first and second objective conditions. If so, add function C to the core call queue. Next, if the core call queue length has not yet reached the preset length, iterate through the branches belonging to the first child node B1, checking if the function B1 corresponding to the first child node B1 satisfies the first and second objective conditions. If so, add function B1 to the core call queue.

[0169] In addition, if the function B0 corresponding to the first child node B0 does not meet at least one of the first and second target conditions, not only will the function B0 not be added to the core call queue, but it will also not be necessary to traverse the branch to which the first child node B1 belongs, thus saving a lot of processing time.

[0170] It should be noted that steps 803-804 above are illustrated using the processing of a single root node as an example. However, in a multi-branch tree with multiple root nodes, the server determines one or more core call queues for each root node, and subsequently determines one or more core call stacks, with each core call stack corresponding to a root node.

[0171] Optionally, if the multi-way tree includes multiple root nodes, the root nodes are sorted in descending order of the execution time of their corresponding root functions. The tree is then traversed according to this sorting. If the root function of the currently traversed root node satisfies the first objective condition, it is added to the core call queue corresponding to that root node. The tree continues traversing the child nodes of that root node until the length of the core call queue corresponding to that root node reaches a preset length, or if the non-root functions corresponding to the remaining child nodes of that root node do not satisfy at least one of the first and second objective conditions. Then, based on the core call queue corresponding to that root node, the core call stack corresponding to that root node is determined. The tree then continues traversing the next root node. If the root function of the currently traversed root node does not satisfy the first objective condition, the traversal of the remaining root nodes in the multi-way tree is stopped.

[0172] For example, a multi-way tree has three root nodes. The root functions corresponding to these three root nodes are sorted in descending order of execution time, resulting in root node 1, root node 2, and root node 3. First, the process iterates to root node 1. Assuming the execution time of root function 1 is greater than a first preset time, root function 1 is added to the core call queue 1. Then, the child nodes of root node 1 are traversed, and child nodes satisfying the first and second target conditions are added to the core call queue 1. This continues until the length of the core call queue 1 reaches a preset length or the non-root functions corresponding to the remaining child nodes of root node 1 do not satisfy at least one of the first and second target conditions. At this point, the core call queue 1 is determined. Based on the core call queue 1 corresponding to root node 1, the core call stack 1 corresponding to root node 1 is generated. Next, the process iterates to root node 2. Assuming the execution time of root function 2 is not greater than the first preset time, the core call queue corresponding to root node 2 is not created, and the child nodes of root node 2 are not traversed. Furthermore, since the three root nodes are arranged in descending order of execution time, this indicates that the execution time of root function 3 corresponding to root node 3 is no greater than the first preset execution time. Therefore, it is not necessary to determine whether root function 3 corresponding to root node 3 satisfies the first objective condition, nor is it necessary to determine whether the child nodes of root node 3 satisfy the first and second objective conditions. Traversing root node 3 and its child nodes can then be stopped. Thus, for the three root nodes in the multi-branch tree, a core call stack is ultimately obtained, namely, core call stack 1 corresponding to root node 1.

[0173] Figure 11 This is a schematic diagram of an operation flow for determining the core call stack provided in an embodiment of this application. See also... Figure 11 The operation process includes:

[0174] 111. Determine whether the root function corresponding to the first root node in the multi-way tree satisfies the first objective condition. If yes, execute step 112; otherwise, take the next root node in the multi-way tree and repeat this operation process.

[0175] 112. Add the function corresponding to the current node to the core call queue and execute step 113.

[0176] 113. Determine if the length of the core call queue has reached the preset length. If yes, traverse the first child node of the current node and execute step 114. If no, generate the core call stack based on the core call queue and end.

[0177] 114. Determine whether the non-root function corresponding to the first child node satisfies the first objective condition. If yes, proceed to step 115. If no, traverse the next child node of the current node.

[0178] 115. Determine whether the non-root function corresponding to the first child node satisfies the second objective condition. If yes, execute step 112; otherwise, traverse the next child node of the current node.

[0179] 805. The server clusters at least two identified core call stacks to obtain clustering results, which include the number of occurrences of each core call stack.

[0180] In one possible implementation, the server groups core call stacks that contain at least two core call stacks with identical core functions into a cluster, and determines the number of core call stacks included in the cluster as the occurrence count of that core call stack.

[0181] In another possible implementation, the server groups core call stacks from at least two core call stacks that meet similarity criteria into a cluster, and determines the number of core call stacks included in that cluster as the frequency of occurrence of one of the core call stacks in that cluster. This one core call stack then serves as the representative of that cluster. Here, two core call stacks meeting the similarity criteria mean that the number of identical core functions in these two core call stacks is greater than a third preset number, or that the proportion of identical core functions in these two core call stacks to the total number of core functions in these two core call stacks is greater than a preset proportion.

[0182] 806. The server selects a first preset number of core call stacks from at least two core call stacks, in descending order of the frequency of each core call stack.

[0183] Selecting kernel call stacks in descending order of frequency ensures that the selected stacks appear more frequently than the unselected stacks, making them more likely to cause stuttering frames. This selection method effectively reduces the number of kernel call stacks, eliminates irrelevant information, and allows for more precise identification of the cause of stuttering.

[0184] 807. The server generates a stuttering report, which includes the selected core call stack and the clustering results of the core call stack.

[0185] For example, stuttering reports such as Figure 12As shown, the stuttering report displays three core call stacks in descending order of frequency, indicating that these three core call stacks are the most likely cause of application stuttering, while core call stacks not shown can be disregarded. It also provides download links for the function call stacks corresponding to each core call stack, along with the corresponding frame number, and details for each core call stack, including the duration, number of calls, function name, and depth of each function within the core call stack.

[0186] The stuttering handling scheme provided in this application embodiment records the function call stacks of stuttering frames during application execution. It retains the core functions in the function call stacks and filters out non-core functions to determine the corresponding core call stacks. Furthermore, it clusters at least two core call stacks and generates a stuttering report based on the clustering results. By filtering the function call stacks, invalid information is removed, improving the relevance of the core call stacks, reducing their complexity, and increasing processing efficiency. Moreover, stack clustering ensures that the stuttering report accurately reflects the cause of the application stuttering, improving the accuracy of the report. It also eliminates the need for users to analyze duplicate core call stacks separately, saving manpower costs.

[0187] Furthermore, the embodiments of this application convert the complex function call stack into a clear and intuitive multi-branch tree. By processing the multi-branch tree, the core functions can be accurately and quickly selected from the function call stack, while non-core functions are filtered out, which enhances the organization and improves processing efficiency and accuracy.

[0188] Furthermore, in the multi-branch tree, the first child nodes are sorted in descending order of the execution time of their corresponding non-root functions. Since the first child nodes are arranged in descending order of their execution time, the server traverses the branches to which the first child nodes belong in sequence according to this sorting. If a non-root function corresponding to a first child node does not satisfy at least one of the first and second objective conditions, it means that the other first child nodes following that first child node will also not satisfy at least one of the first and second objective conditions. Therefore, traversing the branches to which the other first child nodes following that first child node belong can be stopped without further processing of those branches. This effectively reduces the processing load and saves processing time.

[0189] Furthermore, since multiple child nodes of the same upper-level child node are arranged in descending order of their respective processing times, the server will traverse the branches to which the child nodes belong sequentially according to this order. If a non-root function corresponding to a child node fails to satisfy at least one of the first and second objective conditions, it indicates that other child nodes following that child node will also fail to satisfy at least one of the first and second objective conditions. Therefore, traversing the branches to which other child nodes following that child node belongs can be stopped without further processing of those branches. This effectively reduces processing load and saves processing time.

[0190] The above embodiments illustrate the server's processing procedure. The following embodiments will illustrate the processing procedure of the terminal running the application. Figure 13 This is a flowchart of a lag handling method provided in an embodiment of this application. This embodiment is executed by the terminal. See also... Figure 13 The method includes:

[0191] 1301. When the terminal determines that the frame running in the application is a stuttering frame, it obtains stuttering record information, which includes function call stacks. The function call stacks include the functions called during the execution of the frame and the duration of the functions. The stuttering frame is the frame in the application where stuttering occurs.

[0192] During the application's operation, if any frame experiences a stutter, that frame is identified as a stuttered frame, and stuttering log information is retrieved to record the specific circumstances of the stuttering. In addition to the function call stack, the stuttering log information may also include at least one of the following: preset task information, account information, application information, and device information. These information items are similar to those in step 201 and will not be repeated here.

[0193] Optionally, if a frame is determined to meet the stuttering conditions, it is identified as a stuttering frame. The stuttering conditions include: the frame's duration is greater than a third preset duration, and the frame's duration is greater than a preset multiple of the average duration of a second preset number of preceding frames. Therefore, after any frame in the application finishes running, based on the frame's duration and the duration of the second preset number of preceding frames, it is determined whether the frame is a stuttering frame. If the frame is determined to be a stuttering frame, stuttering recording information is obtained.

[0194] The first preset duration is used to indicate whether the function's duration is the cause of frame stuttering. That is, if the function's duration is longer than the first preset duration, it can be considered that the function's duration is too long and that the function may be the cause of frame stuttering. The third preset duration is used to indicate whether frame stuttering occurs. The third preset duration is longer than the first preset duration. For example, the first preset duration is 16 milliseconds and the third preset duration is 84 milliseconds.

[0195] The preceding frame is any other frame that precedes this frame. The preset multiplier is greater than 1. The second preset number can be any number set by the server. For example, if the second preset number is 3 and the preset multiplier is 2, then the frame will be identified as a stuttering frame if the frame's duration is greater than the third preset duration and the frame's duration is more than twice the average duration of the three frames preceding it.

[0196] Optionally, stub code is inserted into one or more functions in the application. This stub code is used to obtain information about the function. Therefore, when the function is run, the inserted stub code is executed, thereby obtaining relevant information about the function, including the function call stack, function execution time, or other information. For example, during the application generation process, stub code is inserted into one or more functions in the application. Afterward, the application is compiled to obtain an executable application, i.e., an application installer, and this installer is then released. Terminals that subsequently download this installer can install and run the application, and during execution, the relevant information about the function corresponding to the inserted stub code will be obtained.

[0197] See Figure 14 The stub code is an instance of the class `Pin`, and the instrumented function is the `Function` function. The `Pin` class is inserted at the entry point of the `Function` function. Therefore, when the `Function` function runs, the `Pin` class at the entry point is executed first. A unique function ID is recorded for the `Function` function, and the constructor of the `Pin` class is passed in. This constructor records the start time `t1` and the function ID of the `Function` function, and also increments the depth by 1. This depth represents the depth of the currently running function; the call relationship between functions can be determined based on the depths of different functions. Afterwards, when the `Function` function finishes running, the destructor of the `Pin` class is called, and the destructor records the end time `t2` of the `Function` function. Then, the frame number corresponding to the current frame, the recorded depth, the function ID, and the function's execution time `t2-t1` are used as cache data and recorded in the cache queue. Additionally, the depth is incremented by 1 to restore the state before the `Function` function ran. Finally, the cache queue is packaged and reported to the server.

[0198] Optionally, the application includes instructions for recording preset task information. These instructions are executed when the preset task is run within the application to record the preset task information. Additionally, the application also includes instructions for recording at least one of account information, application information, and device information. These instructions can be executed within the application to record at least one of these information. Lag log information can then be generated based on the recorded information.

[0199] 1302. The terminal reports the lag log information to the server.

[0200] After reporting the stuttering log information to the server, the server retrieves the stuttering log information, determines the core call stack corresponding to the function call stack, and the core call stack includes the core functions in the function call stack, the execution time of the core functions, and the call relationships between different core functions. The core functions are functions that satisfy a first objective condition, which is that the execution time of the function is greater than a first preset time. The server then clusters the at least two determined core call stacks to obtain clustering results, which include the frequency of occurrence of each type of core call stack. Based on the clustering results, a stuttering report for the application is generated. The server's processing procedure is the same as in the above embodiment and will not be repeated here.

[0201] The stuttering handling scheme provided in this application embodiment records the function call stacks of stuttering frames during application execution. It retains the core functions in the function call stacks and filters out non-core functions to determine the corresponding core call stacks. Furthermore, it clusters at least two core call stacks and generates a stuttering report based on the clustering results. By filtering the function call stacks, invalid information is removed, improving the relevance of the core call stacks, reducing their complexity, and increasing processing efficiency. Moreover, stack clustering ensures that the stuttering report accurately reflects the cause of the application stuttering, improving the accuracy of the report. It also eliminates the need for users to analyze duplicate core call stacks separately, saving manpower costs.

[0202] Based on the above embodiments, this application proposes a scheme for dynamic and controllable function instrumentation and stack clustering. In the application, function call stacks, account information, preset task information, application information, and device information are obtained through instrumentation. The function call stacks are analyzed in the server to find the core call stacks corresponding to the function call stacks. This clusters the same or similar core call stacks, filtering out a large number of duplicate and invalid function call stacks. This allows the server to restore the application's current state and the cause of the lag, so that users can fix the lag problems in the application.

[0203] Figure 15This is a schematic diagram of a stuttering processing device provided in an embodiment of this application. See also... Figure 15 The device includes:

[0204] The information acquisition module 1501 is used to acquire the stuttering record information reported by the application. The stuttering record information includes the function call stack of the stuttering frame. The stuttering frame is the frame in the application where stuttering occurs. The function call stack includes the functions called during the execution of the stuttering frame, the duration of the function, and the call relationship between different functions.

[0205] The core determination module 1502 is used to determine the core call stack corresponding to the function call stack. The core call stack includes the core function in the function call stack, the duration of the core function, and the call relationship between different core functions. The core function is a function that satisfies the first target condition, which is that the duration of the function is greater than the first preset duration.

[0206] Clustering module 1503 is used to cluster at least two identified core call stacks to obtain clustering results, which include the number of occurrences of each core call stack.

[0207] The report generation module 1504 is used to generate application lag reports based on clustering results.

[0208] In one possible implementation, the core functions include: a root function that satisfies the first objective condition, and a non-root function that satisfies the first objective condition and the second objective condition;

[0209] Here, a root function is a function that is not called by other functions, and a non-root function is a function that is called by other functions; the second objective condition is that the difference in execution time between a non-root function and its parent function is less than a preset difference, and the parent function of a non-root function is the function that calls the non-root function.

[0210] In one possible implementation, see [link to relevant documentation]. Figure 16 The core determination module 1502 includes:

[0211] The multi-branch tree generation unit 1512 is used to generate a multi-branch tree corresponding to the function call stack. Each node in the multi-branch tree corresponds to a function in the function call stack, and the node corresponding to any function is a child node of the node corresponding to another function that called the function.

[0212] The multi-branch tree processing unit 1522 is used to add the root function to the core call queue corresponding to the root node in response to the root function corresponding to the root node satisfying the first target condition; add the non-root function corresponding to the target child node of the root node to the core call queue until the length of the core call queue reaches the preset length, or there is no target child node among the remaining child nodes of the root node; and determine the core call stack corresponding to the root node based on the core call queue.

[0213] Here, the target child node refers to the child node of the corresponding non-root function that satisfies the first target condition and the second target condition.

[0214] In one possible implementation, the multi-branch tree processing unit 1522 is used for:

[0215] Sort the multiple first child nodes in descending order of the execution time of the non-root functions corresponding to the first child nodes; the first child node is the child node that is directly connected to the root node.

[0216] Based on the sorting of multiple first child nodes, traverse the branches to which the first child node belongs, and add the non-root function corresponding to the target child node in the currently traversed branch to the core call queue.

[0217] When the core call queue reaches the preset length, stop traversing the remaining child nodes in the branch and the remaining branches in the multi-branch tree, and determine the core call stack based on the core call queue.

[0218] Alternatively, if the core call queue length has not reached the preset length, and all child nodes of the branch have been traversed or there is no target child node among the remaining child nodes of the branch, the next branch to which the first child node belongs is traversed according to the sorting of multiple first child nodes until the core call queue length reaches the preset length, or there is no target child node among the remaining child nodes of the root node. Based on the core call queue, the core call stack is determined.

[0219] In one possible implementation, the multi-branch tree processing unit 1522 is used for:

[0220] In response to the non-root function corresponding to the first child node in the branch satisfying the first objective condition and the second objective condition, the non-root function corresponding to the first child node is added to the core call queue;

[0221] If the length of the core call queue has not reached the preset length, in response to the non-root function corresponding to the next level child node of the first child node satisfying the first target condition and the second target condition, the next level child node is added to the core call queue until the length of the core call queue reaches the preset length, or all child nodes of the branch have been traversed, or the target child node does not exist among the remaining child nodes of the branch.

[0222] In one possible implementation, see [link to relevant documentation]. Figure 16 The core determination module 1502 also includes:

[0223] The filtering module 1532 is used to filter the nodes corresponding to functions that meet the filtering conditions in the multi-branch tree after generating the multi-branch tree corresponding to the function call stack.

[0224] The filtering conditions include at least one of the following:

[0225] This function is a debugging function;

[0226] The function's execution time is less than the second preset time, and the second preset time is less than the first preset time;

[0227] The duration of the function is less than the product of the duration of its parent function and a preset ratio, where the preset ratio is less than 100%.

[0228] In one possible implementation, the report generation module 1504 is used to select a first preset number of core call stacks from at least two core call stacks in descending order of the frequency of each core call stack; and generate a stuttering report, which includes the selected core call stacks and the clustering results of the core call stacks.

[0229] In one possible implementation, the function call stack includes the function sequence number ID corresponding to the function, see [link to relevant documentation]. Figure 16 The device also includes:

[0230] The restoration module 1505 is used to restore the function ID corresponding to each function in each function call stack to the function name corresponding to each function based on the application's symbol table. The symbol table includes at least one function ID and the function name corresponding to each function ID.

[0231] In one possible implementation, a stuttering frame is a frame in the application that meets the stuttering conditions;

[0232] The stuttering conditions include: the frame's duration is greater than the third preset duration, and the frame's duration is greater than a preset multiple of the average duration of the second preset number of preceding frames;

[0233] Among them, the third preset duration is longer than the first preset duration, the preceding frame is another frame located before the first frame, and the preset multiple is greater than 1.

[0234] The stuttering handling scheme provided in this application embodiment records the function call stacks of stuttering frames during application execution. It retains the core functions in the function call stacks and filters out non-core functions to determine the corresponding core call stacks. Furthermore, it clusters at least two core call stacks and generates a stuttering report based on the clustering results. By filtering the function call stacks, invalid information is removed, improving the relevance of the core call stacks, reducing their complexity, and increasing processing efficiency. Moreover, stack clustering ensures that the stuttering report accurately reflects the cause of the application stuttering, improving the accuracy of the report. It also eliminates the need for users to analyze duplicate core call stacks separately, saving manpower costs.

[0235] Figure 17 This is a schematic diagram of a stuttering processing device provided in an embodiment of this application. See also... Figure 17 The device includes:

[0236] The information acquisition module 1701 is used to acquire stuttering record information when it is determined that the frame running in the application is a stuttering frame. The stuttering record information includes function call stack, which includes the functions called during the execution of the frame and the duration of the functions. The stuttering frame is the frame in the application where stuttering occurs.

[0237] The reporting module 1702 is used to report lag log information to the server;

[0238] The server is used to: obtain stuttering log information, determine the core call stack corresponding to the function call stack, the core call stack includes the core function in the function call stack, the duration of the core function, and the call relationship between different core functions, the core function is the function that satisfies the first objective condition, the first objective condition is that the duration of the function is greater than the first preset duration; cluster the at least two determined core call stacks to obtain the clustering results, the clustering results include the occurrence frequency of each core call stack; and generate a stuttering report for the application based on the clustering results.

[0239] The stuttering handling scheme provided in this application embodiment records the function call stacks of stuttering frames during application execution. It retains the core functions in the function call stacks and filters out non-core functions to determine the corresponding core call stacks. Furthermore, it clusters at least two core call stacks and generates a stuttering report based on the clustering results. By filtering the function call stacks, invalid information is removed, improving the relevance of the core call stacks, reducing their complexity, and increasing processing efficiency. Moreover, stack clustering ensures that the stuttering report accurately reflects the cause of the application stuttering, improving the accuracy of the report. It also eliminates the need for users to analyze duplicate core call stacks separately, saving manpower costs.

[0240] It should be noted that the lag processing device provided in the above embodiments is only an example of the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the computer device can be divided into different functional modules to complete all or part of the functions described above. In addition, the lag processing device and the lag processing method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0241] This application also provides a computer device, which includes a processor and a memory. The memory stores at least one computer program, which is loaded and executed by the processor to perform the operations performed in the lag handling method of the above embodiments.

[0242] Optionally, the computer device is provided as a terminal. Figure 18 A schematic diagram of the structure of a terminal 1800 provided in an exemplary embodiment of this application is shown.

[0243] Terminal 1800 includes a processor 1801 and a memory 1802.

[0244] Processor 1801 may include one or more processing cores, such as a quad-core processor, an octa-core processor, etc. Processor 1801 may be implemented using at least one hardware form selected from DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), and PLA (Programmable Logic Array). Processor 1801 may also include a main processor and a coprocessor. The main processor, also known as a CPU (Central Processing Unit), is used to process files in the active state; the coprocessor is a low-power processor used to process files in the standby state. In some embodiments, processor 1801 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content required to be displayed on the screen. In some embodiments, processor 1801 may also include an AI (Artificial Intelligence) processor, which is used to handle computational operations related to machine learning.

[0245] Memory 1802 may include one or more computer-readable storage media, which may be non-transitory. Memory 1802 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In some embodiments, the non-transitory computer-readable storage media in memory 1802 is used to store at least one computer program, which is used by processor 1801 to implement the stuttering processing method provided in the method embodiments of this application.

[0246] In some embodiments, the terminal 1800 may also optionally include: a peripheral device interface 1803 and at least one peripheral device. The processor 1801, memory 1802, and peripheral device interface 1803 can be connected via a bus or signal line. Each peripheral device can be connected to the peripheral device interface 1803 via a bus, signal line, or circuit board. Optionally, the peripheral device includes at least one of: a radio frequency circuit 1804, a display screen 1805, a camera assembly 1806, and a power supply 1807.

[0247] Peripheral device interface 1803 can be used to connect at least one I / O (Input / Output) related peripheral device to processor 1801 and memory 1802. In some embodiments, processor 1801, memory 1802 and peripheral device interface 1803 are integrated on the same chip or circuit board; in some other embodiments, any one or two of processor 1801, memory 1802 and peripheral device interface 1803 can be implemented on separate chips or circuit boards, which is not limited in this embodiment.

[0248] The radio frequency (RF) circuit 1804 is used to receive and transmit RF (Radio Frequency) signals, also known as electromagnetic signals. The RF circuit 1804 communicates with communication networks and other communication devices via electromagnetic signals. The RF circuit 1804 converts electrical signals into electromagnetic signals for transmission, or converts received electromagnetic signals back into electrical signals. Optionally, the RF circuit 1804 includes: an antenna system, an RF transceiver, one or more amplifiers, a tuner, an oscillator, a digital signal processor, a codec chipset, a user identity module card, etc. The RF circuit 1804 can communicate with other devices through at least one wireless communication protocol. This wireless communication protocol includes, but is not limited to: metropolitan area networks (MANs), various generations of mobile communication networks (2G, 3G, 4G, and 5G), wireless local area networks (WLANs), and / or WiFi (Wireless Fidelity) networks. In some embodiments, the RF circuit 1804 may also include circuitry related to NFC (Near Field Communication), which is not limited in this application.

[0249] Display screen 1805 is used to display a UI (User Interface). This UI may include graphics, text, icons, videos, and any combination thereof. When display screen 1805 is a touch display screen, it also has the ability to collect touch signals on or above its surface. These touch signals can be input as control signals to processor 1801 for processing. In this case, display screen 1805 can also be used to provide virtual buttons and / or a virtual keyboard, also known as soft buttons and / or a soft keyboard. In some embodiments, there may be one display screen 1805, disposed on the front panel of terminal 1800; in other embodiments, there may be at least two display screens, disposed on different surfaces of terminal 1800 or in a folded design; in still other embodiments, display screen 1805 may be a flexible display screen, disposed on a curved or folded surface of terminal 1800. Furthermore, display screen 1805 may also be configured as a non-rectangular, irregular shape, i.e., a non-rectangular screen. The display screen 1805 can be made of materials such as LCD (Liquid Crystal Display) and OLED (Organic Light-Emitting Diode).

[0250] The camera assembly 1806 is used to acquire images or videos. Optionally, the camera assembly 1806 includes a front-facing camera and a rear-facing camera. The front-facing camera is disposed on the front panel of the terminal 1800, and the rear-facing camera is disposed on the back of the terminal 1800. In some embodiments, there are at least two rear-facing cameras, which are any one of a main camera, a depth-sensing camera, a wide-angle camera, and a telephoto camera, to achieve background blurring by fusion of the main camera and the depth-sensing camera, panoramic shooting by fusion of the main camera and the wide-angle camera, VR (Virtual Reality) shooting, or other fusion shooting functions. In some embodiments, the camera assembly 1806 may also include a flash. The flash can be a single-color temperature flash or a dual-color temperature flash. A dual-color temperature flash refers to a combination of a warm light flash and a cool light flash, which can be used for light compensation at different color temperatures.

[0251] Power supply 1807 is used to power the various components in terminal 1800. Power supply 1807 can be AC ​​power, DC power, a disposable battery, or a rechargeable battery. When power supply 1807 includes a rechargeable battery, the rechargeable battery can support wired or wireless charging. The rechargeable battery can also be used to support fast charging technology.

[0252] Those skilled in the art will understand that Figure 18The structure shown does not constitute a limitation on terminal 1800 and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0253] Optionally, the computer device is provided as a server. Figure 19 This is a schematic diagram of a server structure provided in an embodiment of this application. The server 1900 can vary significantly depending on its configuration or accuracy. It may include one or more Central Processing Units (CPUs) 1901 and one or more memories 1902. The memories 1902 store at least one computer program, which is loaded and executed by the processor 1901 to implement the methods provided in the above-described method embodiments. Of course, the server may also have wired or wireless network interfaces, a keyboard, and input / output interfaces for input and output. The server may also include other components for implementing device functions, which will not be elaborated upon here.

[0254] This application also provides a computer-readable storage medium storing at least one computer program, which is loaded and executed by a processor to implement the operations performed by the stuttering processing method of the above embodiments.

[0255] This application also provides a computer program product, including a computer program loaded and executed by a processor to perform the operations performed by the stuttering handling method in the above embodiments.

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

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

Claims

1. A method for handling stuttering, characterized in that, The method includes: Obtain the stuttering log information reported by the application. The stuttering log information includes the function call stack of the stuttering frame. The stuttering frame is the frame in which stuttering occurs in the application. The function call stack includes the functions called during the execution of the stuttering frame, the duration of the function, and the call relationship between different functions. Determine the core call stack corresponding to the function call stack. The core call stack includes the core function in the function call stack, the execution time of the core function, and the call relationship between different core functions. The core function is a function that satisfies a first target condition, whereby the execution time of the function is greater than a first preset time. Clustering is performed on at least two of the identified core call stacks to obtain clustering results, the clustering results including the number of occurrences of each core call stack; Based on the clustering results, a lag report for the application is generated.

2. The method according to claim 1, characterized in that, The core functions include: root functions that satisfy the first objective condition, and non-root functions that satisfy the first objective condition and the second objective condition; Wherein, the root function refers to a function that is not called by other functions, and the non-root function refers to a function that is called by other functions; the second objective condition is that the difference in execution time between the non-root function and its parent function is less than a preset difference, and the parent function of the non-root function is the function that calls the non-root function.

3. The method according to claim 2, characterized in that, Determining the core call stack corresponding to the function call stack includes: Generate a multi-branch tree corresponding to the function call stack, where each node in the multi-branch tree corresponds to a function in the function call stack, and the node corresponding to any function is a child node of the node corresponding to another function that called the function; For each root node of the multi-way tree: In response to the root function corresponding to the root node satisfying the first target condition, the root function is added to the core call queue corresponding to the root node; Add the non-root function corresponding to the target child node of the root node to the core call queue until the length of the core call queue reaches the preset length, or the target child node does not exist among the remaining child nodes of the root node. Based on the core call queue, determine the core call stack corresponding to the root node. The target child node refers to the child node of the corresponding non-root function that satisfies the first target condition and the second target condition.

4. The method according to claim 3, characterized in that, The step of adding the non-root function corresponding to the target child node of the root node to the core call queue until the length of the core call queue reaches a preset length, or the target child node does not exist among the remaining child nodes of the root node, and determining the core call stack corresponding to the root node based on the core call queue, includes: The multiple first child nodes are sorted in descending order of the execution time of the non-root functions corresponding to the multiple first child nodes; the first child node refers to the child node directly connected to the root node. According to the sorting of the multiple first child nodes, traverse the branches to which the first child nodes belong, and add the non-root function corresponding to the target child node in the currently traversed branch to the core call queue; When the length of the core call queue reaches the preset length, stop traversing the remaining child nodes in the branch and the remaining branches in the multi-branch tree, and determine the core call stack based on the core call queue; Alternatively, if the length of the core call queue has not reached the preset length, and all child nodes of the branch have been traversed or the target child node is not found among the remaining child nodes of the branch, the branch to which the next first child node belongs is traversed according to the order of the plurality of first child nodes until the length of the core call queue reaches the preset length, or the target child node is not found among the remaining child nodes of the root node, and the core call stack is determined based on the core call queue.

5. The method according to claim 4, characterized in that, Adding the non-root function corresponding to the target child node in the currently traversed branch to the core call queue includes: In response to the non-root function corresponding to the first child node in the branch satisfying the first objective condition and the second objective condition, the non-root function corresponding to the first child node is added to the core call queue; If the length of the core call queue does not reach the preset length, in response to the non-root function corresponding to the next level child node of the first child node satisfying the first target condition and the second target condition, the next level child node is added to the core call queue until the length of the core call queue reaches the preset length, or all child nodes of the branch are traversed, or the target child node is not found among the remaining child nodes of the branch.

6. The method according to claim 3, characterized in that, The method further includes: After generating the multi-branch tree corresponding to the function call stack, the nodes corresponding to the functions that meet the filtering conditions in the multi-branch tree are filtered. The filtering conditions include at least one of the following: The function in question is a debugging function. The time taken by the function is less than the second preset time, and the second preset time is less than the first preset time; The time taken by the function is less than the product of the time taken by the parent function and a preset ratio, where the preset ratio is less than 100%.

7. The method according to claim 1, characterized in that, The step of generating a lag report for the application based on the clustering results includes: A first preset number of core call stacks are selected from at least two core call stacks in descending order of the frequency of occurrence of each type of core call stack. Generate the stuttering report, which includes the selected core call stack and the clustering results of the core call stack.

8. The method according to claim 1, characterized in that, The function call stack includes the function sequence number ID corresponding to the function. Before determining the core call stack corresponding to the function call stack, the method further includes: Based on the symbol table of the application, the function ID corresponding to each function in each function call stack is restored to the function name corresponding to each function. The symbol table includes at least one function ID and the function name corresponding to each function ID.

9. The method according to claim 1, characterized in that, The stuttering frame is a frame in the application that meets the stuttering conditions; The stuttering conditions include: the duration of the frame is greater than a third preset duration, and the duration of the frame is greater than a preset multiple of the average duration of the second preset number of preceding frames. Wherein, the third preset duration is longer than the first preset duration, the preceding frame is another frame located before the frame, and the preset multiple is greater than 1.

10. A method for handling stuttering, characterized in that, The method includes: If it is determined that the frame running in the application is a stuttering frame, stuttering record information is obtained. The stuttering record information includes function call stacks, which include the functions called during the execution of the frame and the duration of the functions. The stuttering frame is the frame in the application where stuttering occurs. Report the lag log information to the server; The server is configured to: acquire the stuttering record information; determine the core call stack corresponding to the function call stack, wherein the core call stack includes the core function in the function call stack, the duration of the core function, and the call relationship between different core functions, wherein the core function is a function that satisfies a first target condition, the first target condition being that the duration of the function is greater than a first preset duration; cluster the at least two determined core call stacks to obtain a clustering result, wherein the clustering result includes the number of occurrences of each core call stack; and generate a stuttering report for the application based on the clustering result.

11. A stuttering processing device, characterized in that, The device includes: The information acquisition module is used to acquire the stuttering record information reported by the application. The stuttering record information includes the function call stack of the stuttering frame. The stuttering frame is the frame in which stuttering occurs in the application. The function call stack includes the functions called during the execution of the stuttering frame, the duration of the function, and the call relationship between different functions. The core determination module is used to determine the core call stack corresponding to the function call stack. The core call stack includes the core function in the function call stack, the time consumption of the core function, and the call relationship between different core functions. The core function is a function that satisfies a first target condition, whereby the time consumption of the function is greater than a first preset time. A clustering module is used to cluster at least two identified core call stacks to obtain clustering results, the clustering results including the number of occurrences of each core call stack; The report generation module is used to generate a lag report for the application based on the clustering results.

12. A stuttering processing device, characterized in that, The device includes: The information acquisition module is used to record frame information corresponding to the currently running frame in the application. The frame information includes a function call stack, which includes the functions called during the execution of the stuttering frame and the duration of the functions. When it is determined that the frame running in the application is a stuttering frame, stuttering record information is acquired. The stuttering record information includes a function call stack, which includes the functions called during the execution of the frame and the duration of the functions. The stuttering frame is the frame in the application where stuttering occurs. The reporting module is used to report the lag record information to the server; The server is configured to: acquire the stuttering record information; determine the core call stack corresponding to the function call stack, wherein the core call stack includes the core function in the function call stack, the duration of the core function, and the call relationship between different core functions, wherein the core function is a function that satisfies a first target condition, the first target condition being that the duration of the function is greater than a first preset duration; cluster the at least two determined core call stacks to obtain a clustering result, wherein the clustering result includes the number of occurrences of each core call stack; and generate a stuttering report for the application based on the clustering result.

13. A computer device, characterized in that, The computer device includes a processor and a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to perform the operations performed by the stuttering processing method as described in any one of claims 1 to 9, or to perform the operations performed by the stuttering processing method as described in claim 10.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to implement the operations performed by the stuttering processing method as described in any one of claims 1 to 9, or to implement the operations performed by the stuttering processing method as described in claim 10.

15. A computer program product, comprising a computer program, characterized in that, The computer program is loaded and executed by a processor to perform the operations performed by the stuttering handling method as described in any one of claims 1 to 9, or to perform the operations performed by the stuttering handling method as described in claim 10.

Images