iOS crash 日志分析

最新推荐文章于 2024-09-14 15:55:09 发布

weixin_34176694

最新推荐文章于 2024-09-14 15:55:09 发布

阅读量77

点赞数

文章标签：移动开发 xcode 嵌入式

原文链接：https://my.oschina.net/jack088/blog/1620572

版权

2019独角兽企业重金招聘Python工程师标准>>>

有很多问题是在开发测试过程中无法遇到和重现的，这就需要统计线上的崩溃信息进行定位。

什么是 dSYM

Xcode编译项目后，我们会看到一个同名的 dSYM 文件，dSYM 是保存 16 进制函数地址映射信息的中转文件，我们调试的 symbols 都会包含在这个文件中，并且每次编译项目的时候都会生成一个新的 dSYM 文件，位于 /Users/<用户名>/Library/Developer/Xcode/Archives 目录下，对于每一个发布版本我们都很有必要保存对应的 Archives 文件当我们软件 release 模式打包或上线后，不会像我们在 Xcode 中那样直观的看到用崩溃的错误，这个时候我们就需要分析 crash report 文件了，iOS 设备中会有日志文件保存我们每个应用出错的函数内存地址，通过 Xcode 的 Organizer 可以将 iOS 设备中的 DeviceLog 导出成 crash 文件，这个时候我们就可以通过出错的函数地址去查询 dSYM 文件中程序对应的函数名和文件名。大前提是我们需要有软件版本对应的 dSYM 文件，这也是为什么我们很有必要保存每个发布版本的 Archives 文件了。

友盟的崩溃信息跟踪

友盟的使用比较简单，因为崩溃信息中有提示的命令，前提是上线时是你本机的 Xcode 进行的上传或导出工作，因为这样才会有dSYM文件。首先打开友盟的崩溃统计，找到要定位的 bug,点击绿色的内存地址，就会弹出一个弹框，拷贝弹框中的命令

友盟

然后打开Mac命令行，将拷贝的命令粘贴进去，按 return 键执行，如果解析成功的话，就会打印出崩溃信息了，方法、文件、行数等。

信息

其他崩溃统计或不是自己打包

如果使用的是其他的崩溃统计服务或者当时并不是自己打包的，只有崩溃信息的内存地址，可以使用下面的办法。首先，找到当时archive的.xcarchive文件。如果是本机进行的archive，那么在>/Users/username/Library/Developer/Xcode/Archives目录下会找到所有的archive文件，该目录是默认的存放目录，如果这是公司的办公本，并且你没有在该目录下找到最近的文件，则有可能是 Xcode 的设置被更改了。打开 Xcode 首选项，选择最右侧的 locations,就可以看到 Xcode 的相关文件存放路径，点击箭头即可打开文件位置。

archive 文件路径

如果并不是本机进行的 archive，那么找到当时的电脑或则从同事那里拷贝到archive也是可以的。好的，archive文件已经找到，下面就可以进行定位了。右键archive文件选择 显示包内容，然后选择 dSYMs 文件夹里的.dSYM 文件再次显示包内容，然后会找到一个 DWARF 的文件夹，保持该 Finder 窗口打开

archive包内容

dsym

最终路径

第三步，打开终端，先输入 cd,然后选中将DWARF文件夹拖到终端窗口上，会看到 cd 后面自动加上了DWARF文件夹的路径，按 return 键进入该目录下最后在终端里输入如下命令atos -arch arm64 -o Xcode 项目名称内存地址例如atos -arch arm64 -o test-IOS 0x1001cb988按 return 键执行就会打印出该内存地址的具体文件、方法以及行数等信息，找到崩溃的位置就知道可能的原因以及解决方法了！

ps:

工具（https://github.com/answer-huang/dSYMTools）分析：

https://www.jianshu.com/p/4a201e4b7ed0

https://www.jianshu.com/p/115ef29b2c90

http://blog.csdn.net/nine_yao/article/details/53411427

转载于:https://my.oschina.net/jack088/blog/1620572