В графическом стеке буферный кэш каждого уровня располагается между Composer HAL и SurfaceFlinger, что позволяет снизить накладные расходы, связанные с отправкой файловых дескрипторов по IPC. До Android 14 этот буферный кэш не очищался при отключении GraphicBufferProducer
от SurfaceFlinger GraphicBufferConsumer
, например, при отключении MediaCodec от SurfaceView. Начиная с Android 14, этот буферный кэш можно принудительно очистить для снижения потребления графической памяти.
Выберите один из двух следующих вариантов:
- Для устройств с Android 14 и более поздних версий необходимо реализовать новый Composer HAL API версии 3.2. Эта опция активирована по умолчанию и обеспечивает максимальную экономию памяти. Устройства, обновляемые до версии 14 и более поздних версий, также могут использовать эту опцию для максимального использования памяти.
- Для устройств, обновляющихся до Android 14 и не требующих реализации API Composer HAL 3.2, можно включить опцию обратной совместимости. Эта опция экономит почти столько же памяти, сколько и предыдущая.
В следующих двух разделах объясняется, как реализовать каждый вариант.
Реализовать API Composer HAL 3.2
Чтобы получить все преимущества памяти графического буфера, необходимо:
- Обновите реализацию Composer HAL до версии 3.2.
- Обработать
LayerCommand::bufferSlotsToClear
, очистив записи кэша буфера, указанные номерами слотов, найденными в списке.
API Composer HAL 3.2, связанные с графической буферной памятью, включая LayerCommand:bufferSlotsToClear
, находятся в LayerCommand.aidl-
.
Включить опцию обратной совместимости
Опция обратно-совместимого сокращения памяти заменяет реальный буфер в слоте кэша буфером-заполнителем 1x1, что приводит к экономии памяти во всех очищенных слотах, за исключением текущего активного слота буфера. Для достижения частичной экономии памяти включите опцию обратно-совместимого сокращения памяти, установив системное свойство surface_flinger.clear_slots_with_set_layer_buffer
в значение true
. Это системное свойство находится в файле property_contexts
.
Настройка этого системного свойства требует, чтобы ваша реализация Composer HAL правильно обрабатывала несколько команд setLayerBuffer
для одного и того же слоя в одном текущем цикле.
Включение опции обратной совместимости имеет следующие последствия:
Для HAL-ов AIDL: SurfaceFlinger отправляет несколько экземпляров
LayerCommand
для одного слоя, каждый с однимBufferCommand
. КаждыйBufferCommand
содержит дескриптор буфера-заполнителя размером 1x1 и номер слота для кэш-буфера, который необходимо очистить.Для HIDL HAL: SurfaceFlinger отправляет несколько команд
SELECT_DISPLAY
,SELECT_LAYER
иSET_BUFFER
. Эти команды содержат дескриптор буфера размером 1x1 и номер слота кэш-буфера, который необходимо очистить.
Обратная совместимость может привести к сбою Composer HAL на некоторых устройствах. Возможно, вам удастся решить эту проблему, изменив Composer HAL. Код, управляющий этим поведением, находится здесь:
Тест потребления кэш-памяти графического буфера
Тесты не позволяют проверить, очищаются ли слоты кэша реализациями HAL. Однако вы можете использовать инструменты отладки для мониторинга использования графического буфера. В процессе мониторинга вы заметите, что ошибок нехватки памяти становится меньше в сценариях, где на YouTube быстро останавливается и запускается несколько разных видео подряд.
Доступны тесты VTS, которые проверяют, что реализация HAL функционально способна принимать вызовы нового API (HAL версии 3.2+) или несколько команд setLayerBuffer
для обратно совместимой реализации. Однако этого недостаточно для проверки корректной работы, поскольку некоторые устройства проходят эти тесты VTS, но не справляются в реальных условиях эксплуатации.
Для получения информации о новых тестах VTS перейдите по следующим ссылкам:
Совместимость с HIDL:
GraphicsComposerHidlCommandTest::SET_LAYER_BUFFER_multipleTimes
Совместимость с AIDL 3.1:
GraphicsComposerAidlCommandTest::SetLayerBufferMultipleTimes
AIDL 3.2:
GraphicsComposerAidlCommandV2Test::SetLayerBufferSlotsToClear