ניהול של framebuffer של לקוח

החל מ-Android 13, המערכת מקצה מאגרי מסגרות חדשים שמשמשים במהלך ההרכבה של הלקוח, בכל פעם שרזולוציית המסך משתנה. ‫SurfaceFlinger מבצע את ההקצאה הזו במחזור הפסילה הבא אחרי שינוי ברזולוציה.

ניהול של מאגר פריימים במהלך מעבר בין רזולוציות

שינויים ברזולוציה מתרחשים באחד משני התרחישים הבאים:

  • אירוע Hotplug, שמופעל על ידי Hardware Composer ‏ (HWC), שמתרחש כשעוברים ממסך חיצוני אחד למסך חיצוני אחר עם רזולוציית ברירת מחדל שונה.

    במהלך אירוע hotplug, ‏ HWC משחרר את ה-handle של מאגרי המסגרות הישנים כשהוא מבטל את ההקצאה של נתוני התצוגה הישנים.

  • מעבר למצב תצוגה שמופעל על ידי SurfaceFlinger, שמתרחש כשמשנים את הרזולוציה באמצעות הגדרות המשתמש, או כשאפליקציה משנה את הרזולוציה באמצעות preferredDisplayModeId.

    במהלך מעבר בין מצבי תצוגה, SurfaceFlinger משחרר את נקודות האחיזה למאגרי מסגרות קיימים של לקוחות לפני שהוא קורא ל-setActiveConfig או ל-setActiveConfigWithConstraints.

כדי למנוע בעיות חמורות כמו פיצול זיכרון במכשירים ללא מספיק זיכרון framebuffer, ‏ HWC צריך לשחרר את ה-handle של ה-framebuffer הישן. הדבר קריטי במקרים הבאים:

שחרור הידיות מאפשר לבטל את ההקצאה של זיכרון מאגר המסגרות באופן מלא לפני ש-SurfaceFlinger מקצה מאגרי מסגרות חדשים במהלך מחזור הפסילה הבא.

המלצות לניהול של מאגר מסגרות

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

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

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

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

בדיקה של ניהול האחסון הזמני של מסגרת

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

  • באירועי hotplug, מנתקים ומחברים מחדש שני מסכים שונים עם רזולוציות שונות.

  • כדי לבדוק את התנהגות הזיכרון של מאגר המסגרות, משתמשים בבדיקת ModeSwitchingTestActivity CTS Verifier כדי להפעיל מעבר בין מצבים. הבדיקה הזו יכולה לזהות באופן ויזואלי בעיות שקשה לזהות אותן באופן פרוגרמטי.