Cloud mobile phone application program crash diagnosis method
By determining and predicting the crash context data based on the running data when the cloud mobile application crashes, the problem of low diagnostic efficiency of cloud mobile application crashes is solved, and diagnostic accuracy and application stability are improved.
Patent Information
- Application Number
- CN202411300990.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-18
- Publication Date
- 2025-01-03
AI Technical Summary
The prior art cannot accurately and efficiently diagnose the crash of cloud mobile applications, resulting in low diagnostic efficiency and poor stability.
When the cloud mobile application crashes, it determines the first crash context data of the crash node based on the running data, performs heuristic search and derivative processing to predict the second crash context data, generates the source data of the crash node, and finally obtains the crash diagnostic data.
It realizes accurate and efficient diagnosis of cloud mobile application crashes, improving the stability and user experience of the application.
Smart Images
Figure CN119248554A_ABST
Abstract
Description
Technical Field
[0001] The present application belongs to the field of cloud phone technology, and specifically relates to a cloud phone application crash diagnosis method. Background Art
[0002] In traditional methods, various abnormal diagnosis of cloud mobile applications, such as crashes, usually need to rely on user reports or manual analysis. This method has subjective and time-consuming problems, and cannot achieve accurate and efficient crash diagnosis. Summary of the invention
[0003] The purpose of the embodiments of the present application is to provide a cloud phone application crash diagnosis method that can solve the problem of being unable to accurately and efficiently implement abnormal diagnosis of cloud phone application crashes.
[0004] In a first aspect, an embodiment of the present application provides a cloud phone application crash diagnosis method, the method comprising: in the event that a cloud phone application crashes, determining first crash context data corresponding to a crash node based on running data of the cloud phone application; predicting second crash context data corresponding to the crash node when the cloud phone application next crashes by performing a derivative processing of a heuristic search on the first crash context data; generating the crash node tracing data based on the first crash context data and the second crash context data; and obtaining crash diagnosis data corresponding to the running data based on the crash node tracing data.
[0005] In a second aspect, an embodiment of the present application provides a cloud phone application crash diagnosis device, which includes: a determination module, which is used to determine, when a cloud phone application crashes, first crash context data corresponding to a crash node based on the running data of the cloud phone application; a prediction module, which is used to predict, by derivative processing of a heuristic search of the first crash context data, the second crash context data corresponding to the crash node when the cloud phone application crashes next time; a generation module, which is used to generate the crash node tracing data based on the first crash context data and the second crash context data; and an acquisition module, which is used to acquire crash diagnosis data corresponding to the running data based on the crash node tracing data.
[0006] In a third aspect, an embodiment of the present application provides an electronic device, which includes a processor and a memory, wherein the memory stores programs or instructions that can be run on the processor, and when the program or instructions are executed by the processor, the steps of the method described in the first aspect are implemented.
[0007] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the method described in the first aspect are implemented.
[0008] In a fifth aspect, an embodiment of the present application provides a chip, comprising a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run a program or instruction to implement the method described in the first aspect.
[0009] In a sixth aspect, an embodiment of the present application provides a computer program product, which is stored in a storage medium and is executed by at least one processor to implement the method described in the first aspect.
[0010] In an embodiment of the present application, when a cloud phone application crashes, the first crash context data corresponding to the crash node can be determined based on the running data of the cloud phone application; then, by performing a derivative process of a heuristic search on the first crash context data, the second crash context data corresponding to the crash node when the cloud phone application crashes next time is predicted; based on the first crash context data and the second crash context data, crash node tracing data is generated; and finally, based on the crash node tracing data, crash diagnosis data corresponding to the running data is obtained. Through the above method, not only can the crash diagnosis of the cloud phone application be accurately and efficiently implemented, but also the stability and user experience of the cloud phone application can be improved. BRIEF DESCRIPTION OF THE DRAWINGS
[0011] Figure 1 A schematic diagram showing a process of diagnosing a cloud phone application crash provided by an embodiment of the present application; Figure 2 A schematic diagram showing a flow chart of another cloud phone application crash diagnosis method provided by an embodiment of the present application; Figure 3 A schematic diagram showing the structure of a cloud phone application crash diagnosis device provided by an embodiment of the present application is shown; Figure 4 A structural block diagram of an electronic device provided by an exemplary embodiment of the present application is shown; Figure 5 A structural block diagram of another electronic device provided by an exemplary embodiment of the present application is shown. DETAILED DESCRIPTION
[0012] The following will be combined with the drawings in the embodiments of the present application to clearly describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments in the present application belong to the scope of protection of this application.
[0013] The terms "first", "second", etc. in the specification and claims of the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable under appropriate circumstances, so that the embodiments of the present application can be implemented in an order other than those illustrated or described here, and the objects distinguished by "first", "second", etc. are generally of one type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.
[0014] The following is a detailed description of the cloud phone application crash diagnosis method provided by the embodiment of the present application through specific embodiments and their application scenarios in conjunction with the accompanying drawings.
[0015] Figure 1 A cloud phone application crash diagnosis method provided by an exemplary embodiment of the present application is shown. The method 100 can be executed by an electronic device. In other words, the method can be executed by software or hardware installed in the electronic device. Figure 1 As shown, the method mainly includes the following steps: S101: When a cloud phone application crashes, first crash context data corresponding to a crash node is determined based on running data of the cloud phone application.
[0016] In an embodiment of the present application, if a cloud phone application crashes, the first crash context data corresponding to the crash node can be determined based on the running data of the cloud phone application. The first crash context data can be obtained through the running data, so that the cause of the crash of the cloud phone application can be accurately obtained.
[0017] In an optional implementation, before determining the first crash context data corresponding to the crash node based on the running data of the cloud phone application, the method further includes: Use a monitoring tool, a logger or a data collector to obtain the operating data of the cloud phone application, wherein the operating data includes at least one of the following: application logs, performance indicators, network traffic, and user operation behavior.
[0018] In a specific implementation, a monitoring tool, a logger, or a custom data collector can be used to obtain the operation data of the cloud phone application. A custom data collection tool can be used, or a third-party tool can be called to obtain the operation data, which is not specifically limited in the embodiments of this application. The operation data may include application logs, performance indicators (such as central processing unit (CPU) usage, memory usage, etc.), network traffic, user operation behavior, etc. Obtaining operation data in the above manner can not only improve efficiency, but also avoid missing data and ensure the integrity of the operation data.
[0019] In an optional implementation, determining the first crash context data corresponding to the crash node based on the running data of the cloud phone application includes: Preprocessing the operation data, wherein the preprocessing includes: removing noise data and removing invalid data; The pre-trained anomaly detection model is used to perform anomaly detection on the pre-processed operation data to determine the first crash context data corresponding to the crash node.
[0020] In an embodiment of the present application, the collected operation data can be preprocessed, and the preprocessing includes: removing noise data and removing invalid data. In practical applications, data cleaning, missing value processing, and outlier detection can be performed to ensure the quality and consistency of the operation data. Useful features can then be extracted from the preprocessed operation data, and then anomaly detection can be performed on it using a pre-trained anomaly detection model to determine the first crash context data corresponding to the crash node. When extracting features, the extraction can be based on statistical methods, machine learning algorithms, or domain knowledge, and the features obtained can be categorical or time series. The feature extraction method is consistent with the subsequent anomaly detection model. For example, when an anomaly detection model based on statistical methods is used, statistical methods such as mean and standard deviation are also used when extracting features. If the anomaly detection model is a model based on a machine learning algorithm such as clustering, support vector machine, or random forest, it can be processed into the feature types required by clustering, support vector machine, and random forest; if the anomaly detection model is a model based on a deep learning algorithm such as an autoencoder or variational autoencoder, the data can be processed into the feature types required by the autoencoder and variational autoencoder. In practical applications, the mean-variance method anomaly diagnosis model can be selected as an anomaly detection model to analyze data and detect anomalies. During the training process of the anomaly diagnosis model, labeled anomaly samples can be used for model training, and unlabeled data can be used for anomaly detection. The cross-validation method is used to evaluate the performance and accuracy of the model. According to the evaluation results, the model is tuned by adjusting the model parameters to improve the performance of the model. Finally, the trained model is used to perform anomaly detection on the operating data. According to the output results of the model, the anomaly can be marked, classified or further analyzed to determine the first crash context data corresponding to the crash node. In practical applications, the anomaly detection model can also be improved, and anomaly detection can be performed directly on the preprocessed training data, which is not specifically limited in the embodiments of the present application. Determining the first crash context data in the above manner can not only improve efficiency, but also obtain more comprehensive first crash context data.
[0021] In another optional implementation, determining the first crash context data corresponding to the crash node based on the running data of the cloud phone application includes: Mining program front-end session data in the running data; Removing the program front-end session data from the operation data to generate updated operation data; Determine first crash context data corresponding to the crashed node according to the updated running data.
[0022] In an embodiment of the present application, the program front-end session data in the running data of the cloud phone application can be mined, and then the program front-end session data can be removed from the running data to generate updated cloud phone application running data; finally, the first crash context data corresponding to the crash node is determined according to the running data of the updated cloud phone application. In practical applications, when mining the program front-end session data in the running data of the cloud phone application, it is first necessary to analyze the interaction process and user interface of the cloud phone application. By monitoring user input, interface operation and browsing history, etc., the data related to the front-end session is extracted. Then, according to the extracted front-end session data, it is processed and removed from the running data of the cloud phone application to ensure that only other running data unrelated to the front-end session is retained. In practical applications, the shielding window information of the program front-end session data can be determined first; then, according to the shielding window information of the program front-end session data, the program front-end session data located in each program level is deleted from the running data to generate the target running data; wherein, in the target running data, the program front-end session data corresponding to the running node is masked shielding data; finally, based on the target running data, the updated running data is generated. When generating the updated operation data of the cloud phone application, the remaining non-front-end session data can be reassembled. In this way, updated operation data that has been streamlined and removed from the front-end session related content can be obtained, so that it can be more focused on other key information, convenient for subsequent analysis and use, and can also protect user privacy and sensitive information at the same time. When obtaining the first crash context data through the updated operation data, an anomaly detection model can be used to obtain it, or other methods can be used, which are not specifically limited in the embodiments of the present application. Obtaining the first crash context data in the above manner can ensure the security of user privacy data.
[0023] In practical applications, the above two methods can be used to determine the first crash context data corresponding to the crash node. One or both methods can be used, and the embodiment of the present application does not specifically limit it. If both methods are used at the same time, the determined first crash context data may be richer and have more detailed details.
[0024] S102: Predicting second crash context data corresponding to the crash node when the cloud phone application crashes next time by performing a derivative process of a heuristic search on the first crash context data.
[0025] In the embodiment of the present application, the second crash context data corresponding to the crash node when the cloud phone application crashes next time can be predicted by performing a derivative process of a heuristic search on the first crash context data. By using a heuristic search technique to further process and analyze the first crash context data, and obtaining the second crash context data corresponding to the crash node when the cloud phone application crashes next time, more detailed information about the crash node can be obtained so as to restore the environment and conditions in which the crash occurred.
[0026] In an optional implementation, the predicting the second crash context data corresponding to the crash node when the cloud phone application crashes next time by performing a derivative process of a heuristic search on the first crash context data includes: determining a search space according to the first crash context data, wherein at least one operation information is recorded in the search space; The first crash context data is taken as an initial node, and the operations corresponding to the at least one operation information are sequentially performed on the first crash context data using a selected heuristic rule to generate the second crash context data.
[0027] In an embodiment of the present application, heuristic rules can be determined to guide the search process according to the characteristics and requirements of the problem. These rules can be derived based on experience or domain knowledge and are used to guide the search direction. The first crash context data is used as the initial state of the node to define the search space, that is, the set of states that can be operated. For example, add, delete or modify certain information in the first crash context data. Use the selected heuristic rules to start the search from the initial state. Evaluate each possible operation according to the heuristic rules, and select the operation that is most likely to generate useful information for expansion. During the search process, record and save the state after each operation until the stop condition is reached. Finally, the state after a series of operations based on the first crash context data is obtained, that is, the second crash context data. In an embodiment of the present application, the derived second crash context data can be realized during the operation of the cloud phone application. According to the above characteristics, some evaluation indicators or manual verification can be used to evaluate the generated second crash context data to determine its relevance and validity with the original running data. In practical applications, the heuristic search used can be a greedy best-first search, an A* search, or other heuristic searches, which are not specifically limited in the embodiments of the present application. Through the above steps, the first crash context data can be subjected to a derivative process based on a heuristic search to generate second crash context data corresponding to the crash node, which is not only more accurate but also can improve efficiency and save resources.
[0028] S103: Generate the crash node tracing data according to the first crash context data and the second crash context data.
[0029] In an embodiment of the present application, crash node tracing data can be generated based on the first crash context data and the second crash context data. The crash node tracing data can provide complete tracking information of the crash node and its related context, which is helpful for understanding the cause of the crash and the abnormal situation behind it.
[0030] In an optional implementation, generating crash node tracing data according to the first crash context data and the second crash context data includes: comparing the first crash context data and the second crash context data to obtain similarities and differences between the first crash context data and the second crash context data; Determining a traceability path from the first crash context data to the second crash context data according to the similarities and differences; The crash node tracing data is obtained by recording the operations or events performed in each step of the tracing path.
[0031] In an embodiment of the present application, the first crash context data and the second crash context data can be compared to find out the similarities and differences between them. In practical applications, this can be done by comparing the elements, features or attributes in the two data sets. Then, based on the similarities and differences, determine the traceability path from the first crash context data to the second crash context data. The traceability path can be a series of operations, events or conversion steps that describe the change process from one state to another. Finally, the crash node traceability data can be obtained by recording the operations or events performed in each step in the traceability path. In practical applications, the operations or events performed in each step can be recorded during the process of following the traceability path. These operations or events can be modifications, processing or transmission of data, etc. Then organize the recorded crash node traceability data to present a clear structure and order. In practical applications, a tree diagram, a timeline or other forms of visualization can be used to display the traceability path and related crash node traceability data. For example, the crash node traceability data can be a data structure containing information such as the location of the crash node, the associated code snippet, the related variables and the state. By analyzing the generated crash node traceability data, the cause of the crash and related information can be understood. In the embodiment of the present application, the root cause of the problem can be inferred by viewing the operations, events or data changes in the traceability path. Through the above steps, the traceability data of the crashed node can be generated to help understand and solve the crash problem.
[0032] In another optional implementation, generating crash node tracing data according to the first crash context data and the second crash context data includes: According to the context key field information of the first crash context data, locate the crash node in the second crash context data, and determine the location information of the crash node tracing data; The crash node tracing data is generated according to the location information of the crash node tracing data and the program front-end session data.
[0033] In an embodiment of the present application, the crash node can be located in the second crash context data according to the context key field information of the first crash context data, and the location information of the crash node tracing data can be determined; then, the crash node tracing data can be generated according to the location information of the crash node tracing data and the program front-end session data. The efficiency can be improved by determining the crash node tracing data by the above method. In the above optional implementation, the generation of the crash node tracing data according to the location information of the crash node tracing data and the program front-end session data includes: Generate intermediate crash node tracing data according to the location information of the crash node tracing data; Based on the crash node corresponding to each of the program front-end session data, each of the program front-end session data is loaded into the corresponding intermediate crash node tracing data that does not contain the program front-end session data, and the crash node tracing data carrying the program front-end session data is generated.
[0034] In an embodiment of the present application, crash node traceability data that does not contain program front-end session data, i.e., intermediate crash node traceability data, can be generated based on the location information of the crash node traceability data; then, based on the crash node corresponding to each program front-end session data, each program front-end session data is loaded into the corresponding intermediate crash node traceability data that does not contain program front-end session data, to generate crash node traceability data that carries program front-end session data. Through the above method, crash node traceability data can be generated based on the location information of the crash node traceability data and the program front-end session data, which can not only improve the accuracy of the data, but also help understand the cause and path of the crash.
[0035] In practical applications, the above two methods can be used to determine the crash node tracing data. One or both of them can be used, and the embodiments of the present application do not make specific limitations.
[0036] S104: Acquire crash diagnosis data corresponding to the operation data according to the crash node tracing data.
[0037] In an embodiment of the present application, crash diagnosis data corresponding to the operating data can be obtained based on the crash node traceability data, which helps to diagnose the cause and mechanism of the crash.
[0038] In an optional implementation, acquiring crash diagnosis data corresponding to the operation data according to the crash node tracing data includes: Determine the specific location of the crash node in the operation data according to the crash node tracing data; According to the specific location of the crashed node, abnormal diagnosis data is obtained from the operation data.
[0039] In an embodiment of the present application, crash node traceability data can be collected, including recorded operations, events, or data changes. Understand the meaning and impact of each step in the crash node traceability data. According to the crash node traceability data, determine the specific location where the crash occurred in the running data of the cloud phone application. This may be a specific operation, event, or data state transition. According to the location of the abnormality occurrence point, the cloud phone application running data related to the crash is extracted from the running data. These data may include the sequence of operations before and after the crash, environmental variables, input and output data, etc. The extracted abnormal diagnostic data is sorted to present a clear structure and format. The diagnostic data can be displayed in tables, graphs, or other ways for better understanding and analysis. The generated target abnormal diagnostic data is analyzed to infer and diagnose the cause and mechanism of the abnormality. The source and key factors of the abnormality can be found by viewing the operations, events, or data changes in the diagnostic data. Through the above steps, abnormal diagnostic data corresponding to the cloud phone application running data can be generated, which helps to locate and solve abnormal problems.
[0040] In another optional implementation, acquiring crash diagnosis data corresponding to the operation data according to the crash node tracing data includes: Determining the dimension information of each of the crashed nodes according to the crashed node tracing data; According to the dimension information of each of the crash nodes, based on a preset crash assessment dimension order, sorting each of the crash nodes; According to the sorted crash nodes, crash diagnosis data related to the crash nodes are collected one by one.
[0041] In an embodiment of the present application, the dimension information of each crash node can be determined according to the crash node tracing data, and then the crash nodes can be sorted based on the preset crash assessment dimension order; finally, according to the sorted crash nodes, the abnormal diagnosis data related to the crash nodes are collected one by one. In practical applications, the order of crash assessment dimensions can be set, for example, the importance of crash assessment dimensions, that is, the weight of each dimension can be determined. These dimensions can include error type, frequency, and impact range, and then the order of crash assessment dimensions is set. The crash nodes are then sorted by analyzing the performance and weight of each crash node under different dimensions. Next, according to the sorted crash nodes, the crash diagnosis data related to them are collected one by one, and the operation data related to them includes crash stack information, log records, and user feedback. By processing and structuring the data, the collected relevant operation data is integrated to meet the predetermined format and requirements to generate crash diagnosis data. Finally, the crash diagnosis data is used to analyze and troubleshoot crash problems, assist in finding the root cause and repairing it, and improve the stability and user experience of cloud phone applications.
[0042] In an embodiment of the present application, when a cloud phone application crashes, the first crash context data corresponding to the crash node can be determined based on the running data of the cloud phone application; then, by performing a derivative process of a heuristic search on the first crash context data, the second crash context data corresponding to the crash node when the cloud phone application crashes next time is predicted; based on the first crash context data and the second crash context data, crash node tracing data is generated; and finally, based on the crash node tracing data, crash diagnosis data corresponding to the running data is obtained. Through the above method, not only can the crash diagnosis of the cloud phone application be accurately and efficiently implemented, but also the stability and user experience of the cloud phone application can be improved.
[0043] In practical applications, the above two methods can be used to determine crash diagnostic data. One or both of them can be used, and the embodiments of the present application do not make specific limitations.
[0044] Figure 2 FIG. 1 is a flow chart showing another method for diagnosing a crash of a cloud phone application provided by an exemplary embodiment of the present application. Figure 2 As shown, the method mainly includes the following steps: S201: Obtaining cloud phone application operation data for abnormality diagnosis. S202: Determine first crash context data corresponding to a crash node from the cloud phone application running data.
[0045] S203: Perform a derivation process based on a heuristic search on the first crash context data to generate second crash context data corresponding to the crash node.
[0046] S204: Generate crash node tracing data according to the first crash context data and the second crash context data. S205: Generate target abnormality diagnosis data corresponding to the cloud phone application running data based on the crash node tracing data.
[0047] In an embodiment of the present application, the operation data of the cloud phone application to be subjected to abnormal diagnosis (crash diagnosis) can be obtained, and the first crash context data corresponding to the crash node can be determined from the operation data of the cloud phone application, and the first crash context data can be derived based on heuristic search to generate the second crash context data corresponding to the crash node. By introducing the heuristic search technology, the first crash context data is further processed and analyzed to obtain more detailed crash context information, and the crash node traceability data is generated based on the first crash context data and the second crash context data. The crash node traceability data provides complete tracking information of the crash node and its related context, which helps to understand the cause of the crash and the abnormal situation behind it. Finally, according to the crash node traceability data, the target abnormal diagnosis data (crash diagnosis data) corresponding to the operation data of the cloud phone application is generated. These diagnostic data describe the abnormal situations existing in the cloud phone application and provide valuable references for problem location and resolution. By integrating the operation data and derivative processing technology, the abnormal situation of the cloud phone application can be accurately analyzed, and detailed abnormal diagnosis data can be provided. This helps to improve the stability and performance of the cloud phone application and enhance the user experience.
[0048] The cloud phone application crash diagnosis method provided in the embodiment of the present application can be executed by a cloud phone application crash diagnosis device. In the embodiment of the present application, the cloud phone application crash diagnosis device executing the cloud phone application crash diagnosis method is taken as an example to illustrate the cloud phone application crash diagnosis device provided in the embodiment of the present application.
[0049] Figure 3 The schematic diagram of the structure of the cloud phone application crash diagnosis device provided by an exemplary embodiment of the present application is shown, which can be implemented as follows: Figure 1 All or part of the content of the illustrated embodiment, the cloud phone application crash diagnosis device includes: a determination module 301, a prediction module 302, a generation module 303 and an acquisition module 304.
[0050] In an embodiment of the present application, a determination module 301 is used to determine, when a cloud phone application crashes, first crash context data corresponding to a crash node based on the running data of the cloud phone application; a prediction module 302 is used to predict, by derivative processing of a heuristic search of the first crash context data, second crash context data corresponding to the crash node when the cloud phone application crashes next time; a generation module 303 is used to generate the crash node tracing data based on the first crash context data and the second crash context data; an acquisition module 304 is used to acquire crash diagnostic data corresponding to the running data based on the crash node tracing data.
[0051] In an optional implementation, the prediction module 302 is used for predicting the second crash context data corresponding to the crash node when the cloud phone application crashes next time by performing a derivative process of a heuristic search on the first crash context data, specifically for: determining a search space according to the first crash context data, wherein at least one operation information is recorded in the search space; The first crash context data is taken as an initial node, and the operations corresponding to the at least one operation information are sequentially performed on the first crash context data using a selected heuristic rule to generate the second crash context data.
[0052] In an optional implementation, the determination module 301 is also used to obtain the operating data of the cloud phone application using a monitoring tool, a logger or a data collector, wherein the operating data includes at least one of the following: application logs, performance indicators, network traffic, and user operation behavior.
[0053] In an optional implementation, when the determination module 301 is used to determine the first crash context data corresponding to the crash node based on the running data of the cloud phone application, it is specifically used to: Preprocessing the operation data, wherein the preprocessing includes: removing noise data and removing invalid data; The pre-trained anomaly detection model is used to perform anomaly detection on the pre-processed operation data to determine the first crash context data corresponding to the crash node.
[0054] In another optional implementation, when the determination module 301 is used to determine the first crash context data corresponding to the crash node based on the running data of the cloud phone application, it is specifically used to: Mining program front-end session data in the running data; Removing the program front-end session data from the operation data to generate updated operation data; Determine first crash context data corresponding to the crashed node according to the updated running data.
[0055] In an optional implementation, when the generating module 303 is used to generate the crash node tracing data according to the first crash context data and the second crash context data, it is specifically used to: comparing the first crash context data and the second crash context data to obtain similarities and differences between the first crash context data and the second crash context data; Determining a traceability path from the first crash context data to the second crash context data according to the similarities and differences; The crash node tracing data is obtained by recording the operations or events performed in each step of the tracing path.
[0056] In another optional implementation, when the generating module 303 is used to generate the crash node tracing data according to the first crash context data and the second crash context data, it is specifically used to: According to the context key field information of the first crash context data, locate the crash node in the second crash context data, and determine the location information of the crash node tracing data; The crash node tracing data is generated according to the location information of the crash node tracing data and the program front-end session data.
[0057] In the above optional implementation, when the generating module 303 is used to generate the crash node tracing data according to the location information of the crash node tracing data and the program front-end session data, it is specifically used to: Generate intermediate crash node tracing data according to the location information of the crash node tracing data; Based on the crash node corresponding to each of the program front-end session data, each of the program front-end session data is loaded into the corresponding intermediate crash node tracing data that does not contain the program front-end session data, and the crash node tracing data carrying the program front-end session data is generated.
[0058] In an optional implementation, when the acquisition module 304 is used to acquire the crash diagnosis data corresponding to the operation data according to the crash node tracing data, it is specifically used to: Determine the specific location of the crash node in the operation data according to the crash node tracing data; According to the specific location of the crashed node, abnormal diagnosis data is obtained from the operation data.
[0059] In another optional implementation, when the acquisition module 304 is used to acquire the crash diagnosis data corresponding to the operation data according to the crash node tracing data, it is specifically used to: Determining the dimension information of each of the crashed nodes according to the crashed node tracing data; According to the dimension information of each of the crash nodes, based on a preset crash assessment dimension order, sorting each of the crash nodes; According to the sorted crash nodes, crash diagnosis data related to the crash nodes are collected one by one.
[0060] The cloud phone application crash diagnosis device in the embodiment of the present application can be an electronic device or a component in an electronic device, such as an integrated circuit or a chip, and the embodiment of the present application does not make any specific limitations.
[0061] The cloud phone application crash diagnosis device in the embodiment of the present application may be a device having an operating system. The operating system may be an Android operating system, an iOS operating system, or other possible operating systems, which are not specifically limited in the embodiment of the present application.
[0062] The cloud phone application crash diagnosis device provided in the embodiment of the present application can achieve Figure 1 To avoid repetition, the various processes implemented in the illustrated method embodiment will not be described again here.
[0063] Alternatively, if Figure 4 As shown, an embodiment of the present application also provides an electronic device 400, including a processor 401 and a memory 402, wherein the memory 402 stores programs or instructions that can be executed on the processor 401, and when the program or instructions are executed by the processor 401, the various steps of the above-mentioned cloud phone application crash diagnosis method are implemented, and the same technical effect can be achieved. To avoid repetition, they will not be repeated here.
[0064] It should be noted that the electronic devices in the embodiments of the present application include the mobile electronic devices and non-mobile electronic devices mentioned above.
[0065] Figure 5 FIG. 5 is a block diagram of another electronic device 500 according to an exemplary embodiment of the present application. The electronic device 500 can be implemented as a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart watch, a TV, etc.
[0066] Typically, the electronic device 500 includes a processor 501 and a memory 502 .
[0067] The processor 501 may include one or more processing cores, such as a 4-core processor, a 10-core processor, etc. The processor 501 may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 501 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 501 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 501 may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.
[0068] The memory 502 may include one or more computer-readable storage media, which may be non-transitory. The memory 502 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in the memory 502 is used to store at least one instruction, which is used to be executed by the processor 501 to implement all or part of the steps in the cloud phone application crash diagnosis method shown in the embodiment of the present application.
[0069] In some embodiments, the electronic device 500 may further optionally include: a peripheral device interface 503 and at least one peripheral device. The processor 501, the memory 502 and the peripheral device interface 503 may be connected via a bus or a signal line. Each peripheral device may be connected to the peripheral device interface 503 via a bus, a signal line or a circuit board. Specifically, the peripheral device includes: at least one of a radio frequency circuit 504, a display screen 505, a camera assembly 506, an audio circuit 507 and a power supply 508.
[0070] In some embodiments, the electronic device 500 further includes one or more sensors 509 , including but not limited to: an acceleration sensor 510 , a gyroscope sensor 511 , a pressure sensor 512 , an optical sensor 513 , and a proximity sensor 514 .
[0071] Those skilled in the art will understand that Figure 5 The structure shown in the figure does not constitute a limitation on the electronic device 500, and may include more or less components than those shown in the figure, or combine some components, or adopt a different component arrangement.
[0072] An embodiment of the present application also provides a computer-readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by a processor, the various processes of the above-mentioned cloud phone application crash diagnosis method are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.
[0073] The processor is the processor in the electronic device described in the above embodiment. The readable storage medium includes a computer readable storage medium, such as a computer read-only memory ROM, a random access memory RAM, a magnetic disk or an optical disk.
[0074] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface is coupled to the processor, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned cloud phone application crash diagnosis method, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.
[0075] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.
[0076] An embodiment of the present application provides a computer program product, which is stored in a storage medium. The program product is executed by at least one processor to implement the various processes of the above-mentioned cloud phone application crash diagnosis method, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.
[0077] It should be noted that, in this article, the terms "comprise", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise one..." do not exclude the presence of other identical elements in the process, method, article or device including the element. In addition, it should be pointed out that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in reverse order according to the functions involved, for example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.
[0078] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.
Claims
1. A cloud phone application crash diagnosis method, characterized in that: include: In the event that a cloud phone application crashes, determining first crash context data corresponding to a crash node based on the running data of the cloud phone application; By performing a derivative process of a heuristic search on the first crash context data, predicting the second crash context data corresponding to the crash node when the cloud phone application crashes next time; generating the crash node tracing data according to the first crash context data and the second crash context data; According to the crash node tracing data, crash diagnosis data corresponding to the operation data is obtained.
2. The method according to claim 1, characterized in that: The method of performing a derivative process of a heuristic search on the first crash context data to predict the second crash context data corresponding to the crash node when the cloud phone application crashes next time includes: determining a search space according to the first crash context data, wherein at least one operation information is recorded in the search space; The first crash context data is taken as an initial node, and the selected heuristic rule is used to sequentially perform operations corresponding to the at least one operation information on the first crash context data to generate the second crash context data.
3. The method according to claim 1, characterized in that Before determining the first crash context data corresponding to the crash node based on the running data of the cloud phone application, the method further includes: Use a monitoring tool, a logger or a data collector to obtain the operating data of the cloud phone application, wherein the operating data includes at least one of the following: application logs, performance indicators, network traffic, and user operation behavior.
4. The method according to claim 1, characterized in that: The determining, based on the running data of the cloud phone application, first crash context data corresponding to the crash node includes: Preprocessing the operation data, wherein the preprocessing includes: removing noise data and removing invalid data; The pre-trained anomaly detection model is used to perform anomaly detection on the pre-processed operation data to determine the first crash context data corresponding to the crash node.
5. The method according to claim 1, characterized in that The determining, based on the running data of the cloud phone application, first crash context data corresponding to the crash node includes: Mining program front-end session data in the running data; Removing the program front-end session data from the operation data to generate updated operation data; Determine first crash context data corresponding to the crashed node according to the updated running data.
6. The method according to claim 1, characterized in that The generating crash node tracing data according to the first crash context data and the second crash context data comprises: comparing the first crash context data and the second crash context data to obtain similarities and differences between the first crash context data and the second crash context data; Determining a traceability path from the first crash context data to the second crash context data according to the similarities and differences; The crash node tracing data is obtained by recording the operations or events performed in each step of the tracing path.
7. The method according to claim 5, characterized in that The generating crash node tracing data according to the first crash context data and the second crash context data comprises: According to the context key field information of the first crash context data, locate the crash node in the second crash context data, and determine the location information of the crash node tracing data; The crash node tracing data is generated according to the location information of the crash node tracing data and the program front-end session data.
8. The method according to claim 7, characterized in that The generating the crash node tracing data according to the location information of the crash node tracing data and the program front-end session data includes: Generate intermediate crash node tracing data according to the location information of the crash node tracing data; Based on the crash node corresponding to each of the program front-end session data, each of the program front-end session data is loaded into the corresponding intermediate crash node tracing data that does not contain the program front-end session data, and the crash node tracing data carrying the program front-end session data is generated.
9. The method according to claim 1, characterized in that: The acquiring crash diagnosis data corresponding to the operation data according to the crash node tracing data includes: Determine the specific location of the crash node in the operation data according to the crash node tracing data; According to the specific location of the crashed node, abnormal diagnosis data is obtained from the operation data.
10. The method according to claim 1, characterized in that The acquiring crash diagnosis data corresponding to the operation data according to the crash node tracing data includes: Determining the dimension information of each of the crashed nodes according to the crashed node tracing data; According to the dimension information of each of the crash nodes, based on a preset crash assessment dimension order, sorting each of the crash nodes; According to the sorted crash nodes, crash diagnosis data related to the crash nodes are collected one by one.