1. 应用发布后,记得保留 xx.app.dSYM文件,前往 /Users/用户名/Library/Developer/Xcode/Archives 目录,找到对应日期内的 xx.xcarchive 文件,显示包内容,从里面取出dsym文件
2. 打开dsym文件分析工具
3. 拖入第一步中的dsym文件,将错误日志中的内存地址复制输入框,点击分析即可
资料:转http://blog.csdn.net/totogo2010/article/details/39892467
要分析崩溃日志,首先需要保留发布时的编译出来的.xcarchive文件。这个文件包含了.DSYM文件。
我一般的做法是,发布成功后,把这个文件.xcarchive直接提交到代码版本库对应的版本分支里,这样就不会搞丢了。
这个文件在哪呢?打开XCode->菜单Window->Organizer,在编译成功的文件上右键,就能打开了。
两种比较麻烦的方法。
第一种方法:
使用dwarfdump命令
dwarfdump --uuid xx.app.dSYM 用来得到app的UUID。
dwarfdump --lookup 0x12b45d -arch armv7 xx.app.dSYM 使错误的日志能看懂,把相应的内存地址对应到正确的地方。
如果一开始dwarfdump命令不能用的话,要先装Command Line Tools,这个在设置里面能下载(cmd+“,”打开设置)。另外还必须在进入.DSYM所在文件夹。
使用dwarfdump需要安装Command Line Tools,XCode里设置下载。而且需要进入.DSYM所在文件夹里进行操作。
第二种方法:
使用xcrun atos命令
atos -o YourApp.app.dSYM/Contents/Resources/DWARF/YourApp 0x00062867
具体步骤:1. cd定位到dsym所在文件夹 2.执行命令 atos -o xxxxx.app.dSYM/Contents/Resources/DWARF/xxxxx 错误编号
(这种方式最靠谱,另两种都不好用或失效了)
第三种方法:
找到当时上传代码时使用的DYSM文件,这文件通常在.xcarchive文件中。 右键该文件, 然后通过Terminal工具跳转到下面的DWARF文件夹中:
- 1
- 1
然后执行
下面重点推荐下这个方法,方便快捷
第四方法:可视化工具
下面这是我的项目里通过友盟统计到的崩溃日志,如果光看这些日志报告的话,是不会知道是哪行代码引起的。
使用方法是把对应版本的.xcarchive文件拖到工具。对比UUID和友盟里日志是否一致,一致就把错误的地址信息拷贝到箭头处。点击分析。
即可得出具体代码崩溃位置。很简单吧。