גורמים לזיכרון נמוך

ה-daemon של low memory killer (LMK) ב-Android עוקב אחרי מצב הזיכרון של מערכת Android שפועלת, ומגיב לעומס גבוה על הזיכרון על ידי סיום התהליכים הכי פחות חיוניים. תפקוד האפליקציה עוקב אחרי סגירות LMK שהשפיעו על המשתמשים ומדווח עליהן ב-Google Play Console, כדי לעזור לכם לזהות בעיות של עומס בזיכרון שמשפיעות על המשתמשים.

מדד LMK בתפקוד האפליקציה

התכונה "תפקוד האפליקציה" יכולה לעזור לכם לעקוב אחרי שיעור ה-LMK של האפליקציה ולשפר אותו. בתפקוד האפליקציה נמדד רק שיעור אחד של אירועי LMK: שיעור אירועי ה-LMK שהשפיעו על המשתמשים.

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

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

המדד הזה מופיע בקטע יציבות בתפקוד האפליקציה:

תרשים 1. עוברים אל שיעור אירועי ה-LMK שהשפיעו על המשתמשים בתפקוד האפליקציה.

כמו במדדים דומים של תפקוד האפליקציה, כמו מקרי ANR וקריסות, אתם יכולים לסנן את המדדים, להשוות את המדדים שלכם לאלה של אפליקציות דומות או לעקוב אחרי השינוי במדד לאורך תקופה ארוכה (עד 3 שנים). הנתונים זמינים לאפליקציות קיימות החל מ-28 בינואר 2025.

איור 2. סקירה כללית של שיעור אירועי ה-LMK בתפקוד האפליקציה.

איך פועל ה-daemon של low memory killer

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

כדי להחליט איזה תהליך להפסיק כשהזיכרון הפנוי אוזל, ה-daemon של low memory killer (LMK)‎ משתמש בניקוד אין זיכרון פנוי (OOM) שנקרא oom_adj_score כדי לתעדף את התהליכים שפועלים. תהליכים עם ניקוד גבוה נסגרים קודם. אפליקציות שפועלות ברקע נסגרות קודם, ותהליכי המערכת נסגרים אחרונים. בטבלה הבאה מפורטות קטגוריות הניקוד של LMK, מהגבוהה לנמוכה. הפריטים בקטגוריה עם הניקוד הגבוה ביותר, בשורה הראשונה, נסגרים קודם:

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

כלים ליצירת פרופיל זיכרון

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

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

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

‫Memory Profiler ב-Android Studio

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

‫Memory Profiler ב-Android Studio שמציג הפניות גלובליות ל-JNI ב-heap.
איור 4. צפייה בהפניות גלובליות ל-JNI ב-Memory Profiler של Android Studio.

כלי פרופיילינג של זיכרון ב-Unity

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

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

מודול הזיכרון מציג הקצאות זיכרון כמו זיכרון טקסטורה וזיכרון רשת.
איור 5. חלון Unity Profiler עם המודול Memory שנבחר.

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

חלון של Unity Memory Profiler שמוצג בו פירוט של תמונת מצב של הזיכרון.
איור 6. ניתוח תמונת מצב של הזיכרון באמצעות החלון Memory Profiler.

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

Unreal Memory Insights

באפליקציות שנוצרו באמצעות Unreal Engine אפשר להשתמש ב-Unreal Memory Insights כדי לראות מידע מפורט על הקצאת זיכרון וביטול הקצאה, כולל תגי Low Level Memory (LLM)‎ ומחסניות קריאות שמשויכות לבלוקים של זיכרון.

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

החל מגרסה 5.4 של UE, הכלי Memory Insights תומך במעקב אחר זיכרון עם מחסניות קריאות לפרויקטים ב-Android.

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

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

תובנות לגבי זיכרון נמוך

ב-Android יש קריאות חוזרות (callbacks) וממשקי API שמאפשרים לצמצם את השימוש בזיכרון של המשחק ולבדוק למה הפעלות קודמות של המשחק הופסקו.

התקשרות חזרה

אל תירשמו לקריאות חוזרות (callbacks) של trim שהוצאו משימוש. ב-Android אין ממשקי API לזיהוי אירועים של מחסור בזיכרון מקורי לפני שהמערכת מפנה זיכרון, וקריאות חוזרות (callbacks) מפורטות לקיצוץ הזיכרון הפעיל (TRIM_MEMORY_RUNNING_*) לא מנעו ביעילות סגירת אפליקציות בגלל מחסור בזיכרון. לכן, ב-Android הוצאו משימוש כל רמות הקיצוץ מלבד TRIM_MEMORY_UI_HIDDEN ו-TRIM_MEMORY_BACKGROUND. השתמשו בקריאות החוזרות (callbacks) הנותרות האלה – או במקבילות של מחזור החיים של המנוע, כמו OnApplicationPause של Unity ו-ApplicationWillEnterBackgroundDelegate של Unreal – כדי לשחרר את ממשק המשתמש ומשאבי העזר כשהמשחק עובר לרקע. פרטים על ההטמעה מופיעים במאמר הפחתת השימוש בזיכרון במשחקים.

סיום המשחק

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

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

  • שימוש ב-ApplicationExitInfo: ה-API הזה מחזיר את הסיבה לכך שמערכת Android סגרה את המשחק הקודם. אפשר להשתמש ב-ApplicationExitInfo כדי לבדוק אם הסיבה ליציאה מתהליך קודם היא זיכרון נמוך (REASON_LOW_MEMORY) או סגירות של מגביל הזיכרון (REASON_MEMORY_LIMITER) (מידע נוסף זמין במאמר ApplicationExitInfo למשחקים). בודקים אם המשחק נסגר בגלל עומס על הזיכרון, כדי לבצע אופטימיזציה של המשחק כך שישתמש בפחות זיכרון במכשיר הזה.
  • זיכרון RAM פיזי כולל: כדי למנוע סגירה של משחקים כשהם פועלים בחזית, וכדי להתאים את המשחק ליכולות של המכשיר, כדאי לבדוק את זיכרון ה-RAM הפיזי הכולל בכל מכשיר כדי להתאים את השימוש בזיכרון של המשחק על סמך הנתון הזה. אם המטרה היא למנוע את סגירת האפליקציות זמן קצר אחרי שהן עוברות לרקע (כדי לאפשר לשחקן לבצע כמה משימות בו-זמנית), צריך להשתמש בקריאות החוזרות (callbacks) של trim (במיוחד TRIM_MEMORY_UI_HIDDEN) כדי לצמצם את השימוש בזיכרון של המשחק.

מקורות מידע נוספים