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 (API-Element)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 .android.graphics.drawable kompiliert. Weitere Informationen zu Drawables und anderen Ressourcen finden Sie unter Ressourcen .android.opengl und javax.microedition.khronos.opengles stellen die OpenGL ES-Funktionalität bereit.Surface (API-Element)Surface . Verwenden Sie direkt die SurfaceView Klasse anstelle der Surface Klasse.SurfaceView (API-Element)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 .R.style aufgeführt sind und denen Theme_ vorangestellt ist.View (API-Element)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 .ViewGroup (API-Element)widget Paket enthalten, erweitern jedoch die ViewGroup Klasse.android.widget .Window (API-Element)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:
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:
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.
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 Verbraucher 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.