הפחתת צריכת הזיכרון של הגרפיקה

ב-stack הגרפיקה, מטמון מאגר לכל שכבה נמצא בין Composer HAL ל-SurfaceFlinger כדי לצמצם את התקורה המשויכת לשליחת מתארי קבצים דרך IPC. לפני Android 14, המטמון של המאגר לא נמחק כש-GraphicBufferProducer מתנתק מ-SurfaceFlinger‏ GraphicBufferConsumer, למשל כש-MediaCodec מתנתק מ-SurfaceView. החל מ-Android 14, אפשר למחוק בכוח את המטמון של המאגר כדי לצמצם את צריכת הזיכרון של הגרפיקה.

בוחרים באחת משתי האפשרויות הבאות:

  • במכשירים שיושקו עם Android מגרסה 14 ואילך, צריך להטמיע את Composer HAL API בגרסה 3.2. האפשרות הזו מופעלת כברירת מחדל ומאפשרת לחסוך הכי הרבה זיכרון. גם במכשירים שמוגדרים לשדרוג לגרסה 14 ואילך אפשר להשתמש באפשרות הזו כדי ליהנות מהיתרונות המלאים של הזיכרון.
  • במכשירים שמשדרגים ל-Android 14 ולא רוצים להטמיע בהם את Composer HAL 3.2 API, אפשר להפעיל את האפשרות לתאימות לאחור. האפשרות הזו חוסכת כמעט כמות זהה של זיכרון כמו האפשרות הקודמת.

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

הטמעת Composer HAL 3.2 API

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

  1. מעדכנים את הטמעת HAL של Composer לגרסה 3.2.
  2. מעבדים את LayerCommand::bufferSlotsToClear על ידי ניקוי הרשומות במטמון המאגר שמסומנות במספרי התחנות שמופיעים ברשימה.

ממשקי ה-API של Composer HAL 3.2 שקשורים לזיכרון של מאגר נתונים גרפי, כולל LayerCommand:bufferSlotsToClear, נמצאים ב-LayerCommand.aidl-.

מפעילים את האפשרות לתאימות לאחור

האפשרות לצמצום הזיכרון עם תאימות לאחור מחליפה מאגר נתונים אמיתי בחריץ המטמון במאגר נתונים של placeholder בגודל 1x1, וכתוצאה מכך חוסך זיכרון בכל החריצים שנמחקו, מלבד החריץ הפעיל הנוכחי של מאגר הנתונים. כדי ליהנות מיתרונות חלקיים של חיסכון בזיכרון, מפעילים את האפשרות של תאימות לאחור על ידי הגדרת ה-syspro של surface_flinger.clear_slots_with_set_layer_buffer ל-true. ה-syspro הזה נמצא בקובץ property_contexts.

כדי להגדיר את sysprop הזה, ההטמעה של HAL ב-Composer צריכה לטפל בצורה נכונה במספר פקודות setLayerBuffer לאותה שכבה במחזור אחד של הצגה.

הפעלת האפשרות התואמת לאחור משפיעה באופן הבא:

  • ב-HAL של AIDL: ‏ SurfaceFlinger שולח כמה מכונות LayerCommand לשכבה אחת, כל אחת עם BufferCommand יחיד. כל BufferCommand מכיל נקודת אחיזה למאגר הנתונים הזמני בגודל 1x1 ומספר חריץ לחריץ מאגר הנתונים הזמני של המטמון שצריך למחוק באופן סופי.

  • ל-HIDL HAL: SurfaceFlinger שולח מספר פקודות SELECT_DISPLAY, SELECT_LAYER ו-SET_BUFFER. הפקודות האלו מכילות נקודת אחיזה למאגר הנתונים הזמני בגודל 1x1 ומספר חריץ לחריץ מאגר הנתונים הזמני של המטמון שצריך למחוק באופן סופי.

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

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

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

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

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