友盟崩溃日志分享,dsym工具
2016-07-28 14:17
363 查看
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 --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所在文件夹里进行操作。
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
然后执行
下面重点推荐下这个方法,方便快捷
使用方法是把对应版本的.xcarchive文件拖到工具。对比UUID和友盟里日志是否一致,一致就把错误的地址信息拷贝到箭头处。点击分析。
即可得出具体代码崩溃位置。很简单吧。
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文件夹中:
$ cd ~/Library/Developer/Xcode/Archives/yyyy-mm-dd/appname.xcarchive/dSYMs/appname.app.dSYM/Contents/Resources/DWARF1
1
然后执行
$ atos -arch arm64 -o xxxMovie 0x1153b9
下面重点推荐下这个方法,方便快捷
第四方法:可视化工具
下面这是我的项目里通过友盟统计到的崩溃日志,如果光看这些日志报告的话,是不会知道是哪行代码引起的。使用方法是把对应版本的.xcarchive文件拖到工具。对比UUID和友盟里日志是否一致,一致就把错误的地址信息拷贝到箭头处。点击分析。
即可得出具体代码崩溃位置。很简单吧。
相关文章推荐
- Android studio快捷键大全+Android studio使用小技巧
- Linux中Apache+Tomcat+JK实现负载均衡和群集的完整过程 .
- git系列------git revert
- 几处错误
- android TextView跑马灯 让字体滚动起来
- MSSQL使用超大内存支持
- 【SSH快速进阶】——Spring AOP原理及其实现
- Tomcat7.0源码分析
- thinkphp连接sql server 2008(同时支持windows和linux环境)
- 一个非常有意思的css3属性filter
- LostRoutes项目日志——编辑project.json
- 关于activity切换,推出和覆盖的实现和区别
- G++ GCC的编译过程
- 苏宁大造818发烧节,玩得是哪招?
- File以及bitmap的联系
- oracle substr
- c++11 之可变参数模板
- VS开发人员命令界面查看C++类内存布局
- svn分支开发与主干合并(branch & merge)
- 移动联通电信基站定位接口