החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.
HAL של Hardware Composer
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
ה-HAL של Hardware Composer (HWC) קובע את הדרך היעילה ביותר לשילוב מאגרים עם החומרה הזמינה. כ-HAL, ההטמעה שלו ספציפית למכשיר, ובדרך כלל מתבצעת על ידי יצרן הציוד המקורי (OEM) של חומרת התצוגה.
קל להבין את הערך של הגישה הזו כשמדברים על שכבות-על, שבהן נעשה שילוב של מספר מאגרים בחומרת המסך ולא ב-GPU. לדוגמה, נניח שמדובר בטלפון Android טיפוסי בפורמט לאורך, שבו סרגל הסטטוס נמצא בחלק העליון, סרגל הניווט נמצא בחלק התחתון ותוכן האפליקציה נמצא בכל שאר המקומות. התוכן של כל שכבה נמצא במאגרים נפרדים. אפשר לטפל בהרכבה באחת מהשיטות הבאות:
- עיבוד (רינדור) של תוכן האפליקציה למאגר שריטות, ואז עיבוד של שורת המצב מעליו, עיבוד של סרגל הניווט מעליו, ולבסוף העברת מאגר השריטה לחומרת המסך.
- העברת כל שלושת המאגרים לחומרת המסך והוראה לו לקרוא נתונים ממאגרים שונים לחלקים שונים של המסך.
הגישה השנייה יכולה להיות יעילה יותר באופן משמעותי.
יכולות מעבד התצוגה משתנות באופן משמעותי. יכול להיות שיהיה קשה להביע באמצעות ממשק API את מספר שכבות-העל, את האפשרות לסובב או למזג שכבות ואת ההגבלות על המיקום והחפיפה. כדי להתאים את האפשרויות האלה, ה-HWC מבצע את החישובים הבאים:
- SurfaceFlinger מספק ל-HWC רשימה מלאה של השכבות ומבקש: "איך רוצים לטפל בזה?"
- התגובה של HWC היא סימון כל שכבה כהרכב של מכשיר או לקוח.
- SurfaceFlinger מטפל בכל לקוח, מעביר את מאגר הפלט ל-HWC ומאפשר ל-HWC לטפל בשאר.
מכיוון שמוכרי החומרה יכולים להתאים אישית את הקוד לקבלת החלטות, אפשר לקבל את הביצועים הטובים ביותר מכל מכשיר.
כשלא קורה כלום במסך, יכול להיות ששימוש בשכבות-על יהיה פחות יעיל מאשר שימוש ב-GL composition. זה נכון במיוחד כשתוכן שכבת-העל מכיל פיקסלים שקופים ושכבות חופפות מעורבבות. במקרים כאלה, ה-HWC יכול לבקש קומפוזיציה של GLES לחלק מהשכבות או לכל השכבות ולשמור את המאגר המורכב. אם SurfaceFlinger מבקש לשלב את אותה קבוצה של מאגרים, ה-HWC יכול להציג את מאגר הגירוד שעבר שילוב קודם. הפעולה הזו יכולה לשפר את חיי הסוללה של מכשיר במצב מנוחה.
בדרך כלל, מכשירי Android תומכים בארבעה מישורי שכבת-על.
ניסיון ליצור קומפוזיציה של יותר שכבות מאשר שכבות-על גורם למערכת להשתמש ב-GLES compositing בחלק מהן. כלומר, מספר השכבות שבהן האפליקציה משתמשת יכול להשפיע באופן מדיד על צריכת החשמל והביצועים.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. 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,["# Hardware Composer HAL\n\nThe Hardware Composer (HWC) HAL determines the most efficient\nway to composite buffers with the available hardware. As a HAL, its\nimplementation is device-specific and usually done by the display hardware OEM.\n\nThe value of this approach is easy to recognize when you consider *overlay\nplanes*, which composite multiple buffers in\nthe display hardware rather than the GPU. For example, consider a typical\nAndroid phone in portrait orientation, with the status bar on top, navigation\nbar at the bottom, and app content everywhere else. The contents for each layer\nare in separate buffers. You can handle composition using either of the\nfollowing methods:\n\n- Rendering the app content into a scratch buffer, then rendering the status bar over it, the navigation bar on top of that, and finally passing the scratch buffer to the display hardware.\n- Passing all three buffers to the display hardware and instructing it to read data from different buffers for different parts of the screen.\n\nThe latter approach can be significantly more efficient.\n\nDisplay processor capabilities vary significantly. The number of overlays,\nwhether layers can be rotated or blended, and restrictions on positioning and\noverlap can be difficult to express through an API. To accommodate these options, the HWC performs\nfollowing calculations:\n\n1. SurfaceFlinger provides HWC with a full list of layers and asks, \"How do you want to handle this?\"\n2. HWC responds by marking each layer as device or client composition.\n3. SurfaceFlinger takes care of any client, passing the output buffer to HWC, and lets HWC handle the rest.\n\nBecause hardware vendors can custom tailor decision-making code, it's possible\nto get the best performance out of every device.\n\nOverlay planes may be less efficient than GL composition when nothing on the\nscreen is changing. This is particularly true when overlay contents have\ntransparent pixels and overlapping layers are blended. In such cases,\nthe HWC can request GLES composition for some or all layers and retain\nthe composited buffer. If SurfaceFlinger asks to composite the same\nset of buffers, the HWC can show the previously composited scratch\nbuffer. This can improve the battery life of an idle device.\n\nAndroid devices typically support four overlay planes.\nAttempting to composite more layers than overlays causes the system to use GLES\ncomposition for some of them, meaning the number of layers used by an app can\nhave a measurable impact on power consumption and performance."]]
