Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.
HAL Hardware Composer
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
HAL Hardware Composer (HWC) menentukan cara paling
efisien untuk menggabungkan buffering dengan hardware yang tersedia. Sebagai HAL, implementasinya bersifat khusus perangkat dan biasanya dilakukan oleh OEM hardware layar.
Nilai pendekatan ini mudah dikenali saat Anda mempertimbangkan bidang
overlay, yang menggabungkan beberapa buffering di
hardware layar, bukan GPU. Misalnya, pertimbangkan ponsel
Android standar dalam orientasi potret, dengan status bar di bagian atas, menu
navigasi di bagian bawah, dan konten aplikasi di tempat lain. Konten untuk setiap lapisan
berada dalam buffering terpisah. Anda dapat menangani komposisi menggunakan salah satu
metode berikut:
- Merender konten aplikasi ke buffer awal, lalu merender status
panel di atasnya, menu navigasi di atasnya, dan terakhir meneruskan buffer awal
ke hardware layar.
- Meneruskan ketiga buffering ke hardware layar dan menginstruksikannya untuk membaca data
dari buffering yang berbeda untuk bagian layar yang berbeda.
Pendekatan yang terakhir dapat secara signifikan lebih efisien.
Kemampuan prosesor layar bervariasi secara signifikan. Jumlah overlay,
apakah lapisan dapat diputar atau digabungkan, dan batasan pada pemosisian dan
tumpang-tindih mungkin sulit untuk diekspresikan melalui API. Untuk mengakomodasi opsi ini, HWC melakukan
perhitungan berikut:
- SurfaceFlinger menyediakan daftar lengkap lapisan kepada HWC dan bertanya, "Bagaimana
Anda ingin menangani ini?"
- HWC merespons dengan menandai setiap lapisan sebagai komposisi perangkat atau klien.
- SurfaceFlinger menangani klien apa pun, meneruskan buffer output
ke HWC, dan memungkinkan HWC menangani sisanya.
Karena vendor hardware dapat menyesuaikan kode pengambilan keputusan secara khusus, Anda dapat
mendapatkan performa terbaik dari setiap perangkat.
Bidang overlay mungkin kurang efisien daripada komposisi GL jika tidak ada yang berubah di
layar. Hal ini terutama berlaku saat konten overlay memiliki
piksel transparan dan lapisan yang tumpang-tindih digabungkan. Dalam kasus tersebut,
HWC dapat meminta komposisi GLES untuk beberapa atau semua lapisan dan mempertahankan
buffer gabungan. Jika SurfaceFlinger meminta untuk menggabungkan kumpulan buffering
yang sama, HWC dapat menampilkan buffering
awal yang telah digabungkan sebelumnya. Hal ini dapat meningkatkan masa pakai baterai perangkat yang tidak ada aktivitasnya.
Perangkat Android biasanya mendukung empat bidang overlay.
Mencoba menggabungkan lebih banyak lapisan daripada overlay menyebabkan sistem menggunakan komposisi
GLES untuk beberapa lapisan, yang berarti jumlah lapisan yang digunakan oleh aplikasi dapat
memiliki dampak yang dapat diukur pada konsumsi daya dan performa.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]
