Cómo reducir el consumo de memoria de gráficos

En la pila de gráficos, hay una caché de búfer por capa entre el HAL de Composer y SurfaceFlinger para reducir la sobrecarga asociada con el envío de descriptores de archivos a través de IPC. Antes de Android 14, esta caché de búfer no se purgaba cuando un GraphicBufferProducer se desconectaba de un SurfaceFlinger GraphicBufferConsumer, como cuando un MediaCodec se desconectaba de una SurfaceView. A partir de Android 14, puedes purgar de manera forzosa esta caché del búfer para reducir el consumo de memoria de gráficos.

Elige una de las siguientes opciones:

  • En el caso de los dispositivos que se inician con Android 14 y versiones posteriores, debes implementar la nueva versión 3.2 de la API de HAL de Composer. Esta opción se activa de forma predeterminada y ahorra la mayor cantidad de memoria. Los dispositivos que se actualizan a la versión 14 y versiones posteriores también pueden usar esta opción para obtener todos los beneficios de la memoria.
  • En el caso de los dispositivos que se actualizan a Android 14 para los que no quieres implementar la API de HAL 3.2 de Composer, puedes habilitar la opción retrocompatible. Esta opción ahorra casi tanta memoria como la opción anterior.

En las siguientes dos secciones, se explica cómo implementar cada opción.

Implementa la API de HAL 3.2 de Composer

Para obtener los beneficios completos de la memoria del búfer de gráficos, debes hacer lo siguiente:

  1. Actualiza tu implementación de HAL de Composer a la versión 3.2.
  2. Procesa LayerCommand::bufferSlotsToClear borrando las entradas de la caché del búfer que indican los números de ranura que se encuentran en la lista.

Las APIs de HAL 3.2 de Composer relacionadas con la memoria del búfer gráfico, incluida LayerCommand:bufferSlotsToClear, se encuentran en LayerCommand.aidl-.

Habilita la opción retrocompatible

La opción de reducción de memoria retrocompatible reemplaza un búfer real en la ranura de caché por un búfer de marcador de posición de 1 x 1, lo que genera ahorros de memoria para todas las ranuras que se borraron definitivamente, excepto la ranura de búfer activa actual. Para obtener beneficios de ahorro de memoria parcial, habilita la opción retrocompatible configurando la propiedad del sistema surface_flinger.clear_slots_with_set_layer_buffer en true. Este sysprop se encuentra en el archivo property_contexts.

La configuración de esta propiedad del sistema requiere que la implementación de HAL de Composer controle correctamente varios comandos setLayerBuffer para la misma capa en un solo ciclo de presentación.

Habilitar la opción retrocompatible tiene los siguientes efectos:

  • Para los HAL de AIDL: SurfaceFlinger envía varias instancias de LayerCommand para una sola capa, cada una con un solo BufferCommand. Cada BufferCommand contiene un identificador de búfer de marcador de posición de 1 × 1 y un número de ranura para la ranura del búfer de caché que se debe purgar.

  • Para HAL de HIDL: SurfaceFlinger envía varios comandos SELECT_DISPLAY, SELECT_LAYER y SET_BUFFER. Estos comandos contienen un identificador de búfer de marcador de posición de 1 × 1 y un número de ranura para la ranura del búfer de caché que se debe borrar.

La opción retrocompatible puede provocar que el HAL de Composer falle en algunos dispositivos. Es posible que puedas modificar el HAL de Composer para resolver este problema. El código que controla este comportamiento se encuentra aquí:

Prueba el consumo de memoria caché del búfer de gráficos

Las pruebas no pueden verificar si las implementaciones de HAL purgan los espacios de caché. Sin embargo, puedes usar tus herramientas de depuración para supervisar el uso del búfer gráfico. Mientras realizas la supervisión, deberías notar que hay menos errores de falta de memoria en situaciones en las que se detienen y comienzan varios videos diferentes en rápida sucesión en YouTube.

Hay pruebas de VTS disponibles que verifican que la implementación de HAL sea funcionalmente capaz de recibir las nuevas llamadas a la API (versión HAL 3.2 y versiones posteriores) o varios comandos setLayerBuffer para la implementación retrocompatible. Sin embargo, esto no debe considerarse una prueba suficiente para la funcionalidad adecuada, ya que algunos dispositivos pasan estas pruebas de VTS, pero fallan durante casos de uso reales.

Para las nuevas pruebas de VTS, navega a los siguientes vínculos: