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

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

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

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

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

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

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

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

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

השימוש ב-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. גרף שמציג את הפעילות בטרמפולינה.

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

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

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

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

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

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

  כדאי לדעת: אפשר להשתמש ב-am trace-ipc start כדי לקבל מידע נוסף על השיחות האלה. צריך להשבית אותו לפני שממשיכים בהשוואה, כי הוא יוצר תקורה משמעותית ונשאר פעיל עד להפעלה מחדש של המכשיר.

• איסוף נתונים במקביל: זהו תהליך נפוץ עם השפעה נמוכה יחסית, אבל אם אתם נתקלים בו לעיתים קרובות, כדאי לבדוק אותו באמצעות הכלי לניתוח פרופיל הזיכרון של 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. ‫Full memory dump (פריקת זיכרון מלאה).

     

     איור 11. בעמודה 'הגודל נשמר'.

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

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

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

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

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