原文是 2017-02-21 Technical Note TN2151
（时间有限，翻译粗糙，见谅，日后再整理）
当应用崩溃时，崩溃日志就被创建起来，这对查找崩溃原因非常有帮助，这个文档包含一系列基本的信息关于怎样符号化，理解并解释崩溃报告。
简介：
当一个应用崩溃时，一封崩溃报告就会被设备创建和保留。在应用结束前崩溃报告描述了一些情况，大多数都包含一份完整的可执行线程，这通常对调试程序非常有用，你应该查看这些崩溃报告去理解你的应用有哪些崩溃并且试着修复这些问题。
可回溯的崩溃报告必须在分析前被符号化，符号用可读性的方法名和行数替代了内存地址，如果你在Xcode的Devices窗口得到了崩溃日志，他们会在几秒后自动的为你自动的进行符号化，如果没有，那你就必须自己通过Xcode的Devices窗口符号化它们，具体细节参考 Symbolicating Crash Reports 这篇文章。
低内存的报告和其他崩溃报告不一样，在这种报告中没有回溯信息。当低内存崩溃发生时，你应该检查你的内存使用模式，和当低内存警告出现时你的处理方式。这篇文章指出了特别对你有用的一些内存管理指南。
获取崩溃和低内存报告
Debugging Deployed iOS Apps 讨论了怎样从iOS设备直接中检索崩溃和低内存报告
App Distribution Guide 中的 Analyzing Crash Reports 讨论了怎样从在App Store下载你的应用的TestFlight测试和用户中查看崩溃报告的总数；
符号化崩溃报告：
符号化是解决回溯地址到源代码方法或方法名的过程，比如符号。如果没有符号化崩溃报告就很难决定崩溃发生的地方。
注意：低内存报告不需要被符号化。
注意：崩溃报告在macOS系统产生时通常会被符号化或者部符号化，这一章节主要讲iOS，watchOS，tvOS的崩溃报告符号化，但是大体过程和macOS的一样。
图1: 崩溃报告和符号化过程的概述
1 当编译器把你的源代码翻译成机器码，它还生成调试符号，将编译后的二进制指令中的每个机器指令映射到源代码中的代码行。根据调试信息格式（DEBUG_INFORMATION_FORMAT）编译设置，这些调试符号储存在二进制或配套调试符号文件中。默认情况下，调试版本的应用程序 储存 调试符号在编译的二进制文件中，而发布版本的应用程序 储存 调试符号在配置dsym文件中，从而减少二进制文件的大小。
调试符号文件和应用二进制文件通过生成的UUID捆绑在一份编译文件。你建立并生成每个应用程序的都会产生一个唯一标识的UUID。即使一个功能相同的可执行文件从相同的源代码重构，并具有相同的编译器设置，但是会有不同的编译UUID。后续版本的调试符号文件，甚至来自同一个源文件，不会与其他版本的二进制文件互用。
2 当你在发布应用程序而存档时，Xcode会随着.dsym文件存放在主页文件夹时存储应用程序二进制文件。你可以在“Archived”部分下的“Xcode Organizer”中找到所有的存档应用。更多关于创建存档的资料，请参见App Distribution Guide.
注意：为了符号化测试员，应用审查人员和客户的崩溃报告，你必须保留每个你发布的应用程序的存档。
3 如果你通过App Store发布的应用程序，或使用TestFlight进行测试，你可以在上传存档到iTunes Connect时选择包含dSYM文件。在提交会话栏中选择 “Include app symbols for your application…”。上传你的dSYM文件对选择了分享诊断数据的TestFlight用户中搜集的崩溃报告来说是必要的，更多关于崩溃报告服务的信息，参考 App Distribution Guide.
注意：即使你在上传你的归档到iTunesConnect ，在App Review中得到的崩溃报告不会被符号化。你需要通过Xcode符号化任何从AppReview中接受的崩溃报告，参见Symbolicating Crash Reports With Xcode.
4 当你的应用程序崩溃，一个unsymbolicated崩溃报告创建并存储在设备上。
5 用户能够按照Debugging Deployed iOS Apps.中的步骤直接从他们的设备中搜索崩溃报告，如果你的应用通过AdHoc或者企业版发布，这是唯一你能从你的用户获得崩溃报告的路径。
6 从设备中获得的崩溃报告没有符号化，需要通过Xcode符号化，Xcode使用二进制文件相关联的dSYM文件替代在源代码中的原位置的每个回溯中的地址。结果就是符号化的崩溃报告。
7 如果用户选择了给苹果公司分享诊断数据，或者用户通过TestFlight安装了测试版本，崩溃报告就会上传到App Store。
8 App Store 符号化这些崩溃报告并且将相识的崩溃报告分组，这些相似的崩溃报告归纳起来叫做崩溃点（Crash Point）。
9 可以通过 Xcode的Crashes organizer符号化崩溃报告。
Bitcode
Bitcode 是编译程序这种的中间表示。但你使用bitcode enabled 来归档一个应用时，编译生成的二进制文件包含bitcode而不是机器码。一旦二进制文件被上传到App Store，bitcode就被编译成机器码。利用未来编译器的改进，App Store可能以后会再次编译bitcode，这对你的部分不会有影响。
图2: 概述bitcode编译过程
因为你的二进制文件在App Store中进行最后的编译，你的mac将不会包含从应用审查或者从他们设备发送崩溃报告的用户中需要符号化崩溃报告的调试符号文件，虽然dSYM文件在你归档应用的时候产生，但是只能用来bitcode二进制文件，并且不能符号化崩溃报告，App Store从Xcode或者iTunes Connect网站得到bitcode编译文件供你下载。为了那些从App Review或者用户从他们的设备发送的崩溃报告中符号化崩溃报告，你必须下载这些dSYM文件。通过崩溃报告服务的崩溃报告将会被自动的符号化。
注意：通过App Store的二进制编译文件将会和最初提交的二进制文件有不通的UUID。
通过Xcode下载dSYM文件：
1 在 Archives organizer 中，选择你最初提交到App Store的归档。
2 点击 Download dSYMs 按钮。
Xcode下载dSYM 文件后嵌入到选择的归档文件中。
通过 iTunes Connect 网址下载dSYMs文件
1 打开 App Details 页面。
2 点击Activity。
3 从所有编译文件中，选择一个版本。
4 点击 Download dSYM 链接。
确定一份崩溃报告是否被符号化
一份崩溃报告可能没有被符号化，完全符号化或者部分符号化。没有被符号化的崩溃报告不会在回溯中包含方法或者函数名。在装载的二进制图像你有可执行代码的十六位进制地址。在一份全部符号化的崩溃报告，在回溯的每行代码的十六进制地址都被相应的符号替代。在部分被符号化的报告中，总有一部分回溯中的地址被相应的符号替代。
很显然，你应该尝试着完全符号化所有你收到的崩溃报告，这将为崩溃提供最清晰的说明。部分的符号化崩溃报告依赖崩溃的类型和成功符号化的部分回溯可能包含足够的信息去理解崩溃。没有被符号化的崩溃报告几乎没有用。
图 3 ：基于一份回溯的各种级别的符号化。
使用Xcode来符号化崩溃报告
Xcode会自动尝试他所遇到的所有崩溃报告。为了符号化你所要做的只是在 Xcode Organizer中添加崩溃报告。
1 把你的iOS设备连接上你的Mac。
2 在“window”目录选择“devices”。
3 在“devices”部分的左栏中，选择一个设备。
4 在右面板的“Device information”部分点击“view device logs”按钮
5 拖动你的崩溃报告到展示面板的左栏。
6 Xcode会自动的符号化崩溃报告并显示结果
为了能符号化崩溃报告，Xcode需要找到如下：
1 崩溃应用的二进制文件和dSYM文件
2 应用链接的所有自定义框架的二进制和dSYM文件。对于应用的源码编译的框架，他们的dSYM文件伴随着应用的dSYM文件被复制到归档中。对于用第三方编译的框架，你必须向作者索要dSYM文件。
3当应用崩溃时运行的操作系统的符号文件。这些符号文件为框架包含了有特定操作系统发布版本的调试信息，（比如iOS9.3.3）。
操作系统符号文件是有特定架构的，64bit设备的操作系统不会包含arm7符号文件。Xcode会自动复制连接你Mac的设备的操作系统符号文件。
如果 如上文件有遗失。Xcode就不会或者只会部分的符号化崩溃报告。