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

פתרון ANR במשחק Unity הוא תהליך שיטתי:

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

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

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

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

ניתוח סמלים

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

איך בודקים את מזהה הגרסה של הסמל

אם מערכת הדיווח מציגה את מזהה ה-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.
• בודקים את קוד המקור של המשחק ומוודאים שכל הלוגיקה שמופעלת בקריאות החוזרות (callback) של OnApplicationFocus() ו-OnApplicationPause() מנוקה בצורה מתאימה.
  • למנוע Unity יש פסק זמן להשהיית הביצוע שלו. עומס עבודה מוגזם בקריאות החוזרות האלה עלול לגרום ל-ANR.
  • כדי לשפר את ניתוח הנתונים, אפשר להוסיף יומנים או נתיבי ניווט לחלקים בקוד.
• כדי לבדוק את הביצועים של המשחק, אפשר להשתמש בUnity Profiler. יצירת פרופיל של האפליקציה יכולה גם לעזור לזהות צווארי בקבוק שעלולים לגרום ל-ANR.
• דרך מצוינת לזהות פעולות קלט/פלט ארוכות ב-thread הראשי היא שימוש במצב קפדני.
• מנתחים את ההיסטוריה של Android Vitals או של שירות דיווח אחר, ובודקים את גרסאות ההפצה של המשחק שבו השגיאה מתרחשת הכי הרבה. בודקים את קוד המקור בהיסטוריית בקרת הגרסאות ומשווים בין שינויי הקוד בין הגרסאות. אם אתם מוצאים משהו חשוד, נסו כל שינוי או תיקון פוטנציאלי בנפרד.
• בודקים את היסטוריית הדיווח על מקרי ANR ב-Google Play עבור המכשירים וגרסאות Android שבהם מתרחשים הכי הרבה מקרי ANR. אם המכשירים או הגרסאות מיושנים, סביר להניח שאפשר להתעלם מהם בבטחה, אם זה לא משפיע על הרווחיות של המשחק. חשוב לבדוק את הנתונים בקפידה, כי קבוצה מסוימת של משתמשים לא תוכל יותר לשחק במשחק שלכם. מידע נוסף זמין במאמר בנושא לוח הבקרה של ההפצה.
• בודקים את קוד המקור של המשחק כדי לוודא שלא מופעל קוד שעלול לגרום לבעיה. לדוגמה, הפונקציה finish עלולה לגרום נזק אם לא משתמשים בה בצורה נכונה. מידע נוסף על פיתוח ל-Android זמין במדריכים למפתחים של Android.
• אחרי שבודקים את הנתונים ומייצאים את גרסת המשחק ל-Android Studio, אפשר לעבוד עם קוד C ו-C++‎, ולכן אפשר לנצל באופן מלא כלים שהם מעבר לפתרונות הסטנדרטיים של Unity, כמו Android Memory Profiler,‏ Android CPU Profiler ו-perfetto.

קוד מנוע Unity

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

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

SDK של צד שלישי

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

ספריית מערכת

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

סיבות ליציאה

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

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