ios - 在黑匣子情况下处理丢失的dSYM文件

Question

我们正在尝试解决使用Fabric / Crashlytics的iOS应用程序中的严重崩溃。我们没有上次使用该应用程序并将其最新版本上传到App Store的人员的详细联系信息。

在项目仪表板中，我注意到消息“在过去的24小时内，发现1个版本中缺少dSYM导致XXX出现未符号化的崩溃”。截图:https://i.imgur.com/YT9gggJ.jpg

我做了我能想到的唯一明智的事情:我去了App Store Connect仪表板。我按照Fabric的官方说明下载了有关构建的dSYM zip:https://docs.fabric.io/apple/_images/download-dsym.png

然后，我转到dSYM工具并直接上传了zip文件。原来，所需的四个文件中只有两个在zip中(我自己也检查过):https://i.imgur.com/JqxZcaD.jpg

所以...我在这里处于黑箱状态...

我不是iOS开发人员

我无权访问用于构建项目的计算机或生成该构建的人

我正在协助刚刚加入

团队的iOS开发人员

我可以访问项目存储库

我可以访问App Store Connect个人资料

我在Fabric

中具有管理员权限

我的问题是:

为什么其他两个dSYM文件不在我从App Store下载的zip文件中？

为什么某些崩溃与一个dSYM相关，而其余崩溃与另一个dSYM相关？我们目前可以访问的崩溃是否有任何分类？

我们可以做一些事情来获得对所有生产崩溃报告的访问权，而无需在App Store中发布新的应用程序版本吗？我们正在尝试避免这种情况的ATM。

编辑＃1 :

因此，发布此版本的人员并不完全遵循最佳实践。我想探讨将dSYM文件提交到服务器存储库的可能性。

这是他们的gitignore:

.DS_Store 
xcuserdata 
<PROJECT NAME>.xcodeproj/project.xcworkspace/xcshareddata/ 
build/ 
Build/

我想构建文件夹几乎排除了这种可能性。我还搜索了文件结构，查找包含文本“com_apple_xcode_dsym_uuids ==”的文件，但未成功...

编辑＃2:

我附上Fabric支持给我的答案的摘录:

If your application is using frameworks, the product folder will have a separate dSYM file generated for each framework built. Eventually all of them are needed if we want to cover our bases and be able to symbolicate a crash in every possible location in our app. A dSYM file generated while building a specific version of the application can only be used to symbolicate crashes from that specific version only.

dSYM files are identified by a Unique ID (UUID), which changes every time we modify and rebuild our code, and that ID is what is used to match a symbol file to a specific crash. A dSYM may be associated with more than one UUID, as it may contain debug information for more than one architecture.

Answer 1

在我看来，您可能需要上传一个新的版本，如果它包含任何错误修复，那毕竟还不错。关于您的问题:

Why were the other two dSYM files not in the zip I downloaded form the App Store?

仅当使用Bitcode分发应用程序时，才可以从App Store连接下载dSYM。位码是源的中间表示，App Store用来生成针对特定体系结构/设备的最终优化机器码。当选择了位码时，所有链接的框架/库也应该使用位码来交付，因此只有一些dSYM看起来很奇怪。尽管可能性不大，但丢失的dSYM是否可能来自另一个版本？

Why are some crashes associated with one dSYM and the rest to another? Is there any sort of categorization of the crashes that we currently have access to?

每个目标/框架/库都生成自己的dSYM，因此您的应用程序可能依赖于一个或多个框架，并且某些崩溃源自该框架。

Can we do something to gain access to all the production crash reports without publishing a new app version to the App Store?

到目前为止，我想不出另一种解决方案。