Crashlytics 为混淆应用手动上传 dSYM答案

【问题标题】：Crashlytics upload dSYM manually for obfuscated applicationCrashlytics 为混淆应用手动上传 dSYM
【发布时间】：2019-02-10 18:05:33
【问题描述】：

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

【问题讨论】：

标签： ios firebase obfuscation crashlytics ixguard

【解决方案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 不会将其识别为有效，如果我修改它并保持其原始结构，它就可以工作。

问题解决了。

我希望这可以帮助将来的人。

【讨论】：

【解决方案2】：

来自 Fabric 和 Firebase 的 Mike 在这里。我们不支持 iXGuard。在 dSYM 丢失后上传它们不会导致任何问题。我的预感是 iXGuard 正在做一些我们没有预料到的事情，因为我们没有对此提供支持。

【讨论】：

感谢您分享您找到的解决方案和信息！