Grafikarchitektur

Was jeder Entwickler über Oberflächen, SurfaceHolder, EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView, SurfaceFlinger und Vulkan wissen sollte.

Auf dieser Seite werden wesentliche Elemente der Android-Grafikarchitektur auf Systemebene und deren Verwendung durch das App-Framework und das Multimediasystem beschrieben. Der Schwerpunkt liegt auf der Art und Weise, wie sich Puffer grafischer Daten durch das System bewegen. Wenn Sie sich jemals gefragt haben, warum sich SurfaceView und TextureView so verhalten oder wie Oberflächen und EGLSurface interagieren, sind Sie hier richtig.

Eine gewisse Vertrautheit mit Android-Geräten und der App-Entwicklung wird vorausgesetzt. Sie benötigen keine detaillierten Kenntnisse des App-Frameworks und es werden nur sehr wenige API-Aufrufe erwähnt, aber das Material überschneidet sich nicht mit anderer öffentlicher Dokumentation. Ziel ist es, Details zu den wichtigen Ereignissen bereitzustellen, die beim Rendern eines Frames für die Ausgabe eine Rolle spielen, damit Sie beim Entwerfen einer App fundierte Entscheidungen treffen können. Um dies zu erreichen, gehen wir von unten nach oben vor und beschreiben, wie die UI-Klassen funktionieren und nicht, wie sie verwendet werden können.

Dieser Abschnitt umfasst mehrere Seiten, die alles abdecken, von Hintergrundmaterial über HAL-Details bis hin zu Anwendungsfällen. Es beginnt mit einer Erläuterung der Android-Grafikpuffer, beschreibt den Kompositions- und Anzeigemechanismus und geht dann zu den übergeordneten Mechanismen über, die den Compositor mit Daten versorgen. Wir empfehlen, die Seiten in der unten aufgeführten Reihenfolge zu lesen, anstatt zu einem Thema zu springen, das interessant klingt.

Low-Level-Komponenten

  • BufferQueue und gralloc . BufferQueue verbindet etwas, das Puffer für grafische Daten generiert (den Producer ), mit etwas, das die Daten zur Anzeige oder weiteren Verarbeitung akzeptiert (den Consumer ). Pufferzuweisungen werden über den Gralloc- Speicherzuweiser durchgeführt, der über eine herstellerspezifische HAL-Schnittstelle implementiert wird.
  • SurfaceFlinger, Hardware Composer und virtuelle Displays . SurfaceFlinger akzeptiert Datenpuffer aus mehreren Quellen, setzt sie zusammen und sendet sie an die Anzeige. Der Hardware Composer HAL (HWC) ermittelt die effizienteste Methode zum Zusammensetzen von Puffern mit der verfügbaren Hardware, und virtuelle Displays stellen zusammengesetzte Ausgaben innerhalb des Systems zur Verfügung (Aufzeichnen des Bildschirms oder Senden des Bildschirms über ein Netzwerk).
  • Oberfläche, Leinwand und SurfaceHolder . Eine Oberfläche erzeugt eine Pufferwarteschlange, die häufig von SurfaceFlinger genutzt wird. Beim Rendern auf einer Oberfläche landet das Ergebnis in einem Puffer, der an den Verbraucher gesendet wird. Canvas-APIs bieten eine Softwareimplementierung (mit Hardwarebeschleunigungsunterstützung) zum direkten Zeichnen auf einer Oberfläche (Low-Level-Alternative zu OpenGL ES). Alles, was mit einer Ansicht zu tun hat, erfordert einen SurfaceHolder, dessen APIs das Abrufen und Festlegen von Oberflächenparametern wie Größe und Format ermöglichen.
  • EGLSurface und OpenGL ES . OpenGL ES (GLES) definiert eine Grafik-Rendering-API, die für die Kombination mit EGL konzipiert ist, einer Bibliothek, die über das Betriebssystem Fenster erstellen und darauf zugreifen kann (zum Zeichnen strukturierter Polygone verwenden Sie GLES-Aufrufe; zum Rendern auf dem Bildschirm verwenden Sie EGL-Aufrufe). ). Auf dieser Seite wird auch ANativeWindow behandelt, das C/C++-Äquivalent der Java-Surface-Klasse, die zum Erstellen einer EGL-Fensteroberfläche aus nativem Code verwendet wird.
  • Vulkan . Vulkan ist eine plattformübergreifende API mit geringem Overhead für leistungsstarke 3D-Grafiken. Wie OpenGL ES bietet Vulkan Tools zum Erstellen hochwertiger Echtzeitgrafiken in Apps. Zu den Vorteilen von Vulkan gehören die Reduzierung des CPU-Overheads und die Unterstützung der Sprache SPIR-V Binary Intermediate .

Hochwertige Komponenten

  • SurfaceView und GLSurfaceView . SurfaceView kombiniert eine Oberfläche und eine Ansicht. Die Ansichtskomponenten von SurfaceView werden von SurfaceFlinger (und nicht von der App) zusammengesetzt, was das Rendern aus einem separaten Thread/Prozess und die Isolierung vom Rendern der App-Benutzeroberfläche ermöglicht. GLSurfaceView stellt Hilfsklassen zur Verwaltung von EGL-Kontexten, zur Kommunikation zwischen Threads und zur Interaktion mit dem Aktivitätslebenszyklus bereit (ist jedoch für die Verwendung von GLES nicht erforderlich).
  • Oberflächentextur . SurfaceTexture kombiniert eine Oberfläche und eine GLES-Textur, um eine BufferQueue zu erstellen, für die Ihre App der Konsument ist. Wenn ein Produzent einen neuen Puffer in die Warteschlange stellt, benachrichtigt er Ihre App, die wiederum den zuvor gehaltenen Puffer freigibt, den neuen Puffer aus der Warteschlange abruft und EGL-Aufrufe durchführt, um den Puffer GLES als externe Textur zur Verfügung zu stellen. Mit Android 7.0 wurde Unterstützung für die Wiedergabe sicherer Texturvideos hinzugefügt, die eine GPU-Nachbearbeitung geschützter Videoinhalte ermöglicht.
  • TextureView . TextureView kombiniert eine Ansicht mit einer SurfaceTexture. TextureView umschließt eine SurfaceTexture und übernimmt die Verantwortung für die Reaktion auf Rückrufe und den Erwerb neuer Puffer. Beim Zeichnen verwendet TextureView den Inhalt des zuletzt empfangenen Puffers als Datenquelle und rendert, wo und wie der Ansichtsstatus es vorgibt. Die Ansichtskomposition wird immer mit GLES durchgeführt, was bedeutet, dass Aktualisierungen von Inhalten dazu führen können, dass auch andere Ansichtselemente neu gezeichnet werden.