ניפוי באגים ומקרי ANR

פתרון שגיאות ANR במשחק ל-Unity הוא תהליך מערכתי:

שילוב שירותי הדיווח

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

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

שילוב של ערכות SDK לדיווח לא משפיע על ביצועי המשחקים או על גודל ה-APK.

ניתוח סמלים

לנתח את הדוחות משירות הדיווח ולבדוק אם דוחות הקריסות הם בפורמט קריא לאנשים. למידע נוסף, אפשר לעיין בקטע סמלים של Android קריסות ושגיאות ANR במשחקי Unity לקבלת מידע נוסף.

איך בודקים את מזהה ה-build של הסמל

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

ב-Windows או ב-macOS:

1. מנווטים לתיקיית הסמלים על סמך הסקריפטים שלכם הקצה העורפי (ראו פתרון:)
   1. משתמשים בפקודה הבאה (ב-Windows, משתמשים בפקודה Cygwin כדי להריץ אותה הכלי readelf)
   2. השימוש ב-GRep הוא אופציונלי
   3. צריך לחפש את מזהה ה-Build

readelf -n libil2cpp.so | grep 'Build ID'
Build ID: b42473fb7449e44e0182dd1f580c99bab0cd8a95

בדיקת קוד המשחק

כשדוח הקריסות מציג פונקציה בספרייה libil2cpp.so, השגיאה אירעה בקוד C# , שמומר ל-C++. ספריית libil2cpp.so כוללת לא רק את קוד המשחק, אלא גם את יישומי הפלאגין והחבילות.

שם הקובץ C++ תואם לשם ההרכבה שהוגדר בפרויקט Unity. אחרת, לשם הקובץ יהיה שם ברירת המחדל Assembly-C# . לדוגמה, איור 3 מציג את השגיאה בקובץ Game.cpp (מודגשת בכחול), הוא השם שמוגדר בקובץ Assembly Definition. Logger הוא/היא שם הכיתה (מודגש באדום) בסקריפט C# , ואחריו שם הפונקציה (מודגש בירוק). לבסוף הוא השם המלא שנוצר על ידי ממיר IL2CPP (מודגש בכתום).

כדי לבדוק את קוד המשחק:

• בודקים אם יש קוד חשוד בפרויקט C# . בדרך כלל, C# לא מטופל החריגים לא יגרמו ל-ANR או לקריסה של אפליקציה. למרות זאת, ודאו שהקוד פועל כראוי במצבים שונים. בודקים אם הקוד משתמש במודול מנוע של צד שלישי, ובוחן אם הגרסה האחרונה הציגו את השגיאה. בנוסף, בודקים אם ביצעתם לאחרונה עדכון Unity או אם השגיאה מתרחשת רק במכשירים מסוימים.
• מייצאים את המשחק כפרויקט Android Studio. עם השלמה את הגישה לקוד המקור המומר של C# במשחק, אפשר למצוא את הפונקציה והיא הגורם ל-ANR. קוד C++ נראה שונה מאוד מקוד C# , ובהמרת הקוד יש בעיה רק לעיתים רחוקות. אם תמצאו משהו, פתחו כרטיס תמיכה של Unity.
• צריך לבדוק את קוד המקור של המשחק ולוודא שהלוגיקה פועלת OnApplicationFocus() ו-OnApplicationPause() מתבצע ניקוי של הקריאות החוזרות (callback).
  • למנוע Unity יש זמן קצוב להשהיית הביצוע. עומס עבודה יתר בקריאות החוזרות האלה עלול לגרום ל-ANR.
  • להוסיף יומנים או נתיבי ניווט לחלקים מהקוד כדי לשפר את ניתוח הנתונים.
• אפשר להשתמש ב-Unity Profiler כדי לחקור את המשחק או של ביצועים. יצירת פרופילים של האפליקציה יכולה גם להיות דרך מצוינת לזהות צווארי בקבוק שעלולים לגרום ל-ANR.
• דרך מצוינת לזהות פעולות קלט/פלט ארוכות ב-thread הראשי היא מחמיר.
• לנתח את מדדי התפקוד של Android או היסטוריית שירותי דיווח אחרת ולבדוק את לפרסם גרסאות של המשחק שבהן השגיאה מתרחשת הכי הרבה. צפייה את קוד המקור בהיסטוריה של בקרת הגרסאות ולהשוות בין שינויים בקוד בין הגרסאות. אם נתקלת במשהו חשוד, אפשר להתנסות בכל אחד מהם שינוי או תיקון אפשרי בנפרד.
• לעיין בהיסטוריית הדיווח על מקרי ANR ב-Google Play למכשירים ול-Android הגרסאות שבהן היו הכי הרבה מקרי ANR. אם המכשירים או הגרסאות מיושנים, סביר להניח שאפשר להתעלם מהם אם הם לא משפיעים על המשחק רווחיות. ללמוד את הנתונים בקפידה, מאחר שקבוצת משתמשים מסוימת לא יוכל יותר לשחק במשחק. למידע נוסף, ראה הפצה מרכז הבקרה.
• צריך לבדוק את קוד המקור של המשחק כדי לוודא שלא קוראים קוד כלשהו עלולה לגרום לבעיה. לדוגמה, האפשרות Finish עלולות להיות הרסניות אם לא משתמשים בהן בצורה נכונה. ניתן לעיין במדריכים למפתחים של Android כדי לקבל מידע נוסף על פיתוח של Android.
• אחרי בדיקת הנתונים וייצוא גרסת ה-build של המשחק אל Android Studio, אתם עובדים עם קוד C ו-C++, וכך אתם יכולים לנצל את כל היתרונות של הכלים מעבר לפתרונות הרגילים של Unity, כמו Android Memory Profiler, Android CPU Profiler וגם perfetto.

קוד מנוע Unity

כדי לדעת אם מתרחשת שגיאת ANR בצד מנוע ה-Unity, צריך לבדוק את libUnity.so או libMain.so בדוחות הקריסות. אם תמצאו אותן, השתמשו את השלבים הבאים:

• קודם כל מחפשים את ערוצי הקהילה (פורומים של Unity, Unity דיונים, Stackoverflow).
• אם לא מוצאים שום דבר, אפשר לדווח על באג כדי לפתור את הבעיה. . לספק דוח קריסות סימבולי כדי שמהנדסי המנוע יוכלו כדי להבין טוב יותר את השגיאה ולפתור אותה.
• בודקים אם הגרסה העדכנית של Unity בוצעו שיפורים ב-LTS שקשורים לבעיות שלך. אם כן, שדרג את את המשחק כדי להשתמש בגרסה הזו. (ייתכן שהפתרון הזה זמין רק עבור חלק מפתחים).
• אם בקוד שלכם נעשה שימוש ב-Activity בהתאמה אישית במקום בברירת המחדל, צריך לבדוק את קוד Java כדי לוודא שהפעילות לא גורמת לבעיות.

SDK של צד שלישי

• צריך לוודא שכל הספריות של הצד השלישי עדכניות ואין בהן דוחות על קריסות או מקרי ANR בגרסה העדכנית של Android.
• נכנסים לפורומים של Unity כדי לבדוק אם יש כבר שגיאות או לפתור את הבעיה בגרסה מאוחרת יותר או אם ניתנה פתרון עקיף אחדות או חבר קהילה.
• יש לעיין בדוח ה-ANR של Google Play ולוודא שהשגיאה עדיין לא זוהו על ידי Google. Google מודעת למקרי ANR מסוימים פועלים לפתרון הבעיות.

ספריית המערכת

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

סיבות יציאה

ApplicationExitInfo הוא ממשק Android API להבנת הגורמים של מקרי ANR. אם במשחק שלך נעשה שימוש ב-Unity 6 ואילך, אפשר לשלוח קריאה ל-ApplicationExitInfo ישירות. בגרסאות ישנות יותר של Unity, צריך להטמיע פלאגין משלכם כדי להפעיל קריאות ApplicationExitInfo מ-Unity.

Crashlytics משתמש גם ב-ApplicationExitInfo; עם זאת, נותנת לך שליטה עדינה יותר ומאפשרת לך לכלול מידע רלוונטי יותר.