iOS开发中的crash文件及重新符号化的问题

苹果iOS App开发难免会遇到Bug,需要进行调试。笔者曾经遇到一个问题是提交到App Store审核的App会报错,但是在本地测试,哪怕是用TestFlight下载提交的那个版本测试,也不会报错。苹果审核员提供了几个crash的文件,建议我们进行问题排查。这就杯具了。因为开发人员在发布的时候,在设置中设置“Strip Debug Symbols During Copy”中“Release”为“Yes”。


iOS开发中的crash文件及重新符号化的问题_第1张图片

所以,打开crash文件一看,在自己的APP那里,显示的都是一堆内存地址,像“0x10004000”这样。


iOS开发中的crash文件及重新符号化的问题_第2张图片

这该如何处理呢?

首先必须认识到,crash文件的解读离不开“Symbolication”(符号化)。没有符号化的crash文件就象上图一样,完全没法理解。而如果正确的符号化了,就会变成下图的样子:


符号化的关键是一个叫做“.dSYMfile”的文件,这是在打包(Archieve)时一并生成的。一般情况下,Xcode的默认配置,打包(Archieve)都会选择“Release”的配置,而“Release”配置会默认设置“Strip Debug Symbols During Copy”为“Yes”,这样生成的binary实际上是不能提供符号信息的。

遇到这种情况,可以按照以下步骤处理:

1)获取和App Store上的版本一致的代码包。配置管理这个时候就显出重要性了:)(所有的代码都必须做配置管理,每一次发布都要打Tag!!)。

2)修改“Strip Debug Symbols During Copy”下“Release”为“No”。

3)重新打包(Archieve)。

4)打开“Windows”->“Devices”,选择开发机,点击右侧的“View Device Logs”。


iOS开发中的crash文件及重新符号化的问题_第3张图片

5)将crash文件拖入左侧,并点击“All Logs”。这时,就可以看到右侧原来不可读内容变成可读的代码,并且定位到了代码行。


iOS开发中的crash文件及重新符号化的问题_第4张图片

6)如果还是仅有内存地址,那么就在左侧的crash记录上点击右键,选择“Re-Symbolicate Log”。如下图:


有了明确的crash记录做指导,我们很快就定位到了真正问题所在。快速地解决了问题。

By the way:上图所示的问题实际上是百度的逆地址查询有可能返回空字符串的城市名称,坑爹的是,百度给出的结果状态却是正确的。但这空的城市名称实际上是没法处理的。在国内,大多数情况下,可能都能得到正确值,但苹果审核员在米国啊!!!

附上苹果官方文档链接:

Understanding and Analyzing iOS Application Crash Reports

你可能感兴趣的:(iOS开发中的crash文件及重新符号化的问题)