Crashlytics 疑難排解與常見問題

iOS 以上版本 Android Flutter： Unity 。

本頁提供疑難排解說明，以及常見問題的解答 關於使用 Crashlytics 的問題如果發生以下情況： 找不到所需資訊或需要其他協助，請 Firebase 支援。

一般疑難排解/常見問題

查看各種格式 Issues (問題) 資料表中的部分問題 (有時也稱為「變化版本」)

您可能會注意到「問題」表格中列出的問題有兩種不同格式 。您可能也注意到， 「變化版本」有些議題原因如下！

我們在 2023 年初推出了改良版的分析引擎，可將事件分組，例如 新版設計和一些進階功能 (例如 變數！)。看看我們最近 網誌文章 瞭解詳細資訊，或參閱有關重點特色的說明。

Crashlytics 會分析應用程式中的所有事件，例如當機次數、一般錯誤 和 ANR) 並建立事件群組，稱為「問題」，也就是 通常都存在故障

為了將事件按照問題分門別類，改良後的分析引擎現在會留意 事件的許多層面，包括堆疊追蹤中的影格 例外狀況訊息、錯誤代碼，以及其他平台或錯誤類型

不過，在這個事件群組中，導致失敗的堆疊追蹤 可能會不同如果堆疊追蹤不同，根本原因可能也不同。 為了呈現問題中可能的差異，我們現在建立了 問題中的變化版本：每個變化版本都是問題中的事件子群組 具有相同失敗點「和」類似的堆疊追蹤。使用變化版本時 可以對問題中最常見的堆疊追蹤進行偵錯，並判斷 導致失敗的根本原因不同

下列改善功能的運作方式如下：

• 問題列中的中繼資料經過修訂
  現在更容易瞭解應用程式中的問題並進行分類。

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

• 更輕鬆地偵錯造成各種根本原因的複雜問題
  使用變化版本對問題中最常發生的堆疊追蹤進行偵錯。

• 更多具參考價值的快訊和信號
  一個新問題其實代表一個新的錯誤。

• 更強大的搜尋功能
  每個問題都含有更易於搜尋的中繼資料 例如例外狀況類型和套件名稱

以下為我們推出的改善功能：

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

• 如果沒有相符的結果，系統會自動套用智慧型事件分組功能 事件，並使用修改過的中繼資料建立新問題 設計。

這是我們即將推出的活動分組功能的第一項重大更新。如果發生以下情況： 提供意見或遇到任何問題，請透過以下管道與我們聯絡： 提出檢舉。

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

如果沒有看到未發生當機情形的指標 (例如未發生當機情形的使用者和工作階段)， 和/或當機風險驟升快訊 Crashlytics SDK 11.7.0 以上版本。

未顯示導覽標記記錄

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

• 您 已啟用 Google Analytics 。

• 您已啟用 Google Analytics 的資料共用功能。進一步瞭解 這項設定位於 管理 Analytics 資料共用設定

• 您 已新增 Google Analytics 專用 Firebase SDK 。 導入您的應用程式您必須將這個 SDK外加新增至 Crashlytics SDK。

• 您正在使用 最新版 Firebase SDK 。 有關您在應用程式中使用的所有產品

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

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

1. 確認您使用的是 8.6.1 以上版本的 Crashlytics Unity 將機器學習工作流程自動化

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

   每次建立版本時，您都必須執行這個 CLI 指令 建立或是您想在當中查看符號化堆疊追蹤的任何版本 也可前往 Firebase 控制台詳情請參閱 取得可讀的當機報告 頁面。

可以使用 Crashlytics 是否與使用 IL2CPP 的應用程式互動？

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

1. 確認您使用的是 8.6.0 以上版本的 Crashlytics Unity 將機器學習工作流程自動化

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

   • Apple 平台應用程式：不需要採取特殊動作。Apple 適用 平台應用程式，Firebase Unity 編輯器外掛程式會自動設定 以便上傳符號。

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

     每次建立版本時，您都必須執行這個 CLI 指令 建立或是您想在當中查看符號化堆疊追蹤的任何版本 也可前往 Firebase 控制台詳情請參閱 取得可讀的當機報告 頁面。

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

「未發生當機情形的價值」是指與 應用程式但「沒有」在特定時間範圍內當機。

以下公式計算未發生當機情形的使用者百分比。輸入內容 這些值是由 Google Analytics 提供

CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100

• 發生當機時，Google Analytics 會傳送 app_exception 事件 類型，CRASHED_USERS 代表相關聯的使用者人數 與該事件類型相符的結果

• ALL_USERS是指互動過的使用者總數 即可查看 Crashlytics 資訊主頁的右上方

注意： 如要自行計算應用程式中未發生當機情形的使用者百分比， 如要查看應用程式的 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% (1/3 未發生當機情形的使用者)。
  在過去兩天內，有三名使用者與您的應用程式互動，但 其中一 (使用者 C) 未發生當機情形。

• 過去 3 天內，未發生當機情形的使用者百分比為 0% (佔 3 的 0) 未發生當機情形的使用者)。
  過去三天內，有三位使用者與您的應用程式互動， 也未發生任何當機情形

請勿以不同時間範圍比較未受當機情況影響的使用者價值。 單一使用者遭遇當機情形的機率增加， 使用應用程式後，未發生當機情形的使用者價值比較可能比較長 時間範圍。

注意： 如果您篩選活動的「事件，未發生當機情形的統計資料」資訊卡，就會顯示空白的「未當機情形統計資料」資訊卡 type 用於一般問題。「未發生當機情形的使用者百分比」 計算嚴重事件的費用

誰可以檢視、撰寫及刪除問題附註？

附註可讓專案成員針對特定問題和狀態提供意見 更新等

專案成員張貼附註時，附註會標示為 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 並未的應用程式版本 您回報的問題 從未針對任何當機情況傳送任何當機報告)，則 Crashlytics 會考量問題迴歸，並重新開啟 問題。

注意： 在 2022 年 2 月之前，Crashlytics 將問題歸類為 在任何應用程式版本中再次發生相同問題 (即便是來自應用程式) 再次發生這個問題 問題結案後所得知的各種版本。這導致 Crashlytics 有時會無法準確辨識迴歸問題。現在我們使用 定義。

問題迴歸時，我們會傳送迴歸偵測快訊，並新增 代表問題發生在 Crashlytics 再次開啟問題。如果您不希望我們重新開啟問題，請遵守我們的 迴歸演算法「靜音」而不是關閉該問題

為什麼我會看到迴歸問題 是否會發生問題？

如果報告來自舊版應用程式，從未傳送任何當機報告： 在你關閉問題後，Crashlytics 會將問題納入考量 並重新開啟問題。

當有以下情況時，就可能發生這種情況：您已修正錯誤，且 發布新版應用程式，但使用者仍保有舊版應用程式 未修正錯誤如果有，其中其中一個舊版本「從未」傳送過 使用者關閉問題後 遇到錯誤時，這些當機報告就會觸發迴歸問題。

如果您不希望系統因為迴歸演算法而將問題重新開啟，請「靜音」 而不是關閉該問題

注意： 在 2022 年 2 月之前，Crashlytics 將問題歸類為 在任何應用程式版本中再次發生相同問題 (即使是應用程式版本) 時也是如此。 我們回報的問題導致 Crashlytics 有時會無法準確辨識迴歸問題。現在我們使用慣例 相同。

如果您發現 但可以於 2022 年 2 月前重新開啟。

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

Crashlytics 可以將未偵測到的例外狀況回報為嚴重錯誤 (從 10.4.0 版 Unity SDK 的部分功能)。下列常見問題有助於解釋原因和最佳做法 使用這項功能的實務做法

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

將未偵測到的例外狀況回報為嚴重錯誤時， 列出可能導致遊戲無法玩的例外情況，即使應用程式 持續執行。

請注意，一旦您開始回報嚴重事件，則未遇到當機情形的使用者 (CFU) 百分比 可能會降低，但「CFU」指標會較能呈現 使用者能有效提升使用者體驗

重要事項： 回報未偵測到的例外狀況，因為嚴重情況並不會影響 Android Vitals。 只有您能看到 Crashlytics 回報的嚴重資料， 發現並修正應用程式和遊戲中的問題。

哪些例外情況 並回報為嚴重事件？

為了讓 Crashlytics 將未偵測到的例外狀況回報為嚴重例外狀況，請同時採取下列兩個動作： 同時必須滿足以下兩個條件：

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

• 您的應用程式 (或內含的程式庫) 會擲回未偵測到的例外狀況。一個 系統不會將已建立的例外狀況視為未擲回，但不會擲回。

啟用回報「嚴重」例外狀況後，我現在又出現許多新嚴重事件。我該如何妥善處理這些例外狀況？

開始收到未偵測到的例外狀況報告後， 處理這些未擷取的例外狀況的一些方法：

• 思考如何著手偵測及處理這些未偵測到的例外狀況。
• 考慮使用不同的選項，將 Unity 偵錯控制台和 Crashlytics 記錄例外狀況。

擷取並處理擲回的例外狀況

建立並擲回例外狀況，以反映非預期或異常情況 州。 解決擲回的例外狀況所反映的問題時，必須傳回 轉換為已知狀態 (這項程序稱為例外狀況) (處理))。

最佳做法是擷取並處理「所有」例外狀況，除非 無法將程式傳回已知狀態。

如要控管透過哪些程式碼擷取及處理的例外狀況類型， 可能會在 try-catch 區塊中產生例外狀況的包裝程式碼。 請確定 catch 陳述式中的條件範圍是 來處理特定例外狀況

在 Unity 或 Crashlytics 中記錄例外狀況

在 Unity 或 Crashlytics 中記錄例外狀況的方法有很多種， 偵錯。

以下是使用 Crashlytics 時最常見的兩項和建議做法 選項：

• 選項 1：在 Unity 控制台中列印，但不回報給 Crashlytics。 開發或疑難排解時

  • 使用 Debug.Log(exception) 在 Unity 控制台中列印。 Debug.LogWarning(exception)和Debug.LogError(exception)， 將例外狀況內容列印到 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
    //
}