在黑盒情况下处理丢失的 dSYM 文件
Dealing with missing dSYM files in a black box situation
我们正在尝试解决使用 Fabric / Crashlytics 的 iOS 应用程序中的严重崩溃问题。我们没有上次处理该应用程序并将最新版本上传到 App Store 的人员的联系方式。
在项目仪表板中，我注意到消息 "Found XXX unsymbolicated crashes from missing dSYMs in 1 version in the last 24 hours"。截图：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 下载的压缩包中？
- 为什么有些崩溃与一个 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.
在我看来，您可能需要上传一个新版本，毕竟如果它包含任何错误修复，那也不算太糟糕。关于您的问题：
Why were the other two dSYM files not in the zip I downloaded form the App Store?
仅当应用是使用 Bitcode 分发时，从 App Store 连接下载 dSYM 的选项才可用。 Bitcode 是 App Store 用于生成最终优化的机器码目标特定 architecture/device 源的中间表示。 When Bitcode is selected all linked frameworks/libs should also be delivered using bitcode, so it looks weird to have only some dSYMs.虽然不太可能，但丢失的 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?
每个 target/framework/lib 都会生成自己的 dSYM，因此您的应用可能依赖于一个或多个框架，并且一些崩溃源自这些框架。
Can we do something to gain access to all the production crash reports without publishing a new app version to the App Store?
到目前为止我想不出其他解决方案。
我们正在尝试解决使用 Fabric / Crashlytics 的 iOS 应用程序中的严重崩溃问题。我们没有上次处理该应用程序并将最新版本上传到 App Store 的人员的联系方式。
在项目仪表板中，我注意到消息 "Found XXX unsymbolicated crashes from missing dSYMs in 1 version in the last 24 hours"。截图：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 下载的压缩包中？
- 为什么有些崩溃与一个 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.
在我看来，您可能需要上传一个新版本，毕竟如果它包含任何错误修复，那也不算太糟糕。关于您的问题：
Why were the other two dSYM files not in the zip I downloaded form the App Store?
仅当应用是使用 Bitcode 分发时，从 App Store 连接下载 dSYM 的选项才可用。 Bitcode 是 App Store 用于生成最终优化的机器码目标特定 architecture/device 源的中间表示。 When Bitcode is selected all linked frameworks/libs should also be delivered using bitcode, so it looks weird to have only some dSYMs.虽然不太可能，但丢失的 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?
每个 target/framework/lib 都会生成自己的 dSYM，因此您的应用可能依赖于一个或多个框架，并且一些崩溃源自这些框架。
Can we do something to gain access to all the production crash reports without publishing a new app version to the App Store?
到目前为止我想不出其他解决方案。