Question

我已经将crashlytics集成到了使用ixguard作为混淆工具的应用程序中。在非混淆版本上使用模拟器进行建议的测试会很好。
要正确解除混淆的应用程序崩溃日志的符号显示，需要一个不同的dSYM文件。这个新的dSYM由混淆工具提供，我使用Firebase门户上传它。
在firebase控制台中，我可以看到由于使应用程序崩溃而生成的一些崩溃日志，但是它们仍然需要正确的dSYM（必需）。似乎没有考虑新的dSYM。
通过运行dwarfdump -u Obfuscated.BS.dSYM，我可以清楚地看到列表中存在必需的UUID，因此它们应该匹配。
我担心的是，在构建时，Fabric运行的脚本应该会在Fabric门户上自动上传dSYM，我想知道这种双重上传是否会破坏某些内容。

Answer 1

我想我已经找到了问题，这可能是由于iXguard生成的dSYM，因为它的结构与Xcode生成的结构不同。在归档文件的dSYM文件夹中，您会找到类似的内容：

dSYM
    |
    |->ThirdPartyLib1.dSYM
    |->ThirdPartyLib2.dSYM
    |->MyApp.dSYM
    |->ThirdPartyLib3.dSYM

MyApp.dSYM的结构如下

MyApp.dSYM
        |
        |->Contents
                |
                |->Info.plist
                |->Resources
                        |
                        |->DWARF
                                |
                                |->MyApp

来自iXguard的那个有点混杂：

MyApp.dSYM
        |
        |->Contents
                |
                |->Info.plist
                |->Resources
                        |
                        |->DWARF
                                |
                                |->MyApp
                                |->ThirdPartyLib1
                                |->ThirdPartyLib2
                                |->ThirdPartyLib3

如果我上载iXguard文件，则Crashlytics无法将其识别为有效文件，如果我对其进行修改以保持其原始结构有效。

问题解决了。

我希望这将来能对某人有所帮助。

Answer 2

来自Fabric和Firebase的Mike。我们不支持iXGuard。 dSYM丢失后再上传不会造成任何问题。我的直觉是iXGuard正在做一些我们没想到的事情，因为我们对此没有支持。

Crashlytics手动上传dSYM，用于混淆的应用程序

2 个答案: