此頁面提供故障排除幫助以及有關使用 Crashlytics 的常見問題解答。如果您找不到所需內容或需要其他幫助，請聯繫Firebase 支持。
一般故障排除/常見問題解答
如果您沒有看到無崩潰的用戶、麵包屑日誌和/或速度警報，我們建議您檢查應用的 Google Analytics 配置。
確保您已在 Firebase 項目中啟用 Google Analytics 。
確保在 Firebase 控制台的集成> Google Analytics頁面中為 Google Analytics 啟用數據共享。請注意，數據共享設置顯示在 Firebase 控制台中，但在 Google Analytics 控制台中進行管理。
除了 Firebase Crashlytics SDK 之外，請確保您已將適用於 Google Analytics 的 Firebase SDK 添加到您的應用 ( iOS+ | Android )。
確保您使用的所有 Firebase SDK ( iOS+ | Android ) 均為最新版本。
特別檢查您是否至少使用以下版本的 Firebase SDK for Google Analytics： iOS+ — v6.3.1+（適用於 macOS 和 tvOS 的 v8.9.0+）| Android — v17.2.3+(BoM v24.7.1+) 。
您可能會注意到 Firebase 控制台的問題表中列出的問題有兩種不同的格式。您可能還會注意到某些問題中有一個稱為“變體”的功能。這就是原因！
2023 年初，我們推出了改進的用於對事件進行分組的分析引擎，以及針對新問題（如變體！）的更新設計和一些高級功能。請查看我們最近的博客文章了解所有詳細信息，但您可以閱讀下面的重點內容。
Crashlytics 分析應用程序中的所有事件（例如崩潰、非致命事件和 ANR）並創建稱為問題的事件組 - 問題中的所有事件都有一個共同的故障點。
為了將事件分組到這些問題中，改進的分析引擎現在會查看事件的許多方面，包括堆棧跟踪中的幀、異常消息、錯誤代碼以及其他平台或錯誤類型特徵。
但是，在這組事件中，導致失敗的堆棧跟踪可能有所不同。不同的堆棧跟踪可能意味著不同的根本原因。為了表示問題中可能存在的差異，我們現在在問題中創建變體- 每個變體是問題中具有相同故障點和類似堆棧跟踪的事件的子組。通過變體，您可以調試問題中最常見的堆棧跟踪，並確定是否有不同的根本原因導致失敗。
以下是您將體驗到的這些改進：
修改了問題行中顯示的元數據
現在可以更輕鬆地理解和分類應用程序中的問題。減少重複問題
行號更改不會導致新問題。更輕鬆地調試具有各種根本原因的複雜問題
使用變體來調試問題中最常見的堆棧跟踪。更有意義的警報和信號
一個新的問題實際上代表一個新的錯誤。更強大的搜索
每個問題都包含更多可搜索的元數據，例如異常類型和包名稱。
以下是這些改進的實施方式：
當我們從您的應用收到新事件時，我們將檢查它們是否與現有問題匹配。
如果沒有匹配，我們將自動將更智能的事件分組算法應用於該事件，並使用改進的元數據設計創建一個新問題。
這是我們對活動分組進行的第一次重大更新。如果您有反饋或遇到任何問題，請通過提交報告告知我們。
無崩潰值表示在特定時間段內使用您的應用但未發生崩潰的用戶百分比。
以下是計算無崩潰用戶百分比的公式。其輸入值由 Google Analytics 提供。
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
當發生崩潰時，Google Analytics 會發送
app_exception事件類型， CRASHED_USERS表示與該事件類型關聯的用戶數量。ALL_USERS表示在您從 Crashlytics 儀表板右上角的下拉菜單中選擇的時間段內與您的應用互動的用戶總數。
無崩潰用戶百分比是一段時間內的匯總，而不是平均值。
例如，假設您的應用程序有三個用戶；我們將他們稱為用戶 A、用戶 B 和用戶 C。下表顯示了哪些用戶每天與您的應用互動，以及哪些用戶當天發生了崩潰：
| 週一 | 週二 | 週三 | |
|---|---|---|---|
| 與您的應用互動的用戶 | 甲、乙、丙 | 甲、乙、丙 | 甲、乙 |
| 發生崩潰的用戶 | C | 乙 | A |
週三，您的無崩潰用戶百分比為 50%（二分之一的用戶沒有崩潰）。
您的兩名用戶在周三使用了您的應用程序，但只有其中一名用戶（用戶 B）沒有發生崩潰。在過去 2 天內，您的無崩潰用戶百分比為 33.3%（三分之一的用戶沒有崩潰）。
您的三位用戶在過去兩天內使用了您的應用程序，但只有其中一位（用戶 C）沒有發生崩潰。在過去 3 天內，您的無崩潰用戶百分比為 0%（三分之 0 的用戶沒有崩潰）。
您的三位用戶在過去三天內使用了您的應用，但其中零位沒有發生崩潰。
註釋允許項目成員對具體問題發表評論，包括問題、狀態更新等。
當項目成員發布註釋時，該註釋會標有其 Google 帳戶的電子郵件地址。所有有權查看註釋的項目成員都可以看到此電子郵件地址以及註釋。
以下描述了查看、寫入和刪除筆記所需的訪問權限：
具有以下任何角色的項目成員可以查看和刪除現有註釋以及針對問題編寫新註釋。
具有以下任何角色的項目成員可以查看針對問題發布的註釋，但無法刪除或寫入註釋。
集成
如果您的項目將 Crashlytics 與 Google 移動廣告 SDK 一起使用，則崩潰報告程序可能會在註冊異常處理程序時進行干擾。要解決此問題，請通過調用disableSDKCrashReporting關閉移動廣告SDK 中的崩潰報告。
將 Crashlytics 鏈接到 BigQuery 後，無論您的 Firebase 項目位於何處，您創建的新數據集都會自動位於美國。
平台支持
回歸問題
當您之前關閉問題時，問題已回歸，但 Crashlytics 會收到一份新報告，表明該問題已再次發生。 Crashlytics 會自動重新打開這些回歸問題，以便您可以根據您的應用程序適當地解決這些問題。
下面是一個示例場景，解釋了 Crashlytics 如何將問題分類為回歸：
- Crashlytics 有史以來第一次收到有關崩潰“A”的崩潰報告。 Crashlytics 針對該崩潰打開了相應的問題（問題“A”）。
- 您快速修復此錯誤，關閉問題“A”，然後發布應用程序的新版本。
- 在您關閉問題後，Crashlytics 會收到有關問題“A”的另一份報告。
- 如果報告來自您關閉問題時 Crashlytics知道的應用程序版本（意味著該版本已發送任何崩潰的崩潰報告），則 Crashlytics 不會將問題視為已回歸。該問題將保持關閉狀態。
- 如果報告來自您關閉問題時 Crashlytics不知道的應用程序版本（意味著該版本根本沒有發送過任何崩潰報告），則 Crashlytics 會認為問題已回歸併將重新打開問題。
當問題回歸時，我們會發送回歸檢測警報並向問題添加回歸信號，讓您知道 Crashlytics 已重新打開該問題。如果您不希望由於我們的回歸算法而重新打開某個問題，請“靜音”該問題而不是關閉它。
如果報告來自舊的應用程序版本，當您關閉問題時，該版本從未發送過任何崩潰報告，則 Crashlytics 會認為問題已退化，並將重新打開問題。
在以下情況下可能會發生這種情況：您已修復了錯誤並發布了應用程序的新版本，但仍有用戶使用未修復錯誤的舊版本。如果碰巧，當您關閉問題時，這些舊版本之一從未發送過任何崩潰報告，並且這些用戶開始遇到該錯誤，那麼這些崩潰報告將觸發回歸問題。
如果您不希望由於我們的回歸算法而重新打開某個問題，請“靜音”該問題而不是關閉它。