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

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

בעיות עיקריות בביצועים

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

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

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

כדאי להגדיר את יעדי ההפעלה הבאים באפליקציות:

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

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

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

גלילה לא חלקה

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

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

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

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

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

חוסר יעילות בצריכת החשמל

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

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

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

זיהוי בעיות

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

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

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

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

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

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

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

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

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

נקודות מעקב

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

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

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

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

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

קומפילציה

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

השימוש ב-speed וב-speed-profile מצמצם את כמות הקוד שמופעל ומפורש מ-dex, וכתוצאה מכך מצמצם את כמות ההידור של just-in-time (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 לבדיקות מיקרו. בין היתר, הסקריפטים האלה מבצעים את הפעולות הבאות:

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

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

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

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

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

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

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

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

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

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

איור 2. מעקב שמציג את המרווח בין אירועי איסוף נתונים.

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

פריימים עם קפיצות

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

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

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

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

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

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

איור 5. דוח מעקב שבו מוצג פריים עם תנועה קופצנית.

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

איור 6. trace שמציג יותר פריימים עם גמגום.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

דברים שכדאי לבדוק:

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

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

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

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

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

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

שימוש במעקב מערכת במכשיר

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

שימוש ב-Memory Profiler של Android Studio

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

     איור 10. ‫Full memory dump (פריקת זיכרון מלאה).

     

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

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

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

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

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