Crashlytics 疑難排解與常見問題

本頁面提供 Crashlytics 的疑難排解說明和常見問題解答。如果找不到所需資訊或需要其他協助，請與 Firebase 支援團隊聯絡。

一般疑難排解/常見問題

在「問題」表格中，部分問題會顯示不同格式 (有時會顯示「變體」)

您可能會發現 Firebase 控制台的「問題」表格中列出的問題有兩種不同格式。此外，您可能會在某些問題中看到「變體」功能。原因如下：

2023 年初，我們推出了改良的分析引擎，可將事件分組，並更新了設計，還為新問題提供一些進階功能 (例如變體！)。詳情請參閱我們最近的網誌文章，以下為重點摘要。

Crashlytics 會分析應用程式中的所有事件 (例如當機、非致命錯誤和 ANR)，並建立稱為「問題」的事件群組。問題中的所有事件都有共同的故障點。

為了將事件歸類為這些問題，改良後的分析引擎現在會查看事件的許多方面，包括堆疊追蹤中的影格、例外狀況訊息、錯誤代碼，以及其他平台或錯誤類型特徵。

不過，在這個事件群組中，導致失敗的堆疊追蹤可能不同。不同的堆疊追蹤可能代表不同的根本原因。為呈現問題中可能存在的差異，我們現在會在問題中建立子類，每個子類都是問題中的事件子群組，這些事件具有相同的故障點和相似的堆疊追蹤。您可以運用子類對問題中最常見的堆疊追蹤進行偵錯，並判斷故障是否出自其他根本原因。

這些改善項目可帶來以下好處：

問題列中顯示的經過改良的中繼資料
現在更容易瞭解及分類應用程式中的問題。
減少重複問題
行號變更不會導致新問題。
更輕鬆地偵錯各種根本原因造成的複雜問題
使用變體偵錯問題中最常見的堆疊追蹤。
更具意義的快訊和信號
新問題實際上代表新錯誤。
更強大的搜尋功能
每個問題都包含更多可搜尋的中繼資料，例如例外狀況類型和套件名稱。

這些改善項目將以以下方式推出：

當我們收到應用程式的新事件時，會檢查這些事件是否與現有問題相符。
如果沒有相符項目，系統會自動對事件套用更智慧的事件分組演算法，並使用經過改良的元資料設計建立新問題。

這是我們首次大幅更新事件分組功能。如有任何意見或遇到問題，請提交回報。

未看到導覽標記記錄

如果沒有看到路徑記錄，建議檢查應用程式的 Google Analytics 設定。請確認符合下列規定：

您已在 Firebase 專案中啟用Google Analytics。
您已為「Google Analytics」啟用「資料共用」。如要進一步瞭解這項設定，請參閱「管理 Analytics 資料共用設定」一文。
您已在應用程式中。除了 Crashlytics SDK 之外，您還必須額外新增這個 SDK。
您在應用程式中使用的所有產品，都採用最新版 Firebase SDK。

未收到當機風險驟升警告

如果沒有看到速度快訊，請確認您使用的是

未看到未發生當機情形的指標 (或看到不可靠的指標)

如果沒有看到未發生當機情形的指標 (例如未受當機情況影響的使用者和工作階段)，或是看到不可靠的指標，請檢查下列事項：

請確認您使用的是
請確認資料收集設定不會影響未發生當機情形的指標品質：
- 如果停用自動當機報告功能，並啟用選擇加入報表，只有明確選擇加入資料收集的使用者，才會將當機資訊傳送至 Crashlytics。因此，由於 Crashlytics 只會收集選擇加入的使用者回報的當機資訊 (而非所有使用者)，免當機指標的準確度會受到影響。這表示未發生當機情形的指標可能較不可靠，且較無法反映應用程式的整體穩定性。
- 如果停用了自動收集資料功能，可以使用 sendUnsentReports 將裝置上快取的報告傳送至 Crashlytics。使用這個方法會將當機資料傳送至 Crashlytics，但不會傳送工作階段資料，導致控制台圖表顯示的無當機指標值偏低或為零。

如何計算不受當機影響的使用者？

請參閱「瞭解未發生當機情形的指標」。

誰可以查看、撰寫及刪除問題的附註？

專案成員可以在附註中針對特定問題留言，提出疑問或更新狀態等。

專案成員發布附註時，系統會標示他們的 Google 帳戶電子郵件地址。所有有權查看附註的專案成員，都能看到這個電子郵件地址和附註。

以下說明查看、撰寫及刪除記事所需的存取權：

專案成員只要具備下列任一角色，即可查看及刪除現有附註，並在問題中撰寫新附註。
- 專案擁有者或編輯者、 Firebase 管理員、品質管理員、或 Crashlytics 管理員
專案成員只要具備下列任一角色，即可查看問題的附註，但無法刪除或撰寫附註。
- 專案檢視者、 Firebase 檢視者、品質檢視者、或 Crashlytics 檢視者

整合

應用程式也使用 Google Mobile Ads SDK，但不會當機

如果您的專案同時使用 Crashlytics 和 Google Mobile Ads SDK，當機報告器可能會在註冊例外狀況處理常式時發生干擾。如要修正這個問題，請呼叫 disableSDKCrashReporting，在 Mobile Ads SDK 中關閉當機報告功能。

我的 BigQuery 資料集位於何處？

將 Crashlytics 連結至 BigQuery 後，無論 Firebase 專案位於何處，您建立的新資料集都會自動位於美國。

平台支援

迴歸的問題

什麼是回歸問題？

如果問題先前已結案，但Crashlytics收到問題再次發生的新報告，就會視為「迴歸」問題。Crashlytics 會自動重新開啟這些回歸問題，方便您視應用程式情況解決問題。

以下範例情境說明 Crashlytics 如何將問題歸類為迴歸：

Crashlytics 首次收到有關「Crash A」的當機報告。Crashlytics 會為該當機事件開啟相應的問題 (問題「A」)。
您迅速修正這個錯誤、關閉「A」問題，然後發布新版應用程式。
Crashlytics在您關閉問題後，收到有關問題「A」的另一份報告。
- 如果報告來自應用程式版本，而您關閉問題時Crashlytics 知道該版本 (表示該版本已針對任何當機情況傳送當機報告)，則 Crashlytics 不會將該問題視為回歸。問題將維持關閉狀態。
- 如果報告來自應用程式版本，而該版本在您關閉問題時Crashlytics 並不知道該問題 (表示該版本從未針對任何當機情況傳送任何當機報告)，則 Crashlytics 會將該問題視為迴歸問題，並重新開啟問題。

如果問題復發，系統會傳送迴歸偵測警報，並在問題中加入迴歸信號，通知您 Crashlytics 已重新開啟問題。如果不想讓問題因迴歸演算法而重新開啟，請「靜音」問題，而非關閉問題。

為什麼舊版應用程式會出現回歸問題？

如果報表來自舊版應用程式，且您關閉問題時，該版本從未傳送任何當機報告，則 Crashlytics 會將問題視為迴歸問題，並重新開啟問題。

如果發生下列情況，就可能需要使用這個功能：您已修正錯誤並發布新版應用程式，但仍有使用者使用舊版應用程式，因此無法取得錯誤修正。如果其中一個舊版從未在您關閉問題時傳送任何異常終止報告，且這些使用者開始遇到錯誤，則這些異常終止報告會觸發回歸問題。

如果不想讓問題因迴歸演算法而重新開啟，請「將問題設為靜音」，而非關閉問題。