【问题标题】:Firebase Crashlytics reportsFirebase Crashlytics 报告
【发布时间】:2020-05-20 08:22:32
【问题描述】:

此问题包含针对“新 Firebase Crashlytics 用户”的服务问题

首先,直到不久前,我还使用 Fabric 进行崩溃报告。 将 Fabric 迁移到 Firebase Crashlytics 后,出现了一些问题。

1) 从 FabricFirebase Crashlytics 的“无崩溃用户”差异,而 Fabric 显示 99% 以上的无崩溃用户, FB-Crashlytics 显示大约 60% 的无崩溃用户。为什么结果不一样?

2) FB Crashlytics NOT 报告针对导致应用程序崩溃的特定对象/字段名称。它也没有报告它发生在哪一行。它只是报告方法名称和异常(类似“Fatal Exception: kotlin.KotlinNullPointerException”的smtng)而不提及引用的名称

附言 已经添加到proguard以下规则:

-keep public class * extends java.lang.Exception

-keep class com.google.firebase.crashlytics.** { *; }
-dontwarn com.google.firebase.crashlytics.**```

【问题讨论】:

    标签: android firebase kotlin crashlytics google-fabric


    【解决方案1】:
    1. 无崩溃用户指标会有所不同,因为 Fabric 依赖于 Fabric Answers,而 Firebase 依赖于 Google Analytics SDK。使用 Firebase,需要一个 user_engagement 事件来定义活动。当应用进入前台并触发 session_start 事件时会触发 user_engagement 事件。 Analytics 将多个应用程序前景/背景计为同一会话的一部分,只要它们彼此相隔 30 分钟,而 Fabric Answers 则为 30 秒。因此,Fabric 计算的会话和用户数比 Google Analytics 多,因为它要求应用程序在正式捕获和计算会话/活动用户之前在前台和后台的时间更少。这会导致大容量应用程序出现小的差异,而每天可能只有几个用户和会话的低容量应用程序可能会出现更大的差异。

    2. Firebase 应报告行号和对象/字段。如果您使用 Kotlin,您可以尝试这样的测试崩溃吗? (https://firebase.google.com/docs/crashlytics/test-implementation?platform=android#force_a_crash_to_test_your_implementation)

    【讨论】:

    • 非常感谢您抽出宝贵时间回答第一个问题,关于第二个问题,您的链接帮助我发现 Firebase Crashlytics 一开始就没有正确实施!
    • 很高兴听到它 =)
    猜你喜欢
    • 1970-01-01
    • 2019-04-18
    • 1970-01-01
    • 2021-06-30
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-02-14
    • 2023-04-10
    相关资源
    最近更新 更多