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.
Zarządzanie framebufferem klienta
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Od Androida 13 nowe framebuffery używane podczas komponowania przez klienta są przydzielane, gdy tylko zmieni się rozdzielczość wyświetlacza. Ta alokacja jest wykonywana przez SurfaceFlinger w następnym cyklu unieważniania po zmianie rozdzielczości.
Zarządzanie ramką obrazu podczas przełączania rozdzielczości
Zmiany rozdzielczości występują w jednym z tych 2 sposobów:
Wydarzenie hotplug, które jest inicjowane przez sterownik sprzętowy (HWC) i występuje podczas przełączania się z jednego zewnętrznego wyświetlacza na inny zewnętrzny wyświetlacz o innej domyślnej rozdzielczości.
Podczas zdarzenia hotplug uchwyty starych framebufferów są uwalniane, gdy stare dane wyświetlania zostaną zwolnione.
Przełączanie trybu wyświetlania inicjowane przez SurfaceFlinger, które występuje, gdy użytkownik zmienia rozdzielczość za pomocą ustawień użytkownika lub gdy aplikacja zmienia rozdzielczość za pomocą preferredDisplayModeId
.
Podczas przełączania trybu wyświetlania uchwyty istniejących framebufferów klienta są uwalniane przez SurfaceFlingera przed wywołaniem funkcji setActiveConfig
lub setActiveConfigWithConstraints
.
Aby uniknąć katastrofalnych problemów, takich jak fragmentacja pamięci, na urządzeniach, które nie zarezerwowały wystarczającej ilości pamięci dla starych i nowych ramek framebuffera, ważne jest, aby HWC przestało używać starych ramek framebuffera i zwolnić wszystkie uchwyty do tych ramek w tych przypadkach:
Zwolnienie uchwytów umożliwia całkowite zwolnienie pamięci buforowej framebuffera przed przydzieleniem nowych framebufferów, które SurfaceFlinger wykonuje podczas następnego cyklu unieważniania.
Rekomendacje dotyczące zarządzania framebufferem
Jeśli HWC nie zwolni uchwytów starych framebufferów na czas, przydzielenie nowego framebuffera nastąpi przed zwolnieniem starego. Może to spowodować katastrofalne problemy, gdy nowa alokacja nie powiedzie się z powodu fragmentacji lub innych problemów. Co gorsza, jeśli HWC w ogóle nie zwolni tych uchwytów, może dojść do wycieku pamięci.
Aby uniknąć poważnych błędów przydzielania, postępuj zgodnie z tymi zaleceniami:
Jeśli HWC musi nadal używać starych buforów ramki klienta do czasu udostępnienia nowych buforów ramki klienta, należy zarezerwować wystarczającą ilość pamięci dla starych i nowych buforów ramki oraz ewentualnie uruchomić algorytmy defragmentacji na przestrzeni pamięci bufora ramki.
Przydziela osobną pulę pamięci na potrzeby framebufferów, która jest oddzielona od reszty pamięci bufora graficznego. Jest to ważne, ponieważ w czasie oddzielenia i przeniesienia framebufferów proces zewnętrzny może próbować przydzielić pamięć graficzną. Jeśli ten sam pulę pamięci graficznej używa bufora ramki, a pamięć graficzna jest pełna, proces zewnętrzny może zająć pamięć graficzną przydzieloną wcześniej przez bufor ramki, pozostawiając w ten sposób niewystarczającą ilość pamięci na przydzielenie bufora ramki lub powodując fragmentację przestrzeni pamięci.
Testowanie zarządzania framebufferem
Producenci OEM powinni przetestować prawidłowe zarządzanie pamięcią buforową klienta na różnych przełącznikach rozdzielczości na urządzeniu, jak opisano poniżej:
W przypadku zdarzeń związanych z podłączeniem wystarczy odłączyć i ponownie podłączyć 2 różne wyświetlacze o różnych rozdzielczościach.
W przypadku przełączania trybów użyj testu ModeSwitchingTestActivity
weryfikatora CTS, aby zainicjować przełączenie trybu w celu przetestowania zachowania pamięci framebuffera.
Ten test może wizualnie zidentyfikować problemy, które są trudne do wykrycia za pomocą programów.
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,["# 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."]]