app崩溃后，从crash报告里，往往只能看到堆栈地址信息，完全不可读。要想精确知道哪里出了问题，需要把crash log解析成可读的文件。本文就是开发人员的角度告诉你，如何快速解析你crash log。
1.准备工作。
第一步：下载对应安装包的.app或者.ipa文件
下载位置：打包平台。
第二步：下载对应安装包的dYSM文件
下载位置：打包平台。
第三步：获取crash文件
途径1：crash监控平台；
途径2：xcode连接iphone后通过Window->Devices中拿到自己的手机设备的device log
注：复制内容保存为xxxx.crash文件
第四步：将.crash文件、.app文件和 .dSYM放在同一个目录下
2.检查dSYM文件与crash是否匹配
第一步：查询app或者dYSM文件的uuid
dwarfdump --uuid CPRelease.app.dSYM
或者：dwarfdump --uuid CPRelease.app/CPRelease
拿到形如：
UUID: 5531F52D-4980-3C43-89D8-B23B05D27CE4 (armv7) CPRelease.app/CPRelease
UUID: 17480E6A-7BAE-3388-BB86-4AC7A55E1A26 (arm64) CPRelease.app/CPRelease
第二步：检查crash文件的uuid
awk '$1~/^Binary/ {for (i=1;i<=2;i++) {getline;print}}' file.crash
拿到形如：
0x4000 - 0x2123fff CPRelease armv7 <5531f52d49803c4389d8b23b05d27ce4> /var/containers/Bundle/Application/40CB558E-8205-4E8C-B526-832EE5D58609/CPRelease.app/CPRelease
0x1fe81000 - 0x1fea8fff dyld armv7s
第三步：比较
上面得到的结果分别是arm7和arm9对应的uuid，通过比较发现，第一步拿到的uuid转换为小写去掉-符号，就与第二步拿到的结果一致，可以确认crash日志与dYSM文件是配套的。
3.拿到XCode自带crash解析工具symbolicatecrash
问题来了，你的symbolicatecrash可执行文件在哪里？看下面：
For Xcode 7.3, you can find the tool at: /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
For Xcode 6 through 7.2, you can find the tool at: /Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/Current/Resources/symbolicatecrash
Or if you're using Xcode 5: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/PrivateFrameworks/DTDeviceKitBase.framework/Versions/Current/Resources/symbolicatecrash
注：找到symbolicatecrash文件后，跟上面几个文件放在同一个目录下。
4.执行命令
./symbolicatecrash ./xxxxx.crash > result.crash
ok！大功告成。
参考文章：
https://possiblemobile.com/2015/03/symbolicating-your-ios-crash-reports/
如何解读你的crash报告？
你需要知道几种常见的crash类型：
1.异常错误码
0x8badf00d错误码：Watchdog超时，意为“ate bad food”。
0xdeadfa11错误码：用户强制退出，意为“dead fall”。
0xbaaaaaad错误码：用户按住Home键和音量键，获取当前内存状态，不代表崩溃。
0xbad22222错误码：VoIP应用（因为太频繁？）被iOS干掉。
0xc00010ff错误码：因为太烫了被干掉，意为“cool off”。
0xdead10cc错误码：因为在后台时仍然占据系统资源（比如通讯录）被干掉，意为“dead lock”。
2.异常类型
SEGV：（Segmentation Violation，段违例），表明内存操作不当，比如访问一个没有权限的内存地址。
SIGABRT：收到Abort信号，可能自身调用abort()或者收到外部发送过来的信号；SIGBUS：总线错误。与SIGSEGV不同的是，SIGSEGV访问的是无效地址（比如虚存映射不到物理内存），而SIGBUS访问的是有效地址，但总线访问异常（比如地址对齐问题）；SIGILL：尝试执行非法的指令，可能不被识别或者没有权限；SIGFPE：Floating Point Error，数学计算相关问题（可能不限于浮点计算），比如除零操作；SIGPIPE：管道另一端没有进程接手数据；
3.代码bug
数组越界、插空、多线程安全性、访问野指针、发送未实现的selector等。