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 (API-Element)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.
android.graphics.drawable kompiliert.
Weitere Informationen zu drawables und anderen Ressourcen finden Sie unter Ressourcen.
android.opengl und javax.microedition.khronos.opengles stellen OpenGL ES-Funktionen bereit.Surface (API-Element)Surface-Objekts. Verwenden Sie die Klasse SurfaceView anstelle der Klasse Surface.
SurfaceView (API-Element)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.
R.style aufgeführt und mit Theme_ vorangestellt sind.View (API-Element)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.
ViewGroup (API-Element)widget, erweitern aber die Klasse ViewGroup.
android.widget. Window (API-Element)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:
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:
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.
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.