Cotton analysis method and device thereof
By automatically filtering target trace files and generating stuttering analysis results, the problem of high workload in stuttering analysis is solved, efficiency is improved and the applicable scenarios are expanded to include video files of different frame rates.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- VIVO MOBILE COMM CO LTD
- Filing Date
- 2022-12-20
- Publication Date
- 2026-05-15
AI Technical Summary
Current technologies for analyzing stuttering are too labor-intensive, resulting in low efficiency, and can only analyze video files with 60 frames per second, limiting their applicability.
By downloading the set of trace files from the target terminal, the system automatically filters the target trace files based on their thread call information and generates stuttering analysis results based on the target threads, thus avoiding manual filtering.
It improves the efficiency of stuttering analysis, is applicable to video files with different frame rates, reduces workload, and expands the applicable scenarios for analysis.
Smart Images
Figure CN115955557B_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of communication technology, specifically relating to a stuttering analysis method and apparatus. Background Technology
[0002] To reduce stuttering during video playback, trace files need to be collected from user terminals. Analysis of these trace files is then performed to determine the cause of the stuttering, allowing for code optimization and improved video playback smoothness. However, current technologies require developers to manually sift through these trace files to identify abnormal ones, a task that is extremely labor-intensive and results in low efficiency for stuttering analysis. Summary of the Invention
[0003] The purpose of this application is to provide a lag analysis method and apparatus that can solve the problem that the workload of lag analysis is too large, resulting in low efficiency of lag analysis.
[0004] In a first aspect, embodiments of this application provide a lag analysis method, the method comprising:
[0005] Download the set of trace files corresponding to the target terminal, wherein the set of trace files includes N first trace files, each of which is used to characterize the thread call information of the target terminal, and N is a positive integer;
[0006] Based on the thread call information corresponding to each first trace file, at least a portion of the first trace files in the trace file set are determined as target trace files;
[0007] Based on the target thread corresponding to each target trace file, generate the stuttering analysis results corresponding to the target terminal.
[0008] Secondly, embodiments of this application provide a stuttering analysis device, the device comprising:
[0009] The download module is used to download the set of trace files corresponding to the target terminal, wherein the set of trace files includes N first trace files, each of which is used to characterize the thread call information of the target terminal, and N is a positive integer;
[0010] The determination module is used to determine at least a portion of the first trace files in each trace file set as target trace files based on the thread call information corresponding to each trace file in each first trace file set;
[0011] The first generation module is used to generate the stuttering analysis results corresponding to the target terminal based on the target thread corresponding to each target trace file.
[0012] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.
[0013] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.
[0014] Fifthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the method as described in the first aspect.
[0015] In a sixth aspect, embodiments of this application provide a computer program product stored in a storage medium, which is executed by at least one processor to implement the method described in the first aspect.
[0016] In this embodiment, after downloading the trace file set, the target trace file is determined based on the thread call information corresponding to each first trace file in the trace file set. Then, based on the target thread corresponding to each target trace file, the stuttering analysis result corresponding to the target terminal is generated. In this process, developers do not need to manually screen the trace files to generate the stuttering analysis result corresponding to the target terminal, which reduces the workload in the stuttering analysis process and thus improves the efficiency of stuttering analysis. Attached Figure Description
[0017] Figure 1 This is a flowchart of the stuttering analysis method provided in the embodiments of this application;
[0018] Figure 2 This is an application flowchart of the stuttering analysis method provided in the embodiments of this application;
[0019] Figure 3 This is a structural diagram of the stuttering analysis device provided in the embodiments of this application;
[0020] Figure 4 This is a structural diagram of the electronic device provided in the embodiments of this application;
[0021] Figure 5 This is a hardware structure diagram of the electronic device provided in the embodiments of this application. Detailed Implementation
[0022] The technical solutions of the embodiments of this application will be clearly described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.
[0023] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.
[0024] This application provides a stuttering analysis method. The stuttering analysis method provided by this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.
[0025] This application provides a method for lag analysis. Please refer to [link / reference]. Figure 1 , Figure 1 This is a flowchart of the stuttering analysis method provided in this application embodiment. The stuttering analysis method provided in this application embodiment includes the following steps:
[0026] S101, Download the set of trace files corresponding to the target terminal.
[0027] The aforementioned set of trace files includes N first trace files, each of which is used to characterize the thread call information of the target terminal, where N is a positive integer. The thread call information includes, but is not limited to, the thread call time period, the name of the calling thread, and the thread response time.
[0028] Optionally, the above trace file is a trace file.
[0029] S102, based on the thread call information corresponding to each first trace file, at least a portion of the first trace files in the trace file set are determined as target trace files.
[0030] In this step, the target trace file is obtained by filtering the N first trace files in the trace file set. The target trace file can be understood as the trace file corresponding to the target terminal when the target terminal is severely lagging.
[0031] S103, Based on the target thread corresponding to each target trace file, generate the stuttering analysis result corresponding to the target terminal.
[0032] As described above, the thread call information represented by the first trace file includes, but is not limited to, the thread call time period, the name of the calling thread, and the thread response time. In this step, the target thread corresponding to the target trace file can be determined based on the name of the calling thread in the thread call information represented by the target trace file. Then, based on the target thread corresponding to the target trace file, the stuttering analysis result corresponding to the target terminal is generated. For specific implementation methods, please refer to the following embodiments.
[0033] In this embodiment, after downloading the trace file set, the target trace file is determined based on the thread call information corresponding to each first trace file in the trace file set. Then, based on the target thread corresponding to each target trace file, the stuttering analysis result corresponding to the target terminal is generated. In this process, developers do not need to manually screen the trace files to generate the stuttering analysis result corresponding to the target terminal, which reduces the workload in the stuttering analysis process and thus improves the efficiency of stuttering analysis.
[0034] Furthermore, related technologies can only perform stuttering analysis on video files with a frame rate of 60 frames per second. However, the stuttering analysis method provided in this application analyzes the stuttering of the target terminal by downloading a set of trace files corresponding to the target terminal. This does not limit the frame rate of the video file, meaning that the stuttering analysis method provided in this application has a wider range of applicable scenarios compared to related technologies.
[0035] Optionally, the downloading of the set of trace files corresponding to the target terminal includes:
[0036] Obtain the list of trace files corresponding to the target terminal;
[0037] Based on the list of trace files, download the M trace files corresponding to the target terminal;
[0038] The M trace files are filtered to obtain a set of trace files.
[0039] It should be understood that each time a lag occurs, the target terminal records the currently invoked application and basic information to generate a trace file. The aforementioned list of trace files includes trace files generated by the target terminal over a period of time. The list of trace files includes a compressed file link and basic information, which is the basic information recorded by the target terminal. The basic information includes, but is not limited to, the system version, the name of the application experiencing lag, and the duration of the lag.
[0040] Optionally, a list of trace files can be obtained at regular intervals. For example, a list of trace files corresponding to the target terminal can be obtained every day. In this case, the trace files represented by the trace file list are the trace files generated when the target terminal experiences lag within a day.
[0041] In this embodiment, after obtaining the list of trace files, the list of trace files can be parsed to obtain multiple compressed file links. After merging duplicate links in the multiple compressed file links and deleting invalid links and empty links in the multiple compressed file links, the M compressed files corresponding to the target terminal are downloaded according to the remaining compressed file links, and the above M compressed files are decompressed to obtain M trace files, where M is a positive integer greater than N.
[0042] Optionally, the above compressed file link can be a log compressed file link. Optionally, the decompressed trace files can be saved in a specified directory.
[0043] The downloaded M trace files are filtered to obtain a set of trace files. For details on how to filter the M trace files, please refer to the following embodiments.
[0044] Optionally, the step of filtering the M trace files to obtain a set of trace files includes:
[0045] Obtain the file parameters of each of the M trace files; determine the trace file whose file parameters meet the preset conditions as the first trace file, and obtain a trace file set consisting of N first trace files;
[0046] The file parameters satisfying preset conditions include: the file includes a raw file and the file size is greater than or equal to a threshold.
[0047] In this embodiment, the file parameters of each of the M trace files are obtained, the trace file whose file parameters meet the preset conditions is determined as the first trace file, and the trace files whose file parameters do not meet the preset conditions are deleted from the M trace files.
[0048] Optionally, the above file parameters include storage capacity and data format. In this case, delete the M trace files that contain the original file but whose storage capacity is less than the threshold, and delete the M trace files that do not contain the original file, thus obtaining N first trace files. It should be understood that the above threshold is a user-defined storage capacity.
[0049] For example, the threshold is 5M, and the data format of the original file is atrace. Therefore, the file in the M trace files that is in atrace format and has a storage capacity greater than or equal to 5M can be identified as the first trace file.
[0050] In this embodiment, by performing preliminary screening on M trace files, files that do not contain the content to be analyzed can be deleted based on the file parameters. This makes it simpler and faster to determine the region where the content to be analyzed is located, thus improving the efficiency of lag analysis.
[0051] Optionally, before determining at least a portion of the first trace files in the trace file set as target trace files based on the thread call information corresponding to each first trace file, the method includes:
[0052] The N first trace files are visualized to generate the target interface.
[0053] In this embodiment, the visualization of the N first trace files can be achieved by converting their file formats, thus generating the target interface. Specifically, a Python conversion script can be used to convert the trace files into files with an .html extension.
[0054] The target interface is used to display thread call information corresponding to each first trace file; as mentioned above, the thread call information includes, but is not limited to, the thread call time period, the name of the calling thread, and the thread response time.
[0055] In this embodiment, a target interface is generated by visualizing N first trace files, and then the lag phenomenon is analyzed more intuitively based on the target interface, thereby improving the efficiency of lag analysis.
[0056] This application provides the following implementation method for determining the target trace file among N first trace files:
[0057] Optionally, determining at least a portion of the first trace files in the trace file set as target trace files based on the thread call information corresponding to each first trace file includes:
[0058] The first trace file whose corresponding target time period falls within a preset time period is identified as the target trace file, wherein the target time period is determined based on the thread call time period; or...
[0059] The first trace file, whose corresponding calling thread name represents the preset thread, is identified as the target trace file.
[0060] One alternative implementation is to determine the target trace file based on a preset time period.
[0061] Specifically, the first trace file includes a timestamp, which is used to represent a base time. As mentioned above, the thread call information in the target interface includes the thread call time period. Optionally, the base time is obtained by parsing the timestamp of the first trace file, and the thread call time period corresponding to the first trace file is added to the base time to obtain the target time period corresponding to the first trace file. The first trace file whose target time period is within the preset time period is determined as the target trace file.
[0062] In this embodiment, a base time is obtained by parsing the timestamp in the first trace file. Then, based on the base time and the thread call time period corresponding to the first trace file, it can be determined whether the first trace file is the target trace file. Compared to related technologies, this embodiment does not require timestamp conversion, reducing workload and thus improving the efficiency of the stuttering analysis method.
[0063] Another alternative implementation is to determine the target trace file based on a preset thread.
[0064] Specifically, the thread call information in the target interface includes the name of the calling thread. The calling thread corresponding to the first trace file can be determined based on the aforementioned calling thread name. If the calling thread corresponding to the first trace file is a preset thread, the first trace file is determined to be the target trace file.
[0065] Understandably, the preset threads can be pre-determined threads that are more prone to stuttering, or threads that are likely to stuttering based on the current scenario.
[0066] For example, if the default thread is the rendering thread, then the first trace file that calls the rendering thread among the N first trace files is determined as the target trace file.
[0067] In this embodiment, the first trace file can be identified as the target trace file by the calling thread corresponding to it. Compared with the manual screening of the first trace file in related technologies, this embodiment determines the target trace file by automatic screening, which reduces the workload and improves the efficiency of the lag analysis method.
[0068] Optionally, generating the stuttering analysis results corresponding to the target terminal based on the target thread corresponding to each target trace file includes:
[0069] The thread whose response duration is greater than a preset duration in each target trace file is identified as the target thread corresponding to the target trace file;
[0070] Based on the tag information corresponding to each target thread, the running state of the target thread is determined;
[0071] Based on the running status of the target thread, generate the stuttering analysis results corresponding to the target terminal.
[0072] Optionally, the above label information is tag information, which is used to characterize the running state of a thread.
[0073] Specifically, after identifying the target trace file, threads whose response time corresponding to the target trace file exceeds a preset duration are identified as target threads. The running status of each target thread is determined based on its corresponding tag information. Optionally, the preset duration is the time required to refresh one frame.
[0074] Optionally, the tag information corresponds to 5 different running states: running, runnable, I / O block, uninterrupt sleep, and sleep.
[0075] Furthermore, based on the running status of the target thread, the cause of the lag in the target terminal is determined, and then the lag analysis results corresponding to the target terminal are generated. The lag analysis results are used to characterize the running status of each target thread in the case of lag in the target terminal.
[0076] Optionally, if the running status corresponding to the tag is running, it means that the reason for the lag in the target terminal is that the target thread runs for too long, the code implementation logic is complex, or the CPU frequency is limited.
[0077] If the running status corresponding to the tag is Runnable, it means that the lag in the target terminal is caused by the target thread not running.
[0078] When the running status corresponding to the tag is I / O block, it means that the lag on the target terminal is caused by I / O operation lag.
[0079] When the running status corresponding to the tag is Uninterrupt sleep, it means that the lag in the target terminal is caused by the interruption of the target thread, and the target thread can be executed by calling another thread.
[0080] If the running status corresponding to the tag is Sleep, it means that the lag in the target terminal is caused by the target thread not running.
[0081] In related technologies, the stuttering analysis results can only indicate whether the target terminal is stuttering, but cannot analyze the cause of the stuttering. In this embodiment, based on the tag information corresponding to each target thread, the running state of the target thread is determined, and then a stuttering analysis result characterizing the cause of the stuttering of the target terminal is generated according to the running state of the target thread, so as to locate the cause of the stuttering.
[0082] For a better understanding of the overall technical solution, please refer to [link / reference]. Figure 2 , Figure 2 The diagram shows the application flowchart of the stuttering analysis method provided in the embodiments of this application.
[0083] like Figure 2 As shown, the process involves: obtaining a list of trace files corresponding to the target terminal; downloading M trace files corresponding to the target terminal; filtering the M trace files to obtain a trace file set; visualizing the N first trace files in the trace file set to generate a target interface; determining the target trace files based on the target interface; and performing stuttering analysis based on the target thread corresponding to each target trace file to generate stuttering analysis results for the target terminal.
[0084] The stuttering analysis device provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.
[0085] like Figure 3 As shown, the stuttering analysis device 300 includes:
[0086] Download module 301 is used to download a set of trace files corresponding to the target terminal, wherein the set of trace files includes N first trace files, each first trace file is used to characterize the thread call information of the target terminal, and N is a positive integer;
[0087] The determining module 302 is used to determine at least a portion of the first trace files in the trace file set as target trace files based on the thread call information corresponding to each first trace file;
[0088] The first generation module 303 is used to generate the stuttering analysis results corresponding to the target terminal based on the target thread corresponding to each target trace file.
[0089] Optionally, the download module 301 is specifically used for:
[0090] Obtain the list of trace files corresponding to the target terminal;
[0091] Based on the list of trace files, download M trace files corresponding to the target terminal; M is a positive integer greater than or equal to N;
[0092] The M trace files are filtered to obtain a set of trace files.
[0093] Optionally, the download module 301 is further specifically used for:
[0094] Obtain the file parameters of each of the M trace files; determine the trace file whose file parameters meet the preset conditions as the first trace file, and obtain a trace file set consisting of N first trace files;
[0095] The file parameters satisfying preset conditions include: the file includes a raw file and the file size is greater than or equal to a threshold.
[0096] Optionally, the stuttering analysis device 300 further includes:
[0097] The second generation module is used to visualize the N first trace files and generate the target interface;
[0098] The target interface is used to display thread call information corresponding to each first trace file; the thread call information includes the thread call time period, the name of the calling thread, and the thread response time.
[0099] Optionally, the determining module 302 is specifically used for:
[0100] The first trace file whose corresponding target time period falls within a preset time period is identified as the target trace file, wherein the target time period is determined based on the thread call time period; or...
[0101] The first trace file, whose corresponding calling thread name represents the preset thread, is identified as the target trace file.
[0102] Optionally, the first generation module 303 is specifically used for:
[0103] The thread whose response duration is greater than a preset duration in each target trace file is identified as the target thread corresponding to the target trace file;
[0104] Based on the tag information corresponding to each target thread, the running state of the target thread is determined;
[0105] Based on the running state of the target thread, a stuttering analysis result corresponding to the target terminal is generated. The stuttering analysis result is used to characterize the running state of each target thread when the target terminal is stuttering.
[0106] In this embodiment, after downloading the trace file set, the target trace file is determined based on the thread call information corresponding to each first trace file in the trace file set. Then, based on the target thread corresponding to each target trace file, the stuttering analysis result corresponding to the target terminal is generated. In this process, developers do not need to manually screen the trace files to generate the stuttering analysis result corresponding to the target terminal, which reduces the workload in the stuttering analysis process and thus improves the efficiency of stuttering analysis.
[0107] The stuttering analysis device in this application embodiment can be an electronic device or a component within an electronic device, such as an integrated circuit or a chip. The electronic device can be a terminal or other devices besides a terminal. For example, the electronic device can be a mobile phone, tablet computer, laptop computer, PDA, in-vehicle electronic device, mobile internet device (MID), augmented reality (AR) / virtual reality (VR) device, robot, wearable device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc. It can also be a server, network attached storage (NAS), personal computer (PC), television (TV), ATM, or self-service machine, etc. This application embodiment does not specifically limit the device.
[0108] The stuttering analysis device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit it.
[0109] The stuttering analysis device provided in this application embodiment can achieve... Figure 1 The various processes implemented in the method implementation examples will not be described again here to avoid repetition.
[0110] Optionally, such as Figure 4 As shown, this application embodiment also provides an electronic device 400, including a processor 401, a memory 402, and a program or instructions stored in the memory 402 and executable on the processor 401. When the program or instructions are executed by the processor 401, they implement the various processes of the above-described stuttering analysis method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.
[0111] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.
[0112] Figure 5 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application.
[0113] The electronic device 500 includes, but is not limited to, components such as: radio frequency unit 501, network module 502, audio output unit 503, input unit 504, sensor 505, display unit 506, user input unit 505, interface unit 508, memory 509, and processor 510.
[0114] Those skilled in the art will understand that the electronic device 500 may also include a power supply (such as a battery) for supplying power to various components. The power supply may be logically connected to the processor 510 through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 5 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here.
[0115] The processor 510 is also used to download a set of trace files corresponding to the target terminal.
[0116] Based on the thread call information corresponding to each first trace file, at least a portion of the trace files in the trace file set are identified as target trace files;
[0117] Based on the target thread corresponding to each target trace file, generate the stuttering analysis results corresponding to the target terminal.
[0118] In this embodiment, after downloading the trace file set, the target trace file is determined based on the thread call information corresponding to each first trace file in the trace file set. Then, based on the target thread corresponding to each target trace file, the stuttering analysis result corresponding to the target terminal is generated. In this process, developers do not need to manually screen the trace files to generate the stuttering analysis result corresponding to the target terminal, which reduces the workload in the stuttering analysis process and thus improves the efficiency of stuttering analysis.
[0119] It should be understood that, in this embodiment, the input unit 504 may include a graphics processing unit (GPU) 5041 and a microphone 5042. The GPU 5041 processes image data of still images or videos obtained by an image capture device (such as a camera) in video capture mode or image capture mode. The display unit 506 may include a display panel 5061, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like. The user input unit 506 includes at least one of a touch panel 5061 and other input devices 5062. The touch panel 5061 is also called a touch screen. The touch panel 5061 may include a touch detection device and a touch controller. Other input devices 5062 may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be described in detail here.
[0120] The memory 509 can be used to store software programs and various data. The memory 509 may primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area may store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, the memory 509 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DRRAM). The memory 509 in this embodiment includes, but is not limited to, these and any other suitable types of memory.
[0121] Processor 510 may include one or more processing units; optionally, processor 510 integrates an application processor and a modem processor, wherein the application processor mainly handles operations involving the operating system, user interface, and applications, and the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into processor 510.
[0122] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described stuttering analysis method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.
[0123] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.
[0124] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described stuttering analysis method embodiment and can achieve the same technical effect. To avoid repetition, it will not be described again here.
[0125] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.
[0126] This application provides a computer program product, which is stored in a storage medium and executed by at least one processor to implement the various processes of the above-described stuttering analysis method embodiments, and can achieve the same technical effect. To avoid repetition, it will not be described again here.
[0127] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.
[0128] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.
[0129] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.
Claims
1. A cascading failure analysis method, characterized in that, include: Download the set of trace files corresponding to the target terminal, wherein the set of trace files corresponding to the target terminal is obtained based on file parameters, wherein the file parameters include: storage capacity and data format, and the set of trace files includes N first trace files, each first trace file is used to characterize the thread call information of the target terminal, where N is a positive integer; Based on the thread call information corresponding to each first trace file, at least a portion of the first trace files in the trace file set are identified as target trace files; Based on the target thread corresponding to each target trace file, generate the stuttering analysis results corresponding to the target terminal; The downloading of the set of trace files corresponding to the target terminal includes: Obtain the list of trace files corresponding to the target terminal; Based on the list of trace files, download M trace files corresponding to the target terminal, where M is a positive integer greater than N; The M trace files are filtered to obtain a set of trace files; The step of filtering the M trace files to obtain a set of trace files includes: Obtain the file parameters of each of the M trace files; The trace file whose file parameters meet the preset conditions among the M trace files is determined as the first trace file, and a trace file set consisting of N first trace files is obtained; The file parameters satisfying the preset conditions include: the trace file includes a raw file and the size of the raw file is greater than or equal to a threshold.
2. The method according to claim 1, characterized in that, Before determining at least a portion of the first trace files in the trace file set as target trace files based on the thread call information corresponding to each first trace file, the method includes: The N first trace files are visualized to generate the target interface; The target interface is used to display thread call information corresponding to each first trace file; the thread call information includes the thread call time period, the name of the calling thread, and the thread response time.
3. The method according to claim 2, characterized in that, The step of determining at least a portion of the first trace files in the trace file set as target trace files based on the thread call information corresponding to each first trace file includes: The first trace file whose corresponding target time period falls within a preset time period is identified as the target trace file, wherein the target time period is determined based on the thread call time period; or... The first trace file, whose corresponding calling thread name represents the preset thread, is identified as the target trace file.
4. The method according to claim 1, characterized in that, The step of generating stuttering analysis results for the target terminal based on the target thread corresponding to each target trace file includes: The thread whose response duration is greater than a preset duration in each target trace file is identified as the target thread corresponding to the target trace file; Based on the tag information corresponding to each target thread, the running state of each target thread is determined; Based on the running status of each target thread, a stuttering analysis result corresponding to the target terminal is generated. The stuttering analysis result is used to characterize the running status of the target thread corresponding to each target trace file when the target terminal is stuttering.
5. A stuttering analysis device, characterized in that, include: The download module is used to download the set of trace files corresponding to the target terminal. The set of trace files corresponding to the target terminal is obtained based on file parameters, including storage capacity and data format. The set of trace files includes N first trace files, each of which is used to characterize the thread call information of the target terminal, where N is a positive integer. The determination module is used to determine at least a portion of the first trace files in the trace file set as target trace files based on the thread call information corresponding to each first trace file; The first generation module is used to generate the stuttering analysis results corresponding to the target terminal based on the target thread corresponding to each target trace file; The download module is specifically used for: Obtain the list of trace files corresponding to the target terminal; Based on the list of trace files, download M trace files corresponding to the target terminal; M is a positive integer greater than N; The M trace files are filtered to obtain a set of trace files; The download module is also specifically used for: Obtain the file parameters of each of the M trace files; determine the trace file whose file parameters meet the preset conditions as the first trace file, and obtain a trace file set consisting of N first trace files; The file parameters satisfying the preset conditions include: the trace file includes a raw file and the size of the raw file is greater than or equal to a threshold.
6. The apparatus according to claim 5, characterized in that, The device further includes: The second generation module is used to visualize the N first trace files and generate the target interface; The target interface is used to display thread call information corresponding to each first trace file; the thread call information includes the thread call time period, the name of the calling thread, and the thread response time.
7. The apparatus according to claim 6, characterized in that, The determining module is specifically used for: The first trace file whose corresponding target time period falls within a preset time period is identified as the target trace file, wherein the target time period is determined based on the thread call time period; or... The first trace file, whose corresponding calling thread name represents the preset thread, is identified as the target trace file.
8. The apparatus according to claim 5, characterized in that, The first generation module is specifically used for: The thread whose response duration is greater than a preset duration in each target trace file is identified as the target thread corresponding to the target trace file; Based on the tag information corresponding to each target thread, the running state of the target thread is determined; Based on the running state of the target thread, a stuttering analysis result corresponding to the target terminal is generated. The stuttering analysis result is used to characterize the running state of each target thread when the target terminal is stuttering.
9. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the stuttering analysis method as described in any one of claims 1-4.
10. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the stuttering analysis method as described in any one of claims 1-4.