Reduce el consumo de memoria gráfica

En la pila de gráficos, una caché de búfer por capa se encuentra 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, el sistema no borraba esta caché de búfer cuando un GraphicBufferProducer se desconectaba del GraphicBufferConsumer de SurfaceFlinger, por ejemplo, cuando un MediaCodec se desconectaba de un 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 dos opciones:

  • En el caso de los dispositivos que se lancen con Android 14 y versiones posteriores, debes implementar la nueva versión 3.2 de la API de la HAL de Composer. Esta opción se activa de forma predeterminada y ahorra la mayor cantidad de memoria. Los dispositivos que se actualicen a la versión 14 y posteriores también pueden usar esta opción para aprovechar al máximo los beneficios de la memoria.
  • En el caso de los dispositivos que se actualizan a Android 14 y para los que no deseas implementar la API de Composer HAL 3.2, puedes habilitar la opción retrocompatible. Esta opción ahorra casi la misma cantidad de memoria que la opción anterior.

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

Implementa la API de HAL de Composer 3.2

Para aprovechar al máximo los beneficios de la memoria del búfer de gráficos, debes hacer lo siguiente:

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

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

Habilita la opción de retrocompatibilidad

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. Esto genera un ahorro de memoria para todos los espacios purgados, excepto para el espacio de búfer activo actual. Para obtener beneficios parciales de ahorro de memoria, habilita la opción retrocompatible estableciendo la propiedad del sistema surface_flinger.clear_slots_with_set_layer_buffer en true. Esta propiedad del sistema se encuentra en el archivo property_contexts.

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

Habilitar la opción compatible con versiones anteriores tiene los siguientes efectos:

  • En el caso de 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 x 1 y un número de ranura para la ranura de búfer de caché que requiere purga.

  • Para los 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 x 1 y un número de ranura para la ranura de búfer de caché que requiere purga.

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

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

Las pruebas no pueden verificar si las implementaciones de HAL purgan las ranuras de caché. Sin embargo, puedes usar tus herramientas de depuración para supervisar el uso del búfer de gráficos. Mientras supervisas, es posible que notes menos errores de memoria insuficiente en situaciones en las que se detienen y se inician rápidamente varios videos diferentes 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 de HAL 3.2 o posterior) o varios comandos setLayerBuffer para la implementación retrocompatible. Sin embargo, esto no se debe considerar una prueba suficiente para la funcionalidad adecuada, ya que algunos dispositivos pasan estas pruebas de VTS, pero fallan durante los casos de uso reales.

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