Google is committed to advancing racial equity for Black communities. See how.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

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 Grafikhardware-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

Unabhängig davon, welche Rendering-API-Entwickler verwenden, wird alles auf einer Oberfläche gerendert. Die Oberfläche stellt die Produzentenseite einer Pufferwarteschlange dar, die häufig von SurfaceFlinger verwendet wird. Jedes Fenster, das auf der Android-Plattform erstellt wird, wird von einer Oberfläche unterstützt. Alle gerenderten sichtbaren Flä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 nachfolgend beschrieben:

Bildstromproduzenten

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

Image-Stream-Konsumenten

Der häufigste Benutzer von Bildströmen ist SurfaceFlinger, der Systemdienst, der die aktuell sichtbaren Oberflächen verwendet und sie mithilfe der vom Fenstermanager bereitgestellten Informationen auf dem Display zusammensetzt. 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 zu erstellen.

Andere OpenGL ES-Apps können ebenfalls Bildströme verwenden, z. B. die Kamera-App, die einen Kameravorschau-Bildstrom verwendet. Nicht-GL-Anwendungen können auch Verbraucher sein, beispielsweise die ImageReader-Klasse.

Hardware-Komponist

Die Hardware-Abstraktion für das Anzeige-Subsystem. SurfaceFlinger kann bestimmte Kompositionsarbeiten an den Hardware Composer delegieren, um Arbeiten von OpenGL und der GPU zu verlagern. SurfaceFlinger fungiert nur als ein weiterer OpenGL ES-Client. Wenn SurfaceFlinger beispielsweise einen oder zwei Puffer aktiv zu einem dritten zusammensetzt, verwendet es OpenGL ES. Dies macht das Compositing zu einer geringeren Leistung, als wenn die GPU alle Berechnungen durchführt.

Der Hardware Composer HAL erledigt die andere Hälfte der Arbeit und ist der zentrale Punkt für das Rendern von Android-Grafiken. Der Hardware Composer muss Ereignisse unterstützen, von denen eines VSYNC ist (ein anderes ist Hotplug für Plug-and-Play-HDMI-Unterstützung).

Gralloc

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

Datenfluss

In der folgenden Abbildung finden Sie eine Darstellung der Android-Grafikpipeline:

Grafikdatenfluss

Abbildung 2. Grafikdatenfluss durch Android

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

BufferQueue

BufferQueues stellen den Klebstoff zwischen den Android-Grafikkomponenten bereit. Dies sind zwei Warteschlangen, die den konstanten Pufferzyklus vom Hersteller zum Verbraucher vermitteln. Sobald die Hersteller ihre Puffer übergeben haben, ist SurfaceFlinger dafür verantwortlich, alles auf dem Display zusammenzusetzen.

In der folgenden Abbildung ist der BufferQueue-Kommunikationsprozess dargestellt.

BufferQueue-Kommunikationsprozess

Abbildung 3. BufferQueue-Kommunikationsprozess

BufferQueue enthält die Logik, die Bildstromproduzenten und Bildstromkonsumenten miteinander verbindet. Einige Beispiele für Bildproduzenten sind die Kameravorschauen, die von den Kamera-HAL- oder OpenGL ES-Spielen erstellt wurden. Einige Beispiele für Bildkonsumenten sind SurfaceFlinger oder eine andere App, die einen OpenGL ES-Stream anzeigt, z. B. die Kamera-App, in der der Kamerasucher angezeigt wird.

BufferQueue ist eine Datenstruktur, die einen Pufferpool mit einer Warteschlange kombiniert und Binder IPC verwendet, um Puffer zwischen Prozessen zu übergeben. Die Produzentenschnittstelle oder was Sie an jemanden weitergeben, der Grafikpuffer generieren möchte, ist IGraphicBufferProducer (Teil von SurfaceTexture ). BufferQueue wird häufig verwendet, um unter anderem auf einer Oberfläche zu rendern und mit einem GL-Consumer zu konsumieren.

BufferQueue kann in drei verschiedenen Modi betrieben werden:

Synchroner Modus - BufferQueue arbeitet standardmäßig in einem synchronen Modus, in dem jeder Puffer, der vom Produzenten eingeht, beim Verbraucher ausgeht. In diesem Modus wird niemals ein 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 auch in einem nicht blockierenden Modus betrieben werden, in dem ein Fehler generiert wird, anstatt in diesen Fällen auf einen Puffer zu warten. Auch in diesem Modus wird niemals ein Puffer verworfen. Dies ist nützlich, um potenzielle Deadlocks in Anwendungssoftware zu vermeiden, die die komplexen Abhängigkeiten des Grafikframeworks möglicherweise nicht verstehen.

Verwerfungsmodus - Schließlich kann BufferQueue so konfiguriert werden, dass alte Puffer verworfen werden, anstatt Fehler zu generieren oder zu warten. Wenn Sie beispielsweise das GL-Rendering in einer Texturansicht durchführen und so schnell wie möglich zeichnen, müssen Puffer gelöscht werden.

Um den größten Teil dieser Arbeit auszuführen, fungiert SurfaceFlinger nur als ein weiterer OpenGL ES-Client. Wenn SurfaceFlinger beispielsweise einen oder zwei Puffer aktiv zu einem dritten zusammensetzt, verwendet es OpenGL ES.

Der Hardware Composer HAL führt die andere Hälfte der Arbeit aus. Diese HAL fungiert als zentraler Punkt für das Rendern von Android-Grafiken.