前言

对于大部分iOSer来说，遇到最严重的问题就是线上crash，因为对于用户来说，最糟糕的体验莫过于使用app的时候突然闪退，比这更糟糕的是再次打开重试依旧闪退。如果不能正常使用，或者使用体验极差，app不是不可替代的，用户很可能选择卸载。所以说保持一个较低的崩溃率对于iOS开发来说非常有必要。

crash的产生和分类

crash是系统的一种保护性行为，一般分为两种，一种是代码异常的崩溃，比如数组越界、坏内存访问，还有一种是性能问题，最常见的就是OOM（out of memory）。为什么这么分类呢，因为代码异常产生的日志属于应用级别的，通过代码就可以获取到，可以上传到自己服务器，然后解析和处理，而系统级的是系统（Jestems机制）杀死App，这种崩溃日志是系统级的，用户可以在设置->隐私->分析->分析与数据找到，但开发者没有办法获取。

代码异常

这种崩溃大部分来说都非常容易解决。其解决过程中最麻烦的肯定是定位代码。如果是接入了第三方crash上报的工具（Bugle），上传了dsym文件，会辅助我们解析堆栈。另外Xcode也自带bug查找中工具。

DSYM文件

dsym文件是符号表文件，是内存地址与函数名、文件名、行号的映射表。工程设置中可以设置其是否生成。

如果想在debug的时候使工程编译更快，可以取消dsym文件的生成。debug模式下，其生成后的目录是和app Product在同一目录，此外dsym文件是有uuid的，可以借助dwarfdump命令查看

dwarfdump --uuid xxx.app.dSYM

使用DSYM文件还原堆栈

如果工程是使用KSCrash一些第三方开源库收集crash日志，上传到自己服务器，需要自己解析的。或者用户遇到闪退，把手机中的crash日志发送给开发者。也可以通过dwarfdump来解析。

dwarfdump  xxx.app.dSYM --lookup <需要解析的相对地址>

在解析之前一定要确认crash日志的里面程序Binary Image uuid 和 dsym文件的uuid一致。

日志捕获的堆栈一般有4列信息，库名称、远行时堆栈地址、运行时起始地址、偏移地址。

有用的信息只有+号后面的。将其转化为二进制，然后再加上符号表 TEXT 段的起始地址，就可以解析了，TEXT 段的起始地址使用otool可以获取：

otool -l xxx.app.dSYM/Contents/Resources/DWARF/<项目名> | grep __TEXT -C 5

所以得到相对地址就是0x0000000100000000 + 0x000FDBB54（16628564）= 0x100FDBB54，使用dwarfdump尝试还原：

如图所示，已经还原到的具体的方法。在使用KSCrash的时候，KSCrash已经帮我们把偏移地址计算好了。

可以看到日志里面都0x100fdbb54就是，之前计算的。

系统级的crash

除了应用代码的crash，还有一些系统讲app杀死的情况，如果app在前台，这时候这种表现就和闪退一样。

OOM

OS、iPadOS、watchOS和tvOS都有一个虚拟内存系统，当操作系统遇到内存压力时，它依赖于所有应用程序释放内存，此时可用内存很低，系统无法满足所有运行的应用程序的需求。在内存压力下，应用程序会在收到内存不足的通知后释放内存。如果所有正在运行的应用程序释放足够的总内存来缓解内存压力，你的应用程序将继续运行。但是，如果由于应用程序没有释放足够的内存而导致内存压力继续存在，系统会通过终止应用程序来回收内存来释放内存。这是一个jetsam事件，系统会创建一个jetsam事件报告，其中包含为什么选择抛弃应用程序的信息。

Jetsam事件报告不同于崩溃报告，因为它们包含了设备上所有应用程序和系统进程的总体内存使用情况，它们是JSON格式的，并且它们不包含应用程序中任何线程的回溯。如果系统由于内存压力而抛弃了你的应用程序，而应用程序是可见的，它会看起来像你的应用程序崩溃了。使用jetsam事件报告来识别你的应用在jetsam事件中的角色，即使你的应用没有被抛弃。

其他

最近公司B端APP有用户反馈闪退，但在崩溃统计平台，其手机设备都没有发现日志。不管是系统的还是应用的都没有。这种崩溃查找就需要测试同学介入，尽量复现，然后再定位跟踪问题。