Grafiken

Symbol für Android Graphics HAL

Das Android-Framework bietet eine Vielzahl von APIs für die Grafikdarstellung für 2D und 3D, die mit den Implementierungen von Grafiktreibern der Hersteller interagieren. Daher ist es wichtig, die Funktionsweise dieser APIs auf höherer Ebene zu verstehen. Auf dieser Seite wird die Grafikhardware-Abstraktionsschicht (HAL) vorgestellt, auf der diese Treiber basieren. Bevor Sie mit diesem Abschnitt fortfahren, sollten Sie sich mit den folgenden Begriffen vertraut machen:

Canvas (generischer Begriff), Canvas (API-Element)
Ein Canvas ist eine Zeichenfläche, die das Zusammensetzen der tatsächlichen Bits mit einer Bitmap oder einem Surface-Objekt übernimmt. Canvas bietet Methoden für die standardmäßige Computerzeichnung von Bitmaps, Linien, Kreisen, Rechtecken, Text usw. und ist an eine Bitmap oder Oberfläche gebunden. Ein Canvas ist die einfachste Möglichkeit, 2D-Objekte auf dem Bildschirm zu zeichnen. Die Basisklasse ist Canvas.
drawable
Ein drawable ist eine kompilierte visuelle Ressource, die als Hintergrund, Titel oder ein anderer Teil des Bildschirms verwendet werden kann. Ein drawable wird in der Regel in ein anderes UI-Element geladen, z. B. als Hintergrundbild. Ein drawable kann keine Ereignisse empfangen, aber verschiedene andere Eigenschaften wie Status und Planung zuweisen, um Unterklassen wie Animationsobjekte oder Bildbibliotheken zu ermöglichen. Viele Zeichnen-Objekte werden aus Drawable-Ressourcendateien geladen – XML- oder Bitmap-Dateien, die das Bild beschreiben. Zeichbare Ressourcen werden in Unterklassen von android.graphics.drawable kompiliert. Weitere Informationen zu drawables und anderen Ressourcen finden Sie unter Ressourcen.
layout resource
Eine Layoutressource ist eine XML-Datei, die das Layout eines Aktivitätsbildschirms beschreibt. Weitere Informationen finden Sie unter Layoutressource.
Nine-Patch (9-Patch, NinePatch)
Ein Nine-Patch-Bild ist eine skalierbare Bitmap-Ressource, die für Hintergründe oder andere Bilder auf dem Gerät verwendet werden kann. Weitere Informationen finden Sie unter Nine-Patch.
OpenGL ES
OpenGL ES ist eine plattformübergreifende API zum Rendern von 2D- und 3D-Grafiken. Android bietet OpenGL ES-Bibliotheken für hardwaregestütztes 3D-Rendering. Für das 2D-Rendering ist ein Canvas die einfachere Option. OpenGL ES ist im Android Native Development Kit (NDK) verfügbar. Die Pakete android.opengl und javax.microedition.khronos.opengles stellen OpenGL ES-Funktionen bereit.
Oberfläche (generischer Begriff), Surface (API-Element)
Eine Oberfläche stellt einen Speicherblock dar, der auf dem Bildschirm zusammengesetzt wird. Eine Oberfläche enthält ein Canvas zum Zeichnen und bietet verschiedene Hilfsmethoden zum Zeichnen von Ebenen und zum Ändern der Größe des Surface-Objekts. Verwenden Sie die Klasse SurfaceView anstelle der Klasse Surface.
Surface View (generischer Begriff), SurfaceView (API-Element)
Eine Oberflächenansicht ist ein View-Objekt, das ein Surface-Objekt zum Zeichnen umschließt und Methoden zum dynamischen Angeben der Größe und des Formats bereitstellt. Eine Oberflächenansicht bietet die Möglichkeit, unabhängig vom UI-Thread für ressourcenintensive Vorgänge wie Spiele oder Kameravorschauen zu zeichnen. Dadurch wird jedoch zusätzlicher Arbeitsspeicher belegt. Eine Oberflächenansicht unterstützt sowohl Canvas- als auch OpenGL ES-Grafik. Die Basisklasse für ein SurfaceView-Objekt ist SurfaceView.
theme
Ein Design besteht aus einer Reihe von Eigenschaften wie Textgröße und Hintergrundfarbe, die zusammen verschiedene Standardanzeigeeinstellungen definieren. Android bietet einige Standardthemen, die in R.style aufgeführt und mit Theme_ vorangestellt sind.
Ansicht (generischer Begriff), View (API-Element)
Eine Ansicht zeichnet einen rechteckigen Bereich auf dem Bildschirm und verarbeitet Klicks, Tastenanschläge und andere Interaktionsereignisse. Die Klasse View ist die Basisklasse für die meisten Layoutkomponenten einer Aktivität oder eines Dialogfelds, z. B. Textfelder und Fenster. Ein View-Objekt erhält von seinem übergeordneten Objekt (siehe ViewGroup) Aufforderungen, sich selbst zu zeichnen, und informiert dieses über seine bevorzugte Größe und Position. Diese werden vom übergeordneten Objekt möglicherweise nicht berücksichtigt. Weitere Informationen finden Sie unter View.
Ansichtsgruppe (generischer Begriff), ViewGroup (API-Element)
Eine Ansichtsgruppe gruppiert eine Reihe von untergeordneten Ansichten. Die Ansichtsgruppe ist dafür verantwortlich, wo untergeordnete Ansichten positioniert werden und wie groß sie sein können. Außerdem wird dort festgelegt, wann die einzelnen Ansichten gezeichnet werden sollen. Einige Ansichtsgruppen sind unsichtbar und dienen nur dem Layout, während andere eine eigene Benutzeroberfläche haben, z. B. ein scrollbares Listenfeld. Ansichtsgruppen befinden sich im Paket widget, erweitern aber die Klasse ViewGroup.
Hierarchie anzeigen
Eine Ansichtshierarchie ist eine Anordnung von Ansichts- und Ansichtsgruppenobjekten, die die Benutzeroberfläche für jede Komponente einer App definiert. Die Hierarchie besteht aus Ansichtsgruppen, die eine oder mehrere untergeordnete Ansichten oder Ansichtsgruppen enthalten. Mit dem Hierarchy Viewer, der im Android SDK enthalten ist, können Sie eine visuelle Darstellung einer Ansichtshierarchie für die Fehlerbehebung und Optimierung abrufen.
Vulkan
Vulkan ist eine plattformübergreifende API mit geringem Overhead für leistungsstarke 3D-Grafiken.
Widget
Ein Widget ist eine von mehreren vollständig implementierten Ansichtsunterklassen, die Formularelemente und andere UI-Komponenten wie ein Textfeld oder ein Pop-up-Menü rendern. Da ein Widget vollständig implementiert ist, werden Messungen, das Zeichnen und die Reaktion auf Bildschirmereignisse von ihm selbst ausgeführt. Widgets befinden sich im Paket android.widget.
Fenster (generischer Begriff), Window (API-Element)
In einer Android-App ist ein Fenster ein Objekt, das von der abstrakten Klasse Window abgeleitet ist und die Elemente eines generischen Fensters angibt, z. B. das Erscheinungsbild, den Text in der Titelleiste sowie die Position und den Inhalt von Menüs. Für Dialoge und Aktivitäten wird eine Implementierung der Klasse Window verwendet, um ein Window-Objekt zu rendern. Sie müssen die Klasse Window nicht implementieren und auch keine Fenster in Ihrer App verwenden.

App-Entwickler können Bilder auf drei Arten auf dem Bildschirm zeichnen: 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 sichtbaren Oberflächen, die gerendert werden, werden von SurfaceFlinger auf dem Display zusammengesetzt.

Das folgende Diagramm zeigt, wie die Hauptkomponenten zusammenwirken:

Komponenten für das Bild-Rendering

Abbildung 1: Wie Oberflächen gerendert werden.

Die Hauptkomponenten werden unten beschrieben:

Image-Stream-Produzenten

Ein Bildstream-Produzent kann alles sein, was Grafik-Buffer für die Nutzung erzeugt. Beispiele sind OpenGL ES, Canvas 2D und Mediaserver-Videodekoder.

Image-Stream-Nutzer

Der häufigste Nutzer von Bildstreams ist SurfaceFlinger, der Systemdienst, der die derzeit sichtbaren Oberflächen nutzt und sie mit Informationen des Fenstermanagers auf dem Display zusammensetzt. SurfaceFlinger ist der einzige Dienst, der den Inhalt des Displays ändern kann. SurfaceFlinger verwendet OpenGL und den Hardware-Composer, um eine Gruppe von Oberflächen zu erstellen.

Auch andere OpenGL ES-Apps können Bildstreams nutzen, z. B. die Kamera-App, die einen Bildstream der Kameravorschau nutzt. Auch Nicht-GL-Apps können Verbraucher sein, z. B. die ImageReader-Klasse.

Hardware Composer

Die Hardwareabstraktion für das Display-Subsystem. SurfaceFlinger kann bestimmte Kompositionen an den Hardware-Composer delegieren, um OpenGL und die GPU zu entlasten. SurfaceFlinger fungiert nur als weiterer OpenGL ES-Client. Wenn SurfaceFlinger also einen oder zwei Buffers aktiv in einen dritten zusammensetzt, verwendet er beispielsweise OpenGL ES. Dadurch ist der Stromverbrauch beim Compositing geringer als wenn die GPU alle Berechnungen durchführt.

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

Gralloch

Der Grafikspeicher-Allocator (Gralloc) ist erforderlich, um von Bildproduzenten angeforderten Arbeitsspeicher zuzuweisen. Weitere Informationen finden Sie unter Gralloc HAL.

Datenfluss

Das folgende Diagramm zeigt die Android-Grafikpipeline:

Grafikdatenfluss

Abbildung 2: Grafischer Datenfluss durch Android

Die Objekte auf der linken Seite sind Renderer, die Grafik-Buffer erstellen, z. B. für den Startbildschirm, die Statusleiste und die System-UI. SurfaceFlinger ist der Compositor und Hardware Composer ist der Komponist.

BufferQueue

BufferQueues dienen als Bindeglied zwischen den Android-Grafikkomponenten. Dies sind zwei Warteschlangen, die den ständigen Zyklus der Puffer vom Erzeuger zum Verbraucher vermitteln. Sobald die Produzenten ihre Buffers übergeben haben, ist SurfaceFlinger dafür verantwortlich, alles auf dem Display zusammenzusetzen.

Das folgende Diagramm zeigt den Kommunikationsvorgang von BufferQueue.

BufferQueue-Kommunikationsprozess

Abbildung 3: BufferQueue-Kommunikationsprozess

BufferQueue enthält die Logik, die Bildstream-Produzenten und Bildstream-Nutzer verbindet. Beispiele für Bilderzeuger sind die Kameravorschauen, die von der Kamera-HAL oder OpenGL ES-Spielen erstellt werden. Beispiele für Bildverbraucher sind SurfaceFlinger oder eine andere App, die einen OpenGL ES-Stream anzeigt, z. B. die Kamera-App, die den Sucher der Kamera anzeigt.

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

BufferQueue kann in drei verschiedenen Modi ausgeführt werden:

Synchroner Modus: BufferQueue arbeitet standardmäßig in einem synchronen Modus, in dem jeder Puffer, der vom Erzeuger kommt, an den Verbraucher gesendet wird. In diesem Modus wird kein Puffer verworfen. Wenn der Produzent zu schnell ist und Puffer schneller erstellt, als sie geleert werden, wird er blockiert und wartet auf kostenlose Puffer.

Nicht blockierender Modus: BufferQueue kann auch im nicht blockierenden Modus ausgeführt werden, in dem in diesen Fällen ein Fehler generiert wird, 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.

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

Für die meisten dieser Aufgaben fungiert SurfaceFlinger als ein weiterer OpenGL ES-Client. Wenn SurfaceFlinger also einen oder zwei Buffers aktiv in einen dritten zusammensetzt, verwendet er OpenGL ES.

Die Hardware Composer HAL führt die andere Hälfte der Arbeit aus. Diese HAL dient als zentraler Punkt für das gesamte Android-Grafik-Rendering.