שימוש בזיכרון (RSS אנונימי + החלפה)

השימוש בזיכרון (RSS אנונימי + שטח החלפה) הוא מדד בתפקוד האפליקציה ל-Android שמשקף את השימוש בזיכרון של האפליקציה.

זיכרון אנונימי הוא זיכרון שלא מגובה על ידי קובץ באחסון, כמו הקצאות של ערימה וזיכרון שהוקצה באמצעות mmap. הוא מתעד את הקצאות הזיכרון הדינמיות של האפליקציה, כולל ה-heap של Java או Kotlin, הקצאות של heap מקומי לא מנוהל (שבו נשמרים נתוני פיקסלים של Bitmap ב-Android 8.0 (רמת API‏ 26) ומעלה) ומחסניות של ביצוע שרשורים. למרות שמערכת ההפעלה יכולה להפיל זיכרון מגובה קובץ במצב של עומס, היא לא יכולה להפיל זיכרון אנונימי.

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

בזיכרון אנונימי, המערכת יכולה לכתוב דפים לשטח החלפה (או zRAM ב-Android) כשהזיכרון נמצא בשימוש רב. המערכת יכולה לקרוא את הדפים האלה בחזרה מהזיכרון הווירטואלי אם צריך.

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

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

זיהוי שימוש גבוה בזיכרון

תפקוד האפליקציה

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

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

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

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

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

זיהוי דליפות זיכרון באמצעות הטיה של הזנב

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

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

משאבים

אבחון שימוש מוגזם בזיכרון באופן מקומי

כדי להתחיל לאבחן את המקור לשימוש מוגזם בזיכרון, אפשר לצלם תמונת מצב של הזיכרון באמצעות Record heap dump בהגדרות למפתחים, ב-Android Studio או ב-Perfetto. מומלץ להתחיל בלכידת תמונת מצב של הזיכרון באופן מקומי אחרי בדיקת התהליכים העיקריים שעובר המשתמש באפליקציה.

מומלץ במיוחד לבדוק את תהליכי המשתמש הבאים:

  • רכיבי WebView וסשנים של דפדפן באפליקציה
  • גלילה מתמשכת עם הרבה מדיה
  • תהליכי עבודה ליצירה ולעריכה של נכסים

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

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

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

דוגמה לתשובה של מיומנויות ה-AI:

I have completed the analysis of memory leaks and bitmap issues for [app] using the provided Perfetto trace.
  Summary of Findings
  The investigation identified a critical memory pressure issue caused by massive bitmap retention within the app process.
...
Recommendations for [app]
   1. [Library] Image Cache Optimization:
       * Review the [Library] caching strategy. Ensure that bitmaps
         loaded for animations are released or downsampled when the animation is
         not in the foreground.
   2. Asset Resolution Audit:
       * The 14.7 MB average size suggests full-screen or extremely high-density assets. Audit the [library] files in the native_home component to ensure they are not using unnecessarily large source images.
   3. View Lifecycle Management:
       * Investigate why 21 [LibraryImage] instances are alive simultaneously. Ensure that views in the bottom
      tab are properly detached or their animations are cleared when switching between tabs.
   4. Fix Surface Leaks:
       * Address the Surface.release failures observed in the logs, as these can lead to both memory leaks and
         native resource exhaustion.

מקורות מידע נוספים להבנת נתוני Heap Dump

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

  • ניתוח ידני: אפשר להיעזר בהנחיות לשימוש ב-Perfetto Heap Dump Explorer כדי ללמוד איך לנווט בהדמיות של תמונת מצב של הזיכרון בממשק המשתמש של Perfetto ולפרש אותן.
  • הקצאות של Java/Kotlin: במאמר הדמיה של תמונת מצב של הזיכרון של ART הראשון מוסבר איך לנתח תמונות מצב של הזיכרון של ART (סביבת זמן הריצה ל-Android) שלב אחר שלב.
  • הקצאות מקוריות: כדי ללמוד איך לאסוף ולנתח פרופילים מקוריים (C/C++) של זיכרון, אפשר לעיין במסמכי התיעוד בנושא Perfetto Native Profiling.
  • בדיקה באמצעות CLI: אפשר להשתמש בפקודה adb dumpsys meminfo כדי לקבל פירוט מהיר של השימוש בזיכרון של האפליקציה במכשיר.

שיפור השימוש בזיכרון

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

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

הקודם
אירועי LMK (הפסקת תהליכים בגלל מחסור בזיכרון)
הבא
שימוש בזיכרון של מפת הסיביות (bitmap)