本文主要介绍 Android、iOS、Harmony 三个平台符号表的定义、查找以及各种配置详细说明 。
Android 符号表
在 Android 平台，包含了 SO 的符号表和 Java 的 mapping 文件两类符号表。
SO 符号表：符号表是内存地址与函数名、文件名、行号的映射表。符号表元素为：
<起始地址> <结束地址> <函数> [<文件名:行号>]。对于 Native Crash，为了能快速并准确地定位用户 App 发生 Crash 的代码位置，平台使用符号表对 App 发生 Crash 的程序堆栈进行解析和还原，例如下图：
mapping 文件：mapping 文件用于对混淆后的 Java 代码进行还原，详见 代码混淆。
Android 的 mapping 文件通过 App 版本，构建号来进行关联。例如，对于指定异常上例，平台通过 App 版本、构建号来查找匹配的符号表文件。对于指定的 App 版本和构建号，平台支持上传多个符号表文件，通过文件名来区分。
平台推荐业务方将宿主的 mapping 文件命名为 mapping.txt，插件或者组件的符号表文件命名为 xxx_mapping.txt，支持通过批量上传，或者多次上传这些符号表文件。详情请参见 Android 应用上传插件的符号表。
查找符号表
SO 符号表位置
Android 平台中，Debug SO 文件是指具有调试信息的 SO 文件，其中包含用户还原堆栈的符号信息。
说明：
为了方便找回 Crash 对应的 Debug SO 文件和还原堆栈，建议每次构建或者发布 App 版本的时候，备份好 Debug SO 文件，或者借助平台的符号表上传工具，将符号表上传到平台。
CMake 编译项目：默认情况下，Debug 编译的 Debug SO 文件位于
<项目文件夹>/<Module>/build/intermediates/cmake/debug/obj/local<架构>/。
NDK 编译项目：默认情况下，Debug 编译的 Debug SO 文件位于
<项目文件夹>/<Module>/build/intermediates/ndk/debug/obj/local<架构>/。
mapping 文件位置
默认情况下，mapping 文件位置在
<项目文件夹>/<Module>/build/outputs/mapping/<build-type>/。
符号表与 Crash 匹配
平台还原 Native Crash 堆栈时，需要根据 UUID 来匹配符号表文件，因此只有上传的符号表文件的 UUID 与 Native Crash 堆栈的 SO 文件的 UUID 一致时（从后往前匹配），才能准确地对堆栈进行还原。
对于 Java 堆栈的还原，当前平台使用 App 版本号 + 构建号来识别和定位 mapping 文件。
查看符号表文件的 UUID，详情请参见 UUID 提取指引。
在问题详情 > 个例详情 > 符号表中查看当前异常堆栈中的符号表信息。
查看 Debug SO 文件的 UUID
符号表文件的 UUID 与 Debug SO 文件的 UUID 是一致的，因此可以通过符号表工具生成的符号表文件来查看 Debug SO 文件的 UUID。操作步骤为：生成符号表文件(.zip) -> 解压符号表文件(.symbol) -> 使用文本编辑器打开符号表文件。
其中符号表文件的 “SHA-1” 信息即 Debug SO 文件的 UUID ，亦是符号表文件的 UUID ，如果文件较大，建议使用 “Sublime Text” 等文本编辑器来打开符号表文件。更多说明请参见 UUID 提取指引。
说明：
由于平台已采用新的 UUID 计算规则，为了能正确地匹配 Crash 堆栈对应的 SO 文件，请使用2.5.0或以上版本的符号表工具。
查找 Crash 对应的 Debug SO 文件
如果本地已经无法找到 Crash 对应的符号表文件或者 Debug SO 文件了，但还能找回 Crash 对应的 App 版本的 Native 工程代码，建议尝试重新用 NDK 编译出 Debug SO 文件并用符号表工具生成符号表文件。
注意：
如果 Native 工程代码无法找回 Debug SO 文件，将无法还原 Crash 堆栈。所以建议在每次构建或者发布 App 版本时，请备份 Debug SO 文件。
iOS 符号表
符号表是内存地址与函数名、文件名、行号的映射表，符号表元素为：
<起始地址> <结束地址> <函数> [<文件名:行号>]。为了能快速并准确地定位用户 App 发生 Crash 的代码位置，平台使用符号表对 App 发生 Crash 的程序堆栈进行解析和还原，例如下图：
dSYM 文件
dSYM 表示 Debug Symbols，即调试符号，称为符号表文件。符号对应着类、函数、变量等，这个符号表文件是内存与符号，例如函数名、文件名、行号等的映射，在崩溃日志分析方面起到了重要作用。
iOS 平台中，dSYM 文件是指具有调试信息的目标文件，文件名通常为：xxx.app.dSYM 。如下图所示：
备份符号表文件：
为了方便找回 Crash 对应的 dSYM 文件和还原堆栈，建议在每次构建或者发布 App 版本时，备份 dSYM 文件。
定位 dSYM 文件
一般情况下，项目编译完 dSYM 文件跟 App 文件在同一个目录下，下面以 Xcode作为 IDE 详细说明定位 dSYM 文件。
1. 进入Xcode。
2. 打开工程（已编译过）。
3. 在左栏找到 Products。
4. 鼠标右键点击编译生成的“xxx.app”，单击 Show in Finder。
说明：
如果有多个 dSYM 文件，在使用符号表工具上传时，可以指定输入为 dSYM 文件所在的目录或者工程目录。
Debug 编译 Xcode 配置
Xcode Release 编译默认会生成 dSYM 文件，而 Debug 编译默认不会生成，对应的 Xcode 配置如下：
XCode -> Build Settings -> Code Generation -> Generate Debug Symbols -> YesXCode -> Build Settings -> Build Option -> Debug Information Format -> DWARF with dSYM File
dSYM 文件与 Crash 的 UUID 匹配
还原 Crash 堆栈时，需要根据 UUID 来匹配符号表文件，因此只有上传的符号表文件的 UUID 与 Crash 对应 App的 UUID 一致时，才能准确地对堆栈进行还原。
查看符号表文件的 UUID，详情请参见 UUID 提取指引。
在问题详情 > 个例详情 > 符号表中查看当前异常堆栈中的符号表信息。
查看 dSYM 文件的 UUID
通过命令查看 UUID
xcrun dwarfdump --UUID <dSYM文件>
通过符号表文件查看 UUID
符号表文件的 UUID 与 dSYM 文件的 UUID 是一致的，因此可以通过符号表工具生成的符号表文件来查看 dSYM 文件的 UUID。操作步骤为：生成符号表文件(.zip) -> 解压符号表文件(.symbol) -> 使用文本编辑器打开符号表文件。
其中符号表文件的 “UUID” 信息即 Debug SO 文件的 UUID，亦是符号表文件的 UUID，如果文件较大，建议使用 “Sublime Text” 等文本编辑器来打开符号表文件。
找回已发布到 App Store 的 App 对应的 dSYM 文件
支持通过 Xcode、iTunes connect、mdfind 工具找回已发布到 App Store 的 App 对应的 dSYM 文件 。
1. 打开 Xcode 顶部菜单栏 > Window > Organizer 窗口。
2. 打开 Xcode 顶部菜单栏，选择 Archive 标签。
3. 找到发布的归档包，右键点击对应归档包，选择 Show in Finder 操作。
4. 右键选择定位到的归档文件，选择显示包内容操作。
5. 选择 dSYMs 目录，目录内即为下载到的 dSYM 文件。
1. 登录 iTunes Connect。
2. 进入我的 App（My Apps） > 活动（Activity）页面。
3. 在所有构件版本（All Builds）中选择某一个版本，单击下载 dSYM（Download dSYM）下载 dSYM 文件。
1. 在平台的 issue 页面查询到 Crash 对应的 UUID。
2. 然后在 Mac 的 Shell 中，用 mdfind 命令定位 dSYM 文件。
mdfind "com_apple_xcode_dsym_UUIDs == <UUID>"
注意：
注意，使用 mdfind 时，UUID 需要格式转换（增加“-”），例如： 12345678-1234-1234-1234-xxxxxxxxxxxx。
例如，要定位的 dSYM 的 UUID为：E30FC309DF7B3C9F8AC57F0F6047D65F 则定位 dSYM 文件的命令如下。
mdfind "com_apple_xcode_dsym_UUIDs == E30FC309-DF7B-3C9F-8AC5-7F0F6047D65F"|12345678-1234-1234-1234-xxxxxxxxxxxx|
说明：
建议每次构建或者发布 App 版本的时候，备份 App 对应的 dSYM 文件。
Harmony（鸿蒙）符号表
SO 符号表：符号表是内存地址与函数名、文件名、行号的映射表。符号表元素为：
<起始地址> <结束地址> <函数> [<文件名:行号>]。对于鸿蒙 Native Crash，为了能快速并准确地定位用户 HAP 发生 Crash 的代码位置，平台使用符号表对 HAP 发生 Crash 的程序堆栈进行解析和还原。例如下图：
nameCache & SourceMaps 文件：Harmony 的 nameCache & SourceMaps 文件类似 Android 的 mapping：nameCache 文件用于混淆前后 ts/js 符号、变量等名称的前后对应；SourceMaps 文件用于混淆前后 ts/js 的行号对应。
nameCache & SourceMaps 文件通过
HAP 版本 + 构建号进行关联。例如，对于指定异常上例，平台通过 HAP 版本 + 构建号来查找匹配的符号表文件。对于指定的 HAP 版本和构建号，平台支持上传多个符号表文件，通过文件名来区分。如同一个版本号 + 构建号，可同时上传以下文件。nameCache.JSON
SourceMaps.JSON
rumpro_nameCache.JSON
rumpro_SourceMaps.JSON
平台推荐业务将宿主的 nameCache 文件和 SourceMaps 文件命名为 nameCache.JSON 和 SourceMaps.JSON，插件或者组件的符号表文件命名为 xxx_nameCache.JSON 或 xxx_SourceMaps.JSON，支持通过批量上传，或者多次上传这些符号表文件。如果相同版本号 + 构建号存在已上传同名文件，则继续上传会覆盖之前的同名文件。
说明：
当前鸿蒙版本 HAR 包暂时不支持混淆构建生成 SourceMaps 文件。
如构建闭源规则链接打不开，需要申请华为鸿蒙开发权限。
查找符号表
SO 符号表位置
Harmony 平台中，Debug SO 文件是指具有调试信息的 SO 文件，其中包含用户还原堆栈的符号信息。Harmony 平台编译 SO 默认使用 Dwarf 5格式调试信息，而 Android 平台通常会使用 Dwarf 4/3 格式调试信息。
说明：
为了方便找回 Crash 对应的 Debug SO 文件和还原堆栈，建议每次构建或者发布 HAP 版本的时候，备份好 Debug SO 文件。或者借助平台的符号表上传工具，将符号表上传到平台。
默认情况下，Harmony 平台 Native 代码使用 CMake 编译，编译的 Debug SO 文件位于
<项目文件夹>/<Module>/build/default/intermediates/cmake/default/obj/<架构>/
nameCache & SourceMaps 文件位置
默认情况下，nameCache 文件位置在：
<项目文件夹>/<Module>/build/default/cache/default/default@CompileArkTs/esmodule/release/obfuscation/nameCache.JSON/默认情况下，SourceMaps 文件位置在：
<项目文件夹>/<Module>/build/default/cache/default/default@CompileArkTs/esmodule/release/SourceMaps.JSON/
提醒：
为了方便找回 Crash 对应的 ts 还原堆栈，建议每次构建或者发布 HAP 版本的时候，备份好 nameCache 和 SourceMaps 文件。或者借助平台的符号表上传工具，将符号表上传到平台。
