דף זה תורגם על ידי Cloud Translation API.

שאלות נפוצות ופתרון בעיות ב-Crashlytics

בדף הזה תוכלו למצוא עזרה בפתרון בעיות ותשובות לשאלות נפוצות על השימוש ב-Crashlytics. אם לא מצאתם את מה שחיפשתם או שאתם צריכים עזרה נוספת, אתם יכולים לפנות לתמיכה של Firebase.

פתרון בעיות כלליות/שאלות נפוצות

רואים פורמטים שונים (ולפעמים 'וריאציות') של חלק מהבעיות בטבלה Issues (בעיות)

יכול להיות שתבחינו בשני פורמטים שונים של בעיות שמופיעות בטבלה בעיות במסוף Firebase. יכול להיות שתבחינו גם בתכונה שנקראת 'וריאציות' בחלק מהבעיות. הנה הסיבות:

בתחילת 2023 השקנו מנוע ניתוח משופר לקיבוץ אירועים, עיצוב מעודכן וכמה תכונות מתקדמות לבעיות חדשות (כמו וריאציות!). בפוסט האחרון בבלוג אפשר לקרוא את כל הפרטים, אבל בהמשך מופיעים עיקרי הדברים.

‫Crashlytics מנתח את כל האירועים מהאפליקציה (כמו קריסות, אירועים לא קריטיים ומקרי ANR) ויוצר קבוצות של אירועים שנקראות בעיות – לכל האירועים בבעיה יש נקודת כשל משותפת.

כדי לקבץ אירועים לבעיות האלה, מנוע הניתוח המשופר בודק עכשיו היבטים רבים של האירוע, כולל המסגרות במעקב אחר מחסנית, הודעת החריגה, קוד השגיאה ומאפיינים אחרים של הפלטפורמה או של סוג השגיאה.

עם זאת, בתוך קבוצת האירועים הזו, יכול להיות שדוחות הקריסות שמובילים לכשל יהיו שונים. דוח קריסה שונה יכול להצביע על סיבת שורש שונה. כדי לייצג את ההבדל האפשרי הזה בתוך בעיה, אנחנו יוצרים עכשיו וריאציות בתוך בעיות – כל וריאציה היא קבוצת משנה של אירועים בבעיה שיש להם אותה נקודת כשל ו עקבות מחסנית דומים. באמצעות וריאציות, אפשר לנפות באגים במעקב אחר מחסנית (stack trace) הנפוץ ביותר בבעיה, ולקבוע אם סיבות שורש שונות מובילות לכשל.

אלה השיפורים שתוכלו לראות:

מטא-נתונים משופרים שמוצגים בשורת הבעיה
עכשיו קל יותר להבין את הבעיות באפליקציה ולסווג אותן.
פחות בעיות כפולות
שינוי במספר השורה לא גורם ליצירת בעיה חדשה.
ניפוי באגים קל יותר בבעיות מורכבות עם מגוון סיבות שורש
אפשר להשתמש בווריאציות כדי לנפות באגים במעקב אחר מחסנית (stack trace) הנפוץ ביותר בבעיה.
התראות וסיגנלים משמעותיים יותר
בעיה חדשה מייצגת באג חדש.
חיפוש יעיל יותר
כל בעיה מכילה יותר מטא-נתונים שאפשר לחפש, כמו סוג החריגה ושם החבילה.

כך מתבצעת ההשקה של השיפורים האלה:

כשנקבל אירועים חדשים מהאפליקציה, נבדוק אם הם תואמים לבעיה קיימת.
אם אין התאמה, נחיל באופן אוטומטי על האירוע את האלגוריתם החכם יותר שלנו לקיבוץ אירועים, וניצור בעיה חדשה עם עיצוב המשופר של המטא-נתונים.

זהו העדכון הגדול הראשון שאנחנו מבצעים לקיבוץ האירועים. אם יש לכם משוב או נתקלתם בבעיות, אתם מוזמנים לשלוח לנו דיווח.

לא רואים יומנים של נתיבי מיקום

אם לא מוצגים יומני נתיב, מומלץ לבדוק את ההגדרה של האפליקציה ל-Google Analytics. צריך לעמוד בדרישות הבאות:

הפעלת Google Analytics בפרויקט Firebase.
הפעלתם את שיתוף הנתונים עבור Google Analytics. מידע נוסף על ההגדרה הזו זמין במאמר ניהול של הגדרות שיתוף הנתונים מ-Analytics
הוספת את Firebase SDK ל-Google Analytics לאפליקציה. צריך להוסיף את ה-SDK הזה בנוסף ל-Crashlytics SDK.
אתם משתמשים ב גרסאות העדכניות ביותר של Firebase SDK לכל המוצרים שבהם אתם משתמשים באפליקציה.

לא רואים התראות על מהירות

אם לא מוצגים לכם התראות על מהירות, ודאו שאתם משתמשים בגרסה Crashlytics SDK 11.7.0+.

לא רואים מדדים לגבי אפליקציות שלא קורסות (או רואים מדדים לא מהימנים)

אם אתם לא רואים מדדים שקשורים לבעיות קריסה (כמו משתמשים וסשנים ללא קריסה) או שאתם רואים מדדים לא מהימנים, כדאי לבדוק את הדברים הבאים:

חשוב לוודא שאתם משתמשים בגרסהCrashlytics SDK 11.7.0 ואילך.
חשוב לוודא שהגדרות איסוף הנתונים לא משפיעות על האיכות של מדדי הנתונים ללא קריסה:
- אם מפעילים דיווח על הסכמה על ידי השבתת הדיווח האוטומטי על קריסות, אפשר לשלוח מידע על קריסות אל Crashlytics רק ממשתמשים שהביעו הסכמה מפורשת לאיסוף נתונים. לכן, הדיוק של מדדים שקשורים לקריסות יושפע כי ל-Crashlytics יש מידע על קריסות רק מהמשתמשים שהביעו הסכמה (ולא מכל המשתמשים). המשמעות היא שהמדדים של אפליקציות ללא קריסות עשויים להיות פחות מהימנים ופחות משקפים את היציבות הכוללת של האפליקציה.
- אם השבתתם את האיסוף האוטומטי של נתונים, אתם יכולים להשתמש ב-sendUnsentReports כדי לשלוח ל-Crashlytics דוחות שמאוחסנים במטמון במכשיר. השימוש בשיטה הזו ישלח נתוני קריסות אל Crashlytics, אבל לא נתוני סשנים, ולכן בתרשימים של המסוף יוצגו ערכים נמוכים או אפס למדדים של אפליקציות שלא קורסות.

איך מחושב שיעור המשתמשים ללא קריסות?

מידע על מדדים שקשורים לאפליקציות שלא קורסות

הצגת דוחות קריסות לא מסומלים של אפליקציות ל-Android בלוח הבקרה Crashlytics

אם אתם משתמשים ב-Unity IL2CPP ואתם רואים מעקב אחר מחסנית שלא עבר סימון, נסו את הפעולות הבאות:

מוודאים שמשתמשים בגרסה v8.6.1 ואילך של Crashlytics Unity SDK.
חשוב לוודא שהגדרתם את הפקודה Firebase ב-CLI crashlytics:symbols:upload ושהיא פועלת כדי ליצור ולהעלות את קובץ הסמלים.

צריך להריץ את פקודת ה-CLI הזו בכל פעם שיוצרים גרסת הפצה או כל גרסה אחרת שרוצים לראות בה את עקבות המחסנית עם הסימבולים במסוף Firebase. מידע נוסף זמין בדף קבלת דוחות קריסה קריאים.

האם אפשר להשתמש ב-Crashlytics עם אפליקציות שמשתמשות ב-IL2CPP?

כן, Crashlytics יכול להציג עקבות מחסנית עם סימבולים לאפליקציות שמשתמשות ב-IL2CPP. היכולת הזו זמינה באפליקציות שפורסמו בפלטפורמות Android או Apple. כך עושים זאת:

מוודאים שמשתמשים בגרסה 8.6.0 ואילך של Crashlytics Unity SDK.
משלימים את המשימות הנדרשות בפלטפורמה שלכם:
- באפליקציות לפלטפורמת Apple: לא נדרשות פעולות מיוחדות. באפליקציות לפלטפורמת Apple, התוסף Firebase Unity Editor מגדיר באופן אוטומטי את פרויקט Xcode להעלאת סמלים.
- באפליקציות ל-Android: מוודאים שהגדרתם את הפקודה Firebase CLI crashlytics:symbols:upload ושהיא פועלת כדי ליצור ולהעלות את קובץ הסמלים.
  
  צריך להריץ את פקודת ה-CLI הזו בכל פעם שיוצרים גרסת הפצה או כל גרסה אחרת שרוצים לראות בה את עקבות המחסנית עם הסימבולים במסוף Firebase. מידע נוסף זמין בדף קבלת דוחות קריסה קריאים.

מי יכול לראות, לכתוב ולמחוק הערות בבעיה?

הערות מאפשרות לחברי הפרויקט להגיב על בעיות ספציפיות עם שאלות, עדכוני סטטוס וכו'.

כשחבר בפרויקט מפרסם הערה, היא מסומנת בתווית עם כתובת האימייל של חשבון Google שלו. כתובת האימייל הזו גלויה, יחד עם ההערה, לכל חברי הפרויקט שיש להם גישה לצפייה בהערה.

בהמשך מפורטות הרשאות הגישה שנדרשות כדי להציג, לכתוב ולמחוק הערות:

חברי פרויקט עם אחד מהתפקידים הבאים יכולים לראות ולמחוק הערות קיימות ולכתוב הערות חדשות בבעיה.
- בעלים או עורך של הפרויקט, אדמין ב-Firebase, אדמין של איכות, או אדמין של Crashlytics
חברי פרויקט עם אחד מהתפקידים הבאים יכולים לראות את ההערות שפורסמו בבעיה, אבל הם לא יכולים למחוק או לכתוב הערה.
- בעל הרשאת צפייה בפרויקט, בעל הרשאת צפייה ב-Firebase, בעל הרשאת צפייה באיכות או בעל הרשאת צפייה ב-Crashlytics

שילובים

באפליקציה נעשה שימוש גם ב-SDK‏ Google Mobile Ads, אבל לא מתרחשות קריסות

אם אתם משתמשים ב-Crashlytics בפרויקט שלכם לצד Google Mobile Ads SDK, סביר להניח שדוחות הקריסה מפריעים בזמן רישום של מטפלי חריגים. כדי לפתור את הבעיה, צריך להשבית את הדיווח על קריסות ב-SDK של Mobile Ads באמצעות הקריאה disableSDKCrashReporting.

איפה נמצא מערך הנתונים שלי ב-BigQuery?

אחרי שמקשרים את Crashlytics ל-BigQuery, מערכי נתונים חדשים שיוצרים ממוקמים באופן אוטומטי בארצות הברית, ללא קשר למיקום של פרויקט Firebase.

בעיות שחזרו

מהי בעיה שחלה בה רגרסיה?

בעיה שסגרתם בעבר חזרה, וקיבלתם דיווח חדש על כך שהיא התרחשה שוב.Crashlytics Crashlytics פותחת מחדש באופן אוטומטי את הבעיות האלה שחזרו, כדי שתוכלו לטפל בהן בהתאם לאפליקציה שלכם.

הנה תרחיש לדוגמה שמסביר איך Crashlytics מסווג בעיה כרגרסיה:

בפעם הראשונה, Crashlytics מקבל דוח קריסה על קריסה מספר A. Crashlytics נפתחת בעיה תואמת לקריסה (בעיה A).
אתם מתקנים את הבאג הזה במהירות, סוגרים את הבעיה 'א' ומפרסמים גרסה חדשה של האפליקציה.
Crashlytics מקבל דיווח נוסף על בעיה א' אחרי שסגרתם את הבעיה.
- אם הדוח הוא מגרסת אפליקציה ש-Crashlytics ידע עליה כשסגרת את הבעיה (כלומר, הגרסה שלחה דוח קריסה על כל קריסה שהתרחשה), אז Crashlytics לא יתייחס לבעיה כאל רגרסיה. הבעיה תישאר סגורה.
- אם הדוח הוא מגרסת אפליקציה שCrashlytics לא הייתה מודעת לבעיה כשסגרתם אותה (כלומר, הגרסה מעולם לא שלחה אף דוח קריסה לגבי קריסה כלשהי), אז Crashlytics תראה את הבעיה כרגרסיה ותפתח אותה מחדש.

אם בעיה חוזרת, אנחנו שולחים התראה על זיהוי רגרסיה ומוסיפים אות רגרסיה לבעיה כדי להודיע לכם ש-Crashlytics פתח מחדש את הבעיה. אם אתם לא רוצים שבעיה תיפתח מחדש בגלל אלגוריתם הרגרסיה שלנו, אתם יכולים להשתיק את הבעיה במקום לסגור אותה.

למה אני רואה בעיות שחזרו בגרסאות קודמות של האפליקציה?

אם הדוח הוא מגרסה ישנה של האפליקציה שמעולם לא שלחה דוחות קריסה כשסגרתם את הבעיה, מערכת Crashlytics תראה שהבעיה חזרה ותפתח אותה מחדש.

מצב כזה יכול לקרות במקרה הבא: תיקנתם באג ופרסמתם גרסה חדשה של האפליקציה, אבל עדיין יש משתמשים בגרסאות ישנות יותר שלא כוללות את תיקון הבאג. אם במקרה אחת מהגרסאות הישנות האלה מעולם לא שלחה דוחות קריסה כשסגרתם את הבעיה, והמשתמשים האלה מתחילים להיתקל בבאג, דוחות הקריסה האלה יפעילו בעיה שחזרה.

אם אתם לא רוצים שהבעיה תיפתח מחדש בגלל אלגוריתם הרגרסיה שלנו, אתם יכולים להשתיק את הבעיה במקום לסגור אותה.

דיווח על חריגים שלא נתפסו כחריגים קריטיים

‫Crashlytics יכול לדווח על חריגים שלא נתפסו כשגיאות קריטיות (החל מגרסה v10.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 ולא מעבירים מחדש את החריגה.
אפשרות 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(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
    //
}