דף זה מספק עזרה בפתרון בעיות ותשובות לשאלות נפוצות לגבי השימוש ב-Crashlytics. אם אינך מוצא את מה שאתה מחפש או זקוק לעזרה נוספת, צור קשר עם התמיכה של Firebase .
פתרון תקלות כללי/שאלות נפוצות
ייתכן שתבחין בשני פורמטים שונים לבעיות המפורטות בטבלת הבעיות שלך במסוף Firebase. וייתכן שתבחין גם בתכונה הנקראת "וריאנטים" בחלק מהבעיות שלך. הנה למה!
בתחילת 2023, השקנו מנוע ניתוח משופר לקיבוץ אירועים, כמו גם עיצוב מעודכן וכמה תכונות מתקדמות לבעיות חדשות (כמו גרסאות!). עיין בפוסט הבלוג האחרון שלנו לקבלת כל הפרטים, אבל אתה יכול לקרוא להלן עבור הדגשים.
Crashlytics מנתחת את כל האירועים מהאפליקציה שלך (כמו קריסות, קריסות, לא קטלניות ומקרי ANR) ויוצרת קבוצות של אירועים הנקראים בעיות - לכל האירועים בבעיה יש נקודת כשל משותפת.
כדי לקבץ אירועים לבעיות אלו, מנוע הניתוח המשופר בוחן כעת היבטים רבים של האירוע, כולל המסגרות במעקב המחסנית, הודעת החריגה, קוד השגיאה ומאפיינים אחרים של פלטפורמה או סוג שגיאה.
עם זאת, בתוך קבוצת אירועים זו, עקבות המחסנית המובילות לכשל עשויות להיות שונות. מעקב אחר מחסנית יכול להיות גורם שורש אחר. כדי לייצג את ההבדל האפשרי הזה בתוך בעיה, אנו יוצרים כעת גרסאות בתוך בעיות - כל וריאציה היא תת-קבוצה של אירועים בבעיה שיש להם אותה נקודת כשל ומעקב מחסנית דומה. עם גרסאות, אתה יכול לנפות באגים במעקבי הערימה הנפוצים ביותר בתוך בעיה ולקבוע אם סיבות שורש שונות מובילות לכשל.
הנה מה שתחווה עם השיפורים האלה:
מטא נתונים מחודשים מוצגים בשורת הבעיה
עכשיו קל יותר להבין ולבדוק בעיות באפליקציה שלך.פחות בעיות כפולות
שינוי מספר שורה אינו גורם לבעיה חדשה.איתור באגים קל יותר של בעיות מורכבות עם סיבות שורש שונות
השתמש בגרסאות כדי לנפות באגים במעקבי הערימה הנפוצים ביותר בתוך בעיה.התראות ואותות משמעותיים יותר
בעיה חדשה מייצגת למעשה באג חדש.חיפוש חזק יותר
כל בעיה מכילה יותר מטא נתונים שניתנים לחיפוש, כמו סוג חריג ושם חבילה.
כך מתגלגלים השיפורים האלה:
כשנקבל אירועים חדשים מהאפליקציה שלך, נבדוק אם הם תואמים לבעיה קיימת.
אם אין התאמה, נחיל אוטומטית את אלגוריתם קיבוץ האירועים החכם יותר שלנו על האירוע וניצור בעיה חדשה עם עיצוב המטא-נתונים המחודש.
זהו העדכון הגדול הראשון שאנו מבצעים לקבוצת האירועים שלנו. אם יש לך משוב או נתקלת בבעיות כלשהן, אנא הודע לנו על ידי הגשת דוח.
אם אינך רואה מדדים ללא קריסות (כמו משתמשים והפעלות ללא קריסות) ו/או התראות על מהירות, ודא שאתה משתמש ב-Crashlytics SDK 11.7.0+.
אם אינך רואה יומני פירורי לחם , אנו ממליצים לבדוק את תצורת האפליקציה שלך עבור Google Analytics. ודא שאתה עומד בדרישות הבאות:
הפעלת את Google Analytics בפרויקט Firebase שלך.
הפעלת שיתוף נתונים עבור Google Analytics. קבל מידע נוסף על הגדרה זו ב'ניהול הגדרות שיתוף הנתונים שלך ב-Analytics'
הוספת אתהוסיף את Firebase SDK עבור Google Analyticsלאפליקציה שלך. יש להוסיף SDK זה בנוסף ל-Crashlytics SDK.
אתה משתמש בגרסאותגרסאות Firebase SDK האחרונותעבור כל המוצרים שבהם אתה משתמש באפליקציה שלך.
אם אתה משתמש ב-Unity IL2CPP ואתה רואה עקבות מחסנית לא סימבולית, נסה את הפעולות הבאות:
ודא שאתה משתמש בגרסה 8.6.1 ומעלה של Crashlytics Unity SDK.
ודא שאתה מוגדר ומפעיל את הפקודה Firebase CLI
crashlytics:symbols:upload
כדי ליצור ולהעלות את קובץ הסמלים שלך.אתה צריך להפעיל את פקודת ה-CLI הזו בכל פעם שאתה יוצר גירסת מהדורה או כל מבנה שעבורו אתה רוצה לראות עקבות מחסנית סימבולית במסוף Firebase. למידע נוסף בדף קבל דוחות קריסה קריא .
כן, Crashlytics יכולה להציג עקבות מחסנית סימבולית עבור האפליקציות שלך המשתמשות ב-IL2CPP. יכולת זו זמינה עבור אפליקציות ששוחררו בפלטפורמות אנדרואיד או אפל. הנה מה שאתה צריך לעשות:
ודא שאתה משתמש בגרסה 8.6.0 ואילך של Crashlytics Unity SDK.
השלם את המשימות הדרושות עבור הפלטפורמה שלך:
עבור אפליקציות פלטפורמת אפל : אין צורך בפעולות מיוחדות. עבור אפליקציות פלטפורמת אפל, הפלאגין Firebase Unity Editor מגדיר באופן אוטומטי את פרויקט Xcode שלך להעלאת סמלים.
עבור אפליקציות 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.
אחוז המשתמשים ללא קריסות הוא צבירה לאורך זמן , לא ממוצע.
לדוגמה, דמיינו לאפליקציה שלכם שלושה משתמשים; נקרא להם משתמש א', משתמש ב' ומשתמש ג'. הטבלה הבאה מציגה אילו משתמשים היו מעורבים באפליקציה שלך בכל יום ואיזה מהמשתמשים הללו קרסה באותו יום:
יוֹם שֵׁנִי | יוֹם שְׁלִישִׁי | יום רביעי | |
---|---|---|---|
משתמשים שהיו מעורבים באפליקציה שלך | א ב ג | א ב ג | א, ב |
משתמש שעבר קריסה | ג | ב | א |
ביום רביעי, אחוז המשתמשים ללא קריסות שלך הוא 50% (1 מכל 2 משתמשים היה ללא קריסות).
שניים מהמשתמשים שלך עסקו באפליקציה שלך ביום רביעי, אבל רק לאחד מהם (משתמש B) לא היו קריסות.במשך היומיים האחרונים, אחוז המשתמשים ללא קריסות שלך הוא 33.3% (1 מתוך 3 משתמשים היה ללא קריסות).
שלושה מהמשתמשים שלך היו מעורבים באפליקציה שלך במהלך היומיים האחרונים, אבל רק לאחד מהם (משתמש C) לא היו קריסות.במשך 3 הימים האחרונים, אחוז המשתמשים ללא קריסות שלך הוא 0% (0 מתוך 3 משתמשים היו ללא קריסות).
שלושה מהמשתמשים שלך היו מעורבים באפליקציה שלך במהלך שלושת הימים האחרונים, אבל לאפס מהם לא היו קריסות.
אין להשוות את ערך המשתמשים ללא קריסות על פני תקופות זמן שונות. ההסתברות שמשתמש בודד יחווה קריסה גדלה ככל שהוא משתמש יותר פעמים באפליקציה שלך, כך שערך המשתמשים ללא קריסה צפוי להיות קטן יותר לתקופות זמן ארוכות יותר.
הערות מאפשרות לחברי הפרויקט להגיב על בעיות ספציפיות בשאלות, עדכוני סטטוס וכו'.
כאשר חבר בפרויקט מפרסם הערה, היא מסומנת עם האימייל של חשבון Google שלו. כתובת דוא"ל זו גלויה, יחד עם ההערה, לכל חברי הפרויקט בעלי גישה לצפות בהערה.
להלן מתאר את הגישה הנדרשת לצפייה, כתיבה ומחיקה של הערות:
חברי פרויקט עם כל אחד מהתפקידים הבאים יכולים להציג ולמחוק הערות קיימות ולכתוב הערות חדשות בנושא.
חברי פרויקט עם כל אחד מהתפקידים הבאים יכולים להציג את ההערות שפורסמו בנושא, אך הם אינם יכולים למחוק או לכתוב הערה.
- Project Viewer , Firebase Viewer , Quality Viewer או Crashlytics Viewer
ראה הבנת מדדים ללא קריסות .
הערות מאפשרות לחברי הפרויקט להגיב על בעיות ספציפיות בשאלות, עדכוני סטטוס וכו'.
כאשר חבר בפרויקט מפרסם הערה, היא מסומנת עם האימייל של חשבון Google שלו. כתובת דוא"ל זו גלויה, יחד עם ההערה, לכל חברי הפרויקט בעלי גישה לצפות בהערה.
להלן מתאר את הגישה הנדרשת לצפייה, כתיבה ומחיקה של הערות:
חברי פרויקט עם כל אחד מהתפקידים הבאים יכולים להציג ולמחוק הערות קיימות ולכתוב הערות חדשות בנושא.
חברי פרויקט עם כל אחד מהתפקידים הבאים יכולים להציג את ההערות שפורסמו בנושא, אך הם אינם יכולים למחוק או לכתוב הערה.
- Project Viewer , Firebase Viewer , Quality Viewer או Crashlytics Viewer
אינטגרציות
אם הפרויקט שלך משתמש ב-Crashlytics לצד Google Mobile Ads SDK, סביר להניח שכתבי הקריסה מתערבים ברישום מטפלי חריגים. כדי לפתור את הבעיה, כבה את דיווח קריסה ב-SDK של מודעות לנייד על ידי קריאה disableSDKCrashReporting
.
לאחר שתקשר את Crashlytics ל-BigQuery, מערכי נתונים חדשים שתיצור ממוקמים אוטומטית בארצות הברית, ללא קשר למיקום פרויקט Firebase שלך.
בעיות נסוגו
לבעיה הייתה רגרסיה כאשר סגרת את הבעיה בעבר, אך Crashlytics מקבל דיווח חדש שהבעיה התרחשה מחדש. Crashlytics פותחת מחדש אוטומטית את הבעיות הללו שנגרמו כדי שתוכל לטפל בהן בהתאם לאפליקציה שלך.
להלן תרחיש לדוגמה המסביר כיצד Crashlytics מסווג בעיה כרגרסיה:
- בפעם הראשונה אי פעם, Crashlytics מקבל דוח התרסקות על התרסקות "A". Crashlytics פותחת בעיה מתאימה לאותה התרסקות (גיליון "A").
- אתה מתקן את הבאג הזה במהירות, סוגר את נושא "A" ואז משחרר גרסה חדשה של האפליקציה שלך.
- Crashlytics מקבל דיווח נוסף על בעיה "A" לאחר שסגרת את הנושא.
- אם הדוח הוא מגרסת אפליקציה ש-Cashlytics ידעה עליה כשסגרת את הבעיה (כלומר שהגרסה שלחה דוח קריסה לכל קריסה בכלל), אז Crashlytics לא תתייחס לבעיה כשגרה. הנושא יישאר סגור.
- אם הדוח הוא מגרסת אפליקציה ש-Cashlytics לא ידעה עליה כשסגרת את הבעיה (כלומר שהגרסה מעולם לא שלחה דוח קריסה עבור קריסה כלשהי), אז Crashlytics מחשיבה את הבעיה כנסגרת ותפתח מחדש את הבעיה .
כאשר בעיה חוזרת, אנו שולחים התראת זיהוי רגרסיה ומוסיפים אות רגרסיה לבעיה כדי ליידע אותך ש-Crashlytics פתחה מחדש את הבעיה. אם אינך רוצה שבעיה תיפתח מחדש עקב אלגוריתם הרגרסיה שלנו, "השתיק" את הבעיה במקום לסגור אותה.
אם דוח הוא מגרסת אפליקציה ישנה שמעולם לא שלחה דוחות קריסה בכלל כשסגרת את הבעיה, אז Crashlytics מחשיבה את הבעיה כנסגרת ותפתח את הבעיה מחדש.
מצב זה יכול לקרות במצב הבא: תיקנת באג והוצאת גרסה חדשה של האפליקציה שלך, אבל עדיין יש לך משתמשים בגרסאות ישנות יותר ללא תיקון הבאג. אם, במקרה, אחת מאותן גרסאות ישנות יותר מעולם לא שלחה דוחות קריסה בכלל כשסגרת את הבעיה, והמשתמשים האלה מתחילים להיתקל בבאג, אז דוחות קריסה אלה היו מפעילים בעיה שנגרמה.
אם אינך רוצה שבעיה תיפתח מחדש עקב אלגוריתם הרגרסיה שלנו, "השתיק" את הבעיה במקום לסגור אותה.
דיווח על חריגים שלא נתפסו כקטלנים
Crashlytics יכולים לדווח על חריגים שלא נתפסו כקטלים (החל מגרסה 10.4.0 של Unity SDK). השאלות הנפוצות הבאות עוזרות להסביר את הרציונל והשיטות המומלצות לשימוש בתכונה זו.
על ידי דיווח על חריגים שלא נתפסו כקטלים, אתה מקבל אינדיקציה מציאותית יותר לאילו חריגים עלולים לגרום לכך שהמשחק לא ניתן לשחק - גם אם האפליקציה תמשיך לפעול.
שים לב שאם תתחיל לדווח על קטלניות, סביר להניח שאחוז המשתמשים ללא התרסקות (CFU) שלך יקטן, אבל מדד CFU יהיה מייצג יותר את חוויות משתמשי הקצה עם האפליקציה שלך.
כדי ש-Crashlytics ידווח על חריגה שלא נתפסה כקטלנית, שני התנאים הבאים חייבים להתקיים:
במהלך האתחול באפליקציה שלך, המאפיין
ReportUncaughtExceptionsAsFatal
חייב להיות מוגדר כ-true
.האפליקציה שלך (או ספרייה כלולה) זורקת חריג שלא נתפס. חריג שנוצר, אך לא נזרק , אינו נחשב ללא נתפס.
כאשר אתה מתחיל לקבל דיווחים על חריגים שלא נתפסו כקטלים, הנה כמה אפשרויות לטיפול בחריגים שלא נתפסו:
- שקול כיצד תוכל להתחיל לתפוס ולטפל בחריגים שלא נתפסו.
- שקול אפשרויות שונות לרישום חריגים למסוף ניפוי באגים של Unity ול-Crashlytics.
לתפוס ולטפל בחריגים שנזרקו
חריגים נוצרים ונזרקים כדי לשקף מצבים בלתי צפויים או חריגים . פתרון הבעיות המשתקפות מחריג שנזרק כרוך בהחזרת התוכנית למצב ידוע (תהליך המכונה טיפול בחריגים ).
השיטה הטובה ביותר היא לתפוס ולטפל בכל החריגים הצפויים, אלא אם לא ניתן להחזיר את התוכנית למצב ידוע.
כדי לשלוט אילו סוגי חריגים נתפסים ומטופלים על ידי איזה קוד, עטוף קוד שעשוי ליצור חריג בבלוק try-catch
. ודא שהתנאים בהצהרות catch
צרים ככל האפשר כדי לטפל בחריגים הספציפיים כראוי.
רישום חריגים ב-Unity או Crashlytics
ישנן מספר דרכים להקליט חריגים ב-Unity או Crashlytics כדי לסייע באיתור באגים.
בעת שימוש ב-Crashlytics, הנה שתי האפשרויות הנפוצות והמומלצות ביותר:
אפשרות 1: הדפס במסוף Unity, אך אל תדווח ל-Crashlytics, במהלך פיתוח או פתרון בעיות
- הדפס למסוף Unity באמצעות
Debug.Log(exception)
,Debug.LogWarning(exception)
ו-Debug.LogError(exception)
אשר מדפיסים את תוכן החריגה למסוף Unity ואינם זורקים מחדש את החריגה.
- הדפס למסוף Unity באמצעות
אפשרות 2: העלה ל-Crashlytics לדיווח מאוחד במרכז השליטה של Crashlytics במצבים הבאים:
- אם חריגה שווה רישום כדי לנפות באגים אפשרי של אירוע Crashlytics לאחר מכן, השתמש
Crashlytics.Log(exception.ToString())
. - אם עדיין יש לדווח על חריגה ל-Crashlytics למרות שנתפס וטופל, השתמש
Crashlytics.LogException(exception)
כדי לרשום אותו כאירוע לא קטלני.
- אם חריגה שווה רישום כדי לנפות באגים אפשרי של אירוע Crashlytics לאחר מכן, השתמש
עם זאת, אם ברצונך לדווח באופן ידני על אירוע קטלני ל- Unity Cloud Diagnostics, תוכל להשתמש Debug.LogException
. אפשרות זו מדפיסה את החריג לקונסולת Unity כמו אפשרות 1, אבל היא גם זורקת את החריג (בין אם הוא נזרק או לא נתפס עדיין). זה זורק את השגיאה באופן לא מקומי. זה אומר שאפילו Debug.LogException(exception)
שמסביב עם בלוקים של try-catch
עדיין מביא לחריג שלא נתפס.
לכן, התקשר 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
//
}