Ios-watchdog watchdog mechanism

background

Application 100% Loss completely failed to start and crashed. Completely cut off the network connection normal boot, debugging mode state of waiting time is very long, but can be started, and with the UI micro-card. A strong feeling that this is thread blocking. Some time ago by the Core Data concurrency toss, see thread problem is slightly flustered. reason

First look at the crash log, as a guess, is really stuck in the main thread; unexpectedly, countless flash-back left only a crash log, as follows:

The first time I saw it, I read some information and I could understand what it was all about. To avoid the failure of the application to cause the interface to be unresponsive, Apple designed the watchdog (watchdog) mechanism. Once timed out, force the kill process. The time to trigger the watchdog mechanism varies in different life cycles:

First of all, to say that the abnormal code, but also the implication is quite deep. 8badf00d = ate bad food, probably is saying that the watchdog eats the rotten food therefore to go violently. An exception record indicates that this is not a crash (a smile: forced withdrawal). The information column indicates a time limit of S. In combination with the application business, the surface reason is: every time you start the application, first a template synchronization, before this need to detect the login status, through the Runloop repeatedly tried until the response was received. Unfortunately, however, this is all happening in the main thread.

Synchronous network request, main thread, super long timeout time, meet these three points, a certain scenario will almost certainly trigger the watchdog mechanism. Countermeasures

A reasonable solution: Asynchronous network requests: The advantages are many, the most important thing is to let you have a carefree and safe access to the network without worrying about the thread. To use synchronous network requests in a non-main thread: if it's harder to run your network code asynchronously (perhaps your application is a large porting project based on synchronous network requests), you can also run synchronization code in a secondary thread, or you can avoid triggering a watchdog mechanism.

In addition, in some cases, such as when the watchdog is triggered when a login and template sync is encountered, in fact, even if it is possible to request again when applying to the template, it is OK to skip the network request first. At this point, I also use a scheme that I think is relatively poor: manipulate everything through runloop, and if you exceed the established timeout, prompt the user to retry or skip the network request for the time being.

The network part of the application is based on the common framework of the company, so priority is given to network requests in the non main thread to avoid triggering the watchdog.

As for the reason why the application can start normally in debug mode, it is entirely because the watchdog mechanism is disabled in this mode.

In addition, in addition to network operations, I/O read-write files and large-scale operations and other time-consuming tasks are also very likely to trigger the watchdog mechanism. reasonable handling of threads, optimization of time-consuming tasks, to a large extent to avoid poor user experience. Reference: Synchronous network requests on the main thread debug mode does not occur crash link: HTTPS://WWW.JIANSHU.COM/P/2E47AD0C8FCE