你的 App 在 iOS 13 上被卡死了吗？

作者 | 王晓晖、邓竹立、朴惠姝

问题表现

自从58同城iOS客户端9.0.0版本上线以来，陆续接到反馈说App有时启动会超时，无法响应，然后被系统杀死，只有重启手机才能恢复。

得知存在App无法启动的问题后，我们马上展开了调查。通过对触发此问题的设备进行测试，发现此问题所影响的不仅仅是58同城App的启动，另有如京东、大众点评、腾讯视频等其他App也无法正常打开。

图1 App启动崩溃截屏

而且经过进一步测试，发现当此问题触发时，在任意App中进行剪贴板的相关操作都会突然导致App卡死无法操作。

图2 App卡死截屏

如何找到崩溃堆栈？

虽然我们总结出了这种卡死App问题的各种表现，但是如果没有清晰的崩溃栈信息，就没有线索去解决这个问题。于是我们开始去Bugly上查找有可能相关联的崩溃信息，但是并没有收获。

为什么Bugly上收集不到崩溃信息？

之后我们拿到发生崩溃的iPhone设备，连接到电脑并通过”Xcode-Devices and Simulators-View Devices Logs”导出了设备的崩溃日志去排查原因。它是在主线程（main-thread）中发生的崩溃，异常类型(Exception Type)为一个终止程序的信号（SIGKILL）类型，Code为0x8badf00d。如下所示：

图3崩溃信息描述

那Bugly为什么收集不到这种崩溃？

（1）信号类型

首先，信号是Unix、类Unix以及其他POSIX兼容的操作系统中进程间通讯的一种有限制的方式。它是一种异步的通知机制，用来提醒进程一个事件已经发生。当一个信号发送给一个进程，操作系统中断了进程正常的控制流程，此时，任何非原子操作都将被中断。如果进程定义了信号的处理函数，那么它将被执行，否则就执行默认的处理函数。因此在应用的Crash引起的程序异常退出都会有signal。它的种类有多种，常见的有SIGSEGV，SIGILL，SIGABRT，SIGBUS，SIGKILL等等。

信号类型

信号解释

SIGSEGV

无效的内存地址引用信号，试图访问未分配给自己的内存, 或试图往没有写权限的内存地址写数据。

SIGILL

执行了非法指令，通常是因为可执行文件本身出现错误, 或者试图执行数据段. 堆栈溢出时也有可能产生这个信号。

SIGABRT

通常由于异常引起的中断信号，异常发生时系统会调用abort()函数发出该信号。

SIGBUS

非法地址, 包括内存地址对齐(alignment)出错。与SIGSEGV的区别在于后者是由于对合法存储地址的非法访问触发的(如访问不属于自己存储空间或只读存储空间)。

SIGKILL

用来立即结束程序的运行，该信号不能被阻塞、处理和忽略。

表 1 信号类型解释

其中本次发生崩溃的信号是终止程序的SIGKILL，它是不能被阻塞、处理和忽略。因此在应用中不能捕获此类崩溃，第三方工具中是无法收集到。

（2）Code异常编码

异常编码也是分析崩溃原因的重要依据之一，该日志中Code码0x8badf00d，即“ate bad food”，表示在应用程序启动、终止或响应系统事件花费的时间过长，应用程序已被系统终止，发生了监视程序超时。它是苹果设计的“看门狗”（watchdog）机制，若超出了该场景所规定的运行时间，“看门狗”就会强制终结这个应用的进程。

触发0x8badf00d的场景除了主线程被卡死的情况，还有以下几种情况：

• 在iOS11.0到iOS11.2以前系统手机在前台收到推送后进入后台被杀死或可能会在前台杀死。

• 开启任务后做了大量耗时操作无法任务结束。

• 系统挂起beginBackgroundTask方法回调中没有关闭后台任务或添加两次或两次以上的回调无法一对一关闭后台任务。

• 开启任务后在到期事件处理的回调中开启子线程进行大量耗时操作等等。

因此以上的场景均无法应用拦截，处理，不能上报到第三方崩溃收集工具中。

借助隐私数据查询崩溃日志

既然第三方崩溃收集工具拿不到日志，那么我们之前是通过将iPhone设备连接到电脑中，通过”Xcode-Devices and Simulators-View Devices Logs”来导出当前设备发生的崩溃日志。这种方式可以收集到所有类型的崩溃。但是不可能人人都具备Xcode工具，也不可能时时刻刻都带电脑。而我们发现苹果会将当前设备所发生的所有事件都记录到系统日志中，包括崩溃日志，CPU Usage日志。

在系统日志中崩溃日志名称的格式为“进程名+日期+时间.ips.synced”或“进程名+日期+时间.ips”，如：“58tongcheng-2019-12-04-113614.ips”。该日志在iOS10.2以及以上系统的设备上可以进入“设置-隐私-诊断与用量”中获取，iOS10.2以上系统的设备上可以进入“设置-隐私-分析-分析数据”中获取。因此，用户可以直接通过iPhone设备选择一个崩溃日志后，通过Airdrops或其他三方app发送到电脑或崩溃自动解析工具进行解析。

图4系统隐私数据

点对点分析崩溃日志

在获取到日志之后如何进行解析呢？针对指定的日志进行日志解析，绝大多数iOS开发者都会想到使用符号表进行解析。但是原始的dSYM文件可能存在没有保存或者丢失的情况。因此58同城对日志解析进行了相应的扩展，扩大了日志的解析的适用范围。除了使用原始的dSYM符号表文件进行日志解析外，58的点对点日志解析工具还支持，针对bugly生成的符号表symbol文件的解析，甚至在没有任何符号表的情况下，也可以根据二进制数据进行日志解析。

基于dSYM符号表

众所周知，崩溃日志符号化所需要的符号表通常指dSYM文件，dSYM文件是用来记录调试信息的文件，其数据存储格式为DWARF格式。其数据来源为应用二进制文件的DEBUG段，记录的信息主要包括：文件路径信息、行号信息、变量与地址的映射、函数与地址的映射等。正是因为其存在地址与符号的映射关系，符号表才可以被用于解析崩溃日志。在得到崩溃日志和相应的dSYM文件后，可借助symbolicatecrash工具实现日志符号化。如果没有symbolicatecrash工具，那么dwarfdump命令也可以逐条实现地址符号化。

在业务开发过程中，本地调试状态下打包是默认不生成dSYM文件的，但是这并不意味着调试信息和符号信息丢失了。当我们本地Xcode打出来的包发生偶现崩溃时，可以通过Xcode提供的dsymutil工具将dSYM文件从应用程序的二进制文件中剥离。剥离出的dSYM文件即可借助相应symbolicatecrash实现地址符号化。

基于bugly符号表

在使用bugly进行崩溃统计时，我们需要将符号表上传到bugly的后台。这个符号表并不是原始的dSYM文件，而是bugly从dSYM文件中提取的文本文件。其数据格式如下图所示：

图5 Symbol文件

bugly的符号表是bugly从dSYM文件中提取的函数地址与符号的映关系，其格式为：起始指令地址 + 结束指令地址 + 代码所在函数名 + 代码所在文件及行号。举例说明，假如我们拿到的崩溃偏移地址为B，通过文本扫描后发现函数F的L行代码的起始指令地址为A，结束指令地址C，地址满足A