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

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

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

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

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

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

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

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

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

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

גלילה לא חלקה

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

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

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

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

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

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

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

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

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

זיהוי בעיות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פריימים עם בעיות בממשק (jank)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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