Application program lag monitoring method and device, equipment and storage medium

Abstract

Embodiments of the present disclosure provide an application program lag monitoring method and device, equipment and a storage medium. The application program lag is monitored according to a lag index. The lag index is used to indicate whether the application program lags. If the application program lags are monitored, tracking information is obtained. The tracking information is data collected at the moment when the application program lags. The tracking information is used to represent the function call time consumption in the application program and the function call time consumption in the operating system before the moment when the application program lags. The tracking information is uploaded to a server. Since the function call time consumption in the application program and the function call time consumption in the operating system are included in the tracking information obtained after the application program lags are monitored, compared with simple long time-consuming function call stack information, the data is more abundant, can better support subsequent positioning of the lag problem of the application program, and improve the accuracy of the lag problem positioning.

Description

Technical Field

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

[0002] Reducing software lag and improving smoothness is a crucial aspect of software optimization. Therefore, it's necessary to monitor application performance for lag and analyze the collected data to pinpoint lag issues.

[0003] In existing technologies, application lag monitoring solutions typically rely on the long-running function call stacks provided by the operating system to determine the cause of the application lag based on the obtained stack information.

[0004] However, application lag is influenced by many factors. In many scenarios, the obtained stack trace information alone is insufficient to accurately analyze the cause of lag, making it impossible to pinpoint the cause of application lag and affecting the smoothness of the application. Summary of the Invention

[0005] This disclosure provides an application lag monitoring method, apparatus, device, and storage medium to overcome the problem of being unable to locate the cause of application lag.

[0006] In a first aspect, embodiments of this disclosure provide a method for monitoring application lag, including:

[0007] Based on the lag index, the application is monitored for lag, wherein the lag index is used to indicate whether the application is lagging; if the application is lagging, the tracking information is obtained, wherein the tracking information is data collected at the moment the application lags, and the tracking information is used to characterize the function call time in the application and the function call time in the operating system before the application lags; the tracking information is uploaded to the server.

[0008] Secondly, embodiments of this disclosure provide an application lag monitoring device, comprising:

[0009] The monitoring unit is used to monitor the application for lag based on lag indicators, wherein the lag indicators are used to indicate whether the application is experiencing lag.

[0010] The acquisition unit is used to acquire tracking information if an application is detected to be lagging. The tracking information is data collected at the moment the application lags. The tracking information is used to characterize the function call time in the application and the function call time in the operating system before the application lags.

[0011] The transceiver unit is used to upload the tracking information to the server.

[0012] Thirdly, embodiments of this disclosure provide an electronic device, including: at least one processor and a memory;

[0013] The memory stores computer-executed instructions;

[0014] The at least one processor executes computer execution instructions stored in the memory, causing the at least one processor to perform the application lag monitoring method as described in the first aspect and various possible designs of the first aspect.

[0015] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the application lag monitoring method described in the first aspect and various possible designs of the first aspect.

[0016] The application lag monitoring method, apparatus, device, and storage medium provided in this embodiment monitor application lag based on lag indicators, wherein the lag indicators are used to indicate whether the application has lag occurred; if application lag is detected, tracking information is obtained, wherein the tracking information is data collected at the moment the application lag occurs, and the tracking information is used to characterize the function call time in the application and the function call time in the operating system before the application lag occurs; the tracking information is uploaded to the server. Because the tracking information obtained after detecting application lag includes the function call time in the application and the function call time in the operating system, it has a richer amount of information and more dimensions than simple long-duration function call stack information. Therefore, based on this tracking information, it can better support the subsequent localization of application lag problems, improve the accuracy of lag problem localization, and improve the effectiveness of application lag monitoring. Attached Figure Description

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

[0018] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of the present disclosure;

[0019] Figure 2 This is an example diagram illustrating a lag monitoring process in the prior art;

[0020] Figure 3 Flowchart of the application lag monitoring method provided in this embodiment of the disclosure Figure 1 ;

[0021] Figure 4 This is a schematic diagram illustrating the acquisition of tracking information according to an embodiment of the present disclosure;

[0022] Figure 5 Flowchart of the application lag monitoring method provided in this embodiment of the disclosure Figure 2 ;

[0023] Figure 6 for Figure 5 The flowchart of step S201 in the illustrated embodiment is shown.

[0024] Figure 7 This is a schematic diagram illustrating the message consumption time in the main thread message queue, provided as an embodiment of the present disclosure.

[0025] Figure 8 for Figure 5 The flowchart of step S203 in the illustrated embodiment is shown.

[0026] Figure 9 A structural block diagram of the application lag monitoring device provided in this embodiment of the disclosure;

[0027] Figure 10 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0029] First, let me explain the terms used in this application:

[0030] Trace information, also known as tracking information, is information that the operating system uses to trace the process corresponding to the exception that occurred when an application encountered an error. This information records the process's stack trace and some virtual machine state information at the time of the exception. The operating system saves this trace information, forming a trace file. For example, the traces.txt file in the Android system records relevant information about the current process when an application experiences an Application Not Responding (ANR) event. Based on the trace information recorded in the trace file, it is possible to analyze and locate application stuttering issues, thereby optimizing the application's smoothness.

[0031] The application scenarios of the embodiments of this disclosure are explained below:

[0032] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of the present disclosure, with reference to... Figure 1 As shown, the application lag data acquisition method provided in this disclosure can be applied to terminal devices, such as smartphones. An application (APP) client is installed and running on the terminal device. To improve the smoothness of the application's operation and provide a better user experience, a server connected to the application client monitors lag on the client and collects lag data uploaded by the client to record lag occurrences. Specifically, for example, the application client can upload lag data to the server periodically according to preset schedule information, or it can upload lag data to the server after detecting lag or according to received instructions. The application developer analyzes the lag data on the server to pinpoint the cause of the lag, thereby optimizing the application, reducing lag, and improving the smoothness of the application's operation.

[0033] Figure 2 This is an example diagram illustrating a stuttering monitoring process in existing technology. (Reference) Figure 2In existing technologies, solutions for monitoring application lag primarily involve monitoring long-running methods and functions within the application and reporting corresponding stack traces. This allows for lag detection, followed by stack aggregation to attribute the lag issue and pinpoint its location. However, many factors contribute to application lag, including not only the functions themselves but also the CPU, memory, and I / O interfaces. These factors can all increase function execution time and cause lag. Relying solely on stack traces only reveals the immediate situation of the lag but fails to pinpoint the true cause.

[0034] This disclosure provides a method for monitoring application lag to solve the above-mentioned problems.

[0035] Figure 3 Flowchart of the application lag monitoring method provided in this embodiment of the disclosure Figure 1 ,refer to Figure 3 The method in this embodiment can be applied to terminal devices, such as smartphones. The application lag monitoring method includes:

[0036] S101, based on the lag indicators, monitor the application for lag, whereby the lag indicators are used to indicate whether the application is experiencing lag.

[0037] For example, stuttering metrics are information used to determine whether an application is stuttering. Specifically, these could include the time taken for an application to call a function during runtime, or the message latency of the application. If the time taken for an application to call a function exceeds a preset threshold, the application is considered to be stuttering. Another example is the number of times an application stutters while calling a function during runtime; if the number of times an application stutters while calling a function exceeds a preset threshold, the application is considered to be stuttering. Furthermore, stuttering metrics can be implemented in other forms depending on specific needs, such as the number of dropped frames, frame rate information, etc., which will not be listed here.

[0038] S102, if an application freeze is detected, obtain tracing information.

[0039] Among them, the trace information is the data collected at the moment when the application freezes. The trace information is used to characterize the time spent on function calls in the application and the time spent on function calls in the operating system before the application freezes.

[0040] Specifically, when an application lag is detected, it's necessary to acquire as much data as possible related to the lag to support subsequent troubleshooting. For example, the time spent causing the application lag includes two parts: function call time and operating system function call time. Function call time is the time consumed during the execution of functions within the application itself, such as app-level function time. Operating system function call time is the time consumed during system-related data reading, writing, and information processing processes during application execution. For example, the time consumed during system-level Application Programming Interface (API) calls. By monitoring application lag and determining the moment of lag, and then acquiring trace information related to application time consumption before the lag occurred, data recording the cause of the application lag can be collected. Optionally, the trace information may also include information characterizing hardware operating parameters when the terminal device is running the application. Examples include CPU operating status information, Graphics Processing Unit (GPU) operating status information, and I / O operating status information. For example, the tracking information is pre-collected by the terminal device and cached in a preset cache area. By reading the data in the cache area, the tracking information at the corresponding time can be obtained.

[0041] Figure 4 This disclosure provides a schematic diagram of obtaining tracking information, such as... Figure 4 As shown, after detecting application lag, the terminal device obtains the memory tracing (mtrace) information cached in the cache to record the time consumption of APP-level functions, the system statistics (atrace) tracing information to record the time consumption of system-level APIs, and the corresponding terminal device running status information, such as CPU running status information, memory running status information, I / O running status information, and GPU running status information, and stores the above information as tracing information.

[0042] S103, upload the tracking information to the server.

[0043] For example, after obtaining the tracking information, the tracking information is stored as a tracking file in a corresponding preset format, such as a JavaScript Object Notation (JSON) file, and the tracking file in the preset format is uploaded to the server to complete the application lag monitoring and data collection process, so that the application developers can analyze the tracking file and locate the application lag problem.

[0044] In one possible implementation, the terminal device can upload the tracking information to the server periodically, such as daily or weekly, based on preset configuration parameters. Alternatively, the terminal device can upload the corresponding tracking information to the server after determining that the application is experiencing lag.

[0045] In another possible implementation, after receiving the upload instruction, the terminal device sends the tracking information to the server. The upload instruction can be input directly by the user to the terminal device, generated by the application according to preset rules, or sent by the server to the terminal device. No specific limitation is made here.

[0046] In this embodiment, application lag is monitored based on lag indicators, which indicate whether the application is experiencing lag. If lag is detected, trace information is obtained. This trace information is data collected at the moment the application lags, representing the time spent on function calls within the application and the time spent on function calls in the operating system before the lag occurs. Uploading the trace information to the server is beneficial because the trace information obtained after detecting application lag includes both the time spent on function calls within the application and the time spent on function calls in the operating system. Compared to simple long-running function call stack information, this information is richer in content and dimensions. Therefore, based on this trace information, it is possible to better support the subsequent localization of application lag issues, improve the accuracy of lag problem localization, and enhance the effectiveness of application lag monitoring.

[0047] Figure 5 Flowchart of the application lag monitoring method provided in this embodiment of the disclosure Figure 2 The application lag monitoring method provided in this embodiment, in Figure 3 Based on the illustrated embodiment, steps S101 and S102 are further refined, and a step of generating a tracking file from the tracking information is added, see reference. Figure 5 The following explanation, based on the Android operating system, outlines methods for detecting application lag:

[0048] Step S201: Count the message consumption time in the main thread message queue. If the message consumption time is greater than the preset time threshold, it is determined that the application is stuck.

[0049] Specifically, a message queue (MQ) is an application-to-application communication method and a typical representative of the consumer-producer model. Messages in the message queue are processed sequentially by the main thread, generating corresponding message latency. The longer the message latency, the more severe the lag. Therefore, based on a preset latency threshold, if the message latency exceeds this threshold, the application is considered to be experiencing lag.

[0050] For example, such as Figure 6 As shown, step S201, which involves calculating the message consumption time in the main thread's message queue, includes two specific implementation steps: S2011 and S2012.

[0051] Step S2011: Using a pre-defined print function in the message pump, print a start label and an end label at the beginning and end of each message in the main thread message queue.

[0052] Step S2012: Determine the message duration based on the interval between the start tag and the end tag.

[0053] Figure 7 This is a schematic diagram illustrating the message consumption time in the main thread message queue, provided by an embodiment of this disclosure. Figure 7 As shown, the Printer function of the message pump (Looper) prints a tag before and after message dispatch, including a start tag and an end tag. The message duration is determined based on the time interval between the start and end tags.

[0054] In one possible implementation, the stuttering metric also includes the number of stutters to determine if the application has stuttered, including:

[0055] The number of times a message takes longer than a preset time threshold within a preset time range is used to determine the number of times the application freezes; if the number of freezes exceeds a preset threshold, then the application is confirmed to have frozen.

[0056] More specifically, for example, based on the message consumption time in the message queue, if within a preset duration range (e.g., 1 minute), the number of times a message consumption time greater than a preset duration threshold (e.g., 500 milliseconds) occurs exceeds a number threshold (e.g., 3 times), then it is determined that the application is experiencing a lag.

[0057] In this embodiment, by using preset duration and frequency thresholds, the lag judgment conditions can be precisely controlled, which can reduce the missed and false judgments of application lag problems and improve the accuracy of lag judgment.

[0058] In one possible implementation, the stuttering metric also includes the number of dropped frames. Based on the stuttering metric, the application is monitored for stuttering, including: determining the frame drop rate based on the display message queue when the terminal device runs the application; if the frame drop rate is greater than a preset frame drop threshold, it is determined that the application is stuttering.

[0059] The frame rate (FPS) of an application is a crucial indicator of whether the application runs smoothly. A high number of dropped frames during application execution indicates lag. Specifically, determining the frame drop rate based on the display message queue of the terminal device running the application involves: counting the latency of MSG_DO_SCHEDULE_VSYNC messages in the message queue, and calculating the difference between the timestamps of the subsequent and previous frames, compared to the time of the previous frame (e.g., 16.67 milliseconds) to obtain the number of dropped frames. Furthermore, for example, if the number of dropped frames is greater than 0, then the application is considered to be lagging. The methods for obtaining the frame rate and the number of dropped frames can be implemented using the Choregrapher class in the Android system, which will not be elaborated upon here.

[0060] Step S202: After determining that the application is stuck, obtain the first tracking information and the second tracking information.

[0061] The first trace information is used to characterize the function execution time of the application; the second trace information is used to characterize the execution time of Android system interface functions. Specifically, obtaining the first and second trace information can include: reading the first and second trace information corresponding to the application stuttering from a preset cache. For example, the preset cache is a ring buffer.

[0062] Optionally, the tracking information also includes third tracking information. In this embodiment, it further includes: acquiring the third tracking information. The third tracking information is used to characterize the hardware operating parameters of the terminal device when running the application. The hardware operating parameters include at least one of the following: CPU operating status information; Graphics Processing Unit (GPU) operating status information; I / O operating status information. For example, after step S202, it further includes: reading the third tracking information corresponding to the application stuttering from a preset cache. In this embodiment, when the application stutters, in some cases, the stuttering phenomenon is caused by the hardware of the terminal device. Therefore, by acquiring the third tracking information characterizing the hardware operating parameters, the content of the tracking information can be further enriched, providing support for locating the cause of the stuttering, so as to achieve more accurate location of the cause of the stuttering.

[0063] Furthermore, exemplarily, the terminal device has a preset cache area. After initializing the cache area, a first tracking information is recorded in real time within the cache area using a memory tracing function (mtrace function); a second tracking information is recorded in real time within the cache area using a system statistics function (atrace function). The memory tracing function and the system statistics function are functionalities in the Android system used to obtain time-consuming information related to applications and operating system APIs; they will not be described in detail here.

[0064] Step S203: The first trace information, the second trace information, and the third trace information are cached in user space through an asynchronous thread to a preset location to generate a trace file, wherein the trace file is used to perform stuttering analysis on the application.

[0065] For example, the first tracking information, the second tracking information, and the third tracking information are all implementations of tracking information, and the tracking information may include one or more of the first tracking information, the second tracking information, and the third tracking information.

[0066] For example, such as Figure 8 As shown, step S203 includes the following three specific implementation steps:

[0067] S2031 intercepts application cache operations, where cache operations are used to characterize the application storing trace information by executing kernel code.

[0068] Specifically, trace information, which stores the stack trace at the moment of the exception when an application encounters an error, is cached as a trace file in existing technologies by switching to kernel mode and executing kernel code to write the trace information to a preset file, trace_mark_fd, thus generating the trace file. In this embodiment, the caching operation is intercepted during the application's process of saving the trace information to the trace file. That is, instead of switching to kernel mode, the trace information is saved in a preset location in user mode. More specifically, this process can be achieved by intercepting the input data of the write function using a hook function, thereby avoiding switching to kernel mode to process the trace information.

[0069] S2032 sends the tracking information to the preset user-mode buffer via an asynchronous thread.

[0070] Furthermore, after intercepting the tracking information, it is sent to a preset user-mode buffer. This process can be implemented in user mode without switching to kernel mode. For example, the terminal device has a ring buffer. The intercepted tracking information is first sent to the ring buffer, and different tracking information is written to the ring buffer sequentially until the buffered data reaches a preset level. Then, the data in the ring buffer is sent as a whole. Since this process always runs in user mode, it avoids frequent calls to kernel threads, reducing the waste of kernel resources.

[0071] Furthermore, once the tracking information cached in the ring buffer reaches a preset data volume, the data in the ring buffer is sent to the user-mode buffer for caching via an asynchronous thread. For example, the user-mode buffer is implemented using the ofstream class in the Android system.

[0072] For example, before sending the data to the preset user-mode buffer via an asynchronous thread, the method further includes: acquiring input / output interface information and lock information. The input / output interface information is used to characterize the thread's input / output state to the trace marker description file, where the trace marker description file is the trace_marker_fd file in the Android system; the lock information is used to characterize the thread's holding state of the trace marker description file. For example, the method also includes: acquiring trace information in a sleep state, where the trace information in a sleep state refers to trace information caused by I / O latency, Binder latency, etc., that are not present in atrace, resulting in the thread being in a Sleep (Sleep or Uninterruptible Sleep) state.

[0073] Accordingly, I / O interface information, lock information, and trace information in a sleep state are sent to the user-space buffer via an asynchronous thread. In this embodiment, by acquiring I / O interface information, lock information, and trace information in a sleep state, the trace information used to locate application lag issues is further enriched, resulting in a generated trace file containing more information indicating lag problems and improving data effectiveness.

[0074] S2033, when it is determined that the amount of data written to the user-mode buffer is greater than or equal to the preset buffer threshold, the data in the user-mode buffer is written to the preset location to generate a trace file.

[0075] For example, when the amount of data written to the user-mode cache is greater than or equal to a preset cache threshold, such as 90% of the maximum write amount of the cache, the data in the user-mode cache is saved in a preset local storage location. At this time, the write function needs to be called to generate the corresponding trace file.

[0076] In existing technologies, by switching to kernel mode and executing kernel code to write a preset file `trace_mark_fd`, during the process of generating a trace file, when multiple threads perform I / O read / write operations on the regular file describing the attributes of `trace_mark_fd`, they all hold a placeholder lock for that regular file, namely the `f_pos_lock`. This position lock is used to ensure the order in which threads write trace information. Under conditions such as low memory, the latency of I / O read / write operations is high. This means that if one thread cannot complete the corresponding I / O read / write operation in time, other threads must wait. Therefore, if, for example, the user interface (UI) thread also needs to operate on the same file, contention for the `f_pos_lock` will occur, leading to program lag. Figure 9 This is a schematic diagram illustrating the implementation process of step S203 in an embodiment of this disclosure. (Refer to...) Figure 9 In this application, the application intercepts the writing of trace information to trace_mark_fd and caches the trace information in the ringbuffer. The trace information is then written to the user-space buffer through the ringbuffer, thereby generating a separate trace file, i.e., stutter data. This reduces the time spent on the write operation, improves the efficiency of the system in processing trace information, and reduces application stuttering.

[0077] Step S204: Upload the tracking file to the server.

[0078] In this embodiment, the method of uploading the tracking file to the server in step S204 is the same as the method of uploading the tracking information to the server in step S103 in the above embodiment. For a detailed discussion, please refer to the discussion of step S103, which will not be repeated here.

[0079] Corresponding to the application lag monitoring method in the above embodiment, Figure 9 This is a structural block diagram of an application lag monitoring device provided in an embodiment of this disclosure. For ease of explanation, only the parts relevant to the embodiments of this disclosure are shown. (Refer to...) Figure 9 The application lag monitoring device 3 includes:

[0080] The monitoring unit 31 is used to monitor the application for lag based on lag indicators, wherein the lag indicators are used to indicate whether the application is experiencing lag.

[0081] The acquisition unit 32 is used to acquire trace information if an application freeze is detected. The trace information is data collected at the moment the application freezes. The trace information is used to characterize the function call time in the application and the function call time in the operating system before the application freezes.

[0082] The transceiver unit 33 is used to upload tracking information to the server.

[0083] In one embodiment of this disclosure, the stuttering metric includes message latency. The monitoring unit 31 is specifically used to: count the message latency in the main thread message queue; if the message latency is greater than a preset duration threshold, then it is determined that the application is stuttering.

[0084] In one embodiment of this disclosure, when the monitoring unit 31 is calculating the message consumption time in the main thread message queue, it is specifically used to: print a start tag and an end tag at the beginning and end of each message in the main thread message queue by using a pre-set print function in the message pump; and determine the message consumption time based on the interval between the start tag and the end tag.

[0085] In one embodiment of this disclosure, the lag indicator also includes the number of lags. When the monitoring unit 31 determines that the application has lag if the message consumption time is greater than a preset duration threshold, it is specifically used to: determine the number of lags based on the number of times the message consumption time is greater than the preset duration threshold within a preset duration range; if the number of lags is greater than a preset number threshold, it is determined that the application has lag.

[0086] In one embodiment of this disclosure, the stuttering indicator includes the number of dropped frames. The monitoring unit 31 is specifically used to: determine the frame drop rate based on the display message queue when the terminal device runs the application; if the frame drop rate is greater than a preset frame drop threshold, then determine that the application is stuttering.

[0087] In one embodiment of this disclosure, the application lag monitoring device further includes:

[0088] The caching unit 34 is used to cache the tracing information in user space to a preset location via an asynchronous thread to generate a tracing file, which is used for application stuttering analysis; the transceiver unit 33 is specifically used to upload the tracing file to the server.

[0089] In one embodiment of this disclosure, when caching the tracing information in user space to a preset location via an asynchronous thread to generate a tracing file, the caching unit 34 is specifically used to: intercept the application's caching operation, wherein the caching operation is used to characterize the application storing tracing information by executing kernel code; send the tracing information to a preset user-space cache via an asynchronous thread; and when it is determined that the amount of data written to the user-space cache is greater than or equal to a preset cache threshold, write the data in the user-space cache to the preset location to generate a tracing file.

[0090] In one embodiment of this disclosure, when the cache unit 34 intercepts the operation of an application storing trace information by executing kernel code, it is specifically used to: intercept the trace information written by the application to the tracer identifier description file by a hook function preset at the write system call location, and write the trace information to the ring memory cache; when the cache unit 34 sends the trace information to the preset user-mode cache through an asynchronous thread, it is specifically used to: write the trace information in the ring memory cache to the user-mode cache through an asynchronous thread.

[0091] In one embodiment of this disclosure, the tracking information includes first tracking information and second tracking information, wherein the first tracking information is used to characterize the function consumption time of the application; the second tracking information is used to characterize the function consumption time of the Android system interface; when acquiring the tracking information, the acquisition unit 32 is specifically used to: read the first tracking information and the second tracking information corresponding to the application stuttering from a preset cache area.

[0092] In one embodiment of this disclosure, the tracking information further includes third tracking information, which is used to characterize the hardware operating parameters of the terminal device when running the application. The hardware operating parameters include at least one of the following: central processing unit operating status information; image processor operating status information; and input / output interface operating status information.

[0093] The acquisition unit 32 is also used to: read the third tracking information corresponding to the application stuttering from the preset cache.

[0094] In one embodiment of this disclosure, the acquisition unit 32 is further configured to: initialize a cache area and record first tracking information in the cache area in real time using a memory tracking function; and record second tracking information in the cache area in real time using a system statistics function.

[0095] In one embodiment of this disclosure, when uploading tracking information to the server, the transceiver unit 33 is specifically used to: format the tracking information to generate a monitoring data file in JSON format; and upload the monitoring data file to the server.

[0096] The device provided in this embodiment can be used to execute the technical solutions of the above method embodiments. Its implementation principle and technical effect are similar, and will not be described again here.

[0097] refer to Figure 10 The diagram illustrates a structural schematic of an electronic device 900 suitable for implementing embodiments of the present disclosure. The electronic device 900 can be a terminal device or a server. The terminal device can include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, personal digital assistants (PDAs), portable Android devices (PADs), portable media players (PMPs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 10 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0098] like Figure 10 As shown, the electronic device 900 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 901, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 902 or a program loaded from a storage device 908 into a random access memory (RAM) 903. The RAM 903 also stores various programs and data required for the operation of the electronic device 900. The processing unit 901, ROM 902, and RAM 903 are interconnected via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0099] Typically, the following devices can be connected to I / O interface 905: input devices 906 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 907 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 908 including, for example, magnetic tapes, hard disks, etc.; and communication devices 909. Communication device 909 allows electronic device 900 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 10 An electronic device 900 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0100] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 909, or installed from a storage device 908, or installed from a ROM 902. When the computer program is executed by a processing device 901, it performs the functions defined in the methods of embodiments of this disclosure.

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

[0102] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0103] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods shown in the above embodiments.

[0104] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0105] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0106] The units described in the embodiments of this disclosure can be implemented in software or in hardware. The name of a unit does not necessarily limit the unit itself; for example, the first acquisition unit can also be described as "a unit that acquires at least two Internet Protocol addresses".

[0107] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

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

[0109] In a first aspect, according to one or more embodiments of this disclosure, an application lag monitoring method is provided, comprising: monitoring the application for lag based on lag indicators, wherein the lag indicators are used to indicate whether the application lags; if the application lags, acquiring tracking information, wherein the tracking information is data collected at the moment the application lags, and the tracking information is used to characterize the function call time in the application and the function call time in the operating system before the moment the application lags; and uploading the tracking information to a server.

[0110] According to one or more embodiments of this disclosure, the stuttering metric includes message latency. Based on the stuttering metric, the application is monitored for stuttering, including: counting the message latency in the main thread message queue; if the message latency is greater than a preset duration threshold, it is determined that the application is stuttering.

[0111] According to one or more embodiments of this disclosure, the message consumption time in the main thread message queue is calculated by: printing a start tag and an end tag at the beginning and end of each message in the main thread message queue using a pre-set print function in the message pump; and determining the message consumption time based on the interval between the start tag and the end tag.

[0112] According to one or more embodiments of this disclosure, the lag indicator also includes the number of lags. If the message consumption time is greater than a preset duration threshold, it is determined that the application has lag, including: determining the number of lags based on the number of times the message consumption time is greater than the preset duration threshold within a preset duration range; if the number of lags is greater than a preset number threshold, it is determined that the application has lag.

[0113] According to one or more embodiments of this disclosure, the stuttering metric includes the number of dropped frames. Based on the stuttering metric, stuttering monitoring of the application includes: determining the frame drop rate based on the display message queue when the terminal device runs the application; if the frame drop rate is greater than a preset frame drop threshold, it is determined that the application is stuttering.

[0114] According to one or more embodiments of this disclosure, the method further includes: caching the tracking information in user space via an asynchronous thread to a preset location to generate a tracking file, wherein the tracking file is used for application stuttering analysis; and uploading the tracking information to a server, including: uploading the tracking file to the server.

[0115] According to one or more embodiments of this disclosure, caching trace information in user space via an asynchronous thread to a preset location to generate a trace file includes: intercepting the application's caching operation, wherein the caching operation is used to characterize the application storing trace information by executing kernel code; sending the trace information to a preset user-space cache via an asynchronous thread; and when it is determined that the amount of data written to the user-space cache is greater than or equal to a preset cache threshold, writing the data in the user-space cache to the preset location to generate a trace file.

[0116] According to one or more embodiments of this disclosure, intercepting an application's operation of storing trace information by executing kernel code includes: intercepting the trace information written by the application to a tracer description file by a hook function preset at the write system call location, and writing the trace information to a circular memory buffer; sending the trace information to a preset user-mode buffer via an asynchronous thread includes: writing the trace information in the circular memory buffer to the user-mode buffer via an asynchronous thread.

[0117] According to one or more embodiments of this disclosure, the tracking information includes first tracking information and second tracking information, wherein the first tracking information is used to characterize the function consumption time of the application; the second tracking information is used to characterize the function consumption time of the Android system interface; obtaining the tracking information includes: reading the first tracking information and the second tracking information corresponding to the application stuttering from a preset cache.

[0118] According to one or more embodiments of this disclosure, the tracking information further includes third tracking information, which characterizes the hardware operating parameters of the terminal device when running an application. The hardware operating parameters include at least one of the following: central processing unit (CPU) operating status information; image processor (GPU) operating status information; and input / output interface (I / O) operating status information. The method further includes: reading the third tracking information corresponding to when the application experiences a lag from a preset cache.

[0119] According to one or more embodiments of this disclosure, the method further includes: initializing a cache and recording first tracking information in the cache in real time using a memory tracking function; and recording second tracking information in the cache in real time using a system statistics function.

[0120] According to one or more embodiments of this disclosure, uploading tracking information to a server includes: formatting the tracking information to generate a monitoring data file in JSON format; and uploading the monitoring data file to the server.

[0121] Secondly, according to one or more embodiments of this disclosure, an application lag monitoring device is provided, comprising:

[0122] The monitoring unit is used to monitor application lag based on lag indicators, which indicate whether the application is experiencing lag.

[0123] The acquisition unit is used to acquire trace information if an application freeze is detected. The trace information is data collected at the moment the application freezes. The trace information is used to characterize the function call time in the application and the function call time in the operating system before the application freezes.

[0124] The transceiver unit is used to upload tracking information to the server.

[0125] According to one or more embodiments of this disclosure, the stuttering metric includes message latency. The monitoring unit is specifically used to: count the message latency in the main thread message queue; if the message latency is greater than a preset duration threshold, then it is determined that the application is stuttering.

[0126] According to one or more embodiments of this disclosure, when the monitoring unit is calculating the message consumption time in the main thread message queue, it is specifically used to: print a start tag and an end tag at the beginning and end of each message in the main thread message queue by using a pre-set print function in the message pump; and determine the message consumption time based on the interval between the start tag and the end tag.

[0127] According to one or more embodiments of this disclosure, the lag indicator also includes the number of lags. When the monitoring unit determines that the application has lags if the message consumption time is greater than a preset duration threshold, it is specifically used to: determine the number of lags based on the number of times the message consumption time is greater than the preset duration threshold within a preset duration range; if the number of lags is greater than a preset number threshold, it is determined that the application has lags.

[0128] According to one or more embodiments of this disclosure, the stuttering indicator includes the number of dropped frames. The monitoring unit is specifically used to: determine the frame drop rate based on the display message queue when the terminal device is running the application; if the frame drop rate is greater than a preset frame drop threshold, then determine that the application is stuttering.

[0129] According to one or more embodiments of this disclosure, the application stuttering monitoring device further includes: a caching unit, used to cache tracking information in user mode via an asynchronous thread to a preset location to generate a tracking file, wherein the tracking file is used for stuttering analysis of the application; and a transceiver unit, specifically used to upload the tracking file to a server.

[0130] According to one or more embodiments of this disclosure, when the caching unit caches the trace information in user space to a preset location via an asynchronous thread to generate a trace file, it is specifically configured to: intercept the application's caching operation, wherein the caching operation is used to characterize the application storing trace information by executing kernel code; send the trace information to a preset user-space cache via an asynchronous thread; and when it is determined that the amount of data written to the user-space cache is greater than or equal to a preset cache threshold, write the data in the user-space cache to the preset location to generate a trace file.

[0131] According to one or more embodiments of this disclosure, when the caching unit intercepts the operation of an application storing trace information by executing kernel code, it is specifically configured to: intercept the trace information written by the application to the tracer identifier description file by a hook function preset at the write system call location, and write the trace information to the circular memory cache; when the caching unit sends the trace information to a preset user-mode cache through an asynchronous thread, it is specifically configured to: write the trace information in the circular memory cache to the user-mode cache through an asynchronous thread.

[0132] According to one or more embodiments of this disclosure, the tracking information includes first tracking information and second tracking information, wherein the first tracking information is used to characterize the function consumption time of the application; the second tracking information is used to characterize the function consumption time of the Android system interface; when the acquisition unit acquires the tracking information, it is specifically used to: read the first tracking information and the second tracking information corresponding to the application stuttering from a preset cache area.

[0133] According to one or more embodiments of this disclosure, the tracking information further includes third tracking information, which characterizes the hardware operating parameters of the terminal device when running an application. The hardware operating parameters include at least one of the following: central processing unit operating status information; image processor operating status information; and input / output interface operating status information. The acquisition unit is further configured to: read the third tracking information corresponding to the application stuttering from a preset cache.

[0134] According to one or more embodiments of this disclosure, the acquisition unit is further configured to: initialize a cache area and record first tracking information in the cache area in real time using a memory tracking function; and record second tracking information in the cache area in real time using a system statistics function.

[0135] According to one or more embodiments of this disclosure, when the transceiver unit uploads tracking information to the server, it is specifically used to: format the tracking information to generate a monitoring data file in JSON format; and upload the monitoring data file to the server.

[0136] Thirdly, according to one or more embodiments of the present disclosure, an electronic device is provided, comprising: at least one processor and a memory;

[0137] The memory stores instructions that the computer executes;

[0138] At least one processor executes computer execution instructions stored in memory, causing at least one processor to perform the application stuttering monitoring method as described in the first aspect above and various possible designs of the first aspect.

[0139] Fourthly, according to one or more embodiments of the present disclosure, a computer-readable storage medium is provided, which stores computer-executable instructions that, when executed by a processor, implement the application stuttering monitoring method described in the first aspect above and various possible designs of the first aspect.

[0140] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0141] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0142] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. An application hang monitoring method, comprising: The application comprises the following steps: According to the jitter index, the application is monitored for jitter, wherein the jitter index is used to indicate whether the application has jitter; If the application is monitored for jitter, the tracking information is obtained, wherein the tracking information is the data collected at the time when the application has jitter, and the tracking information is used to represent the function call time consumption in the application and the function call time consumption in the operating system before the time when the application has jitter; The cache operation of the application is intercepted, wherein the cache operation is used to represent that the application stores the tracking information by executing kernel code; The tracking information is sent to the preset user mode cache area through an asynchronous thread; When it is determined that the data write amount of the user mode cache area is greater than or equal to the preset cache threshold, the data in the user mode cache area is written to the preset position to generate a tracking file, wherein the tracking file is used for jitter analysis of the application; The tracking file is uploaded to the server.

2. The method of claim 1, wherein, The jitter index includes message time consumption, and the application is monitored for jitter according to the jitter index, which comprises the following steps: The message time consumption in the main thread message queue is counted; If the message time consumption is greater than a preset time threshold, it is determined that the application has jitter.

3. The method of claim 2, wherein, The message time consumption in the main thread message queue is counted, which comprises the following steps: A start tag and an end tag are printed respectively at the beginning and the end of each message in the main thread message queue through a preset print function in the message pump; The message time consumption is determined according to the interval time length of the start tag and the end tag.

4. The method of claim 2, wherein, The jitter index also includes the number of jitters, and if the message time consumption is greater than a preset time threshold, it is determined that the application has jitter, which comprises the following steps: The number of jitters is determined according to the number of times that the message time consumption is greater than the preset time threshold within a preset time range; If the number of jitters is greater than a preset number threshold, it is determined that the application has jitter.

5. The method of claim 1, wherein, The jitter index includes the number of lost frames, and the application is monitored for jitter according to the jitter index, which comprises the following steps: The frame loss rate is determined according to the display message queue when the terminal device runs the application; If the frame loss rate is greater than a preset frame loss threshold, it is determined that the application has jitter.

6. The method of claim 1, wherein, The operation of the application for storing the tracking information by executing kernel code is intercepted, which comprises the following steps: The tracking information written by the application to the trace identifier description file is intercepted through a hook function preset at the write system call position, and the tracking information is written to a ring memory cache area; The tracking information is sent to the preset user mode cache area through an asynchronous thread, which comprises the following steps: The tracking information in the ring memory cache area is written to the user mode cache area through an asynchronous thread.

7. The method according to any one of claims 1 to 6, characterized in that, The tracking information includes first tracking information and second tracking information, wherein the first tracking information is used to represent the function time consumption of the application, and the second tracking information is used to represent the Android system interface function time consumption; the tracking information is obtained, which comprises the following steps: The first tracking information and the second tracking information corresponding to the time when the application has jitter are read from the preset cache area.

8. The method of claim 7, wherein, The tracking information further includes third tracking information, the third tracking information being used to represent a hardware running parameter when the terminal device runs the application program, and the hardware running parameter includes at least one of the following: central processing unit running state information; image processor running state information, and input / output interface running state information; The method further includes: reading the third tracking information corresponding to the application program when the application program is stuck from a preset cache area.

9. The method of claim 7, wherein, The method further includes: initializing the cache area, and recording the first tracking information in the cache area in real time through a memory tracking function; and recording the second tracking information in the cache area in real time through a system statistics function.

10. The method according to any one of claims 1 to 6, characterized in that, uploading the tracking information to a server, including: formatting the tracking information to generate a monitoring data file in a JS object score format; uploading the monitoring data file to the server.

11. An application hang monitoring apparatus, comprising: The method includes: a monitoring unit configured to monitor an application program for sticking according to a sticking index, wherein the sticking index is used to indicate whether the application program is stuck; an obtaining unit configured to obtain tracking information if the application program is monitored to be stuck, wherein the tracking information is data collected at a moment when the application program is stuck, and the tracking information is used to represent function call time consumption in the application program and function call time consumption in an operating system before the moment when the application program is stuck; a caching unit configured to intercept a caching operation of the application program, wherein the caching operation is used to represent that the application program stores the tracking information by executing kernel code; send the tracking information to a preset user mode cache area through an asynchronous thread; and write data in the user mode cache area to a preset position to generate a tracking file when it is determined that a data writing amount of the user mode cache area is greater than or equal to a preset cache threshold, wherein the tracking file is used to analyze sticking of the application program; and a transceiving unit configured to upload the tracking file to a server.

12. An electronic device, comprising: The method includes: at least one processor and a memory; the memory stores computer execution instructions; the at least one processor executes the computer execution instructions stored in the memory, so that the at least one processor executes the application program sticking monitoring method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and when a processor executes the computer execution instructions, the application program sticking monitoring method according to any one of claims 1 to 10 is implemented.

14. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor, and the application program sticking monitoring method according to any one of claims 1 to 10 is implemented.

Images