此頁面提供故障排除協助以及有關使用 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）並建立稱為問題的事件群組 - 問題中的所有事件都有一個共同的故障點。
為了將事件分組到這些問題中，改進的分析引擎現在會查看事件的許多方面，包括堆疊追蹤中的幀、異常訊息、錯誤代碼以及其他平台或錯誤類型特徵。
但是，在這組事件中，導致失敗的堆疊追蹤可能有所不同。不同的堆疊追蹤可能意味著不同的根本原因。為了表示問題中可能存在的差異，我們現在在問題中創建變體- 每個變體是問題中具有相同故障點和類似堆疊追蹤的事件的子組。透過變體，您可以調試問題中最常見的堆疊跟踪，並確定是否有不同的根本原因導致失敗。
以下是您將體驗到的這些改進：
修改了問題行中顯示的元數據
現在可以更輕鬆地理解和分類應用程式中的問題。減少重複問題
行號更改不會導致新問題。更輕鬆地調試具有各種根本原因的複雜問題
使用變體來調試問題中最常見的堆疊追蹤。更有意義的警報和信號
一個新的問題實際上代表一個新的bug。更強大的搜尋
每個問題都包含更多可搜尋的元數據，例如異常類型和套件名稱。
以下是這些改進的實施方式：
當我們從您的應用程式收到新事件時，我們將檢查它們是否與現有問題相符。
如果沒有匹配，我們將自動將更聰明的事件分組演算法應用於該事件，並使用改進的元資料設計建立新問題。
這是我們對活動分組進行的第一次重大更新。如果您有回饋或遇到任何問題，請透過提交報告告知我們。
無崩潰值表示在特定時間內使用您的應用程式但未發生崩潰的使用者百分比。
以下是計算無崩潰使用者百分比的公式。其輸入值由 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 會認為問題已退化，並將重新開啟問題。
在以下情況下可能會發生這種情況：您已修復了錯誤並發布了應用程式的新版本，但仍有用戶使用未修復錯誤的舊版本。如果碰巧，當您關閉問題時，這些舊版本之一從未發送任何崩潰報告，並且這些用戶開始遇到該錯誤，那麼這些崩潰報告將觸發回歸問題。
如果您不希望由於我們的回歸演算法而重新開啟某個問題，請「靜音」該問題而不是關閉它。
,此頁面提供故障排除協助以及有關使用 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）並建立稱為問題的事件群組 - 問題中的所有事件都有一個共同的故障點。
為了將事件分組到這些問題中，改進的分析引擎現在會查看事件的許多方面，包括堆疊追蹤中的幀、異常訊息、錯誤代碼以及其他平台或錯誤類型特徵。
但是，在這組事件中，導致失敗的堆疊追蹤可能有所不同。不同的堆疊追蹤可能意味著不同的根本原因。為了表示問題中可能存在的差異，我們現在在問題中創建變體- 每個變體是問題中具有相同故障點和類似堆疊追蹤的事件的子組。透過變體，您可以調試問題中最常見的堆疊跟踪，並確定是否有不同的根本原因導致失敗。
以下是您將體驗到的這些改進：
修改了問題行中顯示的元數據
現在可以更輕鬆地理解和分類應用程式中的問題。減少重複問題
行號更改不會導致新問題。更輕鬆地調試具有各種根本原因的複雜問題
使用變體來調試問題中最常見的堆疊追蹤。更有意義的警報和信號
一個新的問題實際上代表一個新的bug。更強大的搜尋
每個問題都包含更多可搜尋的元數據，例如異常類型和套件名稱。
以下是這些改進的實施方式：
當我們從您的應用程式收到新事件時，我們將檢查它們是否與現有問題相符。
如果沒有匹配，我們將自動將更聰明的事件分組演算法應用於該事件，並使用改進的元資料設計建立新問題。
這是我們對活動分組進行的第一次重大更新。如果您有回饋或遇到任何問題，請透過提交報告告知我們。
無碰撞值表示與您的應用程式互動但在特定時間段內沒有崩潰的用戶的百分比。
這是計算無碰撞用戶百分比的公式。其輸入值由Google Analytics（分析）提供。
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
發生崩潰時，Google Analytics（Google Analytics）會傳送
app_exception事件類型，而CRASHED_USERS表示與該事件類型關聯的使用者數量。ALL_USERS表示您從crashlytics儀表板右上方選單中選擇的時間段與您的應用程式互動的使用者總數。
隨著時間的推移，無碰撞的使用者百分比是聚集的，而不是平均值。
例如，想像您的應用程式有三個使用者；我們將其稱為用戶A，用戶B和用戶C。下表顯示了每天與您的應用程式互動的用戶，這些用戶當天遇到了崩潰：
| 週一 | 週二 | 週三 | |
|---|---|---|---|
| 參與您應用程式的用戶 | 甲、乙、丙 | 甲、乙、丙 | 甲、乙 |
| 崩潰的用戶 | C | 乙 | A |
在星期三，您的無碰撞用戶百分比為50％（2個用戶中有1個沒有崩潰）。
您的兩個用戶在周三使用您的應用程序，但其中只有一個（用戶B）沒有崩潰。在過去的2天中，您的無碰撞用戶百分比為33.3％（3個用戶中有1個沒有崩潰）。
在過去的兩天中，您的三個用戶與您的應用程式接觸，但是其中只有一個（用戶C）沒有崩潰。在過去的3天中，您的無碰撞用戶百分比為0％（3個用戶中有0個用戶沒有崩潰）。
在過去的三天中，您的三個用戶使用您的應用程序，但其中零沒有崩潰。
在不同的時間段內不應比較無崩潰的用戶價值。單一用戶經歷崩潰的機率在使用您的應用程式的次數越多，因此無碰撞的用戶價值可能會在更長的時間段內較小。
註釋允許專案成員就問題，狀態更新等評論特定問題。
當專案成員發布註釋時，它標有Google帳戶的電子郵件。該電子郵件地址與註釋一起可見給所有項目成員，並可以存取該註釋。
以下描述了查看，寫和刪除註釋所需的訪問：
具有以下任何角色的項目成員可以查看和刪除現有的註釋，並就問題寫下新的註釋。
具有以下任何角色的專案成員可以查看發布的註釋，但他們無法刪除或寫筆記。
整合
如果您的專案與Google Mobile Ads SDK一起使用Crashlytics，則在註冊異常處理程序時，碰撞記者可能會幹擾。要解決該問題，請透過呼叫disableSDKCrashReporting在行動廣告SDK中關閉崩潰報告。
將Crashlytics連結到BigQuery之後，無論您的Firebase專案的位置如何，您建立的新資料集將自動位於美國。
平台支援
回歸問題
當您以前關閉問題時，問題已經回歸，但是Crashlytics獲得了新的報告，該報告已經重新出現了。 Crashlytics會自動重新開啟這些回歸的問題，以便您可以根據應用程式來解決它們。
這是一個範例場景，解釋了crashlytics如何將問題分類為迴歸：
- Crashlytics首次獲得了有關崩潰「 A」的崩潰報告。 Crashlytics為此崩潰打開了相應的問題（問題“ A”）。
- 您可以快速修復此錯誤，關閉問題“ A”，然後發布新版本的應用程式。
- 關閉問題後，Crashlytics將獲得另一項有關問題「 A」的報告。
- 如果該報告來自Crashlytics知道何時關閉問題的應用程式版本（這意味著該版本已經為任何崩潰發送了崩潰報告），那麼Crashlytics不會將問題視為回歸的問題。該問題將保持關閉。
- 如果該報告來自App版本，該版本crashlytics不知道您何時關閉問題（這意味著該版本從未為任何崩潰發送任何崩潰報告），則Crashlytics認為該問題會退縮並將重新打開問題。 。
當問題回歸時，我們會發送回歸檢測警報並在問題中添加回歸訊號，以便您知道Crashlytics已重新開放該問題。如果您不希望由於我們的回歸演算法而重新開啟問題，請“靜音”，而不是關閉問題。
如果報告來自舊應用程序，該版本在您關閉問題時根本從未發送任何崩潰報告，則CrashLytics認為該問題會退出並重新開啟問題。
這種情況可能會在以下情況下發生：您已修復了一個錯誤並發布了應用程式的新版本，但是您仍然在舊版本上沒有錯誤修復。如果偶然地，當您關閉問題時，這些較舊版本中的一個從未發送任何崩潰報告，並且這些用戶開始遇到錯誤，那麼這些崩潰報告將觸發回歸的問題。
如果您不希望由於我們的回歸演算法而重新開啟問題，請“靜音”，而不是關閉問題。
，此頁面提供了故障排除的幫助和答案，以解決有關使用CrashLytics的經常提出的問題。如果您找不到想要的東西或需要其他協助，請聯絡Firebase支援。
一般故障排除/常見問題
如果您沒有看到無崩潰的用戶，麵包屑日誌和/或速度警報，我們建議您檢查您的應用程式的配置Google Analytics（分析）。
確保您在Firebase專案中啟用了Google Analytics（分析） 。
確保在Firebase控制台的「整合> Google Analytics （分析）」頁面中啟用了Google Analytics（分析）資料共享。請注意，資料共享設定顯示在Firebase控制台中，但在Google Analytics（分析）中進行了管理。
除了Firebase Crashlytics SDK外，還要確保已將Firebase SDK新增至Google Analytics（ iOS+ | Android ）。
確保您正在為所有Firebase SDK（ ios+ | android ）使用最新版本。
特別是檢查您至少使用以下版本的Firebase SDK進行Google Analytics（分析）：iOS+ - v6.3.1+（MacOS和TVOS的V8.9.0+）| Android - V17.2.3+ （BOM V24.7.1+） 。
您可能會注意到firebase控制台中問題表中列出的問題的兩種不同格式。您可能還會注意到您在某些問題中的功能稱為“變體”。這就是原因！
在2023年初，我們推出了改進的分析引擎，用於分組活動以及更新的設計以及一些新問題的高級功能（例如變體！）。請查看我們最近的部落格文章以獲取所有詳細信息，但是您可以在下面閱讀有關亮點的信息。
Crashlytics分析了您的應用程式中的所有事件（例如崩潰，非投籃和ANRS），並創建了稱為問題的事件組 - 問題中的所有事件都有一個共同的故障點。
要將事件分組到這些問題中，改進的分析引擎現在著眼於事件的許多方面，包括堆疊追蹤中的幀，異常訊息，錯誤代碼以及其他平台或錯誤類型特徵。
但是，在這組事件中，導致故障的堆疊追蹤可能有所不同。不同的堆疊追蹤可能意味著不同的根本原因。為了表示問題中的這種可能差異，我們現在在問題中創建變體- 每個變體都是具有相同故障點和相似堆疊追蹤的問題中的事件子組。使用變體，您可以在問題中調試最常見的堆疊痕跡，並確定不同的根本原因是否導致故障。
這是您將在這些改進方面體驗的內容：
在問題行中顯示的修改後的元數據
現在，在您的應用程式中更容易理解和分類問題。更少的重複問題
行號更改不會導致新問題。透過各種根本原因更容易調試複雜問題
使用變體來調試問題中最常見的堆疊痕跡。更有意義的警報和信號
一個新問題實際上代表了一個新錯誤。更強大的搜尋
每個問題都包含更多可搜尋的元數據，例如異常類型和軟體包名稱。
這些改進是如何推出的：
當我們從您的應用程式獲得新事件時，我們將檢查它們是否與現有問題相符。
如果沒有匹配，我們將自動將我們的更聰明的事件組演算法應用於事件，並透過改進的元資料設計建立新問題。
這是我們對活動分組進行的第一個重大更新。如果您有回饋或遇到任何問題，請透過提交報告，讓我們知道。
The crash-free value represents the percentage of users who engaged with your app but did not have a crash over a specific time period.
Here is the formula for calculating the crash-free users percentage. Its input values are provided by Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
When a crash happens, Google Analytics sends an
app_exceptionevent type, and CRASHED_USERS represents the number of users associated with that event type.ALL_USERS represents the total number of users who engaged with your app over the time period that you've selected from the drop-down menu in the upper-right of the Crashlytics dashboard.
The crash-free users percentage is an aggregation over time , not an average.
For example, imagine your app has three users; we'll call them User A, User B, and User C. The following table shows which users engaged with your app each day and which of those users had a crash that day:
| 週一 | 週二 | 週三 | |
|---|---|---|---|
| Users who engaged with your app | 甲、乙、丙 | 甲、乙、丙 | 甲、乙 |
| User that had a crash | C | 乙 | A |
On Wednesday, your crash-free users percentage is 50% (1 out of 2 users was crash-free).
Two of your users engaged with your app on Wednesday, but only one of them (User B) had no crashes.For the past 2 days, your crash-free users percentage is 33.3% (1 out of 3 users was crash-free).
Three of your users engaged with your app over the past two days, but only one of them (User C) had no crashes.For the past 3 days, your crash-free users percentage is 0% (0 out of 3 users were crash-free).
Three of your users engaged with your app over the past three days, but zero of them had no crashes.
The crash-free users value shouldn't be compared over different time periods. The probability of a single user experiencing a crash grows the more times they use your app, so the crash-free users value is likely to be smaller for longer time periods.
Notes allow project members to comment on specific issues with questions, status updates, etc.
When a project member posts a note, it's labeled with the email of their Google account. This email address is visible, along with the note, to all project members with access to view the note.
The following describes the access required to view, write, and delete notes:
Project members with any of the following roles can view and delete existing notes and write new notes on an issue.
- Project Owner or Editor , Firebase Admin , Quality Admin , or Crashlytics Admin
Project members with any of the following roles can view the notes posted on an issue, but they cannot delete or write a note.
- Project Viewer , Firebase Viewer , Quality Viewer , or Crashlytics Viewer
整合
If your project uses Crashlytics alongside the Google Mobile Ads SDK, it's likely that the crash reporters are interfering when registering exception handlers. To fix the issue, turn off crash reporting in the Mobile Ads SDK by calling disableSDKCrashReporting .
After you link Crashlytics to BigQuery, new datasets you create are automatically located in the United States, regardless of the location of your Firebase project.
平台支援
回歸問題
An issue has had a regression when you've previously closed the issue but Crashlytics gets a new report that the issue has re-occurred. Crashlytics automatically re-opens these regressed issues so that you can address them as appropriate for your app.
Here's an example scenario that explains how Crashlytics categorizes an issue as a regression:
- For the first time ever, Crashlytics gets a crash report about Crash "A". Crashlytics opens a corresponding issue for that crash (Issue "A").
- You fix this bug quickly, close Issue "A", and then release a new version of your app.
- Crashlytics gets another report about Issue "A" after you've closed the issue.
- If the report is from an app version that Crashlytics knew about when you closed the issue (meaning that the version had sent a crash report for any crash at all), then Crashlytics won't consider the issue as regressed. The issue will remain closed.
- If the report is from an app version that Crashlytics did not know about when you closed the issue (meaning that the version had never sent any crash report for any crash at all), then Crashlytics considers the issue reregress rue 。
When an issue regresses, we send a regression detection alert and add a regression signal to the issue to let you know that Crashlytics has re-opened the issue. If you do not want an issue to re-open due to our regression algorithm, "mute" the issue instead of closing it.
If a report is from an old app version that had never sent any crash reports at all when you closed the issue, then Crashlytics considers the issue regressed and will re-open the issue.
This situation can happen in the following situation: You've fixed a bug and released a new version of your app, but you still have users on older versions without the bug fix. If, by chance, one of those older versions had never sent any crash reports at all when you closed the issue, and those users start encountering the bug, then those crash reports would trigger a regressed issue.
If you do not want an issue to re-open due to our regression algorithm, "mute" the issue instead of closing it.