iOS 闪退、崩溃、crash

前言

对于大部分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有用户反应闪退，但在溃散计算渠道，其手机设备都没有发现日志。不管是体系的还是运用的都没有。这种溃散查找就需求测验同学介入，尽量复现，然后再定位跟踪问题。

参考文章

• iOS溃散解析&原理说明
• 苹果官网文档
• iOS溃散无日志景象总结