问题描述
我们已经从fabric.io移到了Firebase，除了一件事之外，其他一切似乎都还不错.我们正在使用 Unity 2019.2.6 ，目标平台是 iOS ，目标体系结构是" Universal ".
We've moved from fabric.io to Firebase and everything seems to be ok except one thing. We're using Unity 2019.2.6, target platform is iOS, target architecture is "Universal".
对于dSYM上传，我将dSYMs文件夹从* .xcarchive打包到dSYMs.zip，然后通过以下代码将其上传到Firebase
For dSYMs uploading I pack dSYMs folder from *.xcarchive to dSYMs.zip and upload it to Firebase via the following code
./upload-symbols -gsp <path_to_plist>/GoogleService-Info.plist -p ios <path_to_dSYMs.zip>/dSYMs.zip
结果，我在终端中看到以下几行:
As a result I see the following lines in my terminal:
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仪表板中看到被符号化的崩溃
After that I can see desymbolicated crashes in Crashlytics dashboard
而且在Crashlytics的dSYMs标签中，我看到以下内容:
But also in Crashlytics dSYMs tab I see the following:
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>
<...>
所以问题是:
-
为什么这些缺少的dsym是可选的?
这些丢失的dsym uuid来自何处?
Where do these missing dsyms uuids are come from?
如果这些uuid_3，uuid_4是我的应用程序支持的体系结构的uuid，而arm64和armv7除外，那么为什么它们不存在于* .xcarchive的dSYMs.zip中?
If these uuid_3, uuid_4 are uuids of architectures supported by my app and other than arm64 and armv7, then why they doesn't exsist in dSYMs.zip from *.xcarchive?
(dwarfdump仅显示* .xcarchive dSYM中的armv7和arm64体系结构)
(dwarfdump shows only armv7 and arm64 architectures in *.xcarchive dSYMs)
- 在哪里可以找到我的应用程序所需的所有dsym?
推荐答案
Firebaser此处-
Firebaser here -
dSYM将为您应用程序中的所有二进制文件和框架生成，并且通常将其标记为必需" dSYM.您在应用程序中链接的框架也将生成dSYM，并且通常将其标记为可选".因此，必需的和可选的dSYM来自不同的库，但最终它们都来自您的应用程序和要链接的任何框架.
dSYMs will generate for all the binaries and frameworks in your app, and those will often be marked as "required" dSYMs. Frameworks you're linking in your app will also have dSYMs generated, and those will often be marked as "optional." So, the required and optional dSYMs are coming from different libraries but in the end they're all coming from your app and any frameworks you're linking.
如果您不上传可选的dSYM，则您可能会看到的行为(大部分时间)是，某些崩溃不会用符号表示一些堆栈帧；在大多数情况下，您的应用程序通过应用程序中链接的方法中的一种或两种运行，而您经常会看到它被来自其他库的符号堆栈框架包围.但是，大多数情况下，可选的dSYM上载到Crashlytics并不那么重要.
If you don't upload your optional dSYMs, the behavior you may see (most of the time) is that some of your crashes will not have a few of the stackframes symbolicated; most likely in those cases your app ran through a method or two of a framework linked in your app, and you'll often see it surrounded by symbolicated stackframes from other libraries. But, most of the time the optional dSYMs are not that important to upload to Crashlytics.
Crashlytics将阻止崩溃报告进入您的仪表板，直到与该崩溃报告相关联的任何必需"缺少的dSYM都被上载.上载后，崩溃将被处理并显示在您的信息中心上.如果仅缺少可选的dSYM，这些崩溃将不会被阻止在您的仪表板上显示.
Crashlytics will stop crash reports from coming through to your dashboard until any "required" missing dSYMs that are associated with that crash report are uploaded. Once uploaded, the crashes will be processed and appear on your dashboard. If only optional dSYMs are missing, those crashes will not be stopped from appearing on your dashboard.
最后，关于查找和上传dSYM，我建议从此处开始: https://firebase.google.com/docs/crashlytics/get-deobfuscated-reports?platform=ios .您可以使用 dwarfdump -u</path/to/dSYMs> 之类的工具来检查您下载的dSYM是否与仪表板上缺少的dSYM的UUID相匹配.
Finally, in terms of locating and uploading your dSYMs, I recommend starting here: https://firebase.google.com/docs/crashlytics/get-deobfuscated-reports?platform=ios. You can use tools like dwarfdump -u </path/to/dSYMs> to check if the dSYMs you've downloaded match the UUIDs of the missing dSYMs in your dashboard.
这篇关于Firebase Crashlytics:缺少可选的dSYM的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！