בדף הזה מפורטת עזרה בפתרון בעיות ותשובות לשאלות נפוצות בנושא השימוש ב-Crashlytics. אם לא מצאתם את מה שחיפשת או אם אתם זקוקים לעזרה נוספת, תוכלו לפנות אל התמיכה של Firebase.
פתרון בעיות כלליות/שאלות נפוצות
פורמטים שונים (ולפעמים 'וריאנטים') של בעיות מסוימות בטבלה בעיות
יכול להיות שתבחינו בשני פורמטים שונים של בעיות שמופיעות בטבלה בעיות במסוף Firebase. יכול להיות שתבחינו גם בתכונה שנקראת 'וריאנטים' בחלק מהבעיות. זו הסיבה!
בתחילת 2023 השקנו מנוע ניתוח משופר לקיבוץ אירועים, עיצוב מעודכן ותכונות מתקדמות לבעיות חדשות (כמו וריאנטים). כל הפרטים מפורטים בפוסט הזה בבלוג, אבל בהמשך מפורטים הדברים העיקריים.
Crashlytics מנתח את כל האירועים מהאפליקציה (כמו קריסות, אירועים לא קטלניים ומקרי ANR) ויוצר קבוצות של אירועים שנקראות בעיות – לכל האירועים בבעיה יש נקודת כשל משותפת.
כדי לקבץ אירועים לבעיות האלה, מנוע הניתוח המשופר בוחן עכשיו היבטים רבים של האירוע, כולל המסגרות בניתוח סטאק, הודעת החריגה, קוד השגיאה ומאפיינים אחרים של פלטפורמה או של סוג השגיאה.
עם זאת, בתוך קבוצת האירועים הזו, יכול להיות שנתוני מעקב הסטאק שיובילו לכשלים יהיו שונים. אם דוח אחר של נתוני סטאק יהיה שונה, יכול להיות שמדובר בגורם אחר לבעיה.
כדי לייצג את ההבדל האפשרי הזה בתוך בעיה, אנחנו יוצרים עכשיו וריאנטים בתוך בעיות – כל וריאנט הוא קבוצת משנה של אירועים בבעיה שיש להם את אותו נקודת כשל וגם נתיב סטאק דומה. בעזרת וריאנטים, תוכלו לנפות באגים בנתוני המעקב הנפוצים ביותר בבעיה ולבדוק אם יש סיבות שונות לבעיה.
אלה השיפורים שתוכלו ליהנות מהם:
מטא-נתונים מעודכנים שמוצגים בשורת הבעיה עכשיו קל יותר להבין את הבעיות באפליקציה ולתעדף אותן.
פחות בעיות כפולות שינוי של מספר שורה לא יוצר בעיה חדשה.
ניפוי באגים קל יותר של בעיות מורכבות עם גורמי שורש שונים אפשר להשתמש בוריאנטים כדי לנפות באגים בנתוני המעקב הנפוצים ביותר בבעיה.
התראות וסמנים משמעותיים יותר בעיה חדשה היא למעשה באג חדש.
חיפוש יעיל יותר כל בעיה מכילה יותר מטא-נתונים שאפשר לחפש, כמו סוג החריגה ושם החבילה.
כך השיפורים האלה ייכנסו לתוקף:
כשנקבל אירועים חדשים מהאפליקציה שלכם, נבדוק אם הם תואמים לבעיה קיימת.
אם לא נמצאה התאמה, נחיל באופן אוטומטי על האירוע את האלגוריתם החכם יותר שלנו לקיבוץ אירועים, ונוצר בעיה חדשה עם העיצוב המחודש של המטא-נתונים.
זהו העדכון המשמעותי הראשון שאנחנו מבצעים לקיבוץ האירועים. אם יש לכם משוב או אם נתקלת בבעיות, אפשר
לשלוח דיווח
.
לא מוצגים מדדים של נסיעות ללא תאונות או התראות על מהירות
אם המדדים של'ללא קריסות' (כמו משתמשים וסשנים ללא קריסות) ו/או ההתראות לגבי מהירות לא מוצגים, צריך לוודא שאתם משתמשים ב-
Crashlytics SDK 11.7.0 ואילך.
היומנים של נתיבי הניווט לא מוצגים
אם יומני הלחם לא מופיעים, מומלץ לבדוק את ההגדרות של האפליקציה לגבי Google Analytics.
צריך לעמוד בדרישות הבאות:
הצגת מעקב סטאק ללא סימון לאפליקציות ל-Android בלוח הבקרה Crashlytics
אם אתם משתמשים ב-Unity IL2CPP ורואים מעקבים אחרי סטאק ללא סימון, נסו את הפעולות הבאות:
עליכם לוודא שאתם משתמשים בגרסה 8.6.1 ואילך של Unity SDK Crashlytics.
חשוב לוודא שהגדרתם את הפקודה crashlytics:symbols:upload ב-CLI של Firebase ושהיא פועלת כדי ליצור ולהעלות את קובץ הסמלים.
צריך להריץ את הפקודה הזו במסוף בכל פעם שיוצרים גרסה זמינה ל-build או כל build שרוצים לראות בו מעקב סמלי אחר סטאק במסוף Firebase. מידע נוסף זמין בדף קבלת דוחות קריסה שניתנים לקריאה.
האם אפשר להשתמש ב-Crashlytics עם אפליקציות שמשתמשות ב-IL2CPP?
כן, אפשר להשתמש ב-Crashlytics כדי להציג מעקב סמלי אחרי סטאק באפליקציות שמשתמשות ב-IL2CPP. היכולת הזו זמינה לאפליקציות שפורסמו בפלטפורמות Android או Apple. כך עושים זאת:
חשוב לוודא שאתם משתמשים ב-Unity SDK של Crashlytics בגרסה 8.6.0 ואילך.
משלימים את המשימות הנדרשות לפלטפורמה:
באפליקציות לפלטפורמת Apple: לא נדרשות פעולות מיוחדות. באפליקציות לפלטפורמות של Apple, הפלאגין של Firebase Unity Editor מגדיר באופן אוטומטי את הפרויקט ב-Xcode להעלאת סמלים.
לאפליקציות ל-Android: מוודאים שהגדרתם את הפקודה crashlytics:symbols:upload ב-CLI של Firebase והפעלתם אותה כדי ליצור את קובץ הסמלים ולהעלות אותו.
צריך להריץ את הפקודה הזו במסוף בכל פעם שיוצרים גרסה זמינה ל-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% (משתמש אחד מתוך שניים לא חווה קריסה). שניים מהמשתמשים שלכם קיימו אינטראקציה עם האפליקציה ביום רביעי, אבל רק אצל אחד מהם (משתמש ב') לא היו קריסות.
ב-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 פותח את הבעיה התואמת לקריסה הזו (בעיה 'א').
אתם מתקנים את הבאג במהירות, סוגרים את הבעיה 'א' ומפיצים גרסה חדשה של האפליקציה.
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//}
