一、前言：
作为一个合格的iOS开发者，除了具有规范强悍的编码能力外，还应该具有过硬的查错纠错能力。在项目运行时，程序崩溃是不可避免的，遇到这个问题，有时会出现一大堆的crash日志，艹，貌似看不懂呀。其实没有那么可怕，我们可以将这些日志格式化，通过它来快速定位问题的所在，以便迅速搞定它。
二、分析：
首先我们来看一个crash日志，大略的介绍其中的几个重要的关键词：
关键词解释：
2.1、 进程信息
第一部分是闪退进程的相关信息：
Incident Identifier ： 是崩溃报告的唯一标识符。
CrashReporter Key： 是与设备标识相对应的唯一键值。虽然它不是真正的设备标识符，但也是一个非常有用的情报:如果你看到100个崩溃日志的CrashReporter Key值都是相同的，或者只有少数几个不同的CrashReport值，说明这不是一个普遍的问题，只发生在一个或少数几个设备上。
Hardware Model ：标识设备类型。 如果很多崩溃日志都是来自相同的设备类型，说明应用只在某特定类型的设备上有问题。上面的日志里，崩溃日志产生的设备是iPhone 4s。
Process：对项目的操作权限，上面的是可读可写
Path:崩溃文件的路径
Identifier:项目标识符，就是Bundle Id
Version:版本号
.....等等.......
2.2、基本信息
这部分给出了一些基本信息，包括闪退发生的日期Date/Time和时间Launch Time，设备的iOS版本OS Version等。
2.3、异常信息
Exception Type:异常的类型。
Exception Codes ：异常错误码
Termination Reason：闪退的原因，比如常见的数组越界啊，什么的。
Triggered by Thread：出现问题在哪个线程，这个比较重要，首先确定在哪个线程中出了问题，然后再去定位。
2.4、线程回溯
这部分提供应用中所有线程的回溯日志。 线程调用的一些，堆栈信息，压根看不懂，所有需要进行符号化处理。
三、解析崩溃日志
用Xcode自带的 symbolicatecrash 工具来解析的.crash文件
3.1、获取crash文件：
a.直接从设备中获取方法如下图
b.如果产品在上架过程中发生崩溃，苹果那边的测试人员给我们直接发送过来已经整理好的崩溃日志文件，只需要根据其解决问题就行。
3.2、找到app包所对应的.dSYM文件。
强调要对应.dSYM 是保存 16 进制函数地址映射信息的中转文件，我们调试的 symbols 都会包含在这个文件中，并且每次编译项目的时候都会生成一个新的 dSYM 文件。测试给过来的.crash文件中，关于崩溃的确切语句和函数部分只有16进制地址符号，并不是我们在xcode调试时看到的xxx.cpp(xxfunction xx行)这样的。一般发布一个版本需要保存好对应的.dSYM和.app包，方便分析crash。如图所示：
3.3、就是找到Xcode中的symbolicatecrash工具咯，本人用的Xcode8，路径为：
其他版本的xcode，自己百度咯，反正都差不多。把我们需要的工具直接复制到桌面上来（方便用）。
3.4、.crash文件的分析
a.配置环境变量DEVELOPER_DIR，（配置好了就不再需要）
b.新建一个文件夹，将第二步中获取的两个文件放在同一个文件夹中
