iOS开发符号表(dSYM)知识总结

11,440 阅读5分钟
原文链接: www.cloudchou.com

iOS开发时经常需要接触符号表的概念,本文主要分享符号表相关知识,包括什么是符号表,符号表的作用,符号表的产生过程,如何查找符号表文件,如何查找符号表文件的uuid。

iOS符号表(dSYM)知识总结

什么是符号表 以及 为什么需要使用符号表

iOS构建时产生的符号表,它是内存地址与函数名,文件名,行号的映射表。 符号表元素如下所示:

<起始地址> <结束地址> <函数> [<文件名:行号>]

类似于android构建release包时的mapping文件,我们利用mapping文件可以将混淆后的APP运行时的现成堆栈信息还原成混淆前的堆栈信息(利用retrace 工具)。所以当应用crash时,我们可以利用crash时的堆栈信息得到对应到源代码的堆栈信息,还能看到出错的代码在多少行,所以能快速定位出错的代码位置,以便快速解决问题。

而iOS应用crash时也有堆栈,release版的应用,crash时的堆栈信息,全是二进制的地址信息。

android至少还能看到函数名字,虽然是混淆的,还能看到系统函数的名字,所以相对来说还好一点)

如果利用这些二进制的地址信息来定位问题是不可能的,因此我们需要将这些二进制的地址信息还原成源代码种的函数以及行号,这时候就需要符号表了。 举个例子:

iOS_dSYM_crash_restore

而debug版本的应用,crash时的堆栈信息有时能看到函数名字,但是也看不到对应的源代码文件的行号,这样也没法定位问题。 debug版本崩溃时的堆栈如下所示:

iOS_dSYM_debug_stacktrace

因此如果我们将产品提供给项目成员体验时,不管是debug版本还是release版本都需要符号表来帮我们将crash的堆栈信息还原成源代码文件对应的信息,以便快速定位问题

如果使用bugly来做crash上报管理,只需要将构建时的符号表上传到bugly,当应用crash时,bugly会将crash信息上报到bugly,然后会自动替我们将原始的crash的二进制堆栈信息还原成包含行号的源代码文件信息,我们就可以快速定位问题

符号表如何产生

看一下ios项目的归档构建流程:

  1. 准备构建环境,构建目录

  2. 编译主工程依赖的Pods工程的静态库或者Framework (=== BUILD TARGET Aspects OF PROJECT Pods WITH CONFIGURATION Debug ===)

  3. 编译主工程的源代码文件 (CompileC)

  4. 链接生成主工程对应的可执行文件 (Ld)

  5. 拷贝图片,localized字符串等资源文件 (CpResource)

  6. 编译storyboard文件 (CompileStoryboard)

  7. CompileAssetCatalog

  8. 处理pinfo.list文件 (ProcessInfoPlistFile)

  9. 生成符号表文件(GenerateDSYMFile)

  10. 链接StoryBoard(LinkStoryboards)

  11. 执行配置的脚本文件(PhaseScriptExecution)

  12. 打包生成app文件,不是ipa文件(ProcessProductPackaging)

  13. 签名 (CodeSign)

  14. 校验 (Validate)

像Bugly要求我们在工程配置的Build Phases里添加它的脚本,用于将生成的符号表上传到bugly。根据归档构建流程,我们知道生成符号表的步骤是在处理pinfo.plst文件之后,所以我们配置的bugly的执行脚本必须放在链接这个步骤之后,否则会导致找不到符号表文件。另外最初生成的符号表并不是在我们看到的归档文件内部,而是放在构建的一个临时目录中,最后才拷贝到归档目录下的,最初生成的符号表文件的存放目录类似于如下:

/Users/cloud/Library/Developer/Xcode/DerivedData/Xxx-ajmvyrkvoxmeqecuyqlnxbgtlaoy/Build/Intermediates.noindex/ArchiveIntermediates/Here/BuildProductsPath/Debug-iphoneos/Xxx.app.dSYM

其实第1步~第11步就是我们为主工程主Target配置的构建步骤,如下所示:

target_build_phases

注意:

  1. debug配置默认不会生成符号表

    如果想生成符号表,可参看:XCode编译后没有生成dSYM文件?

  2. 每次构建时都会产生不同的符号表,这个和android的mapping文件很不一样,每个符号表都有一个唯一的uuid,和每次构建对应

通过归档构建流程得到的是xarchive归档文件,如果要生成ipa文件还必须通过归档文件导出ipa文件 命令行归档的命令如下

xcodebuild -workspace CardPlayer.xcworkspace -scheme CardPlayer  -destination generic/platform=iOS -configuration Debug archive -archivePath ~/Desktop/CardPlayer

命令行导出ipa文件的命令如下所示:

xcodebuild -exportArchive -archivePath ~/Desktop/CardPlayer -exportPath ~/Desktop/CardPlayer2017 -exportOptionsPlist expportOption.plist 

如何定位dSYM文件

参看如何定位dSYM文件

dSYM文件其实是一个带后缀的文件夹形式的文件,内容如下所示:

CardPlayer.app.dSYM/
└── Contents
    ├── Info.plist
    └── Resources
        └── DWARF
            └── CardPlayer

真实的符号表文件其实是1个二进制文件,bugly提供了脚本将这个二进制文件转为文本形式的文件,文件的内容其实就是二进制地址对和源代码文件,行号以及函数名字的对应关系

如何查看dSYM文件的uuid

iOS App崩溃时会有此次构建的uuid信息,如果要将崩溃堆栈还原成对应的源代码文件信息,需要根据这个uuid找到对应的符号表的uuid,这样才能正确还原

参看如何查看dSYM文件的uuid

总结下来有2种方式:

  1. 通过命令查看

    xcrun dwarfdump --uuid <dSYM文件>
    
  2. 通过bugly脚本导出符号表文件查看uuid

如何找回已发布到App Store的App对应的dSYM文件?

参看如何找回已发布到App Store的App对应的dSYM文件

参考资料

  1. iOS符号表

备注

后续再总结开发时崩溃的堆栈如何还原,理论上来说应该有两个步骤:

  1. 监听ios app崩溃, 并打印崩溃堆栈信息至文件里

  2. 将崩溃堆栈信息还原成源文件对应的信息

¥打赏5毛