Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.
Interfejs HAL kompozytora sprzętowego
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Komponent sprzętowy (HWC) decyduje o najskuteczniejszym sposobie łączenia buforów za pomocą dostępnego sprzętu. Jako interfejs HAL jest on implementowany w zależności od urządzenia i zwykle jest wykonywany przez producenta OEM wyświetlacza.
Wartość tego podejścia jest łatwa do zrozumienia, gdy weźmiemy pod uwagę płaty nakładek, które łączą wiele buforów w sprzęcie wyświetlacza, a nie na karcie graficznej. Weźmy na przykład typowy telefon z Androidem w orientacji pionowej, z paskiem stanu u góry, paskiem nawigacji u dołu i treścią aplikacji w pozostałych miejscach. Zawartość każdej warstwy znajduje się w osobnych buforach. Kompozycję możesz dostosować na jeden z tych sposobów:
- Renderowanie treści aplikacji w buforze pomocniczym, a następnie renderowanie paska stanu i paska nawigacyjnego, a na końcu przekazanie bufora pomocniczego do wyświetlacza.
- Przekazywanie wszystkich 3 buforów na wyświetlacz i instruowanie go do odczytywania danych z różnych buforów w różnych częściach ekranu.
To drugie podejście może być znacznie wydajniejsze.
Możliwości procesora wyświetlacza różnią się znacznie. Liczba nakładek, możliwość obracania lub mieszania warstw oraz ograniczenia dotyczące pozycjonowania i nakładania mogą być trudne do wyrażenia za pomocą interfejsu API. Aby uwzględnić te opcje, HWC wykonuje te obliczenia:
- SurfaceFlinger przekazuje HWC pełną listę warstw i pyta: „Jak chcesz to zrobić?”.
- HWC reaguje, oznaczając każdą warstwę jako kompozycję urządzenia lub klienta.
- SurfaceFlinger obsługuje dowolnego klienta, przekazując bufor wyjściowy do HWC, a HWC zajmuje się resztą.
Producenci sprzętu mogą dostosowywać kod do podejmowania decyzji, dzięki czemu można uzyskać najlepszą wydajność każdego urządzenia.
Gdy na ekranie nic się nie zmienia, warstwy nakładki mogą być mniej wydajne niż kompozycja GL. Dotyczy to zwłaszcza sytuacji, gdy nakładka zawiera przezroczyste piksele, a nachodzące na siebie warstwy są mieszane. W takich przypadkach HWC może poprosić o kompozycję GLES dla niektórych lub wszystkich warstw i zatrzymać zbufor złożony. Jeśli SurfaceFlinger poprosi o złożenie tego samego zestawu buforów, HWC może wyświetlić wcześniej złożony bufor roboczy. Może to wydłużyć czas pracy urządzenia na baterii.
Urządzenia z Androidem zwykle obsługują 4 poziomy nakładek.
Próba złożenia większej liczby warstw niż nakładek powoduje, że system używa do niektórych z nich kompozycji GLES, co oznacza, że liczba warstw używanych przez aplikację może mieć zauważalny wpływ na zużycie energii i wydajność.
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-27 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 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."]]
