iOS 以上版本
Android
Flutter:
Unity
。
本頁提供疑難排解說明,以及常見問題的解答
關於使用 Crashlytics 的問題如果發生以下情況:
找不到所需資訊或需要其他協助,請
Firebase 支援 。
一般疑難排解/常見問題
未顯示
未發生當機情形的指標和/或當機風險驟升快訊
如果沒有看到未發生當機情形的指標 (例如未發生當機情形的使用者和工作階段),
和/或當機風險驟升快訊
Crashlytics SDK 11.7.0 以上版本。
未顯示導覽標記記錄
如果沒有看到資訊主頁
導覽標記記錄
建議您檢查應用程式的 Google Analytics 設定。
請確認你符合下列規定:
無符號化
Crashlytics 資訊主頁中 Android 應用程式的堆疊追蹤
如果您使用 Unity IL2CPP
而看到未符號化的堆疊追蹤,請嘗試以下做法:
確認您使用的是 8.6.1 以上版本的 Crashlytics Unity
將機器學習工作流程自動化
確認您已設定並執行 Firebase CLI
使用 crashlytics:symbols:upload
指令產生並上傳符號
檔案。
每次建立版本時,您都必須執行這個 CLI 指令
建立或是您想在當中查看符號化堆疊追蹤的任何版本
也可前往 Firebase 控制台詳情請參閱
取得可讀的當機報告
頁面。
可以使用 Crashlytics
是否與使用 IL2CPP 的應用程式互動?
可以。Crashlytics 可顯示應用程式的符號化堆疊追蹤,
請使用 IL2CPP這項功能適用於 Android 或 Android 平台
Apple 平台。請採取以下行動:
確認您使用的是 8.6.0 以上版本的 Crashlytics Unity
將機器學習工作流程自動化
完成平台的必要工作:
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
注意: 如要自行計算應用程式中未發生當機情形的使用者百分比,
如要查看應用程式的 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 的電子郵件
讓他們使用服務帳戶所有專案都能看到這個電子郵件地址與附註
查看附註的成員。
以下說明查看、寫入及刪除所需的存取權
附註:
誰可以檢視、撰寫及刪除問題附註?
附註可讓專案成員針對特定問題和狀態提供意見
更新等
專案成員張貼附註時,附註會標示為 Google 的電子郵件
讓他們使用服務帳戶所有專案都能看到這個電子郵件地址與附註
查看附註的成員。
以下說明查看、寫入及刪除所需的存取權
附註:
整合
應用程式也會使用
Google Mobile Ads SDK 卻未當機
如果專案同時使用 Crashlytics 和 Google Mobile Ads SDK,
當機回報器很可能幹擾
註冊例外狀況處理常式。如要修正問題,請在以下位置關閉當機報告:
呼叫 disableSDKCrashReporting
來取得 Mobile Ads SDK。
我的 BigQuery 資料集位於何處?
將 Crashlytics 連結至 BigQuery 之後,您建立的新資料集
自動定位位於美國,無論您
Firebase 專案。
迴歸問題
什麼是迴歸?
問題?
您先前關閉的問題發生迴歸問題,
Crashlytics 會收到新問題再次回報的報表。
Crashlytics 會自動重新開啟這些迴歸的問題,讓您
找到適合您的應用程式的問題
以下情境示例將說明 Crashlytics 如何分類
做為迴歸:
Crashlytics 首度將收到有關當機情況的當機報告
「A」。Crashlytics 開啟了相對應的當機問題 (問題「A」)。
您很快便修正錯誤、關閉「A」問題,接著發布新版本的
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 將未偵測到的例外狀況回報為嚴重例外狀況,請同時採取下列兩個動作:
同時必須滿足以下兩個條件:
啟用回報「嚴重」例外狀況後,我現在又出現許多新嚴重事件。我該如何妥善處理這些例外狀況?
開始收到未偵測到的例外狀況報告後,
處理這些未擷取的例外狀況的一些方法:
擷取並處理擲回的例外狀況
建立並擲回例外狀況,以反映非預期或異常情況
州 。
解決擲回的例外狀況所反映的問題時,必須傳回
轉換為已知狀態 (這項程序稱為例外狀況)
(處理) )。
最佳做法是擷取並處理「所有」 例外狀況,除非
無法將程式傳回已知狀態。
如要控管透過哪些程式碼擷取及處理的例外狀況類型,
可能會在 try-catch
區塊中產生例外狀況的包裝程式碼 。
請確定 catch
陳述式中的條件範圍是
來處理特定例外狀況
在 Unity 或 Crashlytics 中記錄例外狀況
在 Unity 或 Crashlytics 中記錄例外狀況的方法有很多種,
偵錯。
以下是使用 Crashlytics 時最常見的兩項和建議做法
選項:
但如果您想手動將嚴重事件回報給 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
//
}