所以这让我抓狂，但我最终发现当我导出我的应用程序进行临时部署时，位码编译选项导致我的调试符号文件 (dSYM) 和我的应用程序 UUID 不匹配，这意味着我无法符号化任何崩溃日志.
关闭该选项可以解决这个问题，但有没有办法在打开该选项的情况下修复它？我阅读了该选项的提示，它说商店使用这种方法。我现在是否也无法从应用商店读取崩溃日志，或者这只是一个本地问题？
这是我从这个 Xcode 版本之前的旧版本中得到的:
dwarfdump --uuid app
DD25E6C9-... (armv7)
29F74B2E-... (arm64)
dwarfdump --uuid app.dsym
DD25E6C9... (armv7)
29F74B2E... (arm64)
很好。现在打开 bitcode:
dwarfdump --uuid app
E7D2BE71-... (armv7)
5C871FD7-... (arm64)
dwarfdump --uuid app.dsym
BC93BCF5-... (armv7)
3312658C... (arm64)
显然它不会符号化。我已经尝试关闭选项并再次匹配。这是 Xcode 没有为新的 bitcode 构建重新生成符号的问题吗？为什么哦，为什么这默认为打开并且不警告您有关崩溃日志的信息？？
最佳答案
启用位码后，XCode 归档过程会产生: 1.原生arm64或armv7代码 2. 比特码 3. dSYM文件(匹配 native 代码的UUID)
当您生成一个临时分布并启用“bitcode 编译”选项时，XCode 也会将 Bitcode 重新编译为 Native，这可能而且通常会导致 arm64 和 armv7 部分的 UUID 不同。原始的 app.dSYM 没有被触及(因此与新的二进制文件不匹配)，而是在同一个 xcarchive 文件夹中生成新的 dSYM，它们的形式为“E2015333-1220-391E-928C-04C32A179EC9.dSYM”并匹配新编译的二进制文件的实际 UUID。
故事并不总是就此结束，这些新的 dSYM 文件可能会被混淆(即使用 __hidden#232434 而不是实际的符号名称)。对它们进行去混淆处理的映射也位于名为“BCSymbolMaps”的文件夹中的 xcarchive 文件夹中。
要对这样的 dSYM 进行反混淆，可以使用以下命令:
dsymutil --symbol-map <bcSymbol-file> <obfuscated-dsym-file>
关于ios - 为什么从 bitcode 重新编译使我无法在 Xcode ad hoc 版本中进行符号化，我该如何解决？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34363485/