iOS-Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d

太过爱你忘了你带给我的痛 2023-10-17 19:26 5阅读 0赞

Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d

异常代码 0x8badf00d 指示应用程序已终止的 [iOS][] 因为watch dog超时发生。应用程序时间太长，启动、 终止，或对系统事件作出响应。一个常见的原因做在主线程上的同步联网。无论操作是线程 0 上： 需要搬到后台线程，或处理方式不同，所以，它不会阻止在主线程

特贴出官方文档：

**Listing 1** Watchdog timeout crash report

<table> 
 <tbody> 
  <tr> 
   <td><pre>Exception Type: 00000020 Exception Codes: 0x8badf00d</pre></td> 
  </tr> 
 </tbody> 
</table>

The most common cause for watchdog timeout crashes in a network application is synchronous networking on the main thread. There are four contributing factors here:

1.  synchronous networking — This is where you make a network request and block waiting for the response.
2.  main thread — Synchronous networking is less than ideal in general, but it causes specific problems if you do it on the main thread. Remember that the main thread is responsible for running the user interface. If you block the main thread for any significant amount of time, the user interface becomes unacceptably unresponsive.
3.  long timeouts — If the network just goes away (for example, the user is on a train which goes into a tunnel), any pending network request won't fail until some timeout has expired. Most network timeouts are measured in minutes, meaning that a blocked synchronous network request on the main thread can keep the user interface unresponsive for minutes at a time.
    
    Trying to avoid this problem by reducing the network timeout is not a good idea. In some situations it can take many seconds for a network request to succeed, and if you always time out early then you'll never make any progress at all.
4.  watchdog — In order to keep the user interface responsive, iOS includes a watchdog mechanism. If your application fails to respond to certain user interface events (launch, suspend, resume, terminate) in time, the watchdog will kill your application and generate a watchdog timeout crash report. The amount of time the watchdog gives you is not formally documented, but it's always less than a network timeout.

One tricky aspect of this problem is that it's highly dependent on the network environment. If you always test your application in your office, where network connectivity is good, you'll never see this type of crash. However, once you start deploying your application to end users—who will run it in all sorts of network environments—crashes like this will become common.

**Warning:** To summarize, if you make synchronous networking calls on the main thread, your application will suffer from watchdog timeout crashes when it's deployed to a wide range of users.

Given a watchdog timeout crash report, you can find the problematic code by looking at the backtrace of the main thread (thread 0). Listing 2 is a typical example.

**Listing 2** Bad app, no biscuit

<table> 
 <tbody> 
  <tr> 
   <td><pre>Thread 0:
0   libSystem.B.dylib 0x00001668 mach_msg_trap + 20
1   libSystem.B.dylib 0x00003734 mach_msg + 44
2   CoreFoundation    0x0002296e CFRunLoopRunSpecific + 1150
3   CoreFoundation    0x000224da CFRunLoopRunInMode + 42
4   CFNetwork         0x0002b118 CFURLConnectionSendSynchronousRequest + 244
5   Foundation        0x000a45a2 +[NSURLConnection sendSynchronousRequest:returningResponse[…]
6   MyBadApp          0x000063f6 0x1000 + 21494
7   MyBadApp          0x0000630a 0x1000 + 21258
8   MyBadApp          0x00006ada 0x1000 + 23258
9   MyBadApp          0x00003618 0x1000 + 9752
10  MyBadApp          0x0000351e 0x1000 + 9502
11  MyBadApp          0x00003874 0x1000 + 10356
12  UIKit             0x00068568 -[UIViewController viewWillMoveToWindow:] + 76
13  UIKit             0x0000988a -[UIView(Hierarchy) _willMoveToWindow:withAncestorView:] + 126
14  UIKit             0x00005e6e -[UIView(Internal) _addSubview:positioned:relativeTo:] + 222
15  UIKit             0x00005d80 -[UIView(Hierarchy) addSubview:] + 16
16  MyBadApp          0x000028d2 0x1000 + 6354
17  UIKit             0x00003e58 -[UIApplication _performInitializationWithURL:payload:] + 336
18  UIKit             0x00003b22 -[UIApplication _runWithURL:payload:launchOrientation:] + 394
19  UIKit             0x0004f8c4 -[UIApplication handleEvent:withNewEvent:] + 1336
20  UIKit             0x0004f242 -[UIApplication sendEvent:] + 38
21  UIKit             0x0004ec8c _UIApplicationHandleEvent + 4772
22  GraphicsServices  0x00003b2c PurpleEventCallback + 660
23  CoreFoundation    0x00022d96 CFRunLoopRunSpecific + 2214
24  CoreFoundation    0x000224da CFRunLoopRunInMode + 42
25  UIKit             0x0000340a -[UIApplication _run] + 342
26  UIKit             0x00001954 UIApplicationMain + 636
27  MyBadApp          0x00002828 0x1000 + 6184
28  MyBadApp          0x000027f8 0x1000 + 6136</pre></td> 
  </tr> 
 </tbody> 
</table>

Looking at frames 5 and 6, you can see that the application has made a synchronous networking call (`+[NSURLConnection sendSynchronousRequest:returningResponse:error:]`) which has blocked waiting for the network, thereby invoking the ire of the watchdog.

Once you've confirmed that this problem is related to your networking code, there are two common solutions:

*  asynchronous networking — The best solution to this problem is to run your networking code asynchronously. Asynchronous networking code has a number of advantages, not least of which is that it lets you access the network safely without having to worry about threads.
 *  synchronous networking on a secondary thread — If it's prohibitively difficult to run your networking code asynchronously (perhaps you're working with a large portable code base that assumes synchronous networking), you can avoid the watchdog by running your synchronous code on a secondary thread.

原因:

程序启动时候不能超过5－6秒（注意设置超时时间）

解决：

UIApplicationDelegate中的不要有耗时操作，或者把耗时操作异步处理。

参考链接：

[https://developer.apple.com/library/content/qa/qa1693/\_index.html][https_developer.apple.com_library_content_qa_qa1693_index.html]

[https://stackoverflow.com/questions/46498547/ios11-watchdog-timeout-crashes-0x8badf00d-but-code-not-on-stack\#][https_stackoverflow.com_questions_46498547_ios11-watchdog-timeout-crashes-0x8badf00d-but-code-not-on-stack]

[iOS]: http://lib.csdn.net/base/ios
[https_developer.apple.com_library_content_qa_qa1693_index.html]: https://developer.apple.com/library/content/qa/qa1693/_index.html
[https_stackoverflow.com_questions_46498547_ios11-watchdog-timeout-crashes-0x8badf00d-but-code-not-on-stack]: https://stackoverflow.com/questions/46498547/ios11-watchdog-timeout-crashes-0x8badf00d-but-code-not-on-stack#