במערך הגרפיקה, מטמון של מאגרים לכל שכבה נמצא בין Composer HAL לבין SurfaceFlinger כדי להפחית את התקורה שקשורה לשליחת מתארים של קבצים דרך IPC. בגרסאות Android קודמות לגרסה 14, המערכת לא מוחקת את מטמון המאגר הזה כש-GraphicBufferProducer מתנתק מ-GraphicBufferConsumer של SurfaceFlinger, למשל כש-MediaCodec מתנתק מ-SurfaceView. החל מ-Android 14, אפשר למחוק בכוח את מטמון המאגר הזה כדי לצמצם את צריכת הזיכרון של הגרפיקה.
בוחרים אחת משתי האפשרויות הבאות:
- במכשירים שמושקים עם Android מגרסה 14 ואילך, צריך להטמיע את גרסה 3.2 של ממשק ה-API החדש של Composer HAL. האפשרות הזו מופעלת כברירת מחדל וחוסכת את כמות הזיכרון המקסימלית. מכשירים שמשדרגים לגרסה 14 ואילך יכולים גם להשתמש באפשרות הזו כדי ליהנות מכל היתרונות של הזיכרון.
- במכשירים שמשדרגים ל-Android 14 ולא רוצים להטמיע את Composer HAL 3.2 API, אפשר להפעיל את האפשרות של תאימות לאחור. האפשרות הזו חוסכת כמעט את אותה כמות זיכרון כמו האפשרות הקודמת.
בקטעים הבאים מוסבר איך להטמיע כל אחת מהאפשרויות.
הטמעה של Composer HAL 3.2 API
כדי ליהנות מכל היתרונות של זיכרון מאגר הגרפיקה, צריך:
- מעדכנים את הטמעת Composer HAL לגרסה 3.2.
- מעבדים את
LayerCommand::bufferSlotsToClearעל ידי מחיקת רשומות של מטמון מאגרים שמסומנות על ידי מספרי המשבצות שמופיעים ברשימה.
ממשקי ה-API של Composer HAL 3.2 שקשורים לזיכרון של מאגר נתונים זמני לגרפיקה, כולל LayerCommand::bufferSlotsToClear, נמצאים בקובץ LayerCommand.aidl.
הפעלת האפשרות שתואמת לדור הקודם
אפשרות הפחתת הזיכרון שתואמת לאחור מחליפה מאגר אמיתי במשבצת המטמון במאגר placeholder בגודל 1x1. כתוצאה מכך, יש חיסכון בזיכרון בכל משבצות המאגר שנמחקו, למעט משבצת המאגר הפעילה הנוכחית. כדי ליהנות מחיסכון חלקי בזיכרון, צריך להפעיל את האפשרות 'תאימות לאחור' על ידי הגדרת מאפיין המערכת surface_flinger.clear_slots_with_set_layer_buffer לערך true. מאפיין המערכת הזה נמצא בקובץ property_contexts.
כדי להגדיר את מאפיין המערכת הזה, הטמעת ה-HAL של Composer צריכה לטפל בצורה נכונה בכמה פקודות setLayerBuffer לאותה שכבה במחזור הצגה יחיד.
הפעלת האפשרות 'תאימות לדור קודם' משפיעה על הדברים הבאים:
ב-HAL של AIDL: SurfaceFlinger שולח כמה מופעים של
LayerCommandלשכבה אחת, כל אחד עםBufferCommandאחד. כלBufferCommandמכיל מאגר זמני של placeholder בגודל 1x1 ומספר משבצת למשבצת של מאגר המטמון שצריך לנקות.ב-HIDL HALs: SurfaceFlinger שולח כמה פקודות
SELECT_DISPLAY,SELECT_LAYER,SET_BUFFER. הפקודות האלה מכילות מאגר זמני של 1x1 לטיפול בנתונים ומספר משבצת למשבצת מאגר המטמון שנדרש לנקות.
האפשרות שתואמת לדור קודם עלולה לגרום לקריסה של Composer HAL במכשירים מסוימים. יכול להיות שתוכלו לשנות את Composer HAL כדי לפתור את הבעיה. הקוד ששולט בהתנהגות הזו נמצא כאן:
בדיקת צריכת הזיכרון של מטמון מאגר הגרפיקה
הבדיקות לא יכולות לאמת אם הטמעות HAL מוחקות את משבצות המטמון. עם זאת, אפשר להשתמש בכלים לניפוי באגים כדי לעקוב אחרי השימוש במאגר הגרפיקה. במהלך המעקב, יכול להיות שתבחינו בפחות שגיאות של חוסר זיכרון בתרחישים שבהם כמה סרטונים שונים מופסקים ומופעלים במהירות ב-YouTube.
יש בדיקות VTS שמאמתות שההטמעה של HAL מסוגלת מבחינה פונקציונלית לקבל את הקריאות החדשות ל-API (גרסה HAL 3.2 ואילך) או פקודות setLayerBuffer מרובות להטמעה שתואמת לאחור. עם זאת, לא מומלץ להסתמך על הבדיקות האלה כדי לוודא שהפונקציונליות תקינה, כי יש מכשירים שעוברים את בדיקות VTS אבל נכשלים בתרחישי שימוש בעולם האמיתי.
למידע על בדיקות VTS חדשות, אפשר לעיין בקישורים הבאים: