Начиная с 27 марта 2025 г. мы рекомендуем использовать android-latest-release
вместо aosp-main
для создания и участия в AOSP. Дополнительные сведения см. в разделе Изменения в AOSP .
Управление клиентским фреймбуфером
Оптимизируйте свои подборки
Сохраняйте и классифицируйте контент в соответствии со своими настройками.
Начиная с Android 13, новые буферы кадров, используемые во время клиентской композиции, выделяются всякий раз, когда изменяется разрешение дисплея. Это выделение выполняется SurfaceFlinger на следующем цикле invalidate после изменения разрешения.
Управление кадровым буфером во время переключения разрешения
Изменения разрешения происходят по одному из следующих двух сценариев:
Событие горячего подключения , инициируемое Hardware Composer (HWC), которое происходит при переключении с одного внешнего дисплея на другой внешний дисплей с другим разрешением по умолчанию.
Во время события горячего подключения дескрипторы старых буферов кадров освобождаются, когда старые данные дисплея освобождаются.
Переключение режима отображения, инициированное SurfaceFlinger, которое происходит, когда пользователь изменяет разрешение с помощью пользовательских настроек или приложение изменяет разрешение с помощью preferredDisplayModeId
.
Во время переключения режима отображения SurfaceFlinger освобождает дескрипторы существующих клиентских фреймбуферов перед вызовом setActiveConfig
или setActiveConfigWithConstraints
.
Чтобы избежать катастрофических проблем, таких как фрагментация памяти, на устройствах, которые не резервируют достаточно памяти для старых и новых буферов кадров, крайне важно, чтобы HWC прекратил использовать старые буферы кадров и освободил все дескрипторы этих буферов кадров, как показано в следующих случаях:
Освобождение дескрипторов позволяет полностью освободить память буфера кадра перед выделением новых буферов кадра, которое SurfaceFlinger выполняет во время следующего цикла аннулирования .
Рекомендации по управлению кадровым буфером
Если HWC не освобождает дескрипторы старых буферов кадров вовремя, выделение нового буфера кадров происходит до освобождения старого буфера кадров. Это может вызвать катастрофические проблемы, когда новое выделение не удается из-за фрагментации или других проблем. Хуже того, если HWC вообще не освобождает эти дескрипторы, может произойти утечка памяти.
Чтобы избежать катастрофических сбоев распределения, следуйте следующим рекомендациям:
Если HWC необходимо продолжать использовать старые клиентские фреймбуферы до тех пор, пока не будут предоставлены новые клиентские фреймбуферы, то крайне важно зарезервировать достаточно памяти как для старых, так и для новых фреймбуферов и, возможно, запустить алгоритмы дефрагментации в пространстве памяти фреймбуфера.
Выделите выделенный пул памяти для буферов кадров, который отделен от остальной памяти графического буфера. Это важно, поскольку между освобождением и перераспределением буферов кадров сторонний процесс может попытаться выделить графическую память. Если тот же пул графической памяти используется буфером кадров и если графическая память заполнена, сторонний процесс может занять графическую память, ранее выделенную буфером кадров, тем самым оставив недостаточно памяти для перераспределения буфера кадров или, возможно, фрагментируя пространство памяти.
Тестовое управление кадровым буфером
OEM-производителям рекомендуется протестировать правильность управления памятью клиентского буфера кадров на всех переключателях разрешения для своих устройств, как описано ниже:
В случае горячего подключения просто отключите и снова подключите два разных дисплея с разными разрешениями.
Для переключения режимов используйте тест ModeSwitchingTestActivity
CTS Verifier, чтобы инициировать переключение режимов для тестирования поведения памяти кадрового буфера. Этот тест может визуально определить проблемы, которые трудно обнаружить программно.
Контент и образцы кода на этой странице предоставлены по лицензиям. Java и OpenJDK – это зарегистрированные товарные знаки корпорации Oracle и ее аффилированных лиц.
Последнее обновление: 2025-07-29 UTC.
[[["Прост для понимания","easyToUnderstand","thumb-up"],["Помог мне решить мою проблему","solvedMyProblem","thumb-up"],["Другое","otherUp","thumb-up"]],[["Отсутствует нужная мне информация","missingTheInformationINeed","thumb-down"],["Слишком сложен/слишком много шагов","tooComplicatedTooManySteps","thumb-down"],["Устарел","outOfDate","thumb-down"],["Проблема с переводом текста","translationIssue","thumb-down"],["Проблемы образцов/кода","samplesCodeIssue","thumb-down"],["Другое","otherDown","thumb-down"]],["Последнее обновление: 2025-07-29 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."]]