如何使用xcode收集崩溃日志和定位崩溃原因？？？

一、先分析app的崩溃的分布情况 这个需要有（iTunes connect账号），通过分析可以查看到自己的app奔溃主要发生在那些机型上。 如果没有账号，别着急，直接歼做走镇亏第二步。

二、打开xcode，下载崩溃日志，直接定位出问题代码行。

1、找到开发者账号进入iTunes connect

进入iTunes connect的界面.png

2、进入app分析，查看app查看情况，app下载量，app崩溃情况

查看app情氏旅衡况

3、这里先关注app崩溃的情况 可以看到历史累计崩溃11次点击这个崩溃的情况进入分析实际上的app的崩溃的分布版本和手机系统版本

可以看到app崩溃主要集中在iOS9.2系统中，app版本3.2中。

如果上级需要，可以针对崩溃的发生出一些报告。

接下来，就直接定位代码崩溃发生的行了。

点击对应的崩溃日志，后面会出现一个箭头，点击箭头就会进入到Xcode中对应的代码行，就可以根据自己的程序逻辑做出相应修改。

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

在你将应用提交到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不好复现，我这边出于偷懒（其实是工作很忙）一直再说不能复现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.错误，尝试执行

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

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

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

---