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

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

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

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

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

因此，我对 Crashlytics 或任何第三方崩溃处理程序服务的良好运行如何需要这两个设置感到有点困惑。

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

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

以下是我的指导方针：

• 向 Apple 提交应用程序时，务必选中“包含符号”框
• 总是剥离你的最后可执行文件（.app、.framework）
• 永远不要删除你的静态库，如果你有的话
• 您希望 Apple 的崩溃报告发挥作用，即使您不打算查看它

通过此配置，本地或由 Apple 生成的 dSYM 将包含 Crashlytics 和 Apple 报告器工作所需的调试信息。这是critical使用位码时，您与 Apple 共享符号。如果不这样做，您可能永远无法看到该版本应用程序的符号崩溃。

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

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

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