iOS Crash收集与分析
一、收集crash
1、使用Xcode从设备获取崩溃日志：
如果你把你的手机连接到Mac，并选择Xcode->Windows->Device and Simulator，然后点击View Device Logs，你会看到手机上会有好多Log，其中Type为Crash的就是崩溃的Log,如下图：
2、通过设备直接获取崩溃日志
1）打开设置->隐私->分析->分析数据，在其中找到你想要的应用程序的日志，日志将使用以下格式命名：<应用名称> _ <崩溃时间> _ <设备名>
2）选择所需的日志，复制文本或点击右上角的分享按钮分享出去，并且把分享得到的.ips.synced或者复制文本而来的.txt文件的后缀名改为.crash
二、dSYM符号集:
1.dsYM
符号集是我们每次Archive一个包之后，都会随之生成的.dSYM文件，这个文件必须使用Xcode进行打包才有（Debug模式默认是关闭的）。每次发布一个版本，我们都需要备份这个文件，以方便以后的调试。
符号集中存储着文件名、函数名、行号与内存地址的映射表，通过符号集分析崩溃的.Crash文件可以准确知道具体的崩溃信息。
我们如果不使用.dSYM文件获取到的崩溃信息都是不完全的（官方文档说了会导致不完全符号化，也就是一部分符号化好了，一部分没有）。
每一个.dSYM文件都有一个UUID，和.app文件中的UUID对应，代表着是一个应用，而.dSYM文件中每一条崩溃信息也有一个单独的UUID，用来和程序的UUID进行校对。
2.符号集的生成与获取：
符号集在Organizer中选中打包的Archive->Show in Finder中选中Archive，右键显示包内容下的dSYMs文件夹下（或者点击Organizer右边的Download dSYM，XCode会从App Store下载该文件并插入到此Archive中）。
如果在Debug模式下，找到项目的Build Settings
把Debug Infomatiion Format设置成DWARF with dSYM file
并把Generate Debug Symbols置为YES
然后编译，在项目文件夹Products中找到.app文件右击Show in Finder找到dSYM文件
通过dSYM中存储的信息可以把crash日志中的16进制数字一一对应成我们看得懂的文件名、函数名和行号，这个过程就叫做符号化
三、校验文件
在符号化Crash文件之前，你需要准备好.crash和.dSYM并校验是否匹配
1.为什么要校验：
因为符号集存储着文件名、函数名、行号的信息，每一次代码更改后编译符号集也会随之变更，所以要想符号化.crash文件，.crash与符号集必须一一对应
也就是说由版本为1.0的代码生成了1.0的APP，同时生成了1.0的符号集，1.0的APP发生了Bug，生成了104115的crash文件，也只有1.0的符号集才能够符号化104115的crash文件，而同时也必须找到1.0的代码才能根据符号化的crash文件精确定位到bug产生的地方。
2.如何判断.crash、.dSYM与.app（是否匹配你的代码）是否匹配
通过UUID来匹配，UUID是Xcode在编译时自动为每个版本生成的唯一标识，即使功能相同的可执行文件是使用相同的编译器设置从相同的源代码重建的，它也将具有不同的构建UUID，总之UUID是唯一的。
3.如何通过命令行获取UUID？
获取.crash的UUID
grep "'Your AppName' arm64" t.crash
获取.dSYM的UUID
dwarfdump --uuid 'Your AppName'.app.dSYM
获取.app的的UUID
dwarfdump --uuid 'Your AppName'.app/'Your AppName'
以上三个UUID相同，说明文件匹配，可以进行去符号化了
四、crash文件符号化
1、通过XCode自动符号化Crash文件
1）如果本地存在.crash对应的.dSYM文件，则直接到上文中（1、使用Xcode从设备获取崩溃日志：）到View Device Logs这步，把文件拖入右边的logs列表，Xcode会自动去符号化文件，如果满眼都是16进制数字的化，点击Re-Symbolicate Log即可
2）如果此时本地的Archive文件已经被你删除，需要把上述两个文件放入同一目录下（全英文目录），如果.dSYM你并没有备份，则需要回到crash日志对应的版本重新打包（论版本控制的重要性！），重复1）的步骤也可以得到符号化的日志。
2、通过命令行工具symbolicatecrash符号化
如果你不想用Xcode去符号化，你也可以通过symbolicatecrash来手动符号化crash日志，symbolicatecrash是Xcode下的一个工具。
1）首先先找到这个工具，我们通过Spotlight搜索找到symbolicatecrash并复制到桌面的CrashSignifying文件夹中，在这个文件夹下同样放入.crash、.dSYM文件。
2）打开终端，进入你刚才创建的CrashSignifying文件夹中，输入命令行
export DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
然后再输入
./symbolicatecrash /Users/你的电脑用户名/Desktop/CrashSignifying/xxx(崩溃日志名字).crash /Users/你电脑的用户名/Desktop/CrashSignifying/xxxx(dSYM文件名字).dSYM > Symbol_Crash.crash
如果报No such file or directory : at ./symbolicatecrash line 909.错误，尝试执行
./symbolicatecrash ./*.crash ./*.app.dSYM>Symbol_Crash.crash
这样crash文件就被符号化完成了
原文链接：https://www.jianshu.com/p/ade5f6acf4d8 来源：简书
四、crash分析
名词解释：
Incident Identifier： 报告的唯一标识符，两份报告决不会共享同一个事件标识符。
CrashReporter Key：每个设备的匿名标识符，来自同一设备的两个报告将包含相同的值。
Process：很明显是我们的进程名称。
Date/Time 与 Launch Time：报告生成时间与程序开始运行时间
Exception Type：异常类型
Exception Note：不属于异常类型的附加信息，如果这个字段包含SIMULATED(不是崩溃)，那这个进程不是崩溃的，而是在系统的请求下被杀死，通常是看门狗机制起了作用（APP内一段时间内无法响应用户的操作，会被系统kill）。
一些较常见的异常类型（如果翻译错误请指正）：
内存访问不良[EXC_BAD_ACCESS // SIGSEGV // SIGBUS]
通常用于访问了不该访问的内存导致或者尝试以不允许的方式访问内存（例如只读属性，比如在上一篇我们提到的通过KVO更改只读属性），并且" Exception SubType"字段会包含kern_return_t来描述错误和未正确访问的内存地址。
下面是官方给出的建议：
- 如果objc_msgSend或objc_release接近崩溃线程的Backtraces(堆栈信息回溯)的顶部，则该进程可能试图向释放的对象发送消息，可以使用Zombie Instrument来分析应用程序，以更好地了解此次崩溃的情况。
- 如果gpus_ReturnNotPermittedKillClient接近崩溃线程的Backtraces的顶部，则该进程被终止，因为它尝试在后台使用OpenGL ES或Metal进行渲染。
异常退出[EXC_CRASH // SIGABRT]
该进程异常退出，此异常类型崩溃的最常见原因是向对象发送了无法识别的消息，比如上文中向NSArray发送了addObject消息。
另外如果App Extensions需要太多时间来初始化（看门狗机制），那么App Extensions将终止于此异常类型，如果扩展因启动时挂起而死亡，则生成的崩溃报告的Exception Subtype将会是LAUNCH_HANG，由于扩展没有main函数，任何花在初始化上的时间都会在+load扩展库和相关库中的静态构造函数和方法中，你应该尽可能多地推迟这项工作。
资源限制[EXC_RESOURCE]
该过程超出了资源消耗限制，这是来自操作系统的通知，该进程正在使用太多的资源,确切的资源列在Exception SubType字段中。如果Exception Note字段包含NON-FATAL CONDITION，则即使生成崩溃报告，该进程也不会被终止。
- 异常子类型MEMORY表示该进程已超过系统施加的内存限制。
- 异常子类型WAKEUPS表示进程中的线程每秒被唤醒的次数过多，这迫使CPU醒来的频率很高，并且消耗电池寿命。
