Data processing method, system and device of iOS application crash log and medium

Abstract

The application discloses an iOS application crash log data processing method, system, device and medium, and the method comprises the following steps: a user terminal acquires a target application corresponding to a log collection instruction, acquires target application crash related logs corresponding to the target application through an exception capture mechanism, stores the target application crash related logs according to a log storage strategy, and sends the target application crash related logs to a server according to a preset log reporting strategy; the server analyzes the target application crash related logs according to a symbol table analysis strategy, obtains an exception detection result and displays the exception detection result. The embodiment of the application can more comprehensively collect iOS application crash related data in the user terminal, covers multiple exception types, and then can be automatically analyzed by the symbol table analysis strategy after being uploaded to the server, so that the analysis efficiency and the efficiency of locating the reason for causing the application to run crash are improved.

Description

iOS application crash log data processing methods, systems, devices, and media Technical Field

[0001] This invention relates to the field of log data processing technology, and in particular to data processing methods, systems, devices, and media for iOS application crash logs. Background Technology

[0002] In smart devices running iOS (an operating system developed by Apple), some existing technologies for handling crash logs of installed applications collect some error information through simple built-in logging functions. These technologies typically only capture exceptions of type NSException, and their ability to collect other types of exceptions is very limited.

[0003] In terms of data collection, existing technologies often only obtain simple error causes, making it difficult to comprehensively collect stack traces, image information, and thread information where the exception occurred. Regarding symbol table resolution, developers mostly need to perform complex manual operations locally, which is not only inefficient but also requires a high level of technical expertise, making one-click symbol table resolution difficult. Furthermore, existing technologies almost completely fail to record abnormal user behavior, such as recent page browsing history, which greatly hinders the identification of the root cause of the problem.

[0004] In the storage and reporting stages, existing technologies lack systematicity and stability. Storage may be limited to simple local file storage, neglecting data security and scalability. Reporting mechanisms may also be inflexible and unable to adapt to efficient transmission under different network environments. This incomplete approach to collection, storage, and reporting leads to significant information gaps for developers analyzing application crashes, greatly increasing the difficulty of troubleshooting and resolving issues, and prolonging the application failure resolution cycle. Summary of the Invention

[0005] This invention provides a data processing method, system, device, and medium for iOS application crash logs, aiming to solve the problem that in the prior art, when a smart device with iOS installed uses a simple built-in logging function to collect some error information, it can only obtain simple error reasons and is difficult to comprehensively collect stack information, image information, thread information of the exception, and user behavior operations, resulting in low accuracy for developers to locate the cause of smart device crashes.

[0006] In a first aspect, embodiments of the present invention provide a data processing method for iOS application crash logs, applied to an iOS application crash log data processing system, the iOS application crash log data processing system including a user terminal and a server; the method includes:

[0007] The user terminal responds to a log collection command generated under user authorization and permission, obtains the target application corresponding to the log collection command, and obtains the target application crash-related logs corresponding to the target application through a preset exception capture mechanism;

[0008] The user terminal stores the target application crash-related logs according to a preset log storage strategy;

[0009] The user terminal sends the target application crash-related logs to the server according to a preset log reporting strategy;

[0010] The server parses the crash-related logs of the target application according to a preset symbol table resolution strategy, obtains the anomaly detection results, and displays them.

[0011] Secondly, embodiments of the present invention also provide a data processing system for iOS application crash logs, which includes a user terminal and a server;

[0012] The user terminal is used to respond to a log collection command generated under user authorization, obtain the target application corresponding to the log collection command, and obtain the target application crash-related logs corresponding to the target application through a preset exception capture mechanism;

[0013] The user terminal is also used to store the target application crash-related logs according to a preset log storage strategy;

[0014] The user terminal is also used to send the target application crash-related logs to the server according to a preset log reporting strategy;

[0015] The server is used to parse the crash-related logs of the target application according to a preset symbol table resolution strategy, obtain the anomaly detection results, and display them.

[0016] Thirdly, embodiments of the present invention also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect above.

[0017] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor, can implement the method described in the first aspect above.

[0018] This invention provides a data processing method, system, device, and medium for iOS application crash logs. The method includes: a user terminal responding to a log collection command generated under user authorization, obtaining the target application corresponding to the log collection command, and acquiring crash-related logs of the target application corresponding to the target application through a preset exception capture mechanism; the user terminal storing the crash-related logs of the target application according to a preset log storage strategy; the user terminal sending the crash-related logs of the target application to a server according to a preset log reporting strategy; and the server parsing the crash-related logs of the target application according to a preset symbol table resolution strategy to obtain and display the exception detection results. This invention can more comprehensively collect iOS application crash-related data from user terminals, covering multiple exception types. After being uploaded to the server, it can be automatically parsed with one click through the symbol table resolution strategy, improving parsing efficiency and the efficiency of locating the cause of application crashes. Attached Figure Description

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

[0020] Figure 1 is a schematic diagram of an application scenario for the data processing method for iOS application crash logs provided in an embodiment of the present invention.

[0021] Figure 2 is a flowchart illustrating the data processing method for iOS application crash logs provided in an embodiment of the present invention;

[0022] Figure 3 is a schematic diagram of the first sub-process of the data processing method for iOS application crash logs provided in an embodiment of the present invention;

[0023] Figure 4 is a schematic diagram of the second sub-process of the data processing method for iOS application crash logs provided in an embodiment of the present invention;

[0024] Figure 5 is a schematic diagram of the third sub-process of the data processing method for iOS application crash logs provided in an embodiment of the present invention;

[0025] Figure 6 is a schematic diagram of the fourth sub-process of the data processing method for iOS application crash logs provided in an embodiment of the present invention;

[0026] Figure 7 is a schematic block diagram of the data processing system for iOS application crash logs provided in an embodiment of the present invention;

[0027] Figure 8 is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

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

[0029] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0030] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0031] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0032] Please refer to Figures 1 and 2 simultaneously. Figure 1 is a schematic diagram of a scenario illustrating the data processing method for iOS application crash logs according to an embodiment of the present invention, and Figure 2 is a flowchart illustrating the data processing method for iOS application crash logs provided in an embodiment of the present invention. As shown in Figure 1, the data processing method for iOS application crash logs provided in this embodiment of the present invention is applied to an iOS application crash log data processing system. The iOS application crash log data processing system includes a user terminal 10 and a server 20, and the user terminal 10 and the server 20 are communicatively connected. As shown in Figure 2, the method includes the following steps S110-S140.

[0033] S110. The user terminal responds to the log collection instruction generated under the user's authorized operation, obtains the target application corresponding to the log collection instruction, and obtains the target application crash-related logs corresponding to the target application through a preset exception capture mechanism.

[0034] In this embodiment, the technical solution is described using an iOS application crash log data processing system as the execution entity. The mobile terminal of the iOS application crash log data processing system is equipped with the iOS system. With user authorization, it can collect, report, and analyze application crash logs for one or more specified applications on the mobile terminal. For example, this application uses a specified application on the mobile terminal as an example. After user authorization, logs can be collected from that application as the target application. Generally, the user is prompted for permission to collect logs upon the first launch of the target application. A log collection command is triggered upon the initial user authorization for log collection from the target application. Subsequently, the log collection command can be automatically triggered each time the user launches the target application. The start time of each log collection command's effective period corresponds to the launch time of the target application in this round of operation, and the end time corresponds to the closing time of the target application in this round of operation plus a preset extended collection time. In this way, the corresponding target application crash-related logs can be collected every time the target application is launched.

[0035] In one embodiment, as shown in FIG3, step S110 includes:

[0036] S111. The exception capture mechanism captures multiple preset types of exceptions during the operation of the target application.

[0037] S112. When an exception is captured through the target application crash-related log, obtain the exception capture result, the error cause of the exception, stack information, image information, thread information corresponding to the exception, and user operation behavior data, and combine them with the user ID corresponding to the target application to form the target application crash-related log.

[0038] In this embodiment, each time the target application starts, an exception capture mechanism that is always active captures multiple preset types of exceptions during the operation of the target application. Once the target application crashes, the exception (such as NSException, CPPException, LastDeallocatedNSException, Mach, Signal, etc., and of course, not limited to exception types, the exception detection types of the exception capture mechanism can be expanded according to actual needs) can be captured through the target application crash-related logs. At this time, it is necessary to specifically obtain the exception capture results, the error cause of the exception, stack information, image information, the thread information corresponding to the exception, and user operation behavior data, and combine them with the user ID corresponding to the target application to form the target application crash-related logs. The collection time period of the above data or information is the effective time period of the log collection instruction corresponding to the specific use of the target application in this round, and it is not necessary to collect all the historical logs of the target application in other rounds of use.

[0039] In one embodiment, step S111 includes:

[0040] The exception handling mechanism uses the Objective-C exception handling mechanism to capture exceptions of type NSException or LastDeallocatedNSException, the C++ language layer exception handling mechanism to capture exceptions of type CPPException, the Mach port exception handling mechanism to capture exceptions of type Mach, and the POSIX signal handling interface mechanism to capture exceptions of type Signal.

[0041] In this embodiment, NSException type exceptions are essentially Objective-C runtime exceptions, which can be caught through the Objective-C exception handling mechanism (more specifically, the @try / @catch / @finally syntax in native Objective-C, triggered by [NSExceptionraise:]).

[0042] Exceptions of type LastDeallocedNSException are not inherently independent exception types; rather, they are special cases of NSException. They are exceptions triggered when accessing an Objective-C object that has already been deallocated (a dangling pointer). They need to be converted to NSException through memory checks, or they can be caught through the Objective-C exception handling mechanism.

[0043] CPPException is essentially a C++ language-level exception, which can be caught through the C++ language-level exception handling mechanism (more specifically, it relies on the native C++ try / catch syntax and can be precisely caught by type).

[0044] Mach-type exceptions are essentially the lowest-level kernel-level exceptions and are the source of all user-mode crashes (such as dangling pointers, floating-point errors, illegal instructions, etc.). They can be caught through Mach port exception handling mechanisms (such as methods that specifically include Mach port and kernel inter-process communication callbacks).

[0045] Signal-type exceptions are essentially POSIX signals, which are user-mode interfaces used by the kernel to pass errors / events to processes. Common crash signal types include SIGSEGV (segmentation fault), SIGABRT (voluntary termination), SIGBUS (bus error), and SIGFPE (floating-point error), which can be captured through the POSIX signal handling interface and asynchronous safety callbacks. As can be seen, by employing the aforementioned multiple exception capture mechanisms, several preset types of exceptions can be captured during the execution of the target application.

[0046] In one embodiment, as shown in FIG4, step S112 includes:

[0047] S1121. Obtain the exception capture result, and obtain the error cause of the exception based on the error cause string, error description or code of the exception capture result;

[0048] S1122. Obtain the stack information corresponding to the exception capture result through a preset backtracking function;

[0049] S1123. Obtain the image information corresponding to the exception capture result from the memory mapping of the target application through a preset dynamic linker function;

[0050] S1124. Obtain the thread information corresponding to the exception in the exception capture result through the thread management interface;

[0051] S1125. By tracking the page browsing history of the target application, the user operation behavior data is obtained.

[0052] In this embodiment, when an exception is captured by the exception handling mechanism, such as at least one of the following types: NSException, LastDeallocatedNSException, CPPException, Mach, or Signal, the error cause of the exception needs to be obtained specifically based on the error cause string (for NSException type exceptions), error description (for CPPException type exceptions), or code (for Mach and Signal type exceptions) of the exception capture result, as the current exception error cause. The stack information of the current thread corresponding to the exception capture result needs to be obtained according to a preset backtrace function (i.e., the backtrace function). The information of the binary modules (such as executable files and dynamic libraries) loaded by the target application during this round of use needs to be obtained according to a preset dynamic linker function (i.e., the dyld function), specifically from the memory mapping of the target application, thereby obtaining the image information corresponding to the exception capture result. It is necessary to obtain the thread IDs, names, priorities, and states of threads in the target application during this round of use through the thread management interface. When an exception occurs, the current thread ID is recorded, and the states and stacks of all threads can be retrieved (for analyzing deadlocks and other issues). It is also necessary to track the page browsing history of the target application, specifically by adding recording logic to the lifecycle functions of each page in the target application, thereby obtaining user operation behavior data. After obtaining the above information, it is stored as a crash-related log for the target application, along with the user ID corresponding to the target application, for subsequent data analysis.

[0053] Alternatively, upon detecting a crash in the target application, only the minimum fields from the pre-mapped file (i.e., the mmap file) in the mobile terminal can be written, such as exception codes, registers, critical stack frame hashes, image UUID lists, and thread IDs, using atomic pointer writes. After the user terminal's system recovers, the crash-related logs of the target application can be supplemented with non-crash context data (user behavior, complete thread stack, network environment, etc.) within a certain time period (specifically, the effective period of the log collection command). This approach can reduce secondary crashes and log corruption.

[0054] S120, The user terminal stores the target application crash-related logs according to a preset log storage strategy.

[0055] In this embodiment, the user terminal may store the target application crash-related logs obtained locally according to a preset log storage strategy, or may store the target application crash-related logs on a cloud server connected to the user terminal according to a preset log storage strategy, so as to ensure that the data is not lost.

[0056] In one embodiment, step S120 includes:

[0057] The log storage strategy is used to classify and store the target application crash-related logs according to the exception type corresponding to the exception capture result.

[0058] In this embodiment, a secure and scalable storage structure is adopted when storing target application crash-related logs in the user terminal. Specifically, the user terminal can temporarily store the target application crash-related logs obtained in a local database (which uses a lightweight database such as SQLite) to ensure that the data is not lost in the event of network instability. At the same time, the target application crash-related logs are classified and organized according to certain classification rules (such as the exception type corresponding to the exception capture result). Cloud storage in the cloud server is used as a means of long-term storage and data backup to ensure the security and permanence of the data.

[0059] In one embodiment, the method further includes the following after step S120:

[0060] The current crash fingerprint data is generated based on the exception capture results, error causes, stack information, image information, thread information corresponding to the exception, and user operation behavior data included in the target application crash-related log, and added to the target application crash-related log to update the target application crash-related log.

[0061] In this embodiment, after the current crash fingerprint data of the target application crash-related logs is determined according to the above method and uploaded to the server, the server can perform cluster analysis on the application crash-related logs with the same crash fingerprint data, which facilitates the batch generation of updated versions of the application for the same type of anomaly.

[0062] S130, The user terminal sends the target application crash-related logs to the server according to a preset log reporting strategy.

[0063] In this embodiment, after storing the crash-related logs of the target application on the user terminal, the locally stored crash-related logs need to be sent to the server for further analysis. Furthermore, during the log data upload process, the stability of network communication needs to be monitored, and an appropriate log reporting strategy should be automatically selected based on the current network conditions. For example, timely batch reporting should be performed when the network is good, and interrupted downloads should be resumed when the network is unstable, ensuring that the data is uploaded to the server accurately.

[0064] In one embodiment, as shown in FIG5, step S130 includes:

[0065] S131. If the target application is detected to be in an activated state, the log reporting policy is switched from an inactive state to an active state.

[0066] S132. If it is determined that the communication network between the user terminal and the server is normal, the target application crash-related logs are encapsulated and updated in a preset encapsulation format and sent to the target application crash-related logs through the log reporting strategy.

[0067] S133. If it is determined that the communication network between the user terminal and the server is abnormal or unavailable, after the communication network is detected to be restored to normal, the target application crash-related logs are encapsulated and updated in a preset encapsulation format and sent to the target application crash-related logs through the log reporting strategy.

[0068] In this embodiment, if the target application is detected as running, it indicates that the user has begun using the target application. At this point, the log reporting strategy can be switched from inactive to active. Then, the network status is obtained in real-time through the network monitoring interface to determine network availability, network type (e.g., WiFi, 4G), and network signal strength. If the communication network between the user terminal and the server is determined to be normal based on the above information, the target application crash-related logs are encapsulated and updated in a preset format (e.g., JSON) and sent to the target application crash-related log server using the log reporting strategy. If the communication network between the user terminal and the server is determined to be abnormal or unavailable based on the above information, specific handling is required. If the communication network is unavailable, uploads can resume after the network recovers. If the communication network is abnormal (e.g., due to network interruption), a breakpoint resume mechanism is used to record the position of the sent log data and continue uploading the remaining log data after the network recovers.

[0069] Furthermore, the log collection, storage, and reporting processing functions for the target application executed in the user terminal (corresponding to steps S110~S130) can be encapsulated into an SDK module (i.e., software development kit) to integrate and process log data as a single encapsulated module.

[0070] In practical implementation, a Bloom filter can be set in the mobile terminal's SDK module to determine whether the hash value corresponding to the target application's crash-related logs already exists. If the hash value already exists, it means that the same application crash-related logs have been reported recently. In this case, the user terminal can choose to report only a lightweight crash count packet (such as including a unique exception ID for a specific exception type and its historical crash count) instead of the complete target application crash-related logs, effectively reducing network bandwidth consumption. The complete target application crash-related logs are only reported to the server when the Bloom filter determines that the hash value corresponding to the target application crash-related logs does not exist.

[0071] S140. The server parses the target application crash-related logs according to a preset symbol table resolution strategy, obtains the anomaly detection results, and displays them.

[0072] In this embodiment, when the server receives target application crash-related logs reported by the user terminal, it can automatically parse the target application crash-related logs with one click through the symbol table resolution strategy, thereby quickly obtaining the anomaly detection results and displaying them visually on the corresponding display device of the server, so that the backend operation and maintenance personnel can view them in a timely manner.

[0073] In one embodiment, as shown in FIG6, step S140 includes:

[0074] S141. Obtain the current application exception symbol table corresponding to the target application; wherein, the current application exception symbol table includes symbol information and application code mapping relationship;

[0075] S142. Parse the target application crash-related logs according to the symbol table parsing strategy and the current application exception symbol table to obtain stack trace information;

[0076] S143. The number of lines of code involved in the exception is obtained by parsing the stack trace information;

[0077] S144. Obtain the error cause and the thread information corresponding to the exception from the crash-related logs of the target application, and combine the exception detection result with the thread information corresponding to the exception and display it accordingly.

[0078] In this embodiment, when parsing the target application crash-related logs on the server, the current application's exception symbol table (specifically a dSYM format file) is first obtained. Before this acquisition, the target application crash-related logs can be format-verified and integrity-checked to ensure data accuracy. Then, the target application crash-related logs are parsed according to the symbol table parsing strategy and the current application exception symbol table (the current application exception symbol table can be deployed as a server interface, effectively reducing the operational difficulty and technical threshold for backend maintenance personnel and improving parsing efficiency). Utilizing the symbol information and application code mapping relationship stored in the current application exception symbol table, a one-click symbol table parsing function is achieved, accurately obtaining stack trace information and parsing and calculating the number of exception code lines. Finally, the parsed exception code line number is integrated with other collected information (such as the error cause, the corresponding thread information, and the user ID) to form the exception detection result, which is then displayed. It is evident that the above parsing process, with the obtained exception code line number and other collected information recording abnormal user behavior operations, provides crucial information for problem localization, improving the overall efficiency of resolving application crash problems.

[0079] At this point, the server's backend maintenance personnel can view the anomaly detection results, repair the corresponding current anomaly, update the repair status corresponding to the anomaly detection results (such as updating from the initial unrepaired status to the repaired status), and update the current version of the target application accordingly before pushing it to the user terminal for application update, thereby preventing the target application from experiencing the same application crash in subsequent use.

[0080] As can be seen, the implementation of this method can collect more comprehensive data related to iOS application crashes on user terminals, covering a variety of exception types. After being uploaded to the server, it can be automatically parsed with one click through the symbol table resolution strategy, which improves the parsing efficiency and the efficiency of locating the cause of application crashes.

[0081] Figure 7 is a schematic block diagram of a data processing system for iOS application crash logs provided in an embodiment of the present invention. As shown in Figure 7, corresponding to the above-described data processing method for iOS application crash logs, the present invention also provides a data processing system 1 for iOS application crash logs. This data processing system 1 for iOS application crash logs includes a unit for executing the above-described data processing method for iOS application crash logs. Referring to Figures 1 and 7, this data processing system 1 for iOS application crash logs includes a user terminal 10 and a server 20, and the user terminal 10 is communicatively connected to the server 20.

[0082] The user terminal 10 is used to respond to a log collection command generated under user authorization, obtain the target application corresponding to the log collection command, and obtain the target application crash-related logs corresponding to the target application through a preset exception capture mechanism.

[0083] In this embodiment, the technical solution is described using an iOS application crash log data processing system as the execution entity. The mobile terminal of the iOS application crash log data processing system is equipped with the iOS system. With user authorization, it can collect, report, and analyze application crash logs for one or more specified applications on the mobile terminal. For example, this application uses a specified application on the mobile terminal as an example. After user authorization, logs can be collected from that application as the target application. Generally, the user is prompted for permission to collect logs upon the first launch of the target application. A log collection command is triggered upon the initial user authorization for log collection from the target application. Subsequently, the log collection command can be automatically triggered each time the user launches the target application. The start time of each log collection command's effective period corresponds to the launch time of the target application in this round of operation, and the end time corresponds to the closing time of the target application in this round of operation plus a preset extended collection time. In this way, the corresponding target application crash-related logs can be collected every time the target application is launched.

[0084] In one embodiment, the user terminal 10 is specifically used for:

[0085] The exception capture mechanism captures multiple preset types of exceptions during the execution of the target application.

[0086] When an exception is captured through the target application crash-related logs, the exception capture result, the error cause of the exception, stack information, image information, thread information corresponding to the exception, and user operation behavior data are obtained, and combined with the user ID corresponding to the target application to form the target application crash-related logs.

[0087] In this embodiment, each time the target application starts, an exception capture mechanism that is always active captures multiple preset types of exceptions during the operation of the target application. Once the target application crashes, the exception (such as NSException, CPPException, LastDeallocatedNSException, Mach, Signal, etc., and of course, not limited to exception types, the exception detection types of the exception capture mechanism can be expanded according to actual needs) can be captured through the target application crash-related logs. At this time, it is necessary to specifically obtain the exception capture results, the error cause of the exception, stack information, image information, the thread information corresponding to the exception, and user operation behavior data, and combine them with the user ID corresponding to the target application to form the target application crash-related logs. The collection time period of the above data or information is the effective time period of the log collection instruction corresponding to the specific use of the target application in this round, and it is not necessary to collect all the historical logs of the target application in other rounds of use.

[0088] In one embodiment, the step of capturing multiple preset types of exceptions during the execution of the target application through the exception capture mechanism includes:

[0089] The exception handling mechanism uses the Objective-C exception handling mechanism to capture exceptions of type NSException or LastDeallocatedNSException, the C++ language layer exception handling mechanism to capture exceptions of type CPPException, the Mach port exception handling mechanism to capture exceptions of type Mach, and the POSIX signal handling interface mechanism to capture exceptions of type Signal.

[0090] In this embodiment, NSException type exceptions are essentially Objective-C runtime exceptions, which can be caught through the Objective-C exception handling mechanism (more specifically, the @try / @catch / @finally syntax in native Objective-C, triggered by [NSExceptionraise:]).

[0091] Exceptions of type LastDeallocedNSException are not inherently independent exception types; rather, they are special cases of NSException. They are exceptions triggered when accessing an Objective-C object that has already been deallocated (a dangling pointer). They need to be converted to NSException through memory checks, or they can be caught through the Objective-C exception handling mechanism.

[0092] CPPException is essentially a C++ language-level exception, which can be caught through the C++ language-level exception handling mechanism (more specifically, it relies on the native C++ try / catch syntax and can be precisely caught by type).

[0093] Mach-type exceptions are essentially the lowest-level kernel-level exceptions and are the source of all user-mode crashes (such as dangling pointers, floating-point errors, illegal instructions, etc.). They can be caught through Mach port exception handling mechanisms (such as methods that specifically include Mach port and kernel inter-process communication callbacks).

[0094] Signal-type exceptions are essentially POSIX signals, which are user-mode interfaces used by the kernel to pass errors / events to processes. Common crash signal types include SIGSEGV (segmentation fault), SIGABRT (voluntary termination), SIGBUS (bus error), and SIGFPE (floating-point error), which can be captured through the POSIX signal handling interface and asynchronous safety callbacks. As can be seen, by employing the aforementioned multiple exception capture mechanisms, several preset types of exceptions can be captured during the execution of the target application.

[0095] In one embodiment, the user terminal 10 is further specifically used for:

[0096] Obtain the exception capture result, and obtain the error cause of the exception based on the error cause string, error description, or code of the exception capture result;

[0097] Obtain the stack information corresponding to the exception capture result through a preset backtracking function;

[0098] The image information corresponding to the exception capture result is obtained from the memory mapping of the target application through a preset dynamic linker function;

[0099] Obtain the thread information corresponding to the exception in the exception capture result through the thread management interface;

[0100] The user's operational behavior data is obtained by tracking the page browsing history of the target application.

[0101] In this embodiment, when an exception is captured by the exception handling mechanism, such as at least one of the following types: NSException, LastDeallocatedNSException, CPPException, Mach, or Signal, the error cause of the exception needs to be obtained specifically based on the error cause string (for NSException type exceptions), error description (for CPPException type exceptions), or code (for Mach and Signal type exceptions) of the exception capture result, as the current exception error cause. The stack information of the current thread corresponding to the exception capture result needs to be obtained according to a preset backtrace function (i.e., the backtrace function). The information of the binary modules (such as executable files and dynamic libraries) loaded by the target application during this round of use needs to be obtained according to a preset dynamic linker function (i.e., the dyld function), specifically from the memory mapping of the target application, thereby obtaining the image information corresponding to the exception capture result. It is necessary to obtain the thread IDs, names, priorities, and states of threads in the target application during this round of use through the thread management interface. When an exception occurs, the current thread ID is recorded, and the states and stacks of all threads can be retrieved (for analyzing deadlocks and other issues). It is also necessary to track the page browsing history of the target application, specifically by adding recording logic to the lifecycle functions of each page in the target application, thereby obtaining user operation behavior data. After obtaining the above information, it is stored as a crash-related log for the target application, along with the user ID corresponding to the target application, for subsequent data analysis.

[0102] Alternatively, upon detecting a crash in the target application, only the minimum fields from the pre-mapped file (i.e., the mmap file) in the mobile terminal can be written, such as exception codes, registers, critical stack frame hashes, image UUID lists, and thread IDs, using atomic pointer writes. After the user terminal's system recovers, the crash-related logs of the target application can be supplemented with non-crash context data (user behavior, complete thread stack, network environment, etc.) within a certain time period (specifically, the effective period of the log collection command). This approach can reduce secondary crashes and log corruption.

[0103] The user terminal 10 is also used to store the target application crash-related logs according to a preset log storage strategy.

[0104] In this embodiment, the user terminal may store the target application crash-related logs obtained locally according to a preset log storage strategy, or may store the target application crash-related logs on a cloud server connected to the user terminal according to a preset log storage strategy, so as to ensure that the data is not lost.

[0105] In one embodiment, the user terminal 10 is further specifically used for:

[0106] The log storage strategy is used to classify and store the target application crash-related logs according to the exception type corresponding to the exception capture result.

[0107] In this embodiment, a secure and scalable storage structure is adopted when storing target application crash-related logs in the user terminal. Specifically, the user terminal can temporarily store the target application crash-related logs obtained in a local database (which uses a lightweight database such as SQLite) to ensure that the data is not lost in the event of network instability. At the same time, the target application crash-related logs are classified and organized according to certain classification rules (such as the exception type corresponding to the exception capture result). Cloud storage in the cloud server is used as a means of long-term storage and data backup to ensure the security and permanence of the data.

[0108] In one embodiment, the user terminal 10 is further specifically used for:

[0109] The current crash fingerprint data is generated based on the exception capture results, error causes, stack information, image information, thread information corresponding to the exception, and user operation behavior data included in the target application crash-related log, and added to the target application crash-related log to update the target application crash-related log.

[0110] In this embodiment, after the current crash fingerprint data of the target application crash-related logs is determined according to the above method and uploaded to the server, the server can perform cluster analysis on the application crash-related logs with the same crash fingerprint data, which facilitates the batch generation of updated versions of the application for the same type of anomaly.

[0111] The user terminal 10 is also used to send the target application crash-related logs to the server according to a preset log reporting strategy.

[0112] In this embodiment, after storing the crash-related logs of the target application on the user terminal, the locally stored crash-related logs need to be sent to the server for further analysis. Furthermore, during the log data upload process, the stability of network communication needs to be monitored, and an appropriate log reporting strategy should be automatically selected based on the current network conditions. For example, timely batch reporting should be performed when the network is good, and interrupted downloads should be resumed when the network is unstable, ensuring that the data is uploaded to the server accurately.

[0113] In one embodiment, the user terminal 10 is further specifically used for:

[0114] If the target application is detected to be running, the log reporting policy is switched from inactive to active.

[0115] If it is determined that the communication network between the user terminal and the server is normal, the target application crash-related logs are encapsulated and updated in a preset encapsulation format and sent to the target application crash-related logs through the log reporting strategy.

[0116] If it is determined that the communication network between the user terminal and the server is abnormal or unavailable, then after the communication network is detected to be restored to normal, the target application crash-related logs are encapsulated and updated in a preset encapsulation format and sent to the target application crash-related logs through the log reporting strategy.

[0117] In this embodiment, if the target application is detected as running, it indicates that the user has begun using the target application. At this point, the log reporting strategy can be switched from inactive to active. Then, the network status is obtained in real-time through the network monitoring interface to determine network availability, network type (e.g., WiFi, 4G), and network signal strength. If the communication network between the user terminal and the server is determined to be normal based on the above information, the target application crash-related logs are encapsulated and updated in a preset format (e.g., JSON) and sent to the target application crash-related log server using the log reporting strategy. If the communication network between the user terminal and the server is determined to be abnormal or unavailable based on the above information, specific handling is required. If the communication network is unavailable, uploads can resume after the network recovers. If the communication network is abnormal (e.g., due to network interruption), a breakpoint resume mechanism is used to record the position of the sent log data and continue uploading the remaining log data after the network recovers.

[0118] Furthermore, the log collection, storage, and reporting processing functions for the target application executed in the user terminal can be encapsulated into an SDK module (i.e., software development kit) to integrate and process log data as a single encapsulated module.

[0119] In practical implementation, a Bloom filter can be set in the mobile terminal's SDK module to determine whether the hash value corresponding to the target application's crash-related logs already exists. If the hash value already exists, it means that the same application crash-related logs have been reported recently. In this case, the user terminal can choose to report only a lightweight crash count packet (such as including a unique exception ID for a specific exception type and its historical crash count) instead of the complete target application crash-related logs, effectively reducing network bandwidth consumption. The complete target application crash-related logs are only reported to the server when the Bloom filter determines that the hash value corresponding to the target application crash-related logs does not exist.

[0120] The server 20 is used to parse the crash-related logs of the target application according to a preset symbol table resolution strategy, obtain the anomaly detection results, and display them.

[0121] In this embodiment, when the server receives target application crash-related logs reported by the user terminal, it can automatically parse the target application crash-related logs with one click through the symbol table resolution strategy, thereby quickly obtaining the anomaly detection results and displaying them visually on the corresponding display device of the server, so that the backend operation and maintenance personnel can view them in a timely manner.

[0122] In one embodiment, the server 20 is specifically used for:

[0123] Obtain the current application exception symbol table corresponding to the target application; wherein, the current application exception symbol table includes symbol information and application code mapping relationship;

[0124] The target application crash-related logs are parsed according to the symbol table resolution strategy and the current application exception symbol table to obtain stack trace information;

[0125] The number of lines of code involved in the exception is obtained by parsing the stack trace information.

[0126] Obtain the error cause and the corresponding thread information from the crash-related logs of the target application, and combine them with the corresponding thread information to form the exception detection result and display it accordingly.

[0127] In this embodiment, when parsing the target application crash-related logs on the server, the current application's exception symbol table (specifically a dSYM format file) is first obtained. Before this acquisition, the target application crash-related logs can be format-verified and integrity-checked to ensure data accuracy. Then, the target application crash-related logs are parsed according to the symbol table parsing strategy and the current application exception symbol table (the current application exception symbol table can be deployed as a server interface, effectively reducing the operational difficulty and technical threshold for backend maintenance personnel and improving parsing efficiency). Utilizing the symbol information and application code mapping relationship stored in the current application exception symbol table, a one-click symbol table parsing function is achieved, accurately obtaining stack trace information and parsing and calculating the number of exception code lines. Finally, the parsed exception code line number is integrated with other collected information (such as the error cause, the corresponding thread information, and the user ID) to form the exception detection result, which is then displayed. It is evident that the above parsing process, with the obtained exception code line number and other collected information recording abnormal user behavior operations, provides crucial information for problem localization, improving the overall efficiency of resolving application crash problems.

[0128] At this point, the server's backend maintenance personnel can view the anomaly detection results, repair the corresponding current anomaly, update the repair status corresponding to the anomaly detection results (such as updating from the initial unrepaired status to the repaired status), and update the current version of the target application accordingly before pushing it to the user terminal for application update, thereby preventing the target application from experiencing the same application crash in subsequent use.

[0129] As can be seen, the implementation of this system can collect more comprehensive data related to iOS application crashes on user terminals, covering a variety of exception types. After being uploaded to the server, it can be automatically parsed with one click through the symbol table resolution strategy, which improves the parsing efficiency and the efficiency of locating the cause of application crashes.

[0130] The data processing system for the aforementioned iOS application crash logs can be implemented as a computer program that can run on the computer device shown in Figure 8.

[0131] Please refer to Figure 8, which is a schematic block diagram of a computer device provided in an embodiment of the present invention. This computer device integrates a data processing system for iOS application crash logs provided in any of the embodiments of the present invention.

[0132] Referring to Figure 8, the computer device 400 includes a processor 402, a memory, and a network interface 405 connected via a system bus 401. The memory may include a storage medium 403 and internal memory 404.

[0133] The storage medium 403 may store an operating system 4031 and a computer program 4032. The computer program 4032 includes program instructions that, when executed, cause the processor 402 to perform a data processing method for iOS application crash logs.

[0134] The processor 402 provides computing and control capabilities to support the operation of the entire computer device.

[0135] The internal memory 404 provides an environment for the computer program 4032 in the storage medium 403 to run. When the computer program 4032 is executed by the processor 402, the processor 402 can execute the above-mentioned data processing method for iOS application crash logs.

[0136] The network interface 405 is used for network communication with other devices. Those skilled in the art will understand that the structure shown in FIG8 is merely a block diagram of a portion of the structure related to the present invention and does not constitute a limitation on the computer device to which the present invention is applied. Specific computer devices may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0137] The processor 402 is used to run the computer program 4032 stored in the memory to implement the above-mentioned data processing method for iOS application crash logs.

[0138] It should be understood that, in this embodiment of the invention, the processor 402 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0139] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0140] Therefore, the present invention also provides a computer-readable storage medium. This computer-readable storage medium stores a computer program, wherein the computer program includes program instructions. When executed by a processor, the program instructions cause the processor to perform the aforementioned data processing method for iOS application crash logs.

[0141] The storage medium can be any computer-readable storage medium that can store program code, such as a USB flash drive, external hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0142] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0143] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0144] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0145] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0146] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A data processing method for iOS application crash logs, applied to an iOS application crash log data processing system, characterized in that, The iOS application crash log data processing system includes a user terminal and a server; the method includes: the user terminal responds to a log collection instruction generated under user-authorized operation, obtains the target application corresponding to the log collection instruction, and obtains the target application crash-related logs corresponding to the target application through a preset exception capture mechanism; the start time of the effective time period of the log collection instruction corresponds to the start time of the target application's current operation, and the end time corresponds to the close time of the target application's current operation plus a preset extended collection time; the user terminal stores the target application crash-related logs according to a preset log storage strategy; the user terminal sends the target application crash-related logs to the server according to a preset log reporting strategy; the server parses the target application crash-related logs according to a preset symbol table parsing strategy, obtains and displays the exception detection results; the method includes: the user terminal responds to a log collection instruction generated under user-authorized operation, obtains the target application crash-related logs corresponding to the log collection instruction, and obtains the target application crash-related logs ... symbol table parsing strategy, obtains the exception detection results and obtains the exception detection results; the method includes: the user terminal responds to a log collection instruction generated under user-authorized operation, obtains the target application crash-related logs corresponding to the target application's current operation, and obtains the target application crash-related logs The exception capture mechanism acquires target application crash-related logs corresponding to the target application, including: capturing multiple preset types of exceptions during the operation of the target application through the exception capture mechanism; when an exception is captured through the target application crash-related logs, acquiring the exception capture result, the error cause of the exception, stack information, image information, thread information corresponding to the exception, and user operation behavior data, and combining them with the user ID corresponding to the target application to form the target application crash-related logs; when a crash is detected in the target application, using atomic write pointers to write exception codes, registers, key stack frame hashes, image UUID lists, and thread IDs, and after the system of the user terminal recovers to normal, supplementing the target application crash-related logs with the non-crash context of the effective time period of the log collection instruction; wherein the non-crash context of the effective time period of the log collection instruction includes user behavior, complete thread stack, and network environment.

2. The method according to claim 1, characterized in that, The method of capturing multiple preset types of exceptions during the operation of the target application through the exception capture mechanism includes: capturing exceptions of type NSException or LastDeallocatedNSException through the Objective-C exception handling mechanism in the exception capture mechanism; capturing exceptions of type CPPException through the C++ language layer exception handling mechanism in the exception capture mechanism; capturing exceptions of type Mach through the Mach port exception handling mechanism in the exception capture mechanism; and capturing exceptions of type Signal through the POSIX signal handling interface handling mechanism in the exception capture mechanism.

3. The method according to claim 1, characterized in that, The process of obtaining the exception capture result, the error cause of the exception, stack information, image information, thread information corresponding to the exception, and user operation behavior data includes: obtaining the exception capture result, and obtaining the error cause of the exception based on the error cause string, error description, or code of the exception capture result; obtaining the stack information corresponding to the exception capture result through a preset backtracking function; obtaining the image information corresponding to the exception capture result from the memory mapping of the target application through a preset dynamic linker function; obtaining the thread information corresponding to the exception in the exception capture result through a thread management interface; and obtaining the user operation behavior data by tracking the page browsing history of the target application.

4. The method according to claim 1, characterized in that, The step of storing the target application crash-related logs according to a preset log storage strategy includes: classifying and storing the target application crash-related logs according to the exception type corresponding to the exception capture result through the log storage strategy.

5. The method according to claim 1, characterized in that, The step of sending the target application crash-related logs to the server according to a preset log reporting strategy includes: if the target application is detected to be running, switching the log reporting strategy from an inactive state to an active state; if it is determined that the communication network between the user terminal and the server is normal, then encapsulating and updating the target application crash-related logs in a preset encapsulation format according to the log reporting strategy and sending them to the target application crash-related logs; if it is determined that the communication network between the user terminal and the server is abnormal or unavailable, then after detecting that the communication network has returned to normal, encapsulating and updating the target application crash-related logs in a preset encapsulation format according to the log reporting strategy and sending them to the target application crash-related logs.

6. The method according to claim 1, characterized in that, The step of parsing the target application crash-related logs according to a preset symbol table resolution strategy to obtain and display anomaly detection results includes: obtaining a current application anomaly symbol table corresponding to the target application; wherein the current application anomaly symbol table includes symbol information and application code mapping relationships; parsing the target application crash-related logs according to the symbol table resolution strategy and the current application anomaly symbol table to obtain stack trace information; obtaining the abnormal code line number by parsing the stack trace information; obtaining the error cause of the anomaly and the thread information corresponding to the anomaly in the target application crash-related logs, and combining the thread information corresponding to the anomaly with the anomaly detection results and displaying them accordingly.

7. A data processing system for iOS application crash logs, characterized in that, It includes a user terminal and a server; the user terminal is used to respond to a log collection command generated under user authorization, obtain the target application corresponding to the log collection command, and obtain the target application crash-related logs corresponding to the target application through a preset exception capture mechanism; the start time of the effective time period of the log collection command corresponds to the start time of the target application's current operation, and the end time corresponds to the shutdown time of the target application's current operation plus a preset extended collection time; The user terminal is also used to store the target application crash-related logs according to a preset log storage strategy; the user terminal is also used to send the target application crash-related logs to the server according to a preset log reporting strategy; the server is used to parse the target application crash-related logs according to a preset symbol table resolution strategy, obtain anomaly detection results, and display them. The step of obtaining target application crash-related logs corresponding to the target application through a preset exception capture mechanism includes: capturing multiple preset types of exceptions during the operation of the target application through the exception capture mechanism; When an exception is captured through the target application crash-related logs, the exception capture result, the error cause of the exception, stack information, image information, thread information corresponding to the exception, and user operation behavior data are obtained, and combined with the user ID corresponding to the target application to form the target application crash-related logs; when a crash of the target application is detected, the exception code, registers, key stack frame hash, image UUID list, and thread ID are written using atomic write pointers, and the target application crash-related logs are supplemented with the non-crash context of the effective time period of the log collection command after the user terminal system recovers to normal; wherein the non-crash context of the effective time period of the log collection command includes user behavior, complete thread stack, and network environment.

8. A computer device, characterized in that, The computer device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the data processing method for iOS application crash logs as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, implement the data processing method for iOS application crash logs as described in any one of claims 1-6.

Images