החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release
במקום ב-aosp-main
כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.
ניהול של framebuffer של לקוח
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
החל מגרסה 13 של Android, מתבצעת הקצאה של מאגרי framebuffer חדשים, שמשמשים במהלך היצירה של הלקוח, בכל פעם שרזולוציית המסך משתנה. הקצאה זו מתבצעת על ידי SurfaceFlinger במחזור הinvalidate הבא אחרי שינוי הרזולוציה.
ניהול של framebuffer במהלך החלפות רזולוציה
שינויים ברזולוציה מתרחשים באחת משתי הסיבות הבאות:
אירוע hotplug, שמופעל על ידי Hardware Composer (HWC), שמתרחש כשמעבירים מסך חיצוני אחד למסך חיצוני אחר עם רזולוציית ברירת מחדל שונה.
במהלך אירוע hotplug, הלחצנים של מסכי ה-framebuffer הישנים משוחררים כשהקצאת הנתונים הישנים של המסך מבוטלת.
מעבר של מצב התצוגה שמופעל על ידי SurfaceFlinger, שמתרחש כשהמשתמש משנה את הרזולוציה באמצעות הגדרות המשתמש, או כשאפליקציה משנה את הרזולוציה באמצעות preferredDisplayModeId
.
במהלך מעבר בין מצבי תצוגה, SurfaceFlinger משחרר את הלחצנים של מאגרי ה-framebuffer הקיימים של הלקוח לפני שהוא קורא ל-setActiveConfig
או ל-setActiveConfigWithConstraints
.
כדי למנוע בעיות חמורות, כמו פיצול זיכרון, במכשירים שלא שומרים מספיק זיכרון למערכי ה-framebuffer הישנים והחדשים, חשוב מאוד ש-HWC יפסיק להשתמש במערכי ה-framebuffer הישנים וישחרר את כל ה-handles למערכי ה-framebuffer האלה, כפי שמתואר במקרים הבאים:
שחרור הלחצנים מאפשר לבטל את ההקצאה של זיכרון framebuffer באופן מלא לפני ההקצאה של framebuffers חדשים, שתתבצע על ידי SurfaceFlinger במהלך המחזור הבא של invalidate.
המלצות לניהול של framebuffer
אם ה-HWC לא משחרר את הלחצנים של מסכי ה-framebuffer הישנים בזמן, הקצאת ה-framebuffer החדשה מתרחשת לפני הביטול של הקצאת ה-framebuffer הישן. מצב כזה עלול לגרום לבעיות חמורות אם ההקצאה החדשה נכשלת בגלל פיצול או בעיות אחרות. גרוע מכך, אם ה-HWC לא משחרר את ה-handles האלה בכלל, יכולה להתרחש דליפת זיכרון.
כדי למנוע כשלים חמורים בהקצאה, כדאי לפעול לפי ההמלצות הבאות:
אם HWC צריך להמשיך להשתמש במאגרי ה-framebuffer הישנים של הלקוח עד שיסופקו מאגרי ה-framebuffer החדשים של הלקוח, חשוב להקצות מספיק זיכרון גם למאגר ה-framebuffer הישן וגם למאגר ה-framebuffer החדש, ואולי גם להריץ אלגוריתמים לפינוי מקום במרחב הזיכרון של מאגר ה-framebuffer.
הקצאת מאגר זיכרון ייעודי למאגרי ה-framebuffer, בנפרד משאר זיכרון מאגר הנתונים הגרפי. זה חשוב כי בין ביטול ההקצאה לבין ההקצאה מחדש של מאגרי הפריימים, תהליך של צד שלישי יכול לנסות להקצות זיכרון גרפיקה. אם מאגר הזיכרון של הגרפיקה משמש את מאגר המסגרות, ואם מאגר הזיכרון של הגרפיקה מלא, התהליך של הצד השלישי יכול לתפוס את מאגר הזיכרון של הגרפיקה שהוקצה בעבר על ידי מאגר המסגרות, וכך לא יישאר מספיק זיכרון להקצאה מחדש של מאגר המסגרות, או שיכול להיות שיגרום לפיצול של מרחב הזיכרון.
בדיקת ניהול של מאגר הפריימים
יצרני ציוד מקורי מומלצים לבדוק אם יש ניהול תקין של זיכרון framebuffer של לקוח במעברים בין רזולוציות במכשיר שלהם, כפי שמתואר בהמשך:
כדי ליצור אירועי hotplug, פשוט מנתקים שני מסכים שונים עם רזולוציות שונות ומחברים אותם מחדש.
כדי לבצע מעבר בין מצבים, משתמשים בבדיקה ModeSwitchingTestActivity
של CTS Verifier כדי להתחיל מעבר בין מצבים לצורך בדיקת התנהגות הזיכרון של framebuffer.
הבדיקה הזו מאפשרת לזהות באופן ויזואלי בעיות שקשה לזהות אותן באופן פרוגרמטי.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת Oracle ו/או של השותפים העצמאיים שלה.
עדכון אחרון: 2025-07-27 (שעון UTC).
[[["התוכן קל להבנה","easyToUnderstand","thumb-up"],["התוכן עזר לי לפתור בעיה","solvedMyProblem","thumb-up"],["סיבה אחרת","otherUp","thumb-up"]],[["חסרים לי מידע או פרטים","missingTheInformationINeed","thumb-down"],["התוכן מורכב מדי או עם יותר מדי שלבים","tooComplicatedTooManySteps","thumb-down"],["התוכן לא עדכני","outOfDate","thumb-down"],["בעיה בתרגום","translationIssue","thumb-down"],["בעיה בדוגמאות/בקוד","samplesCodeIssue","thumb-down"],["סיבה אחרת","otherDown","thumb-down"]],["עדכון אחרון: 2025-07-27 (שעון UTC)."],[],[],null,["# Client framebuffer management\n\nStarting with Android 13, new framebuffers, used during\n[client](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/DisplayCommand.aidl#113)\ncomposition, are allocated whenever the display resolution changes. This\nallocation is performed by SurfaceFlinger on the next *invalidate* cycle\nafter a resolution change.\n\nFramebuffer management during resolution switches\n-------------------------------------------------\n\nResolution changes occur due to one of the following\ntwo scenarios:\n\n- A [hotplug event](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerCallback.aidl#41),\n initiated by Hardware Composer (HWC), which occurs when swapping from one external\n display to a different external display that has a different default resolution.\n\n During a hotplug event, the handles to the old framebuffers are released\n when the old display data is deallocated.\n- A display mode switch initiated by SurfaceFlinger, which occurs when the\n user changes the resolution with [user settings](https://android.googlesource.com/platform/frameworks/base/+/refs/heads/android16-release/core/java/android/hardware/display/DisplayManager.java#1209),\n or an app changes the resolution with [`preferredDisplayModeId`](https://developer.android.com/reference/android/view/WindowManager.LayoutParams#preferredDisplayModeId).\n\n During a display mode switch, the handles to existing client framebuffers\n are released by SurfaceFlinger before calling [`setActiveConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#550)\n or [`setActiveConfigWithConstraints`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#577).\n\nTo avoid catastrophic problems, such as memory fragmentation, on devices that\ndon't reserve enough memory for the old and new framebuffers, it's critical\nthat HWC ceases to use the old framebuffers and releases any\nhandles to these framebuffers as shown in the following cases:\n\n- For hotplug events, immediately before calling [`onHotplug`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerCallback.aidl#41).\n\n- For mode switches, immediately after the call to [`setActiveConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#550)\n or [`setActiveConfigWithConstraints`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#577).\n\nReleasing the handles allows the framebuffer memory to be fully deallocated\nprior to the allocation of new framebuffers that SurfaceFlinger performs\nduring the next *invalidate* cycle.\n\n### Recommendations for framebuffer management\n\nIf HWC doesn't release handles to old framebuffers in time,\nthe new framebuffer allocation takes place before the old framebuffer\ndeallocation. This can cause catastrophic problems when the new allocation fails\ndue to fragmentation or other issues. Even worse, if\nHWC doesn't release these handles at all, a memory leak can\noccur.\n\nTo avoid catastrophic allocation failures, follow these recommendations:\n\n- If HWC needs to continue using the old client framebuffers until the new\n client framebuffers are provided, then it's critical to reserve enough memory\n for both the old and new framebuffers, and possibly run defragmentation\n algorithms on the framebuffer memory space.\n\n- Allocate a dedicated memory pool for the framebuffers that's separate from\n the rest of the graphic buffer memory. This is important because between\n deallocation and reallocation of the framebuffers, a third-party process can\n attempt to allocate graphics memory. If the same graphics memory pool is\n used by the framebuffer and if the graphics memory is full, the third-party\n process can occupy the graphics memory previously allocated by a framebuffer,\n thus leaving insufficient memory for the framebuffer reallocation or, possibly\n fragmenting the memory space.\n\nTest framebuffer management\n---------------------------\n\nOEMs are advised to test for proper client framebuffer memory management across\nresolution switches for their device, described as follows:\n\n- For hotplug events, simply unplug and reconnect two different displays with\n different resolutions.\n\n- For mode switches, use the [`ModeSwitchingTestActivity`](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/apps/CtsVerifier/src/com/android/cts/verifier/tv/display/ModeSwitchingTestActivity.java;l=47-53;drc=c80d948aff1e7df5c2dc0ddba0d1cd63a90e4d9c) CTS\n Verifier test to initiate a mode switch for testing framebuffer memory behavior.\n This test can visually identify problems that are hard to detect\n programmatically."]]