我们已经从fabric.io转移到了Firebase，除了一件事之外，一切似乎都很正常。我们正在使用 Unity 2019.2.6，目标平台是 iOS，目标架构是"通用".
对于dSYMs的上传，我将dSYMs文件夹从*.xcarchive打包成dSYMs.zip，并通过以下代码上传到Firebase。
./upload-symbols -gsp <path_to_plist>/GoogleService-Info.plist -p ios <path_to_dSYMs.zip>/dSYMs.zip
结果，我在终端中看到了以下几行。
Successfully submitted symbols for architecture arm64 with UUID <uuid_1> in dSYM: <path_to_unzipped_dsyms>/dSYMs/<myapp>.app.dSYM
Successfully submitted symbols for architecture armv7 with UUID <uuid_2> in dSYM: <path_to_unzipped_dsyms>/dSYMs/<myapp>.app.dSYM
Successfully uploaded Crashlytics symbols
之后，我可以在Crashlytics的仪表板上看到符号化的崩溃信息。
但是在Crashlytics的dSYMs选项卡中我也看到了以下内容。
Missing dSYMs
UID <uuid_3> Version <my_version> Status **Optional** Crash count <count_1>
UID <uuid_4> Version <my_version> Status **Optional** Crash count <count_2>
<...>
所以问题是：
为什么这些缺失的dsyms 可选?
这些缺失的 dsyms uuids 是怎么来的？
如果这些uuid_3, uuid_4是我的应用程序所支持的架构的uuid，而不是arm64和armv7，那么为什么它们不存在于*.xcarchive的dSYMs.zip中？
(dwarfdump在*.xcarchive dSYMs中只显示了armv7和arm64架构)
Firebaser在这里 -
dSYMs将为你的应用程序中的所有二进制文件和框架生成，这些通常会被标记为 "必需 "的dSYMs.你在应用程序中链接的框架也会有dSYMs生成，这些通常会被标记为 "可选"。因此，所需和可选的dSYMs来自不同的库，但最终它们都来自你的应用程序和你链接的任何框架。
如果你没有上传你的可选dSYMs，你可能会看到的行为（大多数时候）是，你的一些崩溃不会有几个堆栈框架的符号化；很可能在这些情况下，你的应用程序通过你的应用程序中链接的框架的一两个方法运行，你会经常看到它被来自其他库的符号化堆栈框架包围。但是，大多数时候，可选的dSYMs对于上传到Crashlytics并不是那么重要。
Crashlytics会阻止崩溃报告进入你的仪表板，直到与该崩溃报告相关联的 "必需的 "缺失的dSYMs被上传。一旦上传，崩溃报告将被处理并出现在您的仪表板上。如果只丢失了可选的 dSYM，那么这些崩溃事件将会 不 被阻止出现在您的仪表板上。
最后，在定位和上传你的dSYMs方面，我建议从这里开始。https:/firebase.google.comdocscrashlyticsget-deobfuscated-reports?platform=ios。. 你可以使用以下工具 dwarfdump -u </path/to/dSYMs> 来检查您下载的 dSYMs 是否与您仪表板中缺失的 dSYMs 的 UUID 相匹配。
DSyms是与IPA一起创建的iOS-Artefacts（也就是实际的构建文件）。它们不是运行应用程序所必需的，但可以用于Crashlytics（包括Fabric & Firebase），以提供有关崩溃的额外信息。