来到新公司后,前段时间就一直在忙,前不久 项目 终于成功发布上线了,最近就在给项目作优化,并排除一些线上软件的 bug,由于项目中使用了友盟统计,因此在友盟给出的错误信息统计中能比较方便的找出客户端异常的信息,但是不少像数组越界却只给出了 *** -[__NSArrayM objectAtIndex:]: index 50 beyond bounds [0 .. 39]' 这类错误信息,以下图所示: git
遇到这种问题若是经过 objectAtIndex 去检索错误的地方那将会是一个巨大的工做量。 github
dSYM 文件 数组
什么是 dSYM 文件 app
Xcode编译项目后,咱们会看到一个同名的 dSYM 文件,dSYM 是保存 16 进制函数地址映射信息的中转文件,咱们调试的 symbols 都会包含在这个文件中,而且每次编译项目的时候都会生成一个新的 dSYM 文件,位于 /Users/<用户名>/Library/Developer/Xcode/Archives 目录下,对于每个发布版本咱们都颇有必要保存对应的 Archives 文件 ( AUTOMATICALLY SAVE THE DSYM FILES 这篇文章介绍了经过脚本每次编译后都自动保存 dSYM 文件)。 ide
dSYM 文件有什么做用 函数
当咱们软件 release 模式打包或上线后,不会像咱们在 Xcode 中那样直观的看到用崩溃的错误,这个时候咱们就须要分析 crash report 文件了,iOS 设备中会有日志文件保存咱们每一个应用出错的函数内存地址,经过 Xcode 的 Organizer 能够将 iOS 设备中的 DeviceLog 导出成 crash 文件,这个时候咱们就能够经过出错的函数地址去查询 dSYM 文件中程序对应的函数名和文件名。大前提是咱们须要有软件版本对应的 dSYM 文件,这也是为何咱们颇有必要保存每一个发布版本的 Archives 文件了。 工具
如何将文件一一对应 优化
每个 xx.app 和 xx.app.dSYM 文件都有对应的 UUID,crash 文件也有本身的 UUID,只要这三个文件的 UUID 一致,咱们就能够经过他们解析出正确的错误函数信息了。 ui
1.查看 xx.app 文件的 UUID,terminal 中输入命令 : spa
dwarfdump --uuid xx.app/xx (xx表明你的项目名)
2.查看 xx.app.dSYM 文件的 UUID ,在 terminal 中输入命令:
dwarfdump --uuid xx.app.dSYM
3.crash 文件内第一行 Incident Identifier 就是该 crash 文件的 UUID。
dSYM工具
因而我抽了几个小时的时间将这些命令封装到一个应用中,也为之后解决bug提供了便利。
使用步骤:
1.将打包发布软件时的xcarchive文件拖入软件窗口内的任意位置(支持多个文件同时拖入,注意:文件名不要包含空格)
2.选中任意一个版本的xcarchive文件,右边会列出该xcarchive文件支持的CPU类型,选中错误对应的CPU类型。
3.对比错误给出的UUID和工具界面中给出的UUID是否一致。
4.将错误地址输入工具的文本框中,点击分析。
Mac app下载地址 项目源码地址