使用 symbolicatecrash 符号化 crash lo
symbolicatecrash
symbolicatecrash 是什么 ？
symbolicatecrash 是 Xcode 中自带的perl脚本工具，通过iPhone的崩溃日志和应用的.dSYM文件定位发生崩溃的位置，把Crashed日志中的一堆地址替换成代码相应位置。
什么时候能用到 symbolicatecrash ？
通常开发者开发软件时，真机是在身边的可以随时查看， 但如果是把APP安装到其他测试者手机 或者 是提交 App Store 审核被拒时 就无法准确定位 崩溃 活报错原因了，这时候需要 通过 xxx.crash 文件来分析 解决问题，单问题是 xxx.crash 文件的内容 是 十六进制 显示的 ，给我们的分析 拍错 造成很大阻力， 所以这种情况下 我们需要用到 symbolicatecrash 来符号化。
如 ：
审核被拒
分析被拒原因：
朋友你的应用运行在 iPhone OS 11.3.1 突然崩溃，下面是提供的报错日志，自己玩去吧 ！ 有什么问题可以联系我们 ！！！
了解 crash log
简单分析 crash log 文件结构 （一般可以分为6各部分 ） ：
1 报告头 （Header ）
2 异常代码(Exception Codes)
3 应用详情(Application Specific Information)
4. 回溯(Backtrace)
5. 线程状态(Thread State)
6. 二进制映像(Binary Images)
解读 ：
第一部分 Header
报告头
这部分主要是应用相关信息 如： app_name (APP名称) app_version（APP版本号）bundleID（APP 唯一标识）os_version （运行版本）
第二部分 异常代码 （Exception Codes）
Exception Codes
异常代码中包含有：异常类型(Exception Type)、异常子类型(Exception Subtype)、处理器的详细异常代码(processor-specific Exception Codes)和其它能提供更多Crash信息的字段，最后一个字段列出了触发Crash的线程索引。
异常类型(Exception Type) 有以下几种：
a Bad Memory Access（坏内存访问） [EXC_BAD_ACCESS // SIGSEGV // SIGBUS]
这种类型的 Exception 是最为常见的 Crash ，通常是由于访问了无效的内存导致的。
SIGSEGV：访问了无效地址，没有物理内存对应该地址，通常由于重复释放对象导致。
SIGBUS：总线错误，与 SIGSEGV 不同的是，SIGBUS 访问的是有效地址，但总线访问异常，通常是访问了未对齐的数据。
SEGV：代表无效内存地址，比如空指针、未初始化指针、栈溢出等。
b. Abnormal Exit （异常退出） [EXC_CRASH // SIGABRT]
SIGABRT：收到Abort信号退出，通常Foundation库中的容器为了保护状态正常会做一些检测，例如插入nil到数组或字典中等会遇到此类错误。（常见的是再网络请求时发生）。
c. 其它异常类型
有些异常类型没有被命名，以16进制数字表示。
0xbaaaaaad：意味着该Crash log并非一个真正的Crash，它仅仅只是包含了整个系统某一时刻的运行状态，由用户同时按Home键和音量键触发。
0xbad22222：当VoIP程序在后台太过频繁的激活时，系统可能会终止此类程序。
0x8badf00d：程序启动或者恢复时间过长被watch dog终止。
0xc00010ff：程序执行大量耗费CPU和GPU的运算，导致设备过热，触发系统过热保护被系统终止。
0xdead10cc：程序退到后台时还占用系统资源（如通讯录）被系统终止。
0xdeadfa11：程序无响应用户强制退出。当用户长按电源键，直到屏幕出现关机确认画面后再长按Home键，将强制退出应用。我们可以合理认为用户这么做的原因是应用程序没有响应。
第三部分 应用详情(Application Specific Information)有些Crash出现时，会产生额外的信息，这些信息能帮助用户更好地了解应用程序终止时的运行环境。示例如下。
3
第四部分 回溯(Backtrace)
这部分列出了发生Crash时线程的调用栈。示例如下。
4.png
5. 线程状态(Thread State)
这部分列出了发生Crash的线程的状态，即寄存器和寄存器的值。示例如下。
5.png
6. 二进制映像(Binary Images)
这部分列出了当Crash发生时被装载进进程内存空间的依赖库或者模块。示例如下。
6.png
使用 symbolicatecrash 来分析崩溃日志
step 1 ：先在Mac 桌面创建一个新的文件夹，命名为crashAnalysis；
step 2 ：找到 symbolicatecrash 。拷贝 symbolicatecrash 到 crashAnalysis 文件夹中。
最新路径为 ： Xcode.app -- > Contents -- > SharedFrameworks -- >DVTFoundation.framework -- > Versions -- > A -- > Resources -- > symbolicatecrash
如图 ：
path.png
step 3 ：找到 .dSYM 文件拷贝到 crashAnalysis 文件夹中。
操作步骤 ：xcode --> Window --> Organizer ( command + shift +6 )
1.png
-- > 右键显示报内容 如图 ：
2.png
需要注意的是如果.dSYM 文件打开是没有任何内容的，是不可用的。这个时候必须重新生成给文件，在这之前需要在 xcode 中进行如下配置：Build Settings --> 搜索 dsym 选项改为DWARF with dSYM file 再次打包！
step 4 ：获取Crash日志的 .crash 文件 命名为 temp.crash
1 如果是审核被拒 那么 崩溃日志需要下载下来改后缀名为.crash 如图 ：
下载截图.png
2 如果是真机的崩溃日志：
1.png
2.png
3.png
如此就拿到了所有需要的文件如图所示：
结果.png
step 5 ：打开终端 cd 进入 crashAnalysis ，执行以下命令就可以生成最终的 .crash 文件了
export DEVELOPER_DIR=/Applications/XCode.app/Contents/Developer
./symbolicatecrash ./*.crash ./*.app.dSYM > analysis.crash 注 analysis.crash 需要自己命名 这里我使用的是 analysis
接下来 symbolicatecrash 就会运行进行处理了。。。。。。。。。。。。
完成后你会开到 crashAnalysis 中多了个 analysis.crash 文件
5.png
step 6 ： 使用开发者工具 Xcode 打开 analysis.crash 文件 找到 Last Exception Backtrace: （ 异常报错 ）处会看到变化 如图 ：
对比图.png
通过分析会看到崩溃原因是在向字典中插入一个 nil 对象造成的崩溃；
end.png
需要留意的是 这需要是同一版本的 .crash文件 .dSYM文件 才可以 ！
END
