Xcode Bitcode，包括符号设置对 dSYM 生成的影响

Question

由于我使用 Crashlytics 来处理我的崩溃，我总是取消选中“为您的应用程序包含应用程序符号以接收来自 Apple 的符号化崩溃日志”并保留 “包含位码” em> 在将我的应用程序提交到 iTunes Connect 之前进行检查（Apple Watch 的未来证明），如下所示：

Crashlytics 有一篇关于 Bitcode 和缺少 dSYM 问题的文章：

https://docs.fabric.io/apple/crashlytics/missing-dsyms.html#bitcode-download

根据他们的截图，要下载由Bitcode创建的新生成的dSYM文件，iTunes Connect中有一个直接可用的下载链接，但是，您似乎必须选中“包含应用程序符号”才能下载它们，否则你只会得到这个：

因此，对于 Crashlytics 或任何第 3 方崩溃处理程序服务的正常运行如何需要这两个设置，我有点困惑。

我应该同时检查这两个设置吗？是否可以取消选中“包含应用程序符号”，因为我不使用 Apple 的 Crash 管理器（据我了解，dSYM 文件在其后脚本存档期间上传到 Crashlytics）并且只检查 Bitcode 或者如果我这样做我不会无法下载新的 Bitcode 生成的 dSYM（导致 Crashlytics 正确符号崩溃的问题）？

Answer 1

这是个好问题。有许多旋钮会影响您的应用程序的调试符号信息的可用性。这令人困惑，人们经常被它绊倒。

这是我的指导方针：

• 向 Apple 提交应用程序时，请始终选中“包含符号”框
• 始终剥离您的最终可执行文件（.app、.framework）
• 永远不要剥离静态库，如果有的话
• 您希望 Apple 的崩溃报告能够正常工作，即使您不打算查看它

使用此配置，本地或 Apple 生产的 dSYM 将包含 Crashlytics 和 Apple 的报告器工作所需的调试信息。在使用位码时，与 Apple 共享符号是关键。否则，您很可能永远无法看到该版本应用的象征性崩溃。

当然，您可能不希望与 Apple 共享符号有一些正当理由。一是你想混淆你的代码。我知道有一些应用程序可以做到这一点。当然，这是一种权衡，因为它使符号化变得更加困难，甚至不可能，这取决于混淆系统。

还有一些您可能不想剥离可执行文件的原因。一是您依赖于不支持服务器端符号化的第 3 方崩溃报告系统。据我所知，这种情况越来越少见，但需要注意。

最后，您肯定希望 Apple 的崩溃报告系统能够正常工作，即使您从未打算使用它。 Apple 的系统能够比任何第三方解决方案更可靠地捕获更多崩溃。我相信这对于苹果的内部工作也是无价的。它确实有局限性，但实际上不会花费您任何费用。所以，保持它的工作，如果没有其他原因，只是可以选择在未来查看它。