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.
İstemci çerçeve belleği yönetimi
Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Android 13'ten itibaren, ekran çözünürlüğü her değiştiğinde istemci oluşturma sırasında kullanılan yeni çerçeve tamponları ayrılır. Bu atama, çözünürlük değişikliğinden sonraki bir sonraki invalidate döngüsünde SurfaceFlinger tarafından gerçekleştirilir.
Çözünürlük geçişleri sırasında çerçeve arabelleği yönetimi
Çözünürlük değişiklikleri aşağıdaki iki senaryodan biri nedeniyle gerçekleşir:
Donanım Oluşturucu (HWC) tarafından başlatılan ve bir harici ekrandan farklı bir varsayılan çözünürlüğe sahip farklı bir harici ekrana geçiş yapıldığında gerçekleşen bir hotplug etkinliği.
Bir hotplug etkinliği sırasında, eski ekran verileri tahsis edildiğinde eski çerçeve belleklerinin tutamaçlarının ayrılması gerekir.
Kullanıcı kullanıcı ayarlarıyla çözünürlüğü değiştirdiğinde veya bir uygulama preferredDisplayModeId
ile çözünürlüğü değiştirdiğinde SurfaceFlinger tarafından başlatılan ekran modu geçişi.
Ekran modu değiştirilirken, mevcut istemci çerçeve belleklerinin tutamaçları setActiveConfig
veya setActiveConfigWithConstraints
çağrılmadan önce SurfaceFlinger tarafından serbest bırakılır.
Eski ve yeni çerçeve tamponları için yeterli bellek ayırmayan cihazlarda bellek parçalanması gibi ciddi sorunları önlemek için HWC'nin eski çerçeve tamponlarını kullanmayı bırakması ve aşağıdaki durumlarda gösterildiği gibi bu çerçeve tamponlarına ait tüm imleçleri serbest bırakması kritik önem taşır:
İşaretçileri serbest bırakmak, SurfaceFlinger'ın bir sonraki invalidate döngüsü sırasında gerçekleştirdiği yeni çerçeve belleklerinin tahsisinden önce çerçeve belleğinin tamamen tahsis edilmesini sağlar.
Görüntü çerçevesi yönetimiyle ilgili öneriler
HWC, eski çerçeve belleklerinin tutamacını zamanında serbest bırakmazsa yeni çerçeve belleği ayırma işlemi, eski çerçeve belleğinin serbest bırakılmasından önce gerçekleşir. Bu durum, yeni tahsis işlemi parçalanma veya başka sorunlar nedeniyle başarısız olduğunda ciddi sorunlara neden olabilir. Daha da kötüsü, HWC bu imleçleri hiç serbest bırakmazsa hafıza sızıntısı meydana gelebilir.
Yıkıcı düzeyde atama hatalarını önlemek için aşağıdaki önerileri uygulayın:
HWC'nin yeni istemci çerçeve bellekleri sağlanana kadar eski istemci çerçeve belleklerini kullanmaya devam etmesi gerekiyorsa hem eski hem de yeni çerçeve bellekleri için yeterli bellek ayırmak ve muhtemelen çerçeve bellek alanında birleştirme algoritmaları çalıştırmak kritik önem taşır.
Görüntü çerçeveleri için, grafik arabellek belleğinin geri kalanından ayrı bir özel bellek havuzu ayırın. Bu, ekran kartı belleğinin ayrılması ve yeniden ayrılması arasında üçüncü taraf bir işlemin grafik belleği ayırmaya çalışabileceği için önemlidir. Aynı grafik bellek havuzu, çerçeve önbelleği tarafından kullanılıyorsa ve grafik belleği doluysa üçüncü taraf işlemi, daha önce bir çerçeve önbelleği tarafından ayrılan grafik belleğini işgal edebilir. Bu da çerçeve önbelleği yeniden atama işlemi için yetersiz bellek bırakır veya bellek alanını parçalara böler.
Test çerçeve ara belleği yönetimi
OEM'lerin, cihazlarının çözünürlük anahtarları arasında istemci ön çerçeve bellek yönetiminin uygun olup olmadığını test etmeleri önerilir. Bu test aşağıdaki gibi açıklanır:
Sıcak takma etkinlikleri için farklı çözünürlüklere sahip iki farklı ekranı çıkarıp yeniden takmanız yeterlidir.
Mod geçişleri için, ekran kartı belleği davranışını test etmek üzere bir mod geçişi başlatmak amacıyla ModeSwitchingTestActivity
CTS Doğrulayıcı testini kullanın.
Bu test, programatik olarak tespit edilmesi zor olan sorunları görsel olarak tanımlayabilir.
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,["# Client framebuffer management\n\nStarting with Android 13, new framebuffers, used during\n[client](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/DisplayCommand.aidl#113)\ncomposition, are allocated whenever the display resolution changes. This\nallocation is performed by SurfaceFlinger on the next *invalidate* cycle\nafter a resolution change.\n\nFramebuffer management during resolution switches\n-------------------------------------------------\n\nResolution changes occur due to one of the following\ntwo scenarios:\n\n- A [hotplug event](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerCallback.aidl#41),\n initiated by Hardware Composer (HWC), which occurs when swapping from one external\n display to a different external display that has a different default resolution.\n\n During a hotplug event, the handles to the old framebuffers are released\n when the old display data is deallocated.\n- A display mode switch initiated by SurfaceFlinger, which occurs when the\n user changes the resolution with [user settings](https://android.googlesource.com/platform/frameworks/base/+/refs/heads/android16-release/core/java/android/hardware/display/DisplayManager.java#1209),\n or an app changes the resolution with [`preferredDisplayModeId`](https://developer.android.com/reference/android/view/WindowManager.LayoutParams#preferredDisplayModeId).\n\n During a display mode switch, the handles to existing client framebuffers\n are released by SurfaceFlinger before calling [`setActiveConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#550)\n or [`setActiveConfigWithConstraints`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#577).\n\nTo avoid catastrophic problems, such as memory fragmentation, on devices that\ndon't reserve enough memory for the old and new framebuffers, it's critical\nthat HWC ceases to use the old framebuffers and releases any\nhandles to these framebuffers as shown in the following cases:\n\n- For hotplug events, immediately before calling [`onHotplug`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerCallback.aidl#41).\n\n- For mode switches, immediately after the call to [`setActiveConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#550)\n or [`setActiveConfigWithConstraints`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#577).\n\nReleasing the handles allows the framebuffer memory to be fully deallocated\nprior to the allocation of new framebuffers that SurfaceFlinger performs\nduring the next *invalidate* cycle.\n\n### Recommendations for framebuffer management\n\nIf HWC doesn't release handles to old framebuffers in time,\nthe new framebuffer allocation takes place before the old framebuffer\ndeallocation. This can cause catastrophic problems when the new allocation fails\ndue to fragmentation or other issues. Even worse, if\nHWC doesn't release these handles at all, a memory leak can\noccur.\n\nTo avoid catastrophic allocation failures, follow these recommendations:\n\n- If HWC needs to continue using the old client framebuffers until the new\n client framebuffers are provided, then it's critical to reserve enough memory\n for both the old and new framebuffers, and possibly run defragmentation\n algorithms on the framebuffer memory space.\n\n- Allocate a dedicated memory pool for the framebuffers that's separate from\n the rest of the graphic buffer memory. This is important because between\n deallocation and reallocation of the framebuffers, a third-party process can\n attempt to allocate graphics memory. If the same graphics memory pool is\n used by the framebuffer and if the graphics memory is full, the third-party\n process can occupy the graphics memory previously allocated by a framebuffer,\n thus leaving insufficient memory for the framebuffer reallocation or, possibly\n fragmenting the memory space.\n\nTest framebuffer management\n---------------------------\n\nOEMs are advised to test for proper client framebuffer memory management across\nresolution switches for their device, described as follows:\n\n- For hotplug events, simply unplug and reconnect two different displays with\n different resolutions.\n\n- For mode switches, use the [`ModeSwitchingTestActivity`](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/apps/CtsVerifier/src/com/android/cts/verifier/tv/display/ModeSwitchingTestActivity.java;l=47-53;drc=c80d948aff1e7df5c2dc0ddba0d1cd63a90e4d9c) CTS\n Verifier test to initiate a mode switch for testing framebuffer memory behavior.\n This test can visually identify problems that are hard to detect\n programmatically."]]