דוגמאות למדידה ולניתוח של ביצועים

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

ניפוי באגים בהפעלת האפליקציה באמצעות systrace

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

שימוש ב-systrace או ב-Perfetto

כדי לקבל מידע נוסף על שימוש בסיסי ב-systrace, אפשר לצפות בסרטון הבא: Debugging Application Performance.

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

שלבי ההפעלה של האפליקציה:

  • הפעלת התהליך
  • אתחול אובייקטים כלליים של אפליקציות
  • יצירה והפעלה של פעילות
  • הגדלת הפריסה
  • ציור הפריים הראשון

סוגי ההפעלה כוללים את השלבים הבאים:

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

מומלץ לצלם systraces באמצעות אפליקציית מעקב המערכת במכשיר, שזמינה באפשרויות למפתחים. אם רוצים להשתמש בכלים של שורת הפקודה, אפשר להשתמש ב-Perfetto ב-Android מגרסה 10 (רמת API 29) ואילך, ובמכשירים עם גרסאות קודמות צריך להשתמש ב-systrace.

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

אם אפשר, מומלץ לכלול קריאה ל-reportFullyDrawn (זמינה ב-Android 10 ומעלה) כשההפעלה מסתיימת מנקודת המבט של האפליקציה.

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

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

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

Concurrent garbage collection
איור 3. איסוף אשפה מקביל הוא נפוץ וההשפעה שלו נמוכה יחסית, אבל אם הוא מתרחש לעיתים קרובות, כדאי לבדוק אותו באמצעות הכלי לניתוח ביצועים של הזיכרון ב-Android Studio.

קלט/פלט בזמן ההפעלה
איור 4. בודקים אם יש פעולות קלט/פלט במהלך ההפעלה ומחפשים עצירות ארוכות.

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

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

כדאי גם לעיין במדריך בנושא מקורות נפוצים של תופעת הג'אנק

שימוש בכלי ליצירת פרופיל זיכרון ב-Android Studio

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

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

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

1. זיהוי בעיות בזיכרון

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

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

איסוף אשפה
איור 6. פרופיל הזיכרון שמציג אירועים של איסוף אשפה.{.:image-caption}

אחרי שמזהים תרחיש שימוש שמוסיף עומס על הזיכרון, מתחילים לנתח את הסיבות הבסיסיות.

2. אבחון של נקודות חמות של עומס על הזיכרון

בוחרים טווח בציר הזמן כדי לראות את ההקצאות ואת הגודל הרדוד.

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

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

סידור לפי כיתה

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

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

סידור לפי מחסנית הקריאות

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

גודל שטחי לעומת גודל שמתפנה

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

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

Full memory dump
איור 8. אפשר ליצור dump של הזיכרון בכל שלב בלחיצה על הלחצן Dump Java heap (יצירת dump של הזיכרון של Java) בסרגל הכלים של הכלי לניתוח פרופיל הזיכרון.

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

3. מדידת ההשפעה של אופטימיזציה

אחד השיפורים באופטימיזציה של הזיכרון שקל למדוד הוא איסוף זבל (garbage collection). כשפעולת אופטימיזציה מצמצמת את העומס על הזיכרון, אמורות להיות פחות פעולות של איסוף זבל (GC). כדי למדוד את זה, מודדים את הזמן בין איסופי האשפה בציר הזמן של הכלי ליצירת פרופיל. אחרי אופטימיזציות של הזיכרון, אמורים להיות פרקי זמן ארוכים יותר בין איסופי האשפה.

ההשפעה הסופית של שיפורים כאלה בזיכרון היא:

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