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

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

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

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

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

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

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

• הפעלה במצב התחלתי (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" במניפסט כדי להפעיל פרופילים בגרסאות של אפליקציות שמוכנות להפצה.

משתמשים בהגדרות לצמצום קוד ברמת הייצור. בהתאם למשאבים שבהם האפליקציה משתמשת, יכולה להיות לכך השפעה משמעותית על הביצועים. חלק מההגדרות של 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 למיקרו-בנצ'מרקים. בין היתר, הסקריפטים האלה מבצעים את הפעולות הבאות:

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

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

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

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

פעילות טרמפולינה עלולה להאריך את זמן ההפעלה של האפליקציה שלא לצורך, ולכן חשוב לדעת אם האפליקציה שלכם מבצעת פעילות כזו. כפי שאפשר לראות בדוגמה הבאה של מעקב, אחרי 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 מבוסס-האינטרנט. מידע נוסף מופיע במאמר סקירה כללית של מעקב אחר מערכת.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   איור 8. פינוי אשפה.

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

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

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

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

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

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

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

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

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

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

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

     

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

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

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

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

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