Crashlytics 疑難排解與常見問題

在「Issues」資料表中，某些問題顯示不同的格式 (有時是「變化版本」)，

您可能會發現 Firebase 控制台的「問題」表格中列出的問題有兩種不同的格式。您也可能會在部分問題中 發現「變化版本」功能原因如下！

在 2023 年初，我們推出改善的分析引擎，用於將事件分組，以及新版設計和部分針對新問題 (例如變化版本！) 的進階功能。詳情請閱讀我們最新的網誌文章，但您可以閱讀下方摘要，瞭解相關重點。

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

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

但是，在這個事件群組中，導致失敗的堆疊追蹤可能有所不同。不同的堆疊追蹤可能有其他根本原因。為了表示問題中的可能差異，我們現在會在問題中建立「變化版本」，每個變化版本都為某個問題中的事件子群組，而該問題有相同的失敗點和類似的堆疊追蹤。透過變化版本，您可以對問題內最常見的堆疊追蹤進行偵錯，並判斷失敗的根本原因是否有所導致。

這些改進的優點如下：

• 問題列中的中繼資料經過更新
  您現在可以更輕鬆地瞭解應用程式中的問題，並加以分類。

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

• 針對各種根本原因，更輕鬆地偵錯複雜的問題
  使用變化版本對特定問題中最常見的堆疊追蹤進行偵錯。

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

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

以下是這些改善措施的運作方式：

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

• 如果不相符，我們會自動為事件套用更聰明的事件分組演算法，並以新版中繼資料設計建立新問題。

這是我們針對事件分組推出的第一項重大更新。如果您有任何意見或問題，請 提交報告 告訴我們。

未顯示未發生當機情形的指標和/或當機風險驟升快訊

如果沒有看到未受當機情況影響的指標 (例如未受當機影響的使用者和工作階段)，以及/或是當機風險快訊，請確認你使用的是

未顯示導覽標記記錄

如果沒有看到導覽標記記錄，建議您檢查應用程式的 Google Analytics (分析) 設定。請確認你符合下列規定：

• 您已在 Firebase 專案中啟用 Google Analytics (分析)。

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

• 您已 已將 Firebase SDK for Google Analytics (分析) 加進 應用程式。您必須另外加入 Crashlytics SDK。

• 您使用的是 最新的 Firebase SDK 版本 適用於應用程式中使用的所有產品。

在 Crashlytics 資訊主頁中查看 Android 應用程式的無符號堆疊追蹤

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

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

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

   每次建立發布子版本或要透過 Firebase 控制台查看其符號化堆疊追蹤的任何版本時，您都必須執行這項 CLI 指令。詳情請參閱取得可讀取的當機報告頁面。

Crashlytics 可以與使用 IL2CPP 的應用程式搭配使用嗎？

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

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

2. 完成平台的必要工作：

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

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

     每次建立發布子版本或要透過 Firebase 控制台查看其符號化堆疊追蹤的任何版本時，您都必須執行這項 CLI 指令。詳情請參閱取得可讀取的當機報告頁面。

未遇到當機情形的使用者是如何計算的？

「未發生當機情形的值」是指在特定時間範圍內，與應用程式互動但「未」發生當機情形的使用者百分比。

以下公式計算不受當機影響的使用者百分比。其輸入值由 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 稱呼他們。下表顯示每天與應用程式互動的使用者，以及當天有哪些使用者當機：

• 每週三的「未遇到當機情形的使用者」百分比為 50% (每 2 位使用者中有 1 人沒有當機)。
  有兩位使用者在週三與您的應用程式互動，但只有其中一位 (使用者 B) 沒有當機。

• 過去 2 天未遇到當機情形的使用者百分比為 33.3% (3 位使用者中有 1 位未遇到當機情形)。
  有三位使用者在過去兩天內與您的應用程式互動，但只有一位使用者 (使用者 C) 未遇到當機情形。

• 過去 3 天，未受當機情況影響的使用者百分比為 0%，而 3 位使用者中有 0 位未遇到當機情形。
  有三位使用者在過去三天曾與您的應用程式互動，但當中沒有任何人未當機。

請勿比較不同時間範圍的未受當機情況使用者值。單一使用者遇到當機的機率會隨著應用程式使用時間增加，因此在較長的時間範圍內，未受當機情況影響的使用者價值可能較低。

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

附註可讓專案成員對於問題、狀態更新等特定問題加註。

專案成員發布記事時，該記事會標上所屬 Google 帳戶的電子郵件地址。所有有權查看附註的專案成員都會看到這個電子郵件地址以及附註。

以下說明查看、寫入及刪除附註所需的存取權：

• 具有下列任一角色的專案成員可以查看及刪除現有附註，以及針對特定問題撰寫新附註。

  • 專案擁有者或編輯者、Firebase 管理員、品質管理員或 Crashlytics 管理員

• 具備下列任一角色的專案成員可以查看問題張貼的附註，但無法刪除或撰寫附註。

  • 專案檢視者、Firebase 檢視者、品質檢視者或 Crashlytics 檢視者

未遇到當機情形的使用者是如何計算的？

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

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

附註可讓專案成員對於問題、狀態更新等特定問題加註。

專案成員發布記事時，該記事會標上所屬 Google 帳戶的電子郵件地址。所有有權查看附註的專案成員都會看到這個電子郵件地址以及附註。

以下說明查看、寫入及刪除附註所需的存取權：

• 具有下列任一角色的專案成員可以查看及刪除現有附註，以及針對特定問題撰寫新附註。

  • 專案擁有者或編輯者、Firebase 管理員、品質管理員或 Crashlytics 管理員

• 具備下列任一角色的專案成員可以查看問題張貼的附註，但無法刪除或撰寫附註。

  • 專案檢視者、Firebase 檢視者、品質檢視者或 Crashlytics 檢視者

應用程式也使用 Google Mobile Ads SDK，但並未發生當機情形

如果專案和 Google Mobile Ads SDK 搭配使用 Crashlytics，可能會在註冊例外狀況處理常式時幹擾當機回報器。如要修正問題，請呼叫 disableSDKCrashReporting 來關閉 Mobile Ads SDK 中的當機回報功能。

我的 BigQuery 資料集位於何處？

將 Crashlytics 連結至 BigQuery 之後，無論 Firebase 專案所在位置為何，您建立的新資料集都會自動存放在美國。

什麼是迴歸問題？

如果您先前關閉了問題，導致發生迴歸問題，但 Crashlytics 會收到新的報告，說明問題再次發生。Crashlytics 會自動重新開啟這些迴歸的問題，您可以視情況為應用程式解決這些問題。

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

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

問題迴歸時，我們會傳送迴歸偵測快訊，並為問題新增迴歸信號，讓您知道 Crashlytics 已重新開啟問題。如果您不希望我們的迴歸演算法將問題重新開啟，請「靜音」問題，不要關閉問題。

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

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

這種情況可能會發生以下情況：您已修正錯誤並發布新版應用程式，但使用者仍使用舊版本，但未修正錯誤。但如果其中一個舊版本從未在您關閉問題時傳送任何當機報告，而這些使用者開始遇到該錯誤，那麼這些當機報告就會觸發迴歸問題。

如果您不想因為迴歸演算法而使問題重新開啟，請「靜音」問題，而不是關閉問題。

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

透過將未偵測到的例外狀況回報為「fatal」，您可以更實際地指出哪些例外狀況可能會導致遊戲無法玩 (即使應用程式繼續執行)。

請注意，如果您開始回報嚴重錯誤，未受當機情況影響的使用者 (CFU) 百分比可能會減少，但 CFU 指標將更能代表使用者對您應用程式的體驗。

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

為了讓 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.Log(exception.ToString())。
  • 如果警示在擷取及處理的情況下仍應回報給 Crashlytics，請使用 Crashlytics.LogException(exception) 將其記錄為非重大事件。

不過，如要手動向 Unity 雲端診斷回報嚴重事件，可以使用 Debug.LogException。這個選項會將例外狀況列印至 Unity 控制台 (例如方法 1)，但「也會」擲回例外狀況 (無論是否遭到擲回或擷取)。這個函式會以非本機的方式擲回錯誤。這表示即使是在具有 try-catch 區塊的 Debug.LogException(exception) 周圍，仍會導致未偵測到的例外狀況。

因此，只有在您執行下列「所有」功能時，才呼叫 Debug.LogException：

• 如何將例外狀況列印至 Unity 控制台。
• 如要將例外狀況上傳至 Crashlytics，並做為嚴重事件，
• 如要擲回例外狀況，可將其視為「未偵測到」的例外狀況，並回報給 Unity 雲端診斷。

請注意，如果您想將擷取的例外狀況列印至 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
    //
}