所以这让我疯了但我终于发现,当我导出我的应用程序进行adhoc部署时,bitcode编译选项导致我的调试符号文件(dSYM)和我的应用程序UUID不匹配意味着我无法表示任何崩溃日志.
关闭选项修复了这个问题,但有没有办法可以通过选项修复它？我阅读了该选项的提示,它说商店使用这种方法.我现在也无法从应用程序商店读取崩溃日志,或者这只是一个本地问题？
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构建重新生成符号的问题吗？为什么哦,为什么这个默认为ON而不是警告你的崩溃日志？
解决方法
启用bitcode后,XCode归档过程会产生：
1.本机arm64或armv7代码
比特德
3. dSYM文件(匹配本机代码的UUID)
1.本机arm64或armv7代码
比特德
3. dSYM文件(匹配本机代码的UUID)
当您生成ad-hoc分发并启用“bitcode compile”选项时,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>
