À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release
au lieu de aosp-main
pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
HAL Hardware Composer
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Le HAL du compilateur matériel (HWC) détermine le moyen le plus efficace de composer des tampons avec le matériel disponible. En tant que HAL, son implémentation est spécifique à l'appareil et est généralement effectuée par l'OEM du matériel d'affichage.
La valeur de cette approche est facile à reconnaître lorsque vous considérez les plans de superposition, qui composent plusieurs tampons dans le matériel d'affichage plutôt que dans le GPU. Prenons l'exemple d'un téléphone Android typique en mode portrait, avec la barre d'état en haut, la barre de navigation en bas et le contenu de l'application partout ailleurs. Le contenu de chaque calque se trouve dans des tampons distincts. Vous pouvez gérer la composition à l'aide de l'une des méthodes suivantes:
- Rendu du contenu de l'application dans un tampon de travail, puis rendu de la barre d'état par-dessus, de la barre de navigation par-dessus, et enfin transmission du tampon de travail au matériel d'affichage.
- Transmettre les trois tampons au matériel d'affichage et lui demander de lire les données de différents tampons pour différentes parties de l'écran.
Cette dernière approche peut être considérablement plus efficace.
Les fonctionnalités des processeurs d'affichage varient considérablement. Le nombre de superpositions, la possibilité de faire pivoter ou de mélanger les calques, ainsi que les restrictions concernant le positionnement et la superposition peuvent être difficiles à exprimer via une API. Pour prendre en charge ces options, le contrôleur matériel effectue les calculs suivants:
- SurfaceFlinger fournit à HWC une liste complète des calques et demande : "Comment voulez-vous gérer cela ?"
- Le HWC répond en marquant chaque couche comme composition de l'appareil ou du client.
- SurfaceFlinger s'occupe de tous les clients, transfère le tampon de sortie à HWC et laisse HWC gérer le reste.
Étant donné que les fournisseurs de matériel peuvent adapter le code de prise de décision, il est possible d'obtenir les meilleures performances de chaque appareil.
Les plans de superposition peuvent être moins efficaces que la composition GL lorsque rien ne change à l'écran. Cela est particulièrement vrai lorsque les contenus superposés comportent des pixels transparents et que les calques superposés sont mélangés. Dans ce cas, le HWC peut demander une composition GLES pour une partie ou la totalité des calques et conserver le tampon composite. Si SurfaceFlinger demande à composer le même ensemble de tampons, le HWC peut afficher le tampon de travail précédemment composé. Cela peut améliorer l'autonomie de la batterie d'un appareil inactif.
Les appareils Android acceptent généralement quatre plans de superposition.
Si vous essayez de composer plus de calques que de superpositions, le système utilise la composition GLES pour certains d'entre eux. Par conséquent, le nombre de calques utilisés par une application peut avoir un impact mesurable sur la consommation d'énergie et les performances.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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."]]