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

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

בעיות ביצועים מרכזיות

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

זמן האחזור בזמן ההפעלה

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

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

• הפעלה במצב התחלתי (cold start) תוך פחות מ-500 אלפיות השנייה. הפעלה במצב התחלתי מתרחשת כשהאפליקציה שמפעילים לא נמצאת בזיכרון המערכת. האירוע הזה מתרחש כשזו הפעם הראשונה שהאפליקציה מופעלת מאז ההפעלה מחדש או מאז שהמשתמש או המערכת הפסיקו את תהליך האפליקציה.

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

• זמני האחזור של P95 ו-P99 קרובים מאוד לזמן האחזור החציוני. אם האפליקציה נפתחת באיטיות, חוויית המשתמש נפגעת. תקשורת בין תהליכים (IPC) ופעולות קלט/פלט מיותרות במהלך הנתיב הקריטי של הפעלת האפליקציה עלולות לגרום לסכסוך על נעילת הנתונים ולגרום לאי-עקביות.

תנודות בזמן גלילה

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

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

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

מעברים לא חלקים

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

חוסר יעילות בשימוש בחשמל

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

הקצאות זיכרון, שנובעות מיצירת אובייקטים חדשים בקוד, יכולות לגרום לעבודה משמעותית במערכת. הסיבה לכך היא שגם ההקצאות עצמן דורשות מאמץ מ-Android Runtime‏ (ART), וגם שחרור האובייקטים האלה מאוחר יותר (אוסף אשפה) דורש זמן ומאמץ. גם ההקצאה וגם האיסוף מהירים ויעילים הרבה יותר, במיוחד לגבי אובייקטים זמניים. בעבר, השיטה המומלצת הייתה להימנע מהקצאת אובייקטים כשהדבר אפשרי, אבל מומלץ לעשות מה שהכי מתאים לאפליקציה ולמבנה שלכם. לא מומלץ לחסוך בקצאות ולהסתכן בקוד שלא ניתן לתחזק, בהתאם ליכולות של ART.

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

זיהוי בעיות

אנחנו ממליצים על תהליך העבודה הבא לזיהוי בעיות בביצועים ולפתרון שלהן:

1. מזהים את תהליכי חוויית המשתמש החיוניים הבאים ובודקים אותם:
   • תהליכי הפעלה נפוצים, כולל ממסך הבית ומהתראה.
   • מסכים שבהם המשתמש גולל בין הנתונים.
   • מעברים בין מסכים.
   • תהליכים ממושכים, כמו ניווט או הפעלת מוזיקה.
2. אפשר לבדוק מה קורה במהלך התהליכים הקודמים באמצעות הכלים הבאים לניפוי באגים:
   • Perfetto: מאפשר לכם לראות מה קורה בכל המכשיר באמצעות נתוני תזמון מדויקים.
   • Memory Profiler: מאפשר לראות אילו הקצאות זיכרון מתרחשות בערימה.
   • Simpleperf: תרשים אש שבו מוצגות קריאות הפונקציות שמנצלות את הכי הרבה מעבד במהלך תקופה מסוימת. אם זיהית פעולה ב-Systrace שנמשכת זמן רב אבל לא ברור למה, אפשר להשתמש ב-Simpleperf כדי לקבל מידע נוסף.

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

• תהליכים לסטארט-אפים
  • מדדי שדה: זמן ההפעלה של Play Console
  • בדיקות מעבדה: בדיקת סטארט-אפ באמצעות Macrobenchmark
• Jank
  • מדדי שדה
    • מדדי הליבה של Play Console: ב-Play Console אי אפשר לצמצם את המדדים לתהליך משתמש ספציפי. הוא מדווח רק על תנודות כלליות לאורך האפליקציה.
    • מדידה בהתאמה אישית באמצעות FrameMetricsAggregator: אפשר להשתמש ב-FrameMetricsAggregator כדי לתעד מדדי תנודות במהלך תהליך עבודה מסוים.
  • בדיקות מעבדה
    • גלילה באמצעות Macrobenchmark.
    • הבדיקה Macrobenchmark אוספת את תזמון המסגרות באמצעות פקודות dumpsys gfxinfo שמקפות מסלול משתמש יחיד. זוהי דרך להבין את השינויים בתנודות במהלך תהליך ספציפי להמרת משתמש. כדי לזהות נסיגות או שיפורים, המדדים RenderTime, שמציינים את משך הזמן שלוקח לצייר את הפריימים, חשובים יותר ממספר הפריימים הלא חלקים.

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

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

• היקפי מסנני Intent: מוסיפים את autoVerify למסנני Intent רק לכתובות URL שהאפליקציה יכולה להגיב אליהן.
• מעברים לא מאומתים בין פרוטוקולים: הפניות אוטומטיות לא מאומתות בצד השרת ובתת-דומיינים נחשבות לסיכוני אבטחה ולא עוברות אימות. הן גורמות לכשל בכל הקישורים מסוג autoVerify. לדוגמה, הפניה אוטומטית של קישורים מ-HTTP ל-HTTPS, כמו example.com ל-www.example.com, בלי לאמת את הקישורים ל-HTTPS, עלולה לגרום לכישלון האימות. חשוב לאמת את קישורי האפליקציות על ידי הוספת מסנני כוונות.
• קישורים שלא ניתן לאמת: הוספת קישורים שלא ניתן לאמת למטרות בדיקה עלולה לגרום לכך שהמערכת לא תאמת את הקישורים לאפליקציה שלכם.
• שרתי לא מהימנים: חשוב לוודא שהשרתים יכולים להתחבר לאפליקציות הלקוח.

הגדרת האפליקציה לניתוח ביצועים

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

נקודות מעקב

אפשר להוסיף לאפליקציות אירועי מעקב בהתאמה אישית.

בזמן תיעוד העקבות, מתבצע עומס קטן של כ-5μs לכל קטע, לכן אל תוסיפו את העקבות לכל שיטה. מעקב אחרי קטעי עבודה גדולים יותר של יותר מ-0.1ms יכול לספק תובנות משמעותיות לגבי צווארי בקבוק.

שיקולים לגבי APK

וריאנטים של ניפוי באגים יכולים לעזור בפתרון בעיות ובסמלול של דוגמאות למחסנית, אבל יש להם השפעה חמורה על הביצועים. במכשירים עם Android מגרסה 10 (רמת API 29) ואילך, אפשר להשתמש ב-profileable android:shell="true" במניפסט כדי להפעיל יצירת פרופילים בגרסאות build של גרסאות פרסום.

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

קומפילציה

מפעילים קומפילציה של האפליקציה במכשיר למצב ידוע – בדרך כלל speed לשם פשטות, או speed-profile כדי להתאים את הביצועים בסביבת הייצור בצורה טובה יותר (אבל לשם כך צריך לחמם את האפליקציה ולשמור את הפרופילים, או לבצע קומפילציה של הפרופילים הבסיסיים של האפליקציה).

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

הפקודה הבאה מקמפל את האפליקציה באמצעות המצב speed:

adb shell cmd package compile -m speed -f com.example.packagename

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

/data/misc/profiles/ref/[package-name]/primary.prof

שיקולים לגבי המערכת

כדי לבצע מדידות ברמה נמוכה וברמה גבוהה של דיוק, צריך לבצע כיול של המכשירים. להריץ השוואות A/B באותו מכשיר ובאותה גרסת מערכת הפעלה. יכולות להיות הבדלים משמעותיים בביצועים, גם באותו סוג מכשיר.

במכשירים עם הרשאת root, כדאי להשתמש בסקריפט lockClocks למדדי Microbenchmark. בין היתר, הסקריפטים האלה מבצעים את הפעולות הבאות:

• מיקום מעבדים בתדר קבוע.
• משביתים את הליבות הקטנות ומגדירים את ה-GPU.
• משביתים את הבקרה התרמית.

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

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

הפעלה איטית של האפליקציה: פעילות טרמפולינה מיותרת

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

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

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

הקצאות מיותרות שמפעילות פעולות GC תכופות

יכול להיות שתבחינו ב-Systrace שפעולות איסוף אשפה (GC) מתרחשות בתדירות גבוהה יותר מהצפוי.

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

איור 2. מעקב שמציג את המרווח בין אירועי GC.

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

פריימים לא סדירים

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

כשהמסגרות נוצרות עם מעט עבודה נדרשת מהאפליקציה, נקודות המעקב של Choreographer.doFrame() מתרחשות בקצב של 16.7ms במכשיר עם 60FPS:

איור 3. ניתוח שבו מוצגים פריימים מהירים תכופים.

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

איור 4. מעקב שבו מוצגים פריימים מהירים תכופים עם התפרצויות תקופתיות של עבודה.

אם אתם רואים הפרעה בקצב הקבוע הזה, זהו פריים לא יציב, כפי שמוצג באיור 5:

איור 5. מעקב שמראה פריים לא יציב.

אפשר להתאמן בזיהוי שלהם.

איור 6. מעקב שמראה יותר מסגרות לא יציבות.

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

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

טעויות נפוצות ב-RecyclerView

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

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

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

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

ניפוי באגים באפליקציה

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

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

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

אפשר להבדיל בין סוגי הסטארט-אפים בשלבים הבאים:

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

מומלץ לתעד את ה-Systrace באמצעות אפליקציית System Tracing במכשיר. ב-Android מגרסה 10 ואילך, משתמשים ב-Perfetto. ב-Android מגרסה 9 ומטה, משתמשים ב-Systrace. מומלץ גם להציג את קובצי המעקב באמצעות הצגת המעקב של Perfetto באינטרנט. מידע נוסף זמין במאמר סקירה כללית על מעקב במערכת.

כדאי לבדוק את הדברים הבאים:

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

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

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

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

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

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

שימוש ב-System Tracing במכשיר

אפשר להשתמש באפליקציה ברמת המערכת שנקראת System Tracing כדי לתעד מעקב אחרי מערכת במכשיר. האפליקציה הזו מאפשרת להקליט עקבות מהמכשיר בלי לחבר אותו לחשמל או ל-adb.

שימוש בכלי לניתוח ביצועי הזיכרון ב-Android Studio

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

כדי לפתור בעיות זיכרון באפליקציה, אפשר להיעזר במידע שמתקבל מ-Memory Profiler כדי לעקוב אחרי הסיבות לפעולות GC ותדירותן.

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

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

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

   איור 7. הגדלת מספר האובייקטים.

   איור 8. איסוף אשפה.

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

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

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

   איור 9. הערכים של Allocations ו-Shallow Size.

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

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

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

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

   • Shallow Size: מעקב רק אחרי הזיכרון של האובייקט עצמו. הוא שימושי למעקב אחרי כיתות פשוטות שמכילות בעיקר ערכים פרימיטיביים בלבד.

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

     איור 10. דמפ מלא של הזיכרון.

     

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

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

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

   השיפורים בזיכרון משפיעים על הדברים הבאים:

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