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

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

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

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

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

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

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

  1. Обновите реализацию Composer HAL до версии 3.2.
  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 смотрите следующие ссылки: