Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.
Hardware Composer HAL
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Die HAL des Hardware-Composers (HWC) bestimmt die effizienteste Methode, Buffers mit der verfügbaren Hardware zu kombinieren. Als HAL ist die Implementierung gerätespezifisch und wird in der Regel vom OEM der Displayhardware durchgeführt.
Der Wert dieses Ansatzes wird schnell klar, wenn man sich Overlay-Ebenen ansieht, bei denen mehrere Buffers in der Displayhardware und nicht in der GPU zusammengesetzt werden. Stellen Sie sich beispielsweise ein typisches Android-Smartphone im Hochformat vor, mit der Statusleiste oben, der Navigationsleiste unten und App-Inhalten überall sonst. Die Inhalte der einzelnen Ebenen befinden sich in separaten Buffers. Sie können die Zusammensetzung mit einer der folgenden Methoden verarbeiten:
- Die App-Inhalte werden in einem Scratch-Puffer gerendert, dann die Statusleiste darüber und die Navigationsleiste darüber. Schließlich wird der Scratch-Puffer an die Displayhardware übergeben.
- Alle drei Puffer an die Displayhardware übergeben und sie anweisen, Daten aus verschiedenen Puffern für verschiedene Bereiche des Bildschirms zu lesen.
Letzterer Ansatz kann wesentlich effizienter sein.
Die Funktionen von Displayprozessoren variieren erheblich. Die Anzahl der Overlays, ob Ebenen gedreht oder überlagert werden können und Einschränkungen bei Positionierung und Überlappung können über eine API nur schwer ausgedrückt werden. Um diese Optionen zu berücksichtigen, führt das HWC die folgenden Berechnungen durch:
- SurfaceFlinger stellt HWC eine vollständige Liste der Ebenen zur Verfügung und fragt: „Wie möchten Sie das handhaben?“
- HWC reagiert, indem jede Schicht als Geräte- oder Clientzusammensetzung gekennzeichnet wird.
- SurfaceFlinger kümmert sich um jeden Client, übergibt den Ausgabepuffer an HWC und lässt HWC den Rest erledigen.
Da Hardwareanbieter den Entscheidungscode anpassen können, ist es möglich, mit jedem Gerät die bestmögliche Leistung zu erzielen.
Overlay-Ebenen sind möglicherweise weniger effizient als GL-Kompositionen, wenn sich auf dem Bildschirm nichts ändert. Das gilt insbesondere, wenn Overlay-Inhalte transparente Pixel haben und sich überlappende Ebenen überlagern. In solchen Fällen kann der HWC die GLES-Komposition für einige oder alle Ebenen anfordern und den zusammengesetzten Buffer beibehalten. Wenn SurfaceFlinger denselben Satz von Buffers zusammenstellen möchte, kann der HWC den zuvor zusammengesetzten Scratch-Puffer anzeigen. Dadurch kann die Akkulaufzeit eines inaktiv stehenden Geräts verlängert werden.
Android-Geräte unterstützen in der Regel vier Overlay-Ebenen.
Wenn Sie versuchen, mehr Ebenen als Overlays zu kombinieren, verwendet das System für einige von ihnen die GLES-Komposition. Die Anzahl der von einer App verwendeten Ebenen kann sich also messbar auf den Energieverbrauch und die Leistung auswirken.
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2025-07-27 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 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."]]
