Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Arquitectura gráfica

Lo que todo desarrollador debe saber sobre superficies, SurfaceHolder, EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView, SurfaceFlinger y Vulkan.

Esta página describe los elementos esenciales de la arquitectura de gráficos a nivel del sistema Android y cómo los utiliza el marco de la aplicación y el sistema multimedia. La atención se centra en cómo se mueven los búferes de datos gráficos a través del sistema. Si alguna vez se ha preguntado por qué SurfaceView y TextureView se comportan de la forma en que lo hacen, o cómo interactúan las superficies y EGLSurface, está en el lugar correcto.

Se asume cierta familiaridad con los dispositivos Android y el desarrollo de aplicaciones. No necesita un conocimiento detallado del marco de la aplicación y se mencionan muy pocas llamadas a la API, pero el material no se superpone con otra documentación pública. El objetivo es proporcionar detalles sobre los eventos importantes involucrados en la representación de un marco para la salida para ayudarlo a tomar decisiones informadas al diseñar una aplicación. Para lograr esto, trabajamos de abajo hacia arriba, describiendo cómo funcionan las clases de IU en lugar de cómo se pueden usar.

Esta sección incluye varias páginas que cubren todo, desde material de antecedentes hasta detalles de HAL y casos de uso. Comienza con una explicación de los búferes de gráficos de Android, describe la composición y el mecanismo de visualización, luego pasa a los mecanismos de nivel superior que proporcionan datos al compositor. Recomendamos leer las páginas en el orden que se indica a continuación en lugar de saltar a un tema que suene interesante.

Componentes de bajo nivel

  • BufferQueue y gralloc . BufferQueue conecta algo que genera búferes de datos gráficos (el productor ) con algo que acepta los datos para su visualización o procesamiento posterior (el consumidor ). Las asignaciones de búfer se realizan a través del asignador de memoria gralloc implementado a través de una interfaz HAL específica del proveedor.
  • SurfaceFlinger, Hardware Composer y pantallas virtuales . SurfaceFlinger acepta búferes de datos de múltiples fuentes, los compone y los envía a la pantalla. Hardware Composer HAL (HWC) determina la forma más eficiente de componer búferes con el hardware disponible, y las pantallas virtuales hacen que la salida compuesta esté disponible dentro del sistema (grabando la pantalla o enviando la pantalla a través de una red).
  • Superficie, lienzo y SurfaceHolder . Una superficie produce una cola de búfer que SurfaceFlinger suele consumir. Al renderizar en una superficie, el resultado termina en un búfer que se envía al consumidor. Las API de Canvas proporcionan una implementación de software (con soporte de aceleración de hardware) para dibujar directamente en una superficie (alternativa de bajo nivel a OpenGL ES). Todo lo que tenga que ver con una vista implica un SurfaceHolder, cuyas API permiten obtener y configurar parámetros de superficie como el tamaño y el formato.
  • EGLSurface y OpenGL ES . OpenGL ES (GLES) define una API de representación de gráficos diseñada para combinarse con EGL , una biblioteca que puede crear y acceder a ventanas a través del sistema operativo (para dibujar polígonos texturizados, use llamadas GLES; para poner la representación en la pantalla, use llamadas EGL ). Esta página también cubre ANativeWindow, el equivalente C / C ++ de la clase Java Surface utilizada para crear una superficie de ventana EGL a partir de código nativo.
  • Vulkan . Vulkan es una API multiplataforma de baja sobrecarga para gráficos 3D de alto rendimiento. Al igual que OpenGL ES, Vulkan proporciona herramientas para crear gráficos de alta calidad en tiempo real en aplicaciones. Las ventajas de Vulkan incluyen reducciones en la sobrecarga de la CPU y soporte para el lenguaje intermedio binario SPIR-V .

Componentes de alto nivel

  • SurfaceView y GLSurfaceView . SurfaceView combina una superficie y una vista. Los componentes de vista de SurfaceView están compuestos por SurfaceFlinger (y no por la aplicación), lo que permite la representación desde un hilo / proceso separado y el aislamiento de la representación de la interfaz de usuario de la aplicación. GLSurfaceView proporciona clases auxiliares para administrar contextos EGL, comunicación entre subprocesos e interacción con el ciclo de vida de la actividad (pero no es necesario para usar GLES).
  • SurfaceTexture . SurfaceTexture combina una superficie y una textura GLES para crear un BufferQueue para el que su aplicación es el consumidor. Cuando un productor pone en cola un nuevo búfer, notifica a su aplicación, que a su vez libera el búfer previamente retenido, adquiere el nuevo búfer de la cola y realiza llamadas EGL para que el búfer esté disponible para GLES como una textura externa. Android 7.0 agregó soporte para la reproducción de video de textura segura que permite el posprocesamiento de GPU de contenido de video protegido.
  • TextureView . TextureView combina una vista con SurfaceTexture. TextureView envuelve una SurfaceTexture y asume la responsabilidad de responder a las devoluciones de llamada y adquirir nuevos búferes. Al dibujar, TextureView usa el contenido del búfer recibido más recientemente como su fuente de datos, renderizando donde y como el estado de la vista lo indique. La composición de la vista siempre se realiza con GLES, lo que significa que las actualizaciones de contenido pueden hacer que otros elementos de la vista también se vuelvan a dibujar.