Crashlytics 疑難排解與常見問題

iOS+ Android Flutter Unity

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

一般疑難排解/常見問題

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

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

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

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

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

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

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

• 問題列中顯示的經過改良的中繼資料
  現在更容易瞭解及分類應用程式中的問題。

• 減少重複問題
  行號變更不會導致新問題。

• 更輕鬆地對根本原因各異的複雜問題進行偵錯
  使用變體對問題中最常見的堆疊追蹤進行偵錯。

• 更有意義的快訊和信號
  新問題實際上代表新錯誤。

• 更強大的搜尋功能
  每個問題都包含更多可搜尋的中繼資料，例如例外狀況類型和套件名稱。

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

• 當我們收到應用程式的新事件時，會檢查這些事件是否與現有問題相符。

• 如果沒有相符項目，系統會自動對事件套用更智慧的事件分組演算法，並使用經過改良的元資料設計建立新問題。

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

未看到導覽標記記錄

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

• 您已在 Firebase 專案中啟用Google Analytics。

• 您已為「Google Analytics」啟用「資料共用」。如要進一步瞭解這項設定，請參閱「管理 Analytics 資料共用設定」一文。

• 您已在應用程式中 新增 Firebase SDK for Google Analytics 。除了 Crashlytics SDK 之外，您還必須額外新增這個 SDK。

• 您在應用程式中使用的所有產品，都採用最新版 Firebase SDK、最新版 Firebase SDK、最新版 Firebase SDK 和最新版 Firebase SDK。

未收到當機風險驟升警告

如果沒有看到速度快訊，請確認您使用的是 Crashlytics SDK 11.7.0 以上版本。

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

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

• 請確認您使用的是 Crashlytics SDK 11.7.0 以上版本。

• 請確認資料收集設定不會影響未發生當機情形的指標品質：

  • 如果停用自動當機報告功能，並啟用選擇加入報表，只有明確選擇加入資料收集的使用者，才會將當機資訊傳送至 Crashlytics。因此，由於 Crashlytics 只會收集選擇加入的使用者回報的當機資訊 (而非所有使用者)，免當機指標的準確度會受到影響。這表示未發生當機情形的指標可能較不可靠，且較無法反映應用程式的整體穩定性。

  • 如果停用了自動收集資料功能，可以使用 sendUnsentReports 將裝置上快取的報告傳送至 Crashlytics。 使用這個方法會將當機資料傳送至 Crashlytics，但不會傳送工作階段資料，導致控制台圖表顯示的無當機指標值偏低或為零。

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

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

在 Crashlytics 資訊主頁中看到 Android 應用程式的未符號化堆疊追蹤記錄

如果您使用 Unity IL2CPP，且看到未符號化的堆疊追蹤記錄，請嘗試下列做法：

1. 請確認您使用的是 Crashlytics Unity SDK 8.6.1 以上版本。

2. 請確認您已設定並執行 Firebase CLI crashlytics:symbols:upload 指令，產生及上傳符號檔。

   每次建立發布版本或任何建構版本時，您都需要執行這個 CLI 指令，才能在 Firebase 控制台中查看符號化的堆疊追蹤記錄。詳情請參閱「取得可讀取的當機報告」頁面。

Crashlytics 是否可與使用 IL2CPP 的應用程式搭配使用？

可以，Crashlytics可顯示使用 IL2CPP 的應用程式符號化堆疊追蹤記錄。這項功能適用於在 Android 或 Apple 平台上發布的應用程式。請採取以下行動：

1. 請務必使用 Crashlytics Unity SDK 8.6.0 以上版本。

2. 請完成所用平台適用的必要工作：

   • Apple 平台應用程式：不需要採取任何特別行動。如果是 Apple 平台應用程式，Firebase Unity 編輯器外掛程式會自動設定 Xcode 專案，以便上傳符號。

   • Android 應用程式：請確認您已設定並執行 Firebase CLI crashlytics:symbols:upload 指令，產生及上傳符號檔。

     每次建立發布版本或任何建構版本時，您都需要執行這個 CLI 指令，才能在 Firebase 控制台中查看符號化的堆疊追蹤記錄。詳情請參閱「取得可讀取的當機報告」頁面。

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

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

專案成員發布附註時，系統會標示他們的 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 如何將問題歸類為迴歸：

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

注意： 2022 年 2 月前，如果問題在任何應用程式版本中再次發生，Crashlytics就會將問題歸類為回歸，即使是您關閉問題時我們已知的應用程式版本也一樣。這導致Crashlytics有時會誤判迴歸。我們現在使用上述慣例。

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

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

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

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

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

注意： 2022 年 2 月前，如果問題在任何應用程式版本中再次發生，Crashlytics 都會將問題歸類為迴歸問題，即使是您關閉問題時已知的應用程式版本也一樣。這導致系統有時會誤判迴歸。Crashlytics我們現在使用上述慣例。

如果發現 2022 年 2 月前有許多誤判的迴歸問題，可以重新關閉這些問題，避免系統再次開啟。

將未偵測到的例外狀況回報為嚴重錯誤

Crashlytics 可以將未偵測到的例外狀況回報為嚴重事件 (從 Unity SDK 的 10.4.0 版開始)。以下常見問題說明使用這項功能的理由和最佳做法。

為什麼應用程式應將未偵測到的例外狀況回報為嚴重錯誤？

將未偵測到的例外狀況回報為嚴重錯誤，可更如實地指出哪些例外狀況可能導致遊戲無法執行，即使應用程式持續運作也一樣。

請注意，開始回報嚴重錯誤後，無當機使用者 (CFU) 百分比可能會降低，但 CFU 指標會更貼近使用者體驗。

重要事項： 將未處理的例外狀況回報為嚴重錯誤不會影響 Android Vitals。您只會看到 Crashlytics 中回報的嚴重錯誤，方便您找出並修正應用程式和遊戲中的問題。

哪些例外狀況會回報為嚴重錯誤？

如要讓 Crashlytics 將未偵測到的例外狀況回報為嚴重事件，必須符合下列兩項條件：

• 在應用程式初始化期間，ReportUncaughtExceptionsAsFatal 屬性必須設為 true。

• 您的應用程式 (或內含的程式庫) 擲回未擷取的例外狀況。建立但未擲回的例外狀況，不會視為未處理。

啟用將未偵測到的例外狀況回報為嚴重事件後，我現在有許多新的嚴重事件。如何正確處理這些例外狀況？

當您開始收到未處理例外狀況的報告 (顯示為嚴重錯誤) 時，可以採取下列幾種方式處理這些未處理的例外狀況：

• 請考慮如何開始擷取及處理這些未擷取的例外狀況。
• 考慮將例外狀況記錄到 Unity 偵錯控制台和 Crashlytics 的不同選項。

攔截並處理擲回的例外狀況

系統會建立並擲回例外狀況，以反映非預期或例外狀態。如要解決例外狀況反映的問題，必須將程式還原至已知狀態 (這個程序稱為例外狀況處理)。

除非程式無法返回已知狀態，否則最佳做法是擷取並處理所有預期的例外狀況。

如要控管哪些程式碼會擷取及處理哪些類型的例外狀況，請將可能產生例外狀況的程式碼包裝在 try-catch 區塊中。請確保 catch 陳述式中的條件盡可能嚴格，以便適當處理特定例外狀況。

在 Unity 或 Crashlytics 中記錄例外狀況

您可以在 Unity 或 Crashlytics 中記錄例外狀況，協助偵錯問題。

使用 Crashlytics 時，以下是兩種最常見且建議採用的選項：

• 選項 1：在 Unity 控制台中列印，但不要在開發或疑難排解期間向 Crashlytics 回報

  • 使用 Debug.Log(exception)、Debug.LogWarning(exception) 和 Debug.LogError(exception) 列印至 Unity 控制台，這些函式會將例外狀況的內容列印至 Unity 控制台，且不會重新擲回例外狀況。

• 方法 2：在 Crashlytics 資訊主頁中上傳至 Crashlytics，以便在下列情況中取得匯總報表：

  • 如果例外狀況值得記錄，以便偵錯可能的後續 Crashlytics 事件，請使用 Crashlytics.Log(exception.ToString())。
  • 如果例外狀況應仍回報給 Crashlytics，即使已擷取並處理，請使用 Crashlytics.LogException(exception) 將其記錄為非嚴重事件。

不過，如要手動向 Unity Cloud Diagnostics 回報嚴重事件，可以使用 Debug.LogException。這個選項會將例外狀況列印到 Unity 控制台 (如選項 1)，但也會擲回例外狀況 (無論是否已擲回或擷取)。系統會擲回非本機錯誤。也就是說，即使周圍有 Debug.LogException(exception) 區塊，try-catch 仍會導致未處理的例外狀況。

因此，只有在您想同時執行下列所有操作時，才呼叫 Debug.LogException：

• 將例外狀況列印到 Unity 控制台。
• 將例外狀況上傳至 Crashlytics 做為嚴重事件。
• 擲回例外狀況，將其視為未偵測到的例外狀況，並回報給 Unity Cloud Diagnostics。

請注意，如要將偵測到的例外狀況列印到 Unity 控制台 並上傳至 Crashlytics 做為非嚴重事件，請改為執行下列操作：

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}