3

我在一个非常具体的场景中遇到了“未能及时恢复”崩溃（我认为这与看门狗有关）：仅在从后台恢复时，并且仅在进入后台后很短的时间内执行（a最多几秒钟）。

这似乎是相关的崩溃日志：

Incident Identifier: E30F2238-5B15-49A1-BCBC-386791AC93FA
CrashReporter Key:   84f4fb61c9e5c597750146695fffdc55f7273fb7
Hardware Model:      iPod4,1
Process:         XXXXXXX
Path:            /var/mobile/Applications/DE774CCE-D452-418D-A862-4562A0E5F1D0/XXXXXXX.app/XXXXXXX
Identifier:      XXXXXXX
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2013-01-14 13:15:41.955 +0200
OS Version:      iOS 6.0 (10A403)
Report Version:  104

Exception Type:  00000020
Exception Codes: 0x000000008badf00d
Highlighted Thread:  0

Application Specific Information:
XXXXXXX failed to resume in time

Elapsed total CPU time (seconds): 9.140 (user 9.140, system 0.000), 91% CPU 
Elapsed application CPU time (seconds): 7.806, 78% CPU

Thread 0 name:  Dispatch queue: com.apple.main-thread
Thread 0:
0   libsystem_kernel.dylib          0x336fa7cc fsync + 8
1   Foundation                      0x3a444974 _NSWriteBytesToFileWithExtendedAttributes + 668
2   Foundation                      0x3a4446ce _NSWriteBytesToFile + 22
3   Foundation                      0x3a4446ac -[NSData(NSData) writeToFile:atomically:] + 80
4   XXXXXX                          0x001777ee 0xe3000 + 608238
5   CoreFoundation                  0x38361034 _CFXNotificationPost + 1424
6   Foundation                      0x3a437d8c -[NSNotificationCenter postNotificationName:object:userInfo:] + 68
7   Foundation                      0x3a43b84e -[NSNotificationCenter postNotificationName:object:] + 26
8   XXXXXX                          0x000e6616 0xe3000 + 13846
9   UIKit                           0x37e050e4 -[UIApplication _handleApplicationSuspend:eventInfo:] + 780
10  UIKit                           0x37d7b1ea -[UIApplication handleEvent:withNewEvent:] + 2454
11  UIKit                           0x37d7a6d0 -[UIApplication sendEvent:] + 68
12  UIKit                           0x37d7a11e _UIApplicationHandleEvent + 6150
13  GraphicsServices                0x3600d5a0 _PurpleEventCallback + 588
14  GraphicsServices                0x3600d1ce PurpleEventCallback + 30
15  CoreFoundation                  0x383e5170 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 32
16  CoreFoundation                  0x383e5112 __CFRunLoopDoSource1 + 134
17  CoreFoundation                  0x383e3f94 __CFRunLoopRun + 1380
18  CoreFoundation                  0x38356eb8 CFRunLoopRunSpecific + 352
19  CoreFoundation                  0x38356d44 CFRunLoopRunInMode + 100
20  GraphicsServices                0x3600c2e6 GSEventRunModal + 70
21  UIKit                           0x37dce2fc UIApplicationMain + 1116
22  XXXXXXX                         0x000e5cd0 0xe3000 + 11472
23  XXXXXXX                         0x000e5c6c 0xe3000 + 11372

我试过调试这个，但连接到调试器时似乎没有发生（我发现的所有相关信息都表明连接到调试器时 wacthdog 被禁用），所以我然后尝试将进程记录到尝试并遵循发生的事情。

我已将日志记录添加到所有AppDelegate相关方法（applicationWillResignActive、、、甚至）中applicationDidEnterBackground，但从后台返回时没有日志，只有在进入后台时。我知道，即使应用程序在后台运行了指定的时间，某些进程也可以以一种使它们能够恢复的方式进行调度，但我不会自己执行任何此类进程。也许 Facebook SDK 做了类似的事情，但我也找不到任何参考，崩溃日志也没有提供任何指示。applicationWillEnterForegroundapplicationDidBecomeActiveapplicationWillTerminate

我在这里有点不知所措，如果朝着正确的方向推动甚至轻推，我将不胜感激。

4

2 回答 2

7

是的，这与看门狗有关。

您的写作过程是否有可能在主线程上花费了太多时间并且阻塞了那个？这可以解释为什么从后台返回时没有显示日志数据，并且只有在进入后台后不久恢复时才会发生这种情况。

我建议执行以下操作：

  1. 进入后台而不是在主线程中写入数据，而是通过以下方式使用后台任务：

    [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:^{...

  2. 如果应用程序在后台任务仍在运行时恢复，则采取相应措施，例如在完成写入之前不要读取，或者如果它仍在写入则不要再次写入。所以你需要了解自己的状态

最大的规则：永远不要用任何可能花费超过几分之一秒的东西阻塞主线程。将所有内容移到后台线程中，或者在这种情况下移到后台任务中。

于 2013-01-16T13:29:33.097 回答
0

找到你的应用程序崩溃的线程把那个线程放进去 dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{ dispatch_async(dispatch_get_main_queue(), ^{ // run that crashing thread here. }); });

于 2015-09-24T11:27:26.857 回答