iOS Crash收集与分析详解（基础篇）

最近测试妹子老是抱怨我偶现的Bug不好复现，我这边出于偷懒（其实是工作很忙）一直再说不能复现Bug的妹子不是好测试，最近闲下来了，正好谈谈Crash的收集和分析。

噔噔噔噔~万能的官方文档又出现了，先上地址

Understanding and Analyzing Application Crash Reports

如果你把你的手机连接到Mac，并选择Xcode->Windows->Device and Simulator，然后点击View Device Logs，你会看到手机上会有好多Log，其中Type为Crash的就是崩溃的Log,如下图：

1）打开设置->隐私->分析->分析数据，在其中找到你想要的应用程序的日志，日志将使用以下格式命名：<应用名称>_ <崩溃时间>_ <设备名>

2）选择所需的日志，复制文本或点击右上角的分享按钮分享出去，并且把分享得到的.ips.synced或者复制文本而来的.txt文件的后缀名改为.crash，因为Xcode不接受没有.crash扩展名的崩溃日志。

What the fuck??面对一大串的16进制数字你可能会感到一脸懵逼，莫惊慌，如果你仔细的看了看官方文档，你就会发现收集Crash的Log是一件很轻松的事情，然而分析Crash却并不是那么容易的事情（看完这篇文章后你会发现也很容易！！！！）

我们能把16进制数字转换成能看懂的东西么？当然可以，这个时候就需要理解dSYM符号集，细心的小伙伴在看第一张Crash流程图中可能已经发现.xcarchive文件中包含了.dSYM文件。

看到这里你可能已经知道，通过dSYM中存储的信息可以把crash日志中的16进制数字一一对应成我们看得懂的文件名、函数名和行号，这个过程就叫做符号化，那么如何做呢？

获取.crash的UUID

获取.dSYM的UUID

获取.app的的UUID

比如上图能看到三者的UUID都是一致的，可以安心去符号化文件啦。

1）如果本地存在.crash对应的.dSYM文件，则直接到上文中（1、使用Xcode从设备获取崩溃日志：）到 View Device Logs 这步，把文件拖入右边的logs列表，Xcode会自动去符号化文件，如果满眼都是16进制数字的化，点击 Re-Symbolicate Log 即可

如果你不想用Xcode去符号化，你也可以通过 symbolicatecrash 来手动符号化crash日志， symbolicatecrash 是Xcode下的一个工具。

1）首先先找到这个工具，我们通过Spotlight搜索找到 symbolicatecrash 并复制到桌面的CrashSignifying文件夹中，在这个文件夹下同样放入.crash、.dSYM文件。

2）打开终端，进入你刚才创建的CrashSignifying文件夹中，输入命令行

然后在输入

如果报No such file or directory : at ./symbolicatecrash line 909.错误，尝试执行

以上图为例，大部分字段都是不言而喻的，下面列举一些有用处的。（在官方文档都有解释，这里做归纳与翻译）

接着是最重要的堆栈信息，由下到上为最后调用的顺序：

文章写了一半开始忙了起来，第三第四节的内容现在才补上来（已经三天过去啦），如果能给小伙伴带来一点帮助，那我就很开心了，咱们下周再见。

作为一名应用开发者，相信你经常碰到以下情景：

在你将应用提交到App Store之前，想必你已经做了大量的测试工作，在你的设备上它也运行的很好，然而，还是会出现使用时闪退的情况。相信大家已经做好了Crash log的收集工作。

Crash log主要分为两种情况：

1.连接真机进行调试

2.App Store上应用的Bug追踪

本文主要讲的是App Store上bug的分析。

上图正是Apple给的崩溃日志，下面我们逐步分析一下日志的内容。

1.进程信息

Incident Identifier ：crash的id

CrashReporter Key ：crash的设备id

Hardware Model ：手机型号

Process ：[app名字] [进程ID]

Path ：app的位置

Identifier ：bundle ID

Version ：版本号

AppStoreTools

Code Type ：arm64

Role ：app处于前台

Parent Process

Coalition

2.基本信息

Date/Time ：crash发生时间

Launch Time ：app启动时间

OS Version ：iOS版本

Release Type

Baseband Version

Report Version

3.异常信息

Exception Type ：异常类型

Exception Codes ：异常地址

Exception Note ：描述

Triggered by Thread ：异常发生的线程

4.异常回溯

发生异常时的线程堆栈

在分析之前需要准备 dSYM 文件， crash log 和 symbolicatecrash （Xcode自带的崩溃分析工具）。

什么是dSYM文件？

Xcode编译项目后，我们会看到一个同名的 dSYM 文件，dSYM 是保存 16 进制函数地址映射信息的中转文件，我们调试的 symbols 都会包含在这个文件中，并且每次编译项目的时候都会生成一个新的 dSYM 文件，位于 /Users/用户名 /Library/Developer/Xcode/Archives 目录下，对于每一个发布版本我们都很有必要保存对应的 Archives 文件

dSYM文件作用

我们可以通过crash log中出错的函数地址去查询 dSYM 文件中程序对应的函数名和文件名

1.在桌面新建一个文件夹 crashtemp

找到"symbolicatecrash" 文件, 拷贝到刚才创建的 "crashtemp" 文件夹里。

3. Xcode->Window->Organizer->Archives 显示包内容 获取dSYM文件拷贝到刚才创建的 "crashtemp" 文件夹里。

4.crash log文件拷贝到 crashtemp 里。

5.打开终端进入 crashtemp 文件夹:

6.检验crash、dSYM文件是否匹配

每一个xx.app.dSYM 文件都有对应的 UUID，crash 文件也有自己的 UUID，只要这三个文件的 UUID 一致，我们就可以通过他们解析出正确的错误函数信息了。

在 terminal 中输入以下命令，查看UUID：

7.输入以下命令

这时候终端将会进行处理......

生成一个新的文件 symbol.crash ，这就是我们认识的crash文件。

有时候通过 symbolicatecrash 并不能解析出来崩溃信息，或者APP自身的堆栈能解析出来，但是系统的堆栈解析不出来。

可以通过 atos 命令逐行解析，通过这个命令可以解析指定的某一行堆栈。

项目中一部分测试是外包的，测试人员发现了一个偶现的bug，并把.ips文件提供给我们。

下面开始解析crash文件

1.在桌面新建一个文件夹，名字叫crash

2.将.ips文件更名为.crash文件并放到crash文件夹中

3.前往文件夹路径  /应用程序/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources

复制symbolicatecrash脚本并粘贴到crash文件夹中

4.复制xxx.app.dSYM文件粘贴到crash文件夹中

5.打开终端输入命令：

cd/Users/example/Desktop/crash  //进入到桌面crash文件夹中

./symbolicatecrash /Users/example/Desktop/crash/59129929.crash/Users/example/Desktop/crash/xxx.app.dSYM >log.crash //进行crash日志解析

如果终端报错：

Error: "DEVELOPER_DIR" is not defined at ./symbolicatecrash line 69.

输入：

exportDEVELOPER_DIR="/Applications/XCode.app/Contents/Developer"

然后再输入：

./symbolicatecrash /Users/example/Desktop/crash/59129929.crash /Users/example/Desktop/crash/xxx.app.dSYM >log.crash //进行crash日志解析

6.在crash文件中就会新增log.crash文件，然后分析bug就可以了。

---