iOS App 后台任务的坑（奔溃原因分析）

http://www.cocoachina.com/cms/wap.php?action=article&id=24864

 

Background Task 花式 crash

Background Task 的 API 及其简单，begin 和 end 之间的代码全部进入 Background Task 的范畴。但简单的代码隐藏着不小的风险，下面列出三个比较容易出现的 crash。而且这三个 crash 都是客户端自带的 crash 采集工具无法捕捉的，只能通过 Apple 的 crash 日志获得信号。原因很简单，这些 crash 发生的时候 app 一般处于 suspend 状态，根本没有机会执行任何代码，系统直接发送 SIGKILL 信号后就将 app 强杀，并生成一个系统日志，一个只能 Apple 访问的日志，还得用户先同意上传分享。

0xdead10cc

这个 crash 日志一般长这样：

Exception Type:  EXC_CRASH (SIGKILL)

Exception Codes: 0x0000000000000000, 0x0000000000000000

Exception Note:  EXC_CORPSE_NOTIFY

Termination Reason: Namespace SPRINGBOARD, Code 0xdead10cc

Termination Description: SPRINGBOARD, com.xxx.xxx was task-suspended with locked system file

原因我之前介绍过，当你的 App 有 Extension，而且 Extension 存在和 Host App 共享数据的需求，一般做法会将 db 文件放入 shared container 目录下，此时你的 App 就有大概率会发生这种 crash。

App 进入后台运行 Background Task，end 之后 App 被系统 suspend，如果 suspend 之后还存在任何访问 db 的操作，此时 App 会立马被系统强杀，这是 Apple 出于保护数据库文件的完整的考虑。

所以正确的做法是将所有有可能在 App 进入后台之后，还会发生的 db 操作统统封入 Background Task，以确保安全。这个代码写在 db layer 可能更加合适。

而且 Apple 推荐当你想启动 Background Task 的时候，其实并不需要考虑当前 App 是出于 foreground 还是 background，即使 App 在前台启动 Background Task，也并不会占用进入后台之后 3 分钟额度，所以放心大胆的把关键代码放进 Background Task 吧。

0xbada5e47

当你听从了上面的建议，大大方方的把尽可能多的关键代码封入 Background Task 后，那么你可能会遇到下面的 crash：

Exception Type:  EXC_CRASH (SIGKILL)

Exception Codes: 0x0000000000000000, 0x0000000000000000

Exception Note:  EXC_CORPSE_NOTIFY

Termination Reason: Namespace ASSERTIOND, Code 0xbada5e47

同理也是和 Background Task 相关，原因是 Apple 认为你启动了过多的 Background Task，所以要杀掉。多少算多呢？几十个不多，当前的 threshold 是 1000 个，超过 1000 个才会强杀。如果你的 Background Task 封装发生在 db layer，出现大量数据过来需要存储或读取的时候，还是有可能会 hit 这个 limit。

另一个 0xbada5e47 的可能原因是，Background Task 在超时之后会调用 expiry handler，无论你有多少个 Background Task，所有 expiry handler 执行的时间不能超过若干秒，一旦超过也会被枪杀。所以在 expiry handler 里面切忌有任何比如 disk io 的耗时操作。

0x8badf00d

说到 0x8badf00d，大家都很熟悉了，当你的主线程卡住的时间太长，系统的 Watchdog 会将你的 App 强杀，并生成一个带有 0x8badf00d 的 crash 日志。

Background Task 其实也可以 0x8badf00d 的，比如：

Exception Type:  EXC_CRASH (SIGKILL)

Exception Codes: 0x0000000000000000, 0x0000000000000000

Exception Note:  EXC_CORPSE_NOTIFY

Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d

当你的代码逻辑会产生 leaked Background Task 时，就会出现上面的系统强杀 crash 日志了，什么是 leaked Background Task 呢？看代

- (void)startBgTask
{
 self.bgTaskID = [[UIApplication sharedApplication] beginBackgroundTaskWithExpirationHandler:^{
   NSLog(@"Expired: %lu", (unsigned long)self.bgTaskID);
   [[UIApplication sharedApplication] endBackgroundTask:self.bgTaskID];
 }];
}

- (void)endBgTask
{
 [[UIApplication sharedApplication] endBackgroundTask:self.bgTaskID];
}

 

上面的代码如果 startBgTask 执行两次，就一定会出现 leaked Background Task，因为 self.bgTaskID 第二次会被赋予一个新的 ID，之前的 task ID 就丢失了，无法正确调用 end。

那怎么判断 0x8badf00d 到底是主线程卡死，还是出现了 leaked Background Task ？很简单，看主线程的 stack，如果长这样：

Thread 0 Crashed:0   

libsystem_kernel.dylib        0x000000018472be08 0x18472b000 + 35921   

libsystem_kernel.dylib        0x000000018472bc80 0x18472b000 + 32002   

CoreFoundation                0x0000000184c6ee40 0x184b81000 + 9744003   

CoreFoundation                0x0000000184c6c908 0x184b81000 + 9648724   

CoreFoundation                0x0000000184b8cda8 0x184b81000 + 485525   

GraphicsServices              0x0000000186b6f020 0x186b64000 + 450886   

UIKit                          0x000000018eb6d78c 0x18e850000 + 32664447   

Messenger                      0x0000000103015ee4 0x102ff8000 + 1225968   

libdyld.dylib                  0x000000018461dfc0 0x18461d000 + 4032

这个 stack 很经典，经常会看到，不需要 symbolicate 也能知道是干啥，这是 UI 线程 runloop 处于 idle 状态的 stack，在等待 kernel 的 message。表示 UI 线程此时处于闲置状态，这种状态下的系统强杀大概率是由于 leaked Background Task 导致的。

善用设备本地的 crash 日志

当用户的手机遇到 crash，而你既无法重现又在后台找不到 crash 日志的时候，此时你最大的希望就是手机本地的 crash 日志了。

本地日志位于 Settings -> Privacy -> Analytics -> Analytics Data。打开看下，说不定你所开发的 App 的 crash 日志，我手机上微信和支付宝都有好些日志。

日志排序先是按照 App 的名称，再按日志发生的日期。

如果调查内存使用过多的 crash，可以查看 JetsamEvent-xxx 开头的日志。

如果想知道 App 发生 crash 前系统有哪些异常日志，需要首先在设备上安装一个 loggingiOS.mobileconfig 的文件，这个文件基本上就是让用户授权给你记录系统行为，用户在遇到 crash 的时候，同时按下两个音量键 + 电源键，松手震动之后，系统会将过去一段时间的关键日志记录下来，对于分析一些疑难杂症很有帮助，这种日志一般为 sysdiagnose_xxx 开头。

安装上述 loggingiOS.mobileconfig 文件之后，还有另外一个好处，Apple 会记录更多而且更详细的 crash 日志了，因为用户授权过，所以 Apple 可以大胆施为了。这类日志的文件名一般为：stacks + appName - date.ips。

如果用户的设备能重现你所调查的问题，还有另一个简单高效的办法，将手机 usb 连接 mac，然后启动 mac 上的 Console App，就能直观的看到所有系统关键日志了，比如网络异常日志可以查看 nsurlsessiond，定位异常日志查看 locationd，Background Task 异常日志可以查看 assertiond，也可以直接按照你 app 的进程名进行过滤，查看生命周期以及被强杀的原因。