How to report crash logs when iOS App crashes continuously

To ensure the user experience of online apps, we usually monitor the crash rate of online apps in real time. Once a spike is detected, we can immediately investigate the cause. However, the premise of all this is that the crash log can be reported accurately.

[[225352]]

There are two difficulties in reporting crash logs:

The code before the crash handler is installed must be absolutely stable

• If the log collector crashes before it is successfully started, no logs can be collected. There are not many tricks to this, you can only strictly limit the code that can be executed before the handler is started.

App *** loop crash report

• When the crash log is reported, a network request will be sent. What if the App crashes again before the request succeeds? The user may even fall into a crash cycle.

This article describes how to accurately report crash logs when the second situation occurs.

First, we need a more reliable way to determine whether a startup crash occurred last time when the app is started. Here is a feasible idea.

How to detect continuous flash backs

Continuous flashbacks contain two elements, flashback and continuous. Only when these two elements are present at the same time will it affect our log upload. The definition of flashback can be simply as follows:

 App crash time - app startup time <= 5s (or other threshold)

Continuous is defined as at least two or more consecutive crashes. Usually two crashes are enough, and users often give up trying after experiencing two consecutive crashes.

We can try to restore the life cycle of the App crash scenario by recording several special time points and timestamps.

App launch timestamp, defined as launchTs

• Each time the App is started, the current time is recorded and written into the time array.

App crash timestamp, defined as crashTs

• Each time the App is started, the timestamp of the last crash report is obtained through the crash collection library and written into the time array.

App normal exit timestamp, defined as terminateTs

• When the App receives the UIApplicationWillTerminateNotification notification, it records the current timestamp and writes it into the time array. Note that there are many timestamps of App exit behaviors that cannot be accurately recorded.

The reason for recording terminateTs is to exclude a special case where the user manually kills the app immediately after launching it. If we record the above three timestamps correctly, we can get a timeline related to the App crash behavior. For example:

 launchTs => crashTs => launchTs => terminateTs

or

 launchTs => launchTs => launchTs

or

 launchTs => crashTs => launchTs => crashTs => launchTs

Please use your imagination to analyze the behavior characteristics of the three timelines above. Obviously, the third timeline seems to have crashed twice in a row. We only need to add the time interval to determine whether it is two consecutive crashes. Note that if there is a terminateTs between two crashTs, it cannot be considered as a continuous crash. The detection code is relatively simple, so I will not post it.

This timeline only records the App startup and exit behaviors related to the crash. There are many special time points that are not recorded, such as the App being out of memory (FOOM) in the foreground, the App being killed by the system Watch Dog because the main thread is stuck in the foreground, the App being forcibly killed during iOS system upgrades, the App being forcibly killed when upgraded from the AppStore, etc. These special time points are not recorded, but they do not affect our App continuous crash detection, so they can be ignored.

It should be noted that since the timeline record needs to be read from the disk at startup, which involves disk reading and writing, it will affect the startup time of the App. One optimization point is to remove the older timestamps at each write time point, such as only recording the latest 5 timestamps. Or when no crash log is read, there is no need to start the entire process of continuous crash detection.

Next, let's see how we can continue uploading logs if continuous crashes are detected.

Synchronously wait for Crash log upload

The most straightforward way is to wait for the log to be uploaded successfully before the App code continues to execute.

Change the network request to synchronous? This will jam the UI thread, and in scenarios with poor network connection, the system watch dog will kill it, which is obviously not advisable.

We can still maintain asynchronous network requests, but temporarily interrupt the UI thread process, so that the entire App is waiting in the runloop of the UI thread. Once the network request is successful, it jumps back to the original code flow of the UI thread.

Although the implementation is simple, there are a few details that need attention. First, we need to add an App interaction. Once the runloop is entered, a loading interface is displayed to inform the user to wait patiently. Second, the waiting time should not be too long. I personally recommend no more than 5 seconds. Once it exceeds 5 seconds, regardless of whether the request to upload the crash log is successful, the original App code flow should be restored. The situation where the log cannot be uploaded successfully within 5 seconds should be relatively rare unless the log file is too large.

This approach also has obvious flaws. First, the changes are relatively large (modification of the original code flow), second, new UI interactions need to be added, and third, the user's waiting time is prolonged.

Let's look at another trick.

Enable background process to upload crash logs

In fact, the most ideal log upload is to put the uploaded request into another different process, so that even if the App crashes again, it will not affect the execution of the code of another process.

The problem is that iOS apps are in a sandbox environment, and the system does not allow the code to fork a new process.

Fortunately, starting from iOS 8, the system has added a background session feature to NSURLSession. This feature allows NSURLSession to put network requests into a separate process for execution. I personally feel that this feature was originally designed to enhance the experience of downloading audio and video resources in the background of certain apps. After actual testing, I found that no matter downloading or uploading, we can put network requests into another process. The code is also very simple. For example, I wrote the following test code:

 NSURLSessionConfiguration *config = [NSURLSessionConfiguration backgroundSessionConfigurationWithIdentifier:@ "com.mrpeak.background.crashupload" ];
 NSURLSession *session = [NSURLSession sessionWithConfiguration:config delegate:self delegateQueue:[NSOperationQueue new]];
 NSURL *url = [NSURL URLWithString:@ "https://images.unsplash.com/photo-1515816949419-7caf0a210607?ixlib=rb-0.3.5&ixid=eyJ hcHBfaWQiOjEyMDd9&s=f46b60857b4826e733da34993ec26a2f&auto=format&fit=crop&w=1534&q=80" ];
 NSURLSessionDownloadTask *task = [session downloadTaskWithURL:url];
 [task resume]; 
  
 exit(0);

After execution, we can see the following log in the console:

We can clearly see how the nsurlsessiond process completes the network request for us and tries to wake up the App that has exited abnormally.

Of course, this most ideal method also has some details to deal with. For example, how to inform the App that a crash log has been successfully uploaded and removed from the local computer. Since the App that crashes continuously is in an extremely unstable state, no code logic can ensure smooth completion.

I personally feel that an ideal way is to add a special flag to the logs reported by the background process, and then use the client request ID and this flag to deduplicate and sort in the background.

The continuous crash of online apps is an extremely bad and terrible failure. The terrible thing is that when a large number of continuous crashes occur and cannot be monitored, you are humming a little tune and typing code, and your boss suddenly finds that the app on his phone cannot be started. When you open the AppStore, you will find a flood of one-star bad reviews. If it is a mainstream app, it will even be on the technology news. It is not difficult to predict that a big black pot is taking shape. The next app upgrade introduction will definitely include "fire peter".

The full text is over.