Уменьшите потребление графической памяти

В графическом стеке кэш буфера каждого уровня находится между Composer HAL и SurfaceFlinger, чтобы уменьшить накладные расходы, связанные с отправкой файловых дескрипторов по IPC. До Android 14 этот кэш буфера не очищался, когда GraphicBufferProducer отключался от SurfaceFlinger GraphicBufferConsumer , например, когда MediaCodec отключался от SurfaceView. Начиная с Android 14, вы можете принудительно очистить этот кэш буфера, чтобы уменьшить потребление графической памяти.

Выберите один из двух следующих вариантов:

  • Для устройств, запускаемых с Android 14 и выше, необходимо реализовать новый Composer HAL API версии 3.2. Эта опция активирована по умолчанию и экономит большую часть памяти. Устройства, обновляемые до 14 и выше, также могут использовать эту опцию для достижения полного преимущества памяти.
  • Для устройств, обновляющихся до Android 14, для которых вы не хотите внедрять Composer HAL 3.2 API, вы можете включить опцию обратной совместимости. Эта опция экономит почти столько же памяти, сколько и предыдущая опция.

В следующих двух разделах объясняется, как реализовать каждый вариант.

Реализовать API Composer HAL 3.2

Чтобы получить все преимущества памяти графического буфера, необходимо:

  1. Обновите реализацию Composer HAL до версии 3.2.
  2. Обработайте LayerCommand::bufferSlotsToClear , очистив записи кэша буфера, указанные номерами слотов, найденными в списке.

API Composer HAL 3.2, связанные с графической буферной памятью, включая LayerCommand:bufferSlotsToClear , находятся в LayerCommand.aidl- .

Включить опцию обратной совместимости

Опция сокращения памяти с обратной совместимостью заменяет реальный буфер в слоте кэша на буфер-заполнитель 1x1, что приводит к экономии памяти для всех очищенных слотов, за исключением текущего активного слота буфера. Чтобы добиться частичной экономии памяти, включите опцию обратной совместимости, установив sysprop surface_flinger.clear_slots_with_set_layer_buffer в true . Это sysprop находится в файле property_contexts .

Настройка этого системного свойства требует, чтобы реализация Composer HAL корректно обрабатывала несколько команд setLayerBuffer для одного и того же слоя в одном текущем цикле.

Включение опции обратной совместимости имеет следующие последствия:

  • Для AIDL HAL: 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 перейдите по следующим ссылкам: