Grafik

Android Graphics HAL-Symbol

Das Android-Framework bietet eine Vielzahl von Grafik-Rendering-APIs für 2D und 3D, die mit Herstellerimplementierungen von Grafiktreibern interagieren. Daher ist es wichtig, ein gutes Verständnis dafür zu haben, wie diese APIs auf einer höheren Ebene funktionieren. Auf dieser Seite wird die Grafik-Hardware-Abstraktionsschicht (HAL) vorgestellt, auf der diese Treiber basieren.

Anwendungsentwickler zeichnen Bilder auf drei Arten auf den Bildschirm: mit Canvas , OpenGL ES oder Vulkan .

Android-Grafikkomponenten

Egal welche Rendering-API-Entwickler verwenden, alles wird auf einer Oberfläche gerendert. Die Oberfläche stellt die Produzentenseite einer Pufferwarteschlange dar, die häufig von SurfaceFlinger genutzt wird. Jedes Fenster, das auf der Android-Plattform erstellt wird, wird von einer Oberfläche unterstützt. Alle gerenderten sichtbaren Oberflächen werden von SurfaceFlinger auf dem Display zusammengesetzt.

Das folgende Diagramm zeigt, wie die Schlüsselkomponenten zusammenarbeiten:

Bildwiedergabekomponenten

Abbildung 1. Wie Oberflächen gerendert werden

Die Hauptkomponenten werden im Folgenden beschrieben:

Bildstream-Produzenten

Ein Bildstromproduzent kann alles sein, was Grafikpuffer zur Verwendung erzeugt. Beispiele hierfür sind OpenGL ES, Canvas 2D und Mediaserver-Videodecoder.

Konsumenten von Bildstreams

Der häufigste Konsument von Bildstreams ist SurfaceFlinger, der Systemdienst, der die aktuell sichtbaren Oberflächen konsumiert und sie mithilfe der vom Fenstermanager bereitgestellten Informationen auf dem Display zusammenfügt. SurfaceFlinger ist der einzige Dienst, der den Inhalt der Anzeige ändern kann. SurfaceFlinger verwendet OpenGL und den Hardware Composer, um eine Gruppe von Oberflächen zusammenzustellen.

Andere OpenGL ES-Apps können ebenfalls Bildstreams konsumieren, beispielsweise die Kamera-App, die einen Kameravorschau-Bildstream konsumiert. Auch Nicht-GL-Anwendungen können Verbraucher sein, beispielsweise die ImageReader-Klasse.

Hardware-Komponist

Die Hardwareabstraktion für das Anzeigesubsystem. SurfaceFlinger kann bestimmte Kompositionsarbeiten an den Hardware Composer delegieren, um OpenGL und die GPU von der Arbeit zu befreien. SurfaceFlinger fungiert lediglich als ein weiterer OpenGL ES-Client. Wenn SurfaceFlinger beispielsweise aktiv einen oder zwei Puffer zu einem dritten zusammenfügt, verwendet es OpenGL ES. Dies macht das Compositing weniger energieintensiv, als wenn die GPU alle Berechnungen durchführen würde.

Der Hardware Composer HAL übernimmt die andere Hälfte der Arbeit und ist der zentrale Punkt für das gesamte Android-Grafik-Rendering. Der Hardware Composer muss Ereignisse unterstützen, darunter VSYNC (ein anderes ist Hotplug für Plug-and-Play-HDMI-Unterstützung).

Gralloc

Der Grafikspeicher-Allokator (Gralloc) wird benötigt, um von Bildproduzenten angeforderten Speicher zuzuweisen. Einzelheiten finden Sie unter Gralloc HAL .

Datenfluss

Eine Darstellung der Android-Grafikpipeline finden Sie im folgenden Diagramm:

Grafikdatenfluss

Abbildung 2. Grafischer Datenfluss durch Android

Die Objekte auf der linken Seite sind Renderer, die Grafikpuffer erzeugen, z. B. den Startbildschirm, die Statusleiste und die Systembenutzeroberfläche. SurfaceFlinger ist der Compositor und Hardware Composer ist der Composer.

BufferQueue

BufferQueues sorgen für die Verbindung zwischen den Android-Grafikkomponenten. Hierbei handelt es sich um ein Warteschlangenpaar, das den ständigen Pufferzyklus vom Produzenten zum Konsumenten vermittelt. Sobald die Produzenten ihre Puffer übergeben, ist SurfaceFlinger dafür verantwortlich, alles auf dem Display zusammenzusetzen.

Sehen Sie sich das folgende Diagramm für den BufferQueue-Kommunikationsprozess an.

BufferQueue-Kommunikationsprozess

Abbildung 3. BufferQueue-Kommunikationsprozess

BufferQueue enthält die Logik, die Bildstream-Produzenten und Bildstream-Konsumenten miteinander verbindet. Einige Beispiele für Bildproduzenten sind die von der Kamera-HAL oder OpenGL ES-Spielen erzeugten Kameravorschauen. Einige Beispiele für Bildkonsumenten sind SurfaceFlinger oder eine andere App, die einen OpenGL ES-Stream anzeigt, beispielsweise die Kamera-App, die den Kamerasucher anzeigt.

BufferQueue ist eine Datenstruktur, die einen Pufferpool mit einer Warteschlange kombiniert und Binder IPC verwendet, um Puffer zwischen Prozessen zu übergeben. Die Producer-Schnittstelle bzw. das, was Sie jemandem übergeben, der Grafikpuffer generieren möchte, ist IGraphicBufferProducer (Teil von SurfaceTexture ). BufferQueue wird unter anderem häufig zum Rendern auf einer Oberfläche und zum Konsumieren mit einem GL-Consumer verwendet.

BufferQueue kann in drei verschiedenen Modi betrieben werden:

Synchron-ähnlicher Modus – BufferQueue arbeitet standardmäßig in einem synchron-ähnlichen Modus, in dem jeder Puffer, der vom Produzenten eingeht, beim Verbraucher ausgegeben wird. In diesem Modus wird kein Puffer verworfen. Und wenn der Produzent zu schnell ist und Puffer schneller erstellt, als sie geleert werden, blockiert er und wartet auf freie Puffer.

Nicht blockierender Modus – BufferQueue kann in diesen Fällen auch in einem nicht blockierenden Modus arbeiten, in dem es einen Fehler generiert, anstatt auf einen Puffer zu warten. Auch in diesem Modus wird kein Puffer verworfen. Dies ist nützlich, um potenzielle Deadlocks in Anwendungssoftware zu vermeiden, die die komplexen Abhängigkeiten des Grafik-Frameworks möglicherweise nicht versteht.

Verwerfungsmodus – Schließlich kann BufferQueue so konfiguriert werden, dass alte Puffer verworfen werden, anstatt Fehler zu generieren oder zu warten. Wenn beispielsweise das GL-Rendering in eine Texturansicht und das Zeichnen so schnell wie möglich durchgeführt werden sollen, müssen Puffer gelöscht werden.

Um den Großteil dieser Arbeit zu erledigen, fungiert SurfaceFlinger lediglich als ein weiterer OpenGL ES-Client. Wenn SurfaceFlinger beispielsweise aktiv einen oder zwei Puffer zu einem dritten zusammenfügt, verwendet es OpenGL ES.

Der Hardware Composer HAL übernimmt die andere Hälfte der Arbeit. Dieser HAL fungiert als zentraler Punkt für das gesamte Android-Grafik-Rendering.