一、dSYM
什么是dSYM
dSYM实际上放的是程序在编译过程中收集的符号表的信息，其实质上保存符号表数据的是二进制的DWARF(DebuggingWith Arbitrary Record Formats)文件。可以用dwarfdump命令读取出一些可读的信息。
设置Xcode工程生成dSYM
Build Setting中设置Debug Information Format 为 DWARF with dSYM File
Build Setting中设置Generate Debug Symbols 为 Yes
小技巧：当本地调试不需要dSYM的时候，可以设置XCode不生成dSYM，这样做的好处是使得XCode编译运行的速度更快(少了生成dSYM的时间)。
查看dSYM的UUID信息
这个步骤很关键，这是确定dSYM是否可用的唯一标识，用来与崩溃日志进行配对。
注意:
- 只要代码是相同的，编译后产生的dSYM都有一样的UUID，也就意味着你的应用出现闪退，而dSYM丢失的情况，只要工程还在，代码不变就可以重新编译生成dSYM，用来解析崩溃日志。
- dSYM的目录可以重命名，但是.dSYM的后缀不能去掉，不能放在.dSYM的目录文件夹中。
二、崩溃日志
移动设备产生崩溃日志的情况
应用违反操作系统的规则，主要包括三种情况，watchdog超时、用户强制退出和低内存终止。
应用中有bug，这是我们应该关心的情况。
崩溃日志的获取途径(很关键)
手机端:不同的iOS版本在不同的目录下，我的iOS11.2在 设置->隐私->分析->分析数据，可以看到很多不同的.ips文件。
电脑端:使用iTools的工具，选择工具箱栏目，有一个崩溃日志的选项，文件名的格式是”应用名-闪退时间.ips“。
闪退收集框架:如果在应用中接入了闪退收集的框架，或者自己实现了闪退收集的模块，那就还可以通过这些模块获取闪退的日志信息。
了解崩溃日志的文件结构
* Incident Identifier: 崩溃日志的唯一标识符，对应不同的crash
* CrashReporter Key: 设备的标识key值，不同于设备的UDID，当我们拿到大量的闪退日志而只有几个CrashReport Key时可能意味着闪退值发生在个别机器。
* Hardware Model: 设备类型
* Process: 进程名，一般就是我们的AppName，[]中的数字表示的是进程ID
* Path: 可执行程序存储在设备的路径名
* Identifier: App的Indentifier，来自于你的证书
* Version: App的版本，info.plist中CFBundleShortVersionString和CFBundleVersion这两个字段
* Code Type: 当前CPU架构
* Role: 异常发生时该进程task_role的值，貌似是描述进程的结构体某个成员变量的枚举值
* Parent Process: 父进程
* Report Version: 崩溃日志的版本，目前就见过104和105
* Exception Type: 异常的类型
* Thread State: 线程回溯
* Binary Images: 这段内容列出了在线程终止的时候，进程的二进制映像
符号化解析的过程(可不必过多纠结)
详细过程可以参见/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash，这实际上就是一份perl脚本。
使用符号化解析工具，第一步是指定脚本中$DEVELOPER_DIR的值，使用如下命令
export DEVELOPER_DIR="/Applications/Xcode.app/Contents/Developer"
1
进行符号化解析
执行如下命令，实际测试可以发现symbolicatecrash工具最少只需要输入闪退日志就可以进行解析，下面这条命令会把crash.ips解析结果导出到out.log，-v选项可以把解析过程中的一些日志信息打印到标准出错。另外因为symbolicatecrash有个bug，当闪退日志中相邻的重复行太多的时候，命令会卡死，所以在进行解析前先使用uniq去重，再通过管道流向symbolicatecrash即可。
uniq crash.ips | symbolicatecrash -v > out.log
1
其他的一些选项可以查看symbolicatecrash的详细帮助信息。
usage:
symbolicatecrash [--help] [--dsym=DSYM] [--output OUTPUT_FILE] <LOGFILE> [SYMBOL_PATH ...]
<LOGFILE> The crash log to be symbolicated. If "-", then the log will be read from stdin
<SYMBOL_PATH> Additional search paths in which to search for symbol rich binaries
-o | --output <OUTPUT_FILE> The symbolicated log will be written to OUTPUT_FILE. Defaults to "-" (i.e. stdout) if not specified
-d | --dsym <DSYM_BUNDLE> Adds additional dSYM that will be consulted if and when a binary's UUID matches (may be specified more than once)
-h | --help Display this help message
-v | --verbose Enables additional output
上述解析命令能执行成功的前提条件是解析命令的本机是有对应的dSYM存在的。
此外还有一个实际应用中的问题需要补充，因为我们的解析有可能是后台的一个服务，所以解析的过程可能在一个脚本中执行，而脚本解析闪退日志的第一步是下载服务器上的dSYM，一般会是一个压缩包，然后进行解压和符号化解析，这时候解析的过程很可能会失败。
猜测原因是symbolicatecrash工具使用mdfind工具在Mac上进行全局搜索，而由于Mac的缓存机制，刚解压的dSYM，可能还不被认为是dSYM(也就是说缓存机制在一定时间之后会把这个解压出来的dSYM加入到mdfind的搜索范围中，在这之前mdfind找不到)，所以会导致闪退日志找不到解析不出来。解决办法是使用mdimport强制刷新刚解压的dSYM的目录，再进行符号化解析就没问题了。
三、如何解析闪退日志，看懂闪退日志(敲黑板划重点)
分析闪退日志
首先找到闪退发生的闪退类型，如”EXC_BAD_ACCESS”，拿着这个闪退类型去到Apple的官网，可以确定一个大致的方向。
如果是直接从手机拿的系统的闪退日志，异常子类型的字段(Exception Codes)可能会有一串特殊含义的编码(英文或数字都有可能)，可以去Apple官网或者百度搜索其具体含义，以获得进一步的异常信息。
在闪退日志中可能会有这样的字段”Application Specific Information:”，这是闪退日志中最有用的一段信息，这段信息意味着某个NSException导致程序Crash，且这段信息包含了NSException的reason和name，同时还会有”Last Exception Backtrace:”的一段信息，可以精准的定位到程序出错的位置。
找到闪退对应的线程，大部分情况是线程0闪退，分析闪退线程对应的堆栈，找到自己应用的应用名对应的行，一般会解析出函数名、行号和文件名，这里大概就是问题的所在。
闪退日志解析不完整的原因
有以下两种情况（可能还有未知的原因）
1
- 系统的库解不出来, 是因为~/Library/Developer/Xcode/iOS\ DeviceSupport目录下缺失对应的版本系统库的dSYM，可以把对应的设备插在Mac机上，可以自动生成这些文件。
- 用户库解析不出来, 这是因为用户库的dSYM不完整，可能是如下的情况，游戏或者SDK有引用到动态库，而动态库的dSYM是需要额外提供的，所以会解析不出来。
调试的过程中获取闪退日志
在本地打包调试的时候，也可以直接使用Xcode查看闪退日志，这种方式更加的方便，可以看到xcode自动会把闪退日志进行解析，不过前提是XCode已经设置生成dSYM了。
四、简单说下闪退解析服务的完整解决方案
app层面:
接入第三方的闪退收集框架(可以自己实现，原理不难)，开源的如：PLCrashReport。
每次进入app之前检查上一次打开应用是不是出现了闪退，如果是则把上一次出现的闪退日志进行上报，上报的时候可以把用户信息，设备信息，或者玩家等级等信息一并上传，方便进行统计分析。
后台服务:
接收app层的闪退上报。
ios打包的时候应该把ipa跟dSYM对应的管理起来(亲测在 product name 设置标记是可行的)，解析之前去服务器上下载闪退日志对应的dSYM。
按照上述的方式进行闪退日志的解析，另外如果有需求的话，可以对上报的内容进行分类统计(前面有说到，app层面可以把用户信息上传)。
闪退日志上传之后最好按照闪退的类型进行分类，分类的方法(这里我是参考的腾讯Bugly)：首先按包分类，其次如果闪退日志中捕获到异常，那么按照异常类型分类，最后按照关键堆栈里面的第一个非系统方法名进行分类。
原文链接：https://blog.csdn.net/weixin_38440028/article/details/81813972
