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 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 資訊主頁右上角的下拉式選單選取的時間範圍內，曾與應用程式互動的使用者總數。

注意： 如要自行計算應用程式未發生當機情形的使用者百分比，您可以在 Analytics (分析) 資訊主頁中找到應用程式的 app_exception 事件數。不過，由於當機的處理方式有些微差異，因此 Analytics (分析) 資訊主頁中顯示的 app_exception 值有時可能會與計算「不受當機影響的使用者百分比」時採用的值不同。

未遇到當機情形的使用者百分比是長期匯總資料，而非平均值。

舉例來說，假設您的應用程式有三名使用者，分別稱為使用者 A、使用者 B 和使用者 C。下表顯示了每天與應用程式互動的使用者，以及這些使用者當天遇到當機情形的使用者：

	星期一	週二	星期三
曾與您應用程式互動的使用者	A、B、C	A、B、C	A、B
曾發生當機情形的使用者	C	B	A

• 在週三，未發生當機情形的使用者百分比為 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，卻沒有發生當機問題

如果專案同時使用 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 會考量問題迴歸，並重新開啟問題。

注意： 在 2022 年 2 月前，Crashlytics 在「任何」應用程式版本中再次發生相同問題時，會將該問題歸類為迴歸，即使是在您關閉問題後所知的應用程式版本也一樣。這也導致 Crashlytics 有時無法準確識別迴歸問題。現在我們使用的是上述慣例。

發生迴歸問題時，我們會傳送迴歸偵測快訊，並為問題新增迴歸信號，通知 Crashlytics 已重新開啟問題。如果您不希望問題因迴歸演算法而重新開啟，請「忽略」問題，而不要關閉問題。

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

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

在下列情況中，可能會出現這種情況：您修正錯誤並發布了新版應用程式，但使用者仍使用舊版應用程式，而未修正錯誤。也許在您解決問題時，其中一個舊版本從未傳送任何當機報告，而這些使用者開始遇到該錯誤，而這些當機報告將觸發迴歸問題。

如果您不希望問題因迴歸演算法而重新開啟，請「忽略」問題，而不要關閉問題。

注意： 2022 年 2 月前，Crashlytics 在任何應用程式版本中再次發生相同問題時，即使 Crashlytics 問題再次發生，上述問題也歸類為迴歸。這會導致 Crashlytics 有時無法正確識別迴歸問題。現在我們使用的是上述慣例

如果您在 2022 年 2 月前發現許多錯誤的迴歸錯誤，可以重新關閉，以免系統重新開啟。

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

Crashlytics 可以將未偵測到的例外狀況回報為嚴重錯誤 (從 Unity SDK 的 v10.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 診斷報告嚴重事件，可以使用 Debug.LogException。這個選項會將例外狀況輸出至 Unity 主控台 (例如選項 1)，但會擲回例外狀況 (不論是否已擲回或擷取)。這會直接在本機擲回錯誤。這表示，即使周圍的 Debug.LogException(exception) 具有 try-catch 區塊，仍會發生未偵測到的例外狀況。

因此，只有在您要執行「所有」下列操作時，才需要呼叫 Debug.LogException：

• 將例外狀況列印到 Unity 控制台。
• 將例外狀況以嚴重事件的形式上傳到 Crashlytics。
• 如要擲回例外狀況，請將其視為 uncaught 例外狀況，並回報給 Unity Cloud 診斷。

請注意，如果您想將偵測到的例外狀況輸出至 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
    //
}