27 Mart 2025'ten itibaren AOSP'yi derlemek ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleyi inceleyin.
Donanım Bestecisi HAL
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Donanım Oluşturucu (HWC) HAL, mevcut donanımla arabellekleri birleştirmenin en verimli yolunu belirler. HAL olarak uygulanması cihaza özgüdür ve genellikle ekran donanım OEM'si tarafından yapılır.
GPU yerine ekran donanımında birden fazla arabelleği birleştiren yer paylaşımı düzlemlerini göz önünde bulundurduğunuzda bu yaklaşımın değerini kolayca anlayabilirsiniz. Örneğin, dikey yönde bir Android telefonu düşünün. Bu telefonun üst kısmında durum çubuğu, alt kısmında gezinme çubuğu ve diğer kısımlarında uygulama içeriği yer alıyor. Her katmanın içeriği ayrı arabelleklerdedir. Kompozisyonu aşağıdaki yöntemlerden birini kullanarak yönetebilirsiniz:
- Uygulama içeriğini bir geçici arabelleğe, ardından durum çubuğunu ve bunun üzerine gezinme çubuğunu oluşturma ve son olarak geçici arabelleği ekran donanımına aktarma.
- Üç tamponun da ekran donanımına aktarılması ve ekranın farklı bölümleri için farklı tamponlardan veri okuması talimatı verilmesi.
İkinci yaklaşım çok daha verimli olabilir.
Görüntü işlemci özellikleri önemli ölçüde değişiklik gösterir. Yer paylaşımı sayısının, katmanların döndürülüp döndürülemeyeceğinin veya harmanlanıp harmanlanamayacağının, konumlandırma ve çakışmayla ilgili kısıtlamaların API aracılığıyla ifade edilmesi zor olabilir. HWC, bu seçenekleri karşılamak için aşağıdaki hesaplamaları yapar:
- SurfaceFlinger, HWC'ye katmanların tam listesini sağlar ve "Bunu nasıl işlemek istiyorsunuz?" diye sorar.
- HWC, her katmanı cihaz veya istemci bileşimi olarak işaretleyerek yanıt verir.
- SurfaceFlinger, çıkış arabelleğini HWC'ye aktararak tüm istemcileri yönetir ve gerisini HWC'ye bırakır.
Donanım tedarikçileri karar verme kodunu özelleştirebildiğinden her cihazdan en iyi performansı elde etmek mümkündür.
Ekrandaki hiçbir şey değişmediğinde yer paylaşımı düzlemleri GL kompozisyonundan daha verimsiz olabilir. Bu durum özellikle yer paylaşımı içeriklerinde şeffaf pikseller olduğunda ve örtüşen katmanlar karıştırıldığında geçerlidir. Bu gibi durumlarda, HWC bazı veya tüm katmanlar için GLES bileşimi isteyebilir ve birleştirilmiş arabelleği saklayabilir. SurfaceFlinger aynı arabellek grubunu birleştirmeyi isterse HWC, daha önce birleştirilmiş olan çizim arabelleğini gösterebilir. Bu, boşta duran bir cihazın pil ömrünü uzatabilir.
Android cihazlar genellikle dört yer paylaşımı düzlemi destekler.
Yer paylaşımlarından daha fazla katman oluşturmaya çalışmak, sistemin bazı katmanlar için GLES kompozisyonu kullanmasına neden olur. Bu da bir uygulamanın kullandığı katman sayısının güç tüketimi ve performans üzerinde ölçülebilir bir etkisi olabileceği anlamına gelir.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[[["Anlaması kolay","easyToUnderstand","thumb-up"],["Sorunumu çözdü","solvedMyProblem","thumb-up"],["Diğer","otherUp","thumb-up"]],[["İhtiyacım olan bilgiler yok","missingTheInformationINeed","thumb-down"],["Çok karmaşık / çok fazla adım var","tooComplicatedTooManySteps","thumb-down"],["Güncel değil","outOfDate","thumb-down"],["Çeviri sorunu","translationIssue","thumb-down"],["Örnek veya kod sorunu","samplesCodeIssue","thumb-down"],["Diğer","otherDown","thumb-down"]],["Son güncelleme tarihi: 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."]]
