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 aufbauen.
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 Erzeugerseite 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 Oberflächen werden von SurfaceFlinger auf dem Display zusammengesetzt.
Das folgende Diagramm zeigt, wie die Schlüsselkomponenten zusammenarbeiten:
Abbildung 1. Wie Oberflächen gerendert werden
Die Hauptkomponenten werden im Folgenden beschrieben:
Image-Stream-Produzenten
Ein Bildstrom-Erzeuger kann alles sein, was Grafikpuffer für den Verbrauch erzeugt. Beispiele hierfür sind OpenGL ES, Canvas 2D und Mediaserver-Videodecoder.
Verbraucher von Bildströmen
Der häufigste Konsument von Bildstreams ist SurfaceFlinger, der Systemdienst, der die aktuell sichtbaren Oberflächen nutzt 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 zusammenzustellen.
Andere OpenGL ES-Apps können ebenfalls Bildstreams nutzen, beispielsweise die Kamera-App, die einen Kameravorschau-Bildstream nutzt. Nicht-GL-Anwendungen können auch Verbraucher sein, zum Beispiel die ImageReader-Klasse.
Hardware-Komponist
Die Hardwareabstraktion für das Anzeigesubsystem. SurfaceFlinger kann bestimmte Kompositionsarbeiten an den Hardware Composer delegieren, um Arbeit von OpenGL und der GPU zu entlasten. SurfaceFlinger fungiert als nur ein weiterer OpenGL ES-Client. Wenn SurfaceFlinger beispielsweise aktiv einen oder zwei Puffer zu einem dritten zusammensetzt, verwendet es OpenGL ES. Dadurch wird das Compositing energiesparender, als wenn die GPU alle Berechnungen durchführt.
Der Hardware Composer HAL übernimmt die andere Hälfte der Arbeit und ist die zentrale Stelle für alle Android-Grafikwiedergaben. 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 Grafikspeicherzuordner (Gralloc) wird benötigt, um den von Bildproduzenten angeforderten Speicher zuzuweisen. Einzelheiten finden Sie unter Gralloc HAL .
Datenfluss
Im folgenden Diagramm finden Sie eine Darstellung der Android-Grafikpipeline:
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 stellen das Bindeglied zwischen den Android-Grafikkomponenten bereit. Dies sind zwei Warteschlangen, die den konstanten Zyklus von Puffern vom Erzeuger zum Verbraucher vermitteln. Sobald die Hersteller ihre Puffer übergeben, ist SurfaceFlinger dafür verantwortlich, alles auf dem Display zusammenzusetzen.
Siehe das folgende Diagramm für den BufferQueue-Kommunikationsprozess.
Abbildung 3. BufferQueue-Kommunikationsprozess
BufferQueue enthält die Logik, die Bildstromerzeuger und Bildstromverbraucher miteinander verbindet. Einige Beispiele für Bilderzeuger sind die Kameravorschauen, die von den Kamera-HAL- oder OpenGL ES-Spielen erzeugt werden. Einige Beispiele für Bildkonsumenten sind SurfaceFlinger oder eine andere App, die einen OpenGL ES-Stream anzeigt, z. B. 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 oder das, was Sie jemandem übergeben, 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-Verbraucher zu konsumieren.
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 Erzeuger 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 arbeiten, in dem es einen Fehler generiert, anstatt in diesen Fällen 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 Grafikframeworks 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 ein GL-Rendering in eine Texturansicht und ein Zeichnen so schnell wie möglich durchgeführt wird, müssen Puffer gelöscht werden.
Um den größten Teil dieser Arbeit auszuführen, fungiert SurfaceFlinger als nur ein weiterer OpenGL ES-Client. Wenn SurfaceFlinger beispielsweise aktiv einen oder zwei Puffer zu einem dritten zusammensetzt, verwendet es OpenGL ES.
Die andere Hälfte der Arbeit übernimmt der Hardware Composer HAL. Diese HAL fungiert als zentraler Punkt für das gesamte Android-Grafik-Rendering.