iOS崩溃堆栈信息的符号化解析

   最近一段时间，在iOS开发调试过程中以及上线之后，程序经常会出现崩溃的问题。简单的崩溃还好说，复杂的崩溃就需要我们通过解析Crash文件来分析了，解析Crash文件在iOS开发中是比较常见的。但在跟开发者沟通过程中，云捕小编发觉大家对iOS的应用符号表还不是很清楚。 

                                       

       现在网上有很多关于解析崩溃堆栈信息的符号化的博客，但是大多质量参差不齐，或者有些细节没有注意到。今天总结一下对iOS崩溃符号化的使用和技巧：

一．场景

       当我们收集iOS的崩溃信息时，获取到的崩溃堆栈一般是如下的形式，全是十六进制的内存地址形式：

        

       这样的格式我们很难看出实际含义，无法定位问题代码，只有将它们转化为可读的形式才有意义：

        

       如上所示，我们一眼就能看明白，这次崩溃发生在ViewController.m文件的68行，对应的方法是rangeException。那么这样的符号化又是如何实现的呢？

       我们知道，开发者在使用Xcode开发调试App时，一旦遇到崩溃问题，开发者可以直接使用Xcode的调试器定位分析崩溃堆栈。但如果App发布上线，用户的手机发生了崩溃，我们就只能通过分析系统记录的崩溃日志来定位问题，在这份崩溃日志文件中，会指出App出错的函数内存地址，关键的问题，崩溃日志中只有地址，类似 0x2312e92f这种，这看起来岂不是相当头疼，那怎么办呢？

       幸好有dSYM文件的存在，它是帮助苦逼的码农有效定位bug问题的重要途径。崩溃堆栈里的函数地址可以借助dSYM文件来找到具体的文件名、函数名和行号信息的。实际上，在使用Xcode的Organizer查看崩溃日志时，就是根据本地存储的.dSYM文件进行了符号化的操作。