Crashlytics 问题排查和常见问题解答


本页面提供了问题排查帮助，并解答了有关使用 Crashlytics 的常见问题。如果您找不到想要的内容或需要其他帮助，请与 Firebase 支持团队联系。

常规问题排查/常见问题解答

您可能会注意到，Firebase 控制台的“问题”表格中列出的问题有两种不同的格式。您还有可能注意到，某些问题中具有一个称为“变体”的功能。原因如下：

2023 年初，我们发布了经过改进的事件分组分析引擎，还更新了设计，并推出了一些针对新问题的高级功能（例如变体）。如需了解详情，请参阅我们近期发布的博文；如需了解亮点，您可以阅读下文。

Crashlytics 会分析应用的所有事件（如崩溃、非严重错误和 ANR），并创建一种称为问题的事件组，以此将具有共同故障点的所有事件纳入一个问题。

为了将事件划分到这些问题中，经过改进的分析引擎现在会考虑事件的许多方面，包括堆栈轨迹中的帧、异常消息、错误代码以及其他平台或错误类型特征。

但在这种事件组中，导致各事件失败的堆栈轨迹可能有所不同。不同的堆栈轨迹可能代表着不同的根本原因。 为了体现一个问题内部可能存在的此类差异，我们现在会在问题内创建变体，变体是一个问题中的事件子组，该子组内的事件具有共同的故障点以及相似的堆栈轨迹。借助变体，您可以调试一个问题内最普遍的堆栈轨迹，并确定是否有不同的根本原因会导致这一故障。

改进后的体验如下：

  • 改进了问题行中显示的元数据
    现在，您可以更轻松地了解应用中的问题并进行分类。

  • 减少重复问题
    更改行号不会导致新问题。

  • 更轻松地调试存在多种不同根本原因的复杂问题
    使用变体调试一个问题中最普遍的堆栈轨迹。

  • 更有意义的提醒和信号
    新问题表示真的出现了新的 bug。

  • 更强大的搜索功能
    每个问题都包含更易于搜索的元数据，例如异常类型和软件包名称。

具体改进措施如下：

  • 从您的应用获取新事件时，我们会检查这些事件是否与现有问题匹配。

  • 如果没有匹配项，我们会自动为事件应用更智能的事件分组算法，并使用改进后的元数据设计创建新的问题。

这是我们对事件分组进行的第一次重大更新。如果您有任何反馈或遇到任何问题，请通过提交报告告诉我们。

如果您没有看到路径日志，我们建议您检查应用的 Google Analytics 配置。请确保您符合以下要求：

如果您没有看到疾速崩溃提醒，请确保您使用的是 Crashlytics SDK v10.8.0+。

如果您没有看到“未遇到崩溃问题”指标（例如“未遇到崩溃问题”的用户数和“未遇到崩溃问题”的会话数）或看到不可靠的指标，请检查以下各项：

  • 请确保您使用的是 Crashlytics SDK v10.8.0+。

  • 请确保您的数据收集设置不会影响“未遇到崩溃问题”指标的质量：

    • 如果您通过停用自动崩溃报告来启用自选式报告，则崩溃信息只能从明确选择启用数据收集功能的用户那里发送到 Crashlytics。因此，“未遇到崩溃问题”指标的准确性会受到影响，因为 Crashlytics 仅包含这些已选择启用该功能的用户（而非所有用户）的崩溃信息。这意味着，您的“未遇到崩溃问题”指标可能不太可靠，也不能反映您的应用的整体稳定性。

    • 如果您已停用自动数据收集功能，则可以使用 sendUnsentReports 将设备端缓存的报告发送到 Crashlytics。使用此方法会将崩溃数据发送到 Crashlytics，但不会发送会话数据，这会导致控制台图表显示“未遇到崩溃问题”指标的低值或零值。

请参阅了解“未遇到崩溃问题”指标。

如需上传项目的 dSYM 并获取详细输出结果，请检查以下各项：

  1. 确保项目的 build 阶段包含 Crashlytics 运行脚本，该脚本允许 Xcode 在构建时上传项目的 dSYM（如需了解添加该脚本的说明，请参阅初始化 Crashlytics）。更新项目后，强制造成一次崩溃并确认 Crashlytics 信息中心内显示此次崩溃。

  2. 如果您在 Firebase 控制台中看到“dSYM 缺失”提醒，请检查 Xcode，确保它针对构建正确生成了 dSYM。

  3. 如果 Xcode 正确生成了 dSYM，但您仍看到 dSYM 缺失，这很可能是因为运行脚本工具在上传 dSYM 时卡住了。在这种情况下，请尝试以下各项操作：

    • 请确保您使用的是最新版 Crashlytics。

    • 手动上传缺失的 dSYM 文件：

      • 方法 1：在“dSYM”dSYMs标签页中使用基于控制台的“拖放”方法上传包含缺失的 dSYM 文件的 zip 归档文件。
      • 方法 2：对于“dSYM”dSYMs标签页中提供的 UUID，使用 upload-symbols 脚本上传缺失的 dSYM 文件。

  4. 如果您仍然看到 dSYM 缺失或者上传仍然失败，请与 Firebase 支持团队联系，并务必附上您的日志。

如果您的堆栈轨迹的符号化解析似乎不正确，请检查以下各项：

  • 如果来自应用库的帧缺少对应用代码的引用，请确保未设置 -fomit-frame-pointer 编译标志。

  • 如果您看到多个针对应用库的 (Missing) 框架，请检查 Firebase 控制台的“Crashlytics dSYMs”dSYMs标签页中是否有可选的 dSYM 被列为缺失（针对受影响的应用版本）。如果是这样，请按照本页面上 dSYM 缺失/未上传常见问题解答中的“dSYM 缺失提醒”问题排查步骤进行操作。请注意，上传这些 dSYM 并不会对已发生的崩溃进行符号化解析，但这有助于确保对今后的崩溃进行符号化解析。

借助备注功能，项目成员可以就相关疑问或状态更新等特定问题进行备注。

项目成员发布备注时，系统会标注其 Google 账号的电子邮件地址。此电子邮件地址将与备注一起向有权访问备注的所有项目成员显示。

下文介绍了查看、撰写和删除备注所需的权限：

集成

如果您的项目同时使用 Crashlytics 和 Google Mobile Ads SDK，这可能是由于在注册异常处理程序时，崩溃报告工具进行了干扰。如需解决此问题，请调用 disableSDKCrashReporting，在 Mobile Ads SDK 中关闭崩溃报告。

无论您的 Firebase 项目位于何处，将 Crashlytics 关联到 BigQuery 后，您创建的新数据集都会自动采用美国位置。

平台支持

可以，您可以在 macOS 和 tvOS 项目中实现 Crashlytics。确保包含 Firebase SDK for Google Analytics 的 v8.9.0 或更高版本，以便崩溃时可以访问 Google Analytics 收集的指标（未遇到崩溃问题的用户、最新版本、疾速崩溃提醒和路径日志）。

现在，您可以报告单个 Firebase 项目中的多个应用的崩溃情况，即使这些应用是针对不同的 Apple 平台（例如 iOS、tvOS 和 Mac Catalyst）而构建的也无妨。以前，如果应用包含相同的软件包 ID，您需要将这些应用拆分为单独的 Firebase 项目。

回归问题

如果您之前修复并关闭了某个问题，但 Crashlytics 收到了一个该问题再次发生的新报告，则表明该问题已回归。Crashlytics 会自动重新打开这些回归问题，以便您可以根据自己的应用需求采取相应措施。

以下示例场景说明了 Crashlytics 如何将问题归类为回归问题：

  1. Crashlytics 首次收到有关崩溃“A”的崩溃报告。Crashlytics 会为该崩溃打开相应的问题（问题“A”）。
  2. 您快速修复此 bug，关闭问题“A”，然后发布应用的新版本。
  3. 在您关闭问题后，Crashlytics 收到关于问题“A”的另一份报告。
    • 如果报告来自 Crashlytics 在您关闭问题时知道的应用版本（这意味着该版本已针对任何崩溃发送了崩溃报告），则 Crashlytics 不会将问题视为回归。此问题将保持关闭状态。
    • 如果报告来自 Crashlytics 在您关闭问题时不知道的应用版本（这意味着该版本从未针对任何崩溃发送过崩溃报告），则 Crashlytics 会将该问题视为回归问题，并将其重新打开。

当某个问题回归时，我们会发送回归检测提醒，并向该问题添加回归信号，让您知道 Crashlytics 已经重新打开了问题。如果您不希望由于回归算法而要重新打开问题，请“忽略”问题，而不是将其关闭。

如果报告来自在您关闭问题时从未发送过任何崩溃报告的旧应用版本，则 Crashlytics 会认为问题已回归，并会重新打开问题。

在以下情况下，可能会出现这种情形：您已修复了一个 bug，并发布了应用的新版本，但仍有一些用户使用的是旧版本，而且未进行 bug 修复。如果偶然情况下，当您关闭问题时，其中一个旧版本根本没有发送过任何崩溃报告，并且这些用户开始遇到 bug，那么这些崩溃报告将触发回归问题。

如果您不希望由于回归算法而要重新打开问题，请“忽略”问题，而不是将其关闭。