今天捣鼓了一天的crash日志终于顺利的把16进制的堆栈信息还原了,特地来写个简书。每个iOS肯定都很羡慕Android的崩溃日志,直接定位到错误代码的位置,让你快速定位BUG,iOS一出现bug就会出现一堆的16进制地址,让人类无法阅读,今天索性研究了一天,来跟大家分享下如何把这些16进制还原成对应的代码位置,像java一样定位bug。
首先来普及下几个小知识:
1.什么是符号表
符号表就是指在Xcode项目编译后,在编译生成的二进制文件.app的同级目录下生成的同名的.dSYM文件.dSYM文件其实是一个目录,在子目录中包含了一个16进制的保存函数地址映射信息的中转文件,所有Debug的symbols都在这个文件中(包括文件名、函数名、行号等),所以也称之为调试符号信息文件。
2.符号表有什么用
符号表就是用来符号化 crash log(崩溃日志)。crash log中有一些方法16进制的内存地址等,通过符号表就能找到对应的能够直观看到的方法名之类。
3.如何得到.dsYM文件
我们在Archive的时候会生成.xcarchive文件,然后显示包内容就能够在里面找到.dsYM文件和.app文件。
下图是线上收集的bug崩溃信息
花红圈的地方就我的APP报错的位置信息,在你们的日志里tcrrdios应该是你们对应的appname,后面紧跟的是2个16进制地址。
解析上面这点信息首先获取APP编译时的.xcarchive
OK,以上步骤就可以得到你的.xcarchive。什么?你没有?编译后就删除了?那你就只能等下次了,这个文件没发布一次版本最好保存起来防止日后出现问题找到问题的代码。
找到了你的.xcarchive右击“显示包内容”---“dSYMs”-----“[你的appname].app.dSYM”---右击"显示包内容"---"Contents"-----"Resources"----"DWARF"。这时你会看到和你APPNAME一样的文件,打开命令行输入atos -o [拖动地址到这里] -l [16进制地址] -arch arm64 [16进制地址]。
以我的文件为例最终命令为:
atos -o /Users/lr_ios1/Desktop/a/tcrrdios.app.dSYM/Contents/Resources/DWARF/tcrrdios-l 0x0000000100030000 -arch arm64 0x00000001000507f4
注意空格!!!注意空格!!!注意空格!!!重要的事情要说三遍
arm64是根据你实际CPU类型,这个现在基本都是64位的了,5以下的机型就是armv7。
执行完上面的命令得到的结果是:
-[MainViewController viewDidLoad] (in tcrrdios) (MainViewController.m:31)
这个返回值的意思大家应该都能看得懂了,发生崩溃的位置就是MainViewController.m这个文件的31行,也就是MainViewController这个类的viewDidLoad函数中。
来张图吧。。。。
到这里我相信小白也能看得懂了。其实我也是小白o(>﹏<)o。。。
什么?还是太难?好吧,介绍你们一种图形界面的方法,炒鸡简单,我就不详细介绍了,
https://github.com/answer-huang/dSYMTools
对就是上面的地址,作者已经把源码开源了,图形化定位代码位置够简单了吧,上面有操作方法。
顺便提供下下载地址:
https://pan.baidu.com/s/1mg01Qha