השימוש בזיכרון (RSS אנונימי + החלפה) הוא מדד ב-תפקוד האפליקציה שמשקף את השימוש בזיכרון באפליקציה שלכם.
זיכרון אנונימי הוא זיכרון שלא מגובה על ידי קובץ באחסון, כמו הקצאות של heap וזיכרון שהוקצה באמצעות mmap. הוא מתעד את הקצאות הזיכרון הדינמיות של האפליקציה, כולל ה-heap של Java או Kotlin, הקצאות של heap מקומי לא מנוהל (שבו נשמרים נתוני פיקסלים של Bitmap ב-Android 8.0 (רמת API 26) ומעלה) ומחסניות של ביצוע שרשורים. למרות שהמערכת יכולה להפסיק להשתמש בזיכרון שמוקצה לקבצים כשיש עומס, היא לא יכולה להפסיק להשתמש בזיכרון אנונימי.
גודל הזיכרון התושב (RSS) הוא המספר הכולל של דפי זיכרון (משותפים ולא משותפים) שנעשה בהם שימוש בתהליך מסוים, ושנשמרים בזיכרון RAM פיזי. דף נחשב כ'משותף' אם יותר מתהליך אחד ניגש אליו (למשל, אפליקציות שניגשות לאותה ספרייה).
בזיכרון אנונימי, המערכת יכולה לכתוב דפים לשטח החלפה (או zRAM ב-Android) כשהזיכרון נמצא בשימוש רב. המערכת יכולה לקרוא את הדפים האלה בחזרה מהזיכרון הווירטואלי אם צריך.
בסך הכול, השימוש בזיכרון (זיכרון RSS אנונימי + החלפה) הוא מדד של מספר דפי הזיכרון הכולל של האפליקציה שלא מגובה על ידי קובץ באחסון, כולל כל הזיכרון שנשמר גם על ידי המערכת בהחלפה. מעקב אנונימי RSS + swap מבטיח שתוכלו לראות את הזיכרון שבשימוש האמיתי של האפליקציה, שלא ניתן להוציא ממנו נתונים.
אם השימוש בזיכרון של האפליקציה גבוה, כדאי לבדוק את הבעיה לעומק ולפתור אותה באמצעות ההנחיות שבדף הזה.
זיהוי שימוש גבוה בזיכרון
תפקוד האפליקציה
בנתונים של מדד תפקוד האפליקציה אפשר לראות את השימוש בזיכרון באפליקציה שלכם, לפי מצבי התהליך הבאים:
- חזית: התהליך של האפליקציה גלוי. ערך גבוה של P99 כאן משפיע לעיתים קרובות על הביצועים שהמשתמשים חווים (תנודות או קריסות של OOM) והוא מושפע מאוד משמירה של רכיבי ממשק משתמש או פעילויות שכבר לא נחוצות.
- שירות מורגש: התהליך של האפליקציה פועל במצב מורגש. ההגבלה הזו חלה על שירותים שפועלים ברקע, על משימות דחופות ועל משימות של העברת נתונים ביוזמת המשתמשים. ההגבלה יכולה לחול גם על שירותים שקשורים למערכת או על שירותים שקשורים לאפליקציות אחרות. מכיוון שהשירותים האלה מיועדים למשימות ארוכות טווח, שמירה של זיכרון בגלל דליפות או אי-שחרור של משאבים עלולה להגדיל את זנב P99 לאורך זמן.
- רקע: האפליקציה מפעילה שירות הפועל ברקע, או שהועברה לאחרונה לרקע, אבל עדיין לא נשמרה במטמון. כאן יכולות להתרחש דליפות של עיבוד ברקע ומשאבים שלא שוחררו. מצב התהליך הזה פחות חשוב מתהליכים שפועלים ברקע או מתהליכים שניתן לראות, ולכן כדאי להימנע משמירה של כמויות גדולות של זיכרון במצב הזה.
- במטמון: האפליקציה נמצאת במצב מטמון. המצב הזה רגיש מאוד לעומס על זיכרון המערכת, כמו LMK. מכיוון שמערכת ההפעלה יכולה להוציא את מצב התהליך הזה מהזיכרון בכל שלב, המצב הזה מסופק רק למטרות ניפוי באגים.
כדי להבין איך מצבי התהליך האלה קשורים לonTrimMemory קריאות חוזרות (callback), אפשר לעיין בהנחיות בנושא שחרור זיכרון בתגובה לאירועים.
בנוסף, הנתונים של מדד תפקוד האפליקציה מפרטים את השימוש בזיכרון של האפליקציה לפי קטגוריות של זיכרון RAM. מדד השימוש בזיכרון מוצג כציר זמן של ערכי אחוזונים יומיים, לצד הערך היומי האחרון של האחוזונים ה-50 וה-90.
אחרי שמזהים את נתוני הבסיס של הזיכרון, פועלים לפי ההנחיות כדי לאבחן את השימוש המוגזם בזיכרון ולשפר אותו.
זיהוי דליפות זיכרון באמצעות הטיה של הזנב
כדי לזהות דליפות זיכרון, כדאי לחפש בנתוני מדדי התפקוד של Android פער בין המשתמשים הטיפוסיים (אחוזון 50) לבין המשתמשים בקצה (אחוזון 90). בעוד שנפיחות כללית של נכסים מגדילה את הזיכרון באופן אחיד בכל האחוזונים, דליפות זיכרון מצטברות לאורך זמן, וגורמות להטיה חזקה של הנתונים בקצה הזנב.
מומלץ להשוות בין מדדי P90 ו-P99 לבין נקודת הבסיס P50 לפי שם התהליך. אם היחס בין P90 ל-P50 גבוה מ-3.5, סביר להניח שיש דליפת זיכרון במהלך הפעלות ממושכות. בתרחישי שימוש מסוימים, יחס גבוה לא תמיד מצביע על דליפה, אבל כדאי להעריך את תהליך העבודה הספציפי כדי לקבוע אם השימוש הגבוה בזיכרון הוא התנהגות צפויה.
משאבים
אבחון שימוש מוגזם בזיכרון באופן מקומי
כדי להתחיל באבחון המקור של שימוש מוגזם בזיכרון, אפשר לתעד תמונת מצב של הזיכרון באמצעות תיעוד תמונת מצב של הזיכרון בהגדרות למפתחים, ב-Android Studio או ב-Perfetto. מומלץ להתחיל בלכידת תמונת מצב של הזיכרון באופן מקומי אחרי בדיקת התהליך שעובר המשתמש העיקרי באפליקציה.
מומלץ במיוחד לבדוק את תהליכי המשתמש הבאים:
- רכיבי WebView וסשנים של דפדפן באפליקציה
- גלילה מתמשכת עם הרבה מדיה
- תהליכי עבודה ליצירה ולעריכה של נכסים
כדי לבדוק אם יש דליפות זיכרון פוטנציאליות, קודם צריך לזהות את התהליכים שצורכים הכי הרבה זיכרון באמצעות הטבלה שם התהליך בלוח הבקרה 'שימוש בזיכרון' של תפקוד האפליקציה. לאחר מכן, מריצים את התהליך שעובר המשתמש המתאים באופן מקומי ואוספים תמונת מצב של הזיכרון במצבי תהליך שונים (גלוי, שירות שפועל בחזית ובמטמון) כדי לוודא שהאפליקציה משחררת זיכרון אחרי שהיא עוברת לרקע.
אם אתם מנפים באגים בבעיות שקשורות לזיכרון באמצעות הכלי לניתוח ביצועים (profiler) ב-Android Studio, אתם יכולים גם להשתמש בשילוב של LeakCanary כדי לייעל את זיהוי הדליפות והעותקים הכפולים של מפות הסיביות (bitmap), וכך לשפר את השימוש בתמונות.
אחרי שיוצרים את קובץ ה-heap dump, מומלץ להשתמש ביכולות ה-AI של Perfetto כדי לנתח את קובץ ה-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 dumps
במקורות המידע הבאים אפשר לקרוא מידע נוסף על ניתוח של קובצי heap dump ועל ניפוי באגים בשימוש בזיכרון:
- ניתוח ידני: אפשר להיעזר בהנחיות לשימוש ב-Perfetto Heap Dump Explorer כדי ללמוד איך לנווט בהדמיות של תמונת מצב של הזיכרון בממשק המשתמש של Perfetto ולפרש אותן.
- הקצאות של Java/Kotlin: במאמר הדמיה של תמונת מצב של הזיכרון של ART הראשון מוסבר איך לנתח תמונות מצב של הזיכרון של ART (סביבת זמן הריצה ל-Android) שלב אחר שלב.
- הקצאות מקוריות: כדי ללמוד איך לאסוף ולנתח פרופילים מקוריים (C/C++) של זיכרון, אפשר לעיין במסמכי התיעוד בנושא Perfetto Native Profiling.
- בדיקה באמצעות CLI: אפשר להשתמש בפקודה adb dumpsys meminfo כדי לקבל פירוט מהיר של השימוש בזיכרון של האפליקציה במכשיר.
- ניתוח בעזרת AI: אפשר להשתמש ב-Perfetto AI Skills כדי להריץ ניתוח מבוסס-LLM שיעזור לכם לזהות דליפות זיכרון והקצאות מוגזמות בנתוני העקבות.
- ניתוח מבוסס SQL: אפשר להשתמש ב-Perfetto SQL ובמיומנויות ניתוח עקבות כדי להריץ שאילתות מובְנות ותסריטים מיוחדים לניתוח נתוני עקבות מורכבים.
שיפור השימוש בזיכרון
בקטעים הבאים מוסבר איך לשפר את השימוש בזיכרון של האפליקציה:
- צמצום של קוד האפליקציה ושל טביעת הרגל של המשאבים
- מעקב אחר הזיכרון הזמין והשימוש בזיכרון
- שימוש במבני קוד יעילים יותר מבחינת זיכרון
הוראות מפורטות לפתרון בעיות שקשורות לזיכרון מופיעות במדריך ניהול הזיכרון של האפליקציה.