A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
HAL de Hardware Composer
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
La HAL de Hardware Composer (HWC) determina la forma más eficiente de combinar búferes con el hardware disponible. Como HAL, su implementación es específica del dispositivo y, por lo general, la realiza el OEM de hardware de la pantalla.
El valor de este enfoque es fácil de reconocer cuando consideras los planos superpuestos, que combinan varios búferes en el hardware de la pantalla en lugar de la GPU. Por ejemplo, considera un teléfono Android típico en orientación vertical, con la barra de estado en la parte superior, la barra de navegación en la parte inferior y el contenido de la app en todas partes. El contenido de cada capa se encuentra en búferes separados. Puedes controlar la composición con uno de los siguientes métodos:
- Renderiza el contenido de la app en un búfer de borrado en blanco, luego renderiza la barra de estado sobre él, la barra de navegación sobre esa, y, por último, pasa el búfer de borrado en blanco al hardware de la pantalla.
- Pasar los tres búferes al hardware de la pantalla y ordenarle que lea datos de diferentes búferes para diferentes partes de la pantalla
El último enfoque puede ser mucho más eficiente.
Las capacidades del procesador de la pantalla varían de forma significativa. La cantidad de superposiciones, si las capas se pueden rotar o combinar, y las restricciones de posicionamiento y superposición pueden ser difíciles de expresar a través de una API. Para admitir estas opciones, el HWC realiza los siguientes cálculos:
- SurfaceFlinger proporciona a HWC una lista completa de capas y le pregunta: "¿Cómo quieres controlar esto?".
- HWC responde marcando cada capa como composición del dispositivo o del cliente.
- SurfaceFlinger se encarga de cualquier cliente, pasa el búfer de salida a HWC y permite que HWC controle el resto.
Debido a que los proveedores de hardware pueden personalizar el código de toma de decisiones, es posible obtener el mejor rendimiento de cada dispositivo.
Los planos superpuestos pueden ser menos eficientes que la composición de GL cuando no cambia nada en la pantalla. Esto es especialmente cierto cuando el contenido superpuesto tiene píxeles transparentes y las capas superpuestas se combinan. En esos casos, el HWC puede solicitar la composición de GLES para algunas o todas las capas y retener el búfer compuesto. Si SurfaceFlinger solicita combinar el mismo conjunto de búferes, el HWC puede mostrar el búfer de borrado compuesto anteriormente. Esto puede mejorar la duración de batería de un dispositivo inactivo.
Por lo general, los dispositivos Android admiten cuatro planos superpuestos.
Si intentas combinar más capas que superposiciones, el sistema usará la composición de GLES para algunas de ellas, lo que significa que la cantidad de capas que usa una app puede tener un impacto medible en el consumo de energía y el rendimiento.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]
