iOS Crash 分析攻略，死磕原理

• CrashReporter Key: CrashReporter 的 uuid, 如果自己捕获日志，这个可以忽略。

• Hardware Model: 机型

• Process: 进程名和进程ID

• Path: 进程的可执行文件路径

• Identifier: Info.plist 中配置的 CFBundleIdentifier 值

• Version: CFBundleVersion (CFBundleVersionShort) 即应用的Build号+版本号

• Code Type: 机型的 CPU 架构，但是不是详细的架构名。比如 arm64e 在这里也是 ARM-64

• Parent Process: 父进程和进程ID

• Data/Time: Crash发生的具体时间。

• Launch Time： 进程启动时间

• OS Version: iOS 系统版本和 build号

• Report Version: Crash日志格式的版本号，一般是 104。如果这个version偏高，用系统的symbolicatecrash命令不能符号化日志，一般如果看到是204， 改成104之后用symbolicatecrash就可以符号化了

Crash 异常码

---

在 Crash 头部信息之下, 会有个段记录了 Crash 异常码。类似下图：

这里我们应该关注：

• Exception Type: 异常码，一般格式是 Mach异常码 ( UNIX 信号类型 )

• Exception Subtype: 一般情况里面带的是 Mach异常的 subcode, 还有 Crash 相关地址信息。

• Triggered by Thread: 发生Crash的线程，大部分情况到这个线程的堆栈里面去看 Crash 堆栈。

• Application Specific Information: 如果是 Objc/c++ Exception 异常，这里是异常的信息，这个是定位异常的关键信息

• Last Exception Backtrace: 抛出异常的代码堆栈, 如果是 Objc/c++ Exception 异常造成的 Crash，就看这个堆栈，Crashed Thread: 里的堆栈是 abort()，没有意义。

附异常码的解释, 非所有异常码，只是我们 Crash 中可能会看到的 :

Mach 异常	UNIX 信号	简介	案例
EXC_BAD_ACCESS	SIGBUS	总线错误	1、内存地址对齐出错 2、试图执行没有执行权限的代码地址
	SIGSEGV	段错误	1、访问未申请的虚拟内存地址 2、没有写权限的内存写入
EXC_BAD_INSTRUCTION	SIGILL	非法指令，即机器码指令不正确	1, iOS 上偶现的问题，遇到之后用户会连续闪退，直到应用二进制的缓存重新加载 或重启手机。此问题挺影响体验，但是报给苹果不认，因为苹果那边没有收集到，目前没有太好办法。因为 iOS 应用内无法对一篇内存同时获取 w+x 权限的，因此应用无法造成此类问题，所以判断是苹果的问题。
EXC_ARITHMETIC	SIGFPE	算术运算出错，比如除0错误	iOS 默认是不启用的，所以我们一般不会遇到
EXC_SOFTWARE (我们在 Crash 日志中一般不会看到这个类型，苹果的日志里会是