代码之家  ›  专栏  ›  技术社区  ›  Dean Panayotov

在黑盒情况下处理丢失的DSYM文件

  •  1
  • Dean Panayotov  · 技术社区  · 6 年前

    我们正在尝试解决使用Fabric/Crashlytics的iOS应用程序中的严重崩溃问题。我们没有上次使用该应用程序并将最新版本上载到应用程序商店的人员的详细联系信息。

    在项目仪表板中,我注意到消息“在过去24小时内,发现1个版本的DSYMS丢失导致XXX个未经符号化的崩溃”。截图: https://i.imgur.com/YT9gggJ.jpg

    我做了我能想到的唯一明智的事情:我去了AppStoreConnectDashboard。我根据Fabric的官方说明下载了有关构建的dsym-zip: https://docs.fabric.io/apple/_images/download-dsym.png

    然后我转到dsym工具并直接上传zip。事实证明,所需的四个文件中只有两个在zip中(我自己也检查过它): https://i.imgur.com/JqxZcaD.jpg

    所以…我在黑匣子里…

    • 我不是iOS开发者
    • 我无法访问用于构建项目的计算机或生成该构建的人员
    • 我正在帮助刚加入团队的iOS开发人员
    • 我可以访问项目存储库
    • 我可以访问应用商店连接配置文件
    • 我有织物的管理员权限

    我的问题是:

    1. 为什么我从应用商店下载的另外两个dsym文件不在zip中?
    2. 为什么有些崩溃与一个DSYM相关,而其余的则与另一个DSYM相关?我们目前可以访问的崩溃是否有任何分类?
    3. 在不向应用商店发布新的应用程序版本的情况下,我们能做些什么来访问所有的生产崩溃报告吗?我们试图避免这种情况ATM。

    编辑第1页 :

    所以这个发布了构建的人并没有完全遵循最佳实践。我想探讨一下将DSYM文件提交给服务器repo的可能性。

    这是他们的GitIgnore:

    .DS_Store 
    xcuserdata 
    <PROJECT NAME>.xcodeproj/project.xcworkspace/xcshareddata/ 
    build/ 
    Build/
    

    我想构建文件夹几乎排除了这种可能性。我还搜索了文件结构中包含文本“com-apple-xcode-dsym-uuids==”,但没有成功…

    编辑第2页:

    我附加了一个织物支持给我的答案:

    如果您的应用程序正在使用框架,则产品文件夹将 为每个构建的框架生成单独的DSYM文件。最终 如果我们想覆盖我们的基地并且能够 在我们的应用程序中的每一个可能的位置都象征着崩溃。一个DSYM文件 在生成应用程序的特定版本时生成 仅用于表示来自该特定版本的崩溃。

    DSYM文件由唯一ID(UUID)标识,它更改 我们修改和重建代码的时间,这个ID是用来 将符号文件与特定崩溃匹配。DSYM可能与 多个UUID,因为它可能包含多个的调试信息 一个架构。

    1 回复  |  直到 6 年前
        1
  •  2
  •   Ivan S Ivanov    6 年前

    在我看来,你可能需要上传一个新的版本,如果它包含了任何错误修复,那也不算太糟糕。关于你的问题:

    为什么我从应用商店下载的另外两个dsym文件不在zip中?

    只有当应用程序使用比特码分发时,才能从应用程序商店连接下载DSYMS。比特码是应用商店用来生成针对特定体系结构/设备的最终优化机器代码的源代码的中间表示。选择bitcode时,所有链接的框架/lib也应该使用bitcode交付,所以只有一些dsyms看起来很奇怪。虽然不太可能,但丢失的DSYM是否可能来自另一个构建?

    为什么有些崩溃与一个DSYM相关,而其余的则与另一个DSYM相关?我们目前可以访问的崩溃是否有任何分类?

    每个目标/framework/lib都会生成自己的dsyms,因此您的应用程序可能依赖于一个或多个框架,并且某些崩溃源自该框架。

    在不向应用商店发布新的应用程序版本的情况下,我们能做些什么来访问所有的生产崩溃报告吗?

    到目前为止,我想不出另一个解决办法。