Crashlytics 疑難排解與常見問題

iOS+ Android Flutter Unity

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

一般疑難排解/常見問題

在「Issues」表格中看到某些問題的不同格式 (有時是「變化版本」)

您可能會發現，在 Firebase 控制台的「Issues」表格中，問題列表的格式有兩種。你可能也會在部分問題中看到名為「變化版本」的功能。原因如下！

在 2023 年初，我們推出了經過改善的分析引擎，可用於將事件分組，並為新問題提供更新的設計和一些進階功能 (例如變數)。詳情請參閱我們最近的網誌文章，但您也可以閱讀下文摘要。

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

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

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

以下是這些改善項目的使用體驗：

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

• 減少重複問題
  變更行號不會產生新問題。

• 更輕鬆偵錯有不同根本原因的複雜問題
  使用變化版本偵錯問題中常見的堆疊追蹤。

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

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

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

• 從您的應用程式取得新事件後，我們會檢查這些事件是否與現有問題相符。

• 如果沒有相符項目，系統會自動將更智慧的事件分組演算法套用至事件，並使用重新設計的結構描述設計建立新問題。

這是我們對事件分組功能進行的第一個重大更新。如有任何意見回饋或遇到問題，請 回報 。

找不到導覽標記記錄

如果您沒有看到麵包屑記錄，建議您檢查應用程式是否已設定 Google Analytics。請確認你符合下列規定：

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

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

• 您已新增 Google Analytics 的 Firebase SDK。Crashlytics

• 您使用的是 最新版 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 的 v8.6.1 以上版本。

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

   每次建立發布版本或任何您想在 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 指令，以產生及上傳符號檔案。

     每次建立發布版本或任何您想在 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 首次收到「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。這個選項會像選項 1 一樣將例外狀況列印到 Unity 主控台，但也會擲回例外狀況 (無論是否已擲回或擷取)。會擲回非本機錯誤。也就是說，即使使用 try-catch 區塊包圍 Debug.LogException(exception)，仍會導致未偵測到的例外狀況。

因此，只有在您想執行以下「所有」時，才呼叫 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
    //
}