בדף הזה מפורטת עזרה בפתרון בעיות ותשובות לשאלות נפוצות בנושא השימוש ב-Crashlytics. אם לא מצאתם את מה שחיפשת או אם אתם זקוקים לעזרה נוספת, תוכלו לפנות אל התמיכה של Firebase.
פתרון בעיות כלליות/שאלות נפוצות
פורמטים שונים (ולפעמים 'וריאנטים') של בעיות מסוימות בטבלה בעיות
יכול להיות שתבחינו בשני פורמטים שונים של בעיות שמופיעות בטבלה בעיות במסוף Firebase. יכול להיות שתבחינו גם בתכונה שנקראת 'וריאנטים' בחלק מהבעיות. זו הסיבה!
בתחילת 2023 השקנו מנוע ניתוח משופר לקיבוץ אירועים, וגם עיצוב מעודכן וכמה תכונות מתקדמות לבעיות חדשות (כמו וריאציות!). כל הפרטים מפורטים בפוסט הזה בבלוג, אבל בהמשך מפורטים הדברים העיקריים.
Crashlytics מנתחת את כל האירועים מהאפליקציה (כמו קריסות, מקרים לא חמורים ומקרי ANR) ויוצרת קבוצות של אירועים שנקראים בעיות – לכל האירועים באותה בעיה יש נקודת כשל משותפת.
כדי לקבץ אירועים לבעיות האלה, מנוע הניתוח המשופר בוחן עכשיו היבטים רבים של האירוע, כולל המסגרות בניתוח סטאק, הודעת החריגה, קוד השגיאה ומאפיינים אחרים של פלטפורמה או של סוג השגיאה.
עם זאת, בקבוצת האירועים הזו, דוחות הקריסות שמובילים לכשל עשויים להיות שונים. אם דוח אחר של נתוני סטאק יהיה שונה, יכול להיות שמדובר בגורם אחר לבעיה.
כדי לייצג את ההבדל האפשרי הזה בתוך בעיה, אנחנו יוצרים עכשיו וריאנטים בתוך בעיות – כל וריאנט הוא קבוצת משנה של אירועים בבעיה שיש להם את אותו נקודת כשל וגם נתיב סטאק דומה. בעזרת הווריאנטים תוכלו לנפות באגים בנתוני המעקב הנפוצים ביותר בבעיה, ולבדוק אם יש סיבות שונות לבעיה.
אלה השיפורים שתוכלו ליהנות מהם:
מטא-נתונים מעודכנים שמוצגים בשורת הבעיה עכשיו קל יותר להבין את הבעיות באפליקציה ולתעדף אותן.
פחות בעיות כפולות שינוי של מספר השורה לא מוביל ליצירת בעיה חדשה.
ניפוי באגים קל יותר של בעיות מורכבות עם גורמי שורש שונים אפשר להשתמש בוריאנטים כדי לנפות באגים בנתוני המעקב הנפוצים ביותר בבעיה.
התראות וסמנים משמעותיים יותר בעיה חדשה היא בעצם באג חדש.
חיפוש יעיל יותר כל בעיה מכילה יותר מטא-נתונים שאפשר לחפש, כמו סוג החריגה ושם החבילה.
כך השיפורים האלה ייכנסו לתוקף:
כשנקבל אירועים חדשים מהאפליקציה, נבדוק אם הם תואמים לבעיה קיימת.
אם לא נמצאה התאמה, נחיל באופן אוטומטי על האירוע את האלגוריתם החכם יותר שלנו לקיבוץ אירועים, ונוצר בעיה חדשה עם העיצוב המחודש של המטא-נתונים.
זהו העדכון המשמעותי הראשון שאנחנו מבצעים לקיבוץ האירועים. אם יש לך משוב או אם נתקלת בבעיות, אפשר
לשלוח לנו דוח
.
לא מוצגים מדדים של נסיעות ללא תאונות או התראות על מהירות
אם המדדים של 'ללא קריסות' (כמו משתמשים וסשנים ללא קריסות) ו/או ההתראות לגבי מהירות לא מוצגים, צריך לוודא שאתם משתמשים ב-
Crashlytics SDK 11.7.0 ואילך.
היומנים של נתיבי הניווט לא מוצגים
אם יומני הלחם לא מופיעים, מומלץ לבדוק את ההגדרות של האפליקציה לגבי Google Analytics.
צריך לעמוד בדרישות הבאות:
מוצגים דוחות קריסות לא
מהאתר של אפליקציות ל-Android במרכז הבקרה של Crashlytics
אם אתם משתמשים ב-Unity IL2CPP ורואים מעקבים אחרי סטאק ללא סימון, נסו את הפעולות הבאות:
חשוב לוודא שאתם משתמשים בגרסה 8.6.1 ואילך של Crashlytics Unity SDK.
חשוב לוודא שהגדרתם את הפקודה crashlytics:symbols:upload ב-CLI של Firebase ושהיא פועלת כדי ליצור ולהעלות את קובץ הסמלים.
צריך להריץ את הפקודה הזו במסוף בכל פעם שיוצרים גרסה זמינה ל-build או כל build שרוצים לראות בו מעקב סמלי אחר סטאק במסוף Firebase. מידע נוסף זמין בדף קבלת דוחות קריסה שניתנים לקריאה.
האם אפשר להשתמש ב-Crashlytics עם אפליקציות שמשתמשות ב-IL2CPP?
כן, אפשר להשתמש ב-Crashlytics כדי להציג מעקב סמלי אחרי סטאק באפליקציות שמשתמשות ב-IL2CPP. היכולת הזו זמינה לאפליקציות שפורסמו בפלטפורמות Android או Apple. כך עושים זאת:
חשוב לוודא שאתם משתמשים בגרסה 8.6.0 ואילך של Crashlytics Unity SDK.
משלימים את המשימות הנדרשות לפלטפורמה:
באפליקציות לפלטפורמת Apple: לא נדרשות פעולות מיוחדות. באפליקציות לפלטפורמות של Apple, הפלאגין של Firebase Unity Editor מגדיר באופן אוטומטי את הפרויקט ב-Xcode להעלאת סמלים.
לאפליקציות ל-Android: מוודאים שהגדרתם את הפקודה crashlytics:symbols:upload ב-CLI של Firebase והפעלתם אותה כדי ליצור את קובץ הסמלים ולהעלות אותו.
צריך להריץ את פקודת ה-CLI הזו בכל פעם שיוצרים גרסת build של גרסה או כל build שעבורו רוצים לראות דוחות קריסות סימבוליים במסוף Firebase. מידע נוסף זמין בדף קבלת דוחות קריסה שניתנים לקריאה.
איך מחושבים המשתמשים ללא קריסות?
הערך 'ללא קריסות' מייצג את אחוז המשתמשים שהיו להם אינטראקציות עם האפליקציה אבל לא התרחשה קריסה אצלם בפרק זמן ספציפי.
זו הנוסחה לחישוב אחוז המשתמשים ללא קריסות. ערכי הקלט שלו מסופקים על ידי Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100
כשמתרחשת קריסה, Google Analytics שולח סוג אירוע app_exception ו-CRASHED_USERS מייצג את מספר המשתמשים שמשויכים לסוג האירוע הזה.
הערך ALL_USERS מייצג את המספר הכולל של המשתמשים שהיו להם אינטראקציות עם האפליקציה שלכם במהלך תקופת הזמן שבחרתם בתפריט הנפתח בפינה השמאלית העליונה של לוח הבקרה Crashlytics.
אחוז המשתמשים ללא קריסות הוא צבירה לאורך זמן, ולא ממוצע.
לדוגמה, נניח שיש באפליקציה שלכם שלושה משתמשים. נקרא להם משתמש א', משתמש ב' ומשתמש ג'. בטבלה הבאה מוצגים המשתמשים שהתעניינו באפליקציה בכל יום, ואלה מביניהם שחלה אצלם קריסה באותו יום:
שני
שלישי
רביעי
משתמשים שהיו להם אינטראקציות עם האפליקציה
א', ב', ג'
א', ב', ג'
א', ב'
משתמש שחלה בו קריסה
C
B
A
ביום רביעי, אחוז המשתמשים שלא חוו קריסות הוא 50% (1 מתוך 2 משתמשים היה ללא קריסות). שניים מהמשתמשים שלכם קיימו אינטראקציה עם האפליקציה ביום רביעי, אבל רק אצל אחד מהם (משתמש ב') לא היו קריסות.
ב-2 הימים האחרונים, אחוז המשתמשים שלא חוו קריסה הוא 33.3% (משתמש אחד מתוך 3 לא חווה קריסה). שלושה מהמשתמשים שלכם היו פעילים באפליקציה בימים האחרונים, אבל רק אצל אחד מהם (משתמש ג') לא היו קריסות.
ב-3 הימים האחרונים, אחוז המשתמשים שהאפליקציה שלהם לא קרסה הוא 0% (0 מתוך 3 משתמשים לא חוו קריסה). שלושה מהמשתמשים שלכם היו פעילים באפליקציה ב-3 הימים האחרונים, אבל אף אחד מהם לא דיווח על קריסה.
אין להשוות את הערך 'משתמשים ללא קריסות' בין תקופות זמן שונות.
ככל שמשתמש יחיד משתמש באפליקציה יותר פעמים, כך עולה הסבירות שהוא יחווה קריסה. לכן, סביר להניח שהערך של משתמשים ללא קריסות יהיה נמוך יותר בפרקי זמן ארוכים יותר.
מי יכול לראות, לכתוב ולמחוק הערות בבעיה?
הערות מאפשרות לחברי הפרויקט להגיב על בעיות ספציפיות לגבי שאלות, עדכוני סטטוס וכו'.
כשחבר בצוות פרויקט מפרסם הערה, היא מסומנת בכתובת האימייל של חשבון Google שלו. כתובת האימייל הזו, יחד עם ההערה, גלויות לכל חברי הפרויקט שיש להם גישה להערה.
בהמשך מפורטות ההרשאות הנדרשות כדי להציג, לכתוב ולמחוק הערות:
חברי צוות בפרויקט עם אחד מהתפקידים הבאים יכולים להציג ולמחוק הערות קיימות ולכתוב הערות חדשות בבעיה.
הערות מאפשרות לחברי הפרויקט להגיב על בעיות ספציפיות לגבי שאלות, עדכוני סטטוס וכו'.
כשחבר בצוות פרויקט מפרסם הערה, היא מסומנת בכתובת האימייל של חשבון Google שלו. כתובת האימייל הזו, יחד עם ההערה, גלויות לכל חברי הפרויקט שיש להם גישה להערה.
בהמשך מפורטות ההרשאות הנדרשות כדי להציג, לכתוב ולמחוק הערות:
חברי צוות בפרויקט עם אחד מהתפקידים הבאים יכולים להציג ולמחוק הערות קיימות ולכתוב הערות חדשות בבעיה.
באפליקציה נעשה שימוש גם ב-SDK של Google Mobile Ads, אבל לא מתרחשות קריסות
אם בפרויקט שלכם נעשה שימוש ב-Crashlytics לצד ה-SDK של Google Mobile Ads, סביר להניח שדיווחי הקריסות מפריעים לרישום של מנהלי החריגות. כדי לפתור את הבעיה, אפשר להשבית את דיווח הקריסה ב-SDK Mobile Ads על ידי קריאה ל-disableSDKCrashReporting.
איפה נמצא מערך הנתונים שלי ב-BigQuery?
אחרי שמקשרים את Crashlytics ל-BigQuery, מערכי נתונים חדשים שיצרתם ממוקמים באופן אוטומטי בארצות הברית, ללא קשר למיקום של פרויקט Firebase.
בעיות שחוזרות
מהי בעיה של רגרסיה?
הבעיה חוזרת אם סגרתם אותה בעבר אבל קיבלתם דיווח חדש על כך שהיא חוזרת Crashlytics.
Crashlytics פותח מחדש באופן אוטומטי את הבעיות האלה כדי שתוכלו לטפל בהן בהתאם לאפליקציה שלכם.
לפניכם תרחיש לדוגמה שמסביר איך Crashlytics מסווג בעיה כרגרסיה:
בפעם הראשונה, Crashlytics מקבל דוח קריסה לגבי 'תאונה א'. Crashlytics פותח בעיה תואמת לקריסה הזו (בעיה 'A').
אתם מתקנים את הבאג במהירות, סוגרים את הבעיה 'א' ומפיצים גרסה חדשה של האפליקציה.
Crashlytics מקבל דיווח נוסף על בעיה 'א' אחרי שסגרתם את הבעיה.
אם הדוח מגיע מגרסה של האפליקציה ש-Crashlyticsידעה עליה כשסגרתם את הבעיה (כלומר, הגרסה שלחה דוח קריסה לגבי כל קריסה), Crashlytics לא תתייחס לבעיה כאל חזרה לאחור. הבעיה תישאר סגורה.
אם הדוח מגיע מגרסה של האפליקציה ש-Crashlyticsלא ידעה עליה כשסגרתם את הבעיה (כלומר, הגרסה אף פעם לא שלחה אף דוח קריסה לגבי קריסה כלשהי), Crashlytics תתייחס לבעיה כאל חזרה לאחור ותפתח מחדש את הבעיה.
כשבעיה ברגרסיה, אנחנו שולחים התראה על זיהוי רגרסיה ומוסיפים אות רגרסיה לבעיה כדי להודיע לכם שהבעיה נפתחה מחדש על ידי Crashlytics. אם אתם לא רוצים שבעיה מסוימת תיפתח מחדש עקב אלגוריתם הרגרסיה שלנו, תוכלו "להשתיק" את הבעיה במקום לסגור אותה.
למה אני רואה בעיות מסוג רגרסיה
בגרסאות ישנות יותר של האפליקציה?
אם דוח מסוים מגיע מגרסה ישנה של האפליקציה שאף פעם לא שלחו דוחות קריסה כשסגרת את הבעיה, Crashlytics יתייחס לבעיה כחזרה לגרסה הקודמת שלה ויפתח מחדש את הבעיה.
המצב הזה יכול לקרות במצב הבא: תיקנתם באג ושחררתם גרסה חדשה של האפליקציה, אבל עדיין יש משתמשים בגרסאות ישנות יותר של האפליקציה בלי תיקון הבאג. אם במקרה אחת מהגרסאות הישנות האלה אף פעם לא שלחה דוחות קריסה כשסגרתם את הבעיה, והמשתמשים האלה מתחילים להיתקל בבאג, דוחות הקריסה האלה יגרמו לבעיה של נסיגה.
אם אתם לא רוצים שהבעיה תיפתח מחדש בגלל אלגוריתם הרגרסיה שלנו, תוכלו להשתיק אותה במקום לסגור אותה.
דיווח על חריגות שלא נלכדו כחריגות קטלניות
Crashlytics יכול לדווח על חריגות שלא נלכדו כחריגות קריטיות (החל מ-v10.4.0 של Unity SDK). כדי להבין את ההיגיון מאחורי התכונה הזו ואת השיטות המומלצות לשימוש בה, כדאי לעיין בשאלות הנפוצות הבאות.
למה אפליקציה צריכה לדווח על חריגות שלא נלכדו כחריגות קריטיות?
דיווח על חריגות שלא תפסתם כחריגות קטלניות נותן לכם אינדיקציה מציאותית יותר לגבי החריגות שעלולות לגרום לכך שלא תהיה אפשרות לשחק במשחק – גם אם האפליקציה ממשיכה לפעול.
לתשומת ליבכם: אם תתחילו לדווח על אירועים קטלניים, סביר להניח שאחוז המשתמשים ללא קריסות (CFU) יקטן, אבל המדד CFU יהיה מייצג יותר את חוויית המשתמשים באפליקציה.
אילו חריגות ידווחו כקריטיות?
כדי ש-Crashlytics ידווח על חריגה שלא תפסה כחריגה קטלנית, צריכים להתקיים שני התנאים הבאים:
חריגות נוצרות ומשוחררות כדי לשקף מצבים לא צפויים או חריגים.
כדי לפתור את הבעיות שמוצגות על ידי חריגה שהושמה, צריך להחזיר את התוכנית למצב ידוע (תהליך שנקרא טיפול בחריגות).
מומלץ לזהות ולטפל בכל החריגות הצפויות, אלא אם אי אפשר להחזיר את התוכנית למצב ידוע.
כדי לקבוע אילו סוגים של חריגות יתגלו ויטופלו על ידי איזה קוד, צריך לעטוף קוד שעלול ליצור חריגה בבלוק try-catch.
חשוב לוודא שהתנאים במשפטי catch מצומצמים ככל האפשר כדי לטפל בחריגים הספציפיים בצורה מתאימה.
חריגים ביומן ב-Unity או Crashlytics
יש כמה דרכים לתעד חריגות ב-Unity או ב-Crashlytics כדי לעזור בניפוי הבאגים.
בהמשך מפורטות שתי האפשרויות הנפוצות והמומלצות ביותר לשימוש ב-Crashlytics:
אפשרות 1: הדפסה במסוף Unity, אבל לא לדווח ל-Crashlytics במהלך הפיתוח או פתרון הבעיות
הדפסה במסוף Unity באמצעות Debug.Log(exception), Debug.LogWarning(exception) ו-Debug.LogError(exception), שמדפיסות את תוכן החריגה במסוף Unity ולא גורמות להשלכת החריגה מחדש.
אפשרות 2: מעלים את הנתונים אל Crashlytics כדי לקבל דיווח מאוחד בלוח הבקרה של Crashlytics במקרים הבאים:
אם כדאי לתעד חריגה ביומן כדי לנפות באגים באירוע Crashlytics אפשרי שיתרחש לאחר מכן, צריך להשתמש ב-Crashlytics.Log(exception.ToString()).
אם עדיין צריך לדווח ל-Crashlytics על חריג כלשהו למרות שנתפסו וטופלו, אפשר להשתמש ב-Crashlytics.LogException(exception) כדי לתעד את החריגה כאירוע לא חמור.
עם זאת, אם רוצים לדווח באופן ידני על אירוע קטלני ל-Unity Cloud Diagnostics, אפשר להשתמש ב-Debug.LogException. האפשרות הזו מדפיסה את החריג במסוף Unity כמו אפשרות 1, אבל היא גם גורמת להשלכת החריג (גם אם הוא כבר הושלך או נתפס). היא גורמת להשלכת השגיאה באופן לא מקומי. כלומר, גם אם Debug.LogException(exception) מוקף בבלוקים של try-catch, עדיין תהיה חריגה לא מקובלת.
לכן, כדאי לקרוא ל-Debug.LogException אם ורק אם רוצים לבצע את כל הפעולות הבאות:
כדי להדפיס את החריג במסוף Unity.
כדי להעלות את החריגה אל Crashlytics כאירוע קטלני.
כדי להפעיל את החריג, צריך להתייחס אליו כאל חריג לא מזוהה ולדווח עליו ל-Unity Cloud Diagnostics.
שימו לב: אם רוצים להדפיס חריגה שנתפסה במסוף Unity וגם להעלות אותה אל Crashlytics כאירוע לא קטלני, צריך לבצע את הפעולות הבאות במקום זאת:
try{methodThatThrowsMyCustomExceptionType();}catch(MyCustomExceptionTypeexception){// 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//}
