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. Bevor Sie mit diesem Abschnitt fortfahren, machen Sie sich mit den folgenden Begriffen vertraut:

Canvas (allgemeiner Begriff), Canvas (API-Element)
Eine Leinwand ist eine Zeichenoberfläche, die die Zusammenstellung der tatsächlichen Bits anhand einer Bitmap oder eines Surface übernimmt. Canvas verfügt über Methoden zum standardmäßigen Computerzeichnen von Bitmaps, Linien, Kreisen, Rechtecken, Text usw. und ist an eine Bitmap oder Oberfläche gebunden. Eine Leinwand ist die einfachste und einfachste Möglichkeit, 2D-Objekte auf dem Bildschirm zu zeichnen. Die Basisklasse ist Canvas .
zeichnbar
Ein Drawable ist eine zusammengestellte visuelle Ressource, die als Hintergrund, Titel oder anderer Teil des Bildschirms verwendet werden kann. Ein Drawable wird normalerweise in ein anderes UI-Element geladen, beispielsweise als Hintergrundbild. Ein Drawable ist nicht in der Lage, Ereignisse zu empfangen, weist jedoch verschiedene andere Eigenschaften wie Status und Zeitplanung zu, um Unterklassen wie Animationsobjekte oder Bildbibliotheken zu ermöglichen. Viele zeichnbare Objekte werden aus zeichnbaren Ressourcendateien geladen – XML- oder Bitmap-Dateien, die das Bild beschreiben. Zeichenbare Ressourcen werden in Unterklassen von android.graphics.drawable kompiliert. Weitere Informationen zu Drawables und anderen Ressourcen finden Sie unter Ressourcen .
Layout-Ressource
Eine Layoutressource ist eine XML-Datei, die das Layout eines Aktivitätsbildschirms beschreibt. Weitere Informationen finden Sie unter Layout-Ressource .
Neun-Patch (9-Patch, NinePatch)
Ein Nine-Patch ist eine in der Größe veränderbare 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 stellt OpenGL ES-Bibliotheken für hardwarebeschleunigtes 3D-Rendering bereit. Für das 2D-Rendering ist eine Leinwand die einfachere Option. OpenGL ES ist im Android Native Development Kit (NDK) verfügbar. Die Pakete android.opengl und javax.microedition.khronos.opengles stellen die OpenGL ES-Funktionalität bereit.
Oberfläche (allgemeiner Begriff), Surface (API-Element)
Eine Oberfläche stellt einen Speicherblock dar, der auf dem Bildschirm zusammengesetzt wird. Eine Oberfläche enthält eine Leinwand zum Zeichnen und bietet verschiedene Hilfsmethoden zum Zeichnen von Ebenen und zum Ändern der Größe des Surface . Verwenden Sie direkt die SurfaceView Klasse anstelle der Surface Klasse.
Oberflächenansicht (allgemeiner Begriff), SurfaceView (API-Element)
Eine Oberflächenansicht ist ein View Objekt, das ein Surface Objekt zum Zeichnen umschließt und Methoden zur dynamischen Angabe seiner Größe und seines Formats bereitstellt. Eine Oberflächenansicht bietet eine Möglichkeit, unabhängig vom UI-Thread für ressourcenintensive Vorgänge wie Spiele oder Kameravorschauen zu zeichnen, benötigt dadurch aber zusätzlichen Speicher. Eine Oberflächenansicht unterstützt sowohl Canvas- als auch OpenGL ES-Grafiken. Die Basisklasse für ein SurfaceView Objekt ist SurfaceView .
Thema
Ein Design besteht aus einer Reihe von Eigenschaften wie Textgröße und Hintergrundfarbe, die gebündelt sind, um verschiedene Standardanzeigeeinstellungen zu definieren. Android bietet einige Standardthemen, die in R.style aufgeführt sind und denen Theme_ vorangestellt ist.
view (allgemeiner Begriff), View (API-Element)
Eine Ansicht zeichnet einen rechteckigen Bereich auf dem Bildschirm und verarbeitet Klick-, Tastenanschlag- und andere Interaktionsereignisse. Die View Klasse ist die Basisklasse für die meisten Layoutkomponenten eines Aktivitäts- oder Dialogbildschirms, wie z. B. Textfelder und Fenster. Ein View Objekt empfängt Aufrufe von seinem übergeordneten Objekt (siehe ViewGroup ), um sich selbst zu zeichnen, und informiert sein übergeordnetes Objekt über seine bevorzugte Größe und Position, die vom übergeordneten Objekt möglicherweise nicht respektiert werden. Weitere Informationen finden Sie unter View .
Ansichtsgruppe (allgemeiner Begriff), ViewGroup (API-Element)
Eine Ansichtsgruppe gruppiert eine Reihe untergeordneter Ansichten. Die Ansichtsgruppe ist dafür verantwortlich, zu entscheiden, wo untergeordnete Ansichten positioniert werden und wie groß sie sein können, sowie dafür, dass sie bei Bedarf jede Ansicht selbst zeichnen. Einige Ansichtsgruppen sind unsichtbar und dienen nur dem Layout, während andere über eine integrierte Benutzeroberfläche verfügen, z. B. ein Listenfeld mit Bildlauf. Ansichtsgruppen sind im widget Paket enthalten, erweitern jedoch die ViewGroup Klasse.
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. Sie können eine visuelle Darstellung einer Ansichtshierarchie zum Debuggen und Optimieren erhalten, indem Sie den Hierarchie-Viewer verwenden, der mit dem Android SDK geliefert wird.
Vulkan
Vulkan ist eine plattformübergreifende API mit geringem Overhead für leistungsstarke 3D-Grafiken.
Widget
Ein Widget gehört zu einer Reihe vollständig implementierter Ansichtsunterklassen, die Formularelemente und andere UI-Komponenten wie ein Textfeld oder ein Popup-Menü rendern. Da ein Widget vollständig implementiert ist, übernimmt es die Messung, das Zeichnen selbst und die Reaktion auf Bildschirmereignisse. Widgets befinden sich im Paket android.widget .
Fenster (allgemeiner Begriff), Window (API-Element)
In einer Android-App ist ein Fenster ein von der abstrakten Klasse Window abgeleitetes Objekt, das die Elemente eines generischen Fensters angibt, z. B. das Erscheinungsbild, den Titelleistentext sowie die Position und den Inhalt von Menüs. Dialoge und Aktivitäten verwenden eine Implementierung der Window Klasse, um ein Window Objekt darzustellen. Sie müssen die Window Klasse nicht implementieren oder Windows in Ihrer App verwenden.

App-Entwickler 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-Apps 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 Konsumenten 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.