最近一段时间,在iOS开发调试过程中以及上线之后,程序经常会出现崩溃的问题。简单的崩溃还好说,复杂的崩溃就需要我们通过解析Crash文件来分析了,解析Crash文件在iOS开发中是比较常见的。但在跟开发者沟通过程中,云捕小编发觉大家对iOS的应用符号表还不是很清楚。
![u=3993536932,2484420707&fm=21&gp=0](https://i-blog.csdnimg.cn/blog_migrate/4572a0dbf04ecafad16755adc3d48371.jpeg)
现在网上有很多关于解析崩溃堆栈信息的符号化的博客,但是大多质量参差不齐,或者有些细节没有注意到。今天总结一下对iOS崩溃符号化的使用和技巧:
一.场景
当我们收集iOS的崩溃信息时,获取到的崩溃堆栈一般是如下的形式,全是十六进制的内存地址形式:
![](https://i-blog.csdnimg.cn/blog_migrate/517e466e949a0f224af48ba5f91f79a6.png)
这样的格式我们很难看出实际含义,无法定位问题代码,只有将它们转化为可读的形式才有意义:
![](https://i-blog.csdnimg.cn/blog_migrate/1c2d821e2e943fa05f14953951d0e275.png)
如上所示,我们一眼就能看明白,这次崩溃发生在ViewController.m文件的68行,对应的方法是rangeException。那么这样的符号化又是如何实现的呢?
我们知道,开发者在使用Xcode开发调试App时,一旦遇到崩溃问题,开发者可以直接使用Xcode的调试器定位分析崩溃堆栈。但如果App发布上线,用户的手机发生了崩溃,我们就只能通过分析系统记录的崩溃日志来定位问题,在这份崩溃日志文件中,会指出App出错的函数内存地址,关键的问题,崩溃日志中只有地址,类似 0x2312e92f这种,这看起来岂不是相当头疼,那怎么办呢?
幸好有dSYM文件的存在,它是帮助苦逼的码农有效定位bug问题的重要途径。崩溃堆栈里的函数地址可以借助dSYM文件来找到具体的文件名、函数名和行号信息的。实际上,在使用Xcode的Organizer查看崩溃日志时,就是根据本地存储的.dSYM文件进行了符号化的操作。
![u=3993536932,2484420707&fm=21&gp=0](https://i-blog.csdnimg.cn/blog_migrate/4572a0dbf04ecafad16755adc3d48371.jpeg)
现在网上有很多关于解析崩溃堆栈信息的符号化的博客,但是大多质量参差不齐,或者有些细节没有注意到。今天总结一下对iOS崩溃符号化的使用和技巧:
一.场景
当我们收集iOS的崩溃信息时,获取到的崩溃堆栈一般是如下的形式,全是十六进制的内存地址形式:
![](https://i-blog.csdnimg.cn/blog_migrate/517e466e949a0f224af48ba5f91f79a6.png)
这样的格式我们很难看出实际含义,无法定位问题代码,只有将它们转化为可读的形式才有意义:
![](https://i-blog.csdnimg.cn/blog_migrate/1c2d821e2e943fa05f14953951d0e275.png)
如上所示,我们一眼就能看明白,这次崩溃发生在ViewController.m文件的68行,对应的方法是rangeException。那么这样的符号化又是如何实现的呢?
我们知道,开发者在使用Xcode开发调试App时,一旦遇到崩溃问题,开发者可以直接使用Xcode的调试器定位分析崩溃堆栈。但如果App发布上线,用户的手机发生了崩溃,我们就只能通过分析系统记录的崩溃日志来定位问题,在这份崩溃日志文件中,会指出App出错的函数内存地址,关键的问题,崩溃日志中只有地址,类似 0x2312e92f这种,这看起来岂不是相当头疼,那怎么办呢?
幸好有dSYM文件的存在,它是帮助苦逼的码农有效定位bug问题的重要途径。崩溃堆栈里的函数地址可以借助dSYM文件来找到具体的文件名、函数名和行号信息的。实际上,在使用Xcode的Organizer查看崩溃日志时,就是根据本地存储的.dSYM文件进行了符号化的操作。