Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.
Grafikarchitektur
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Was jeder Entwickler über Oberflächen, SurfaceHolder, EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView, SurfaceFlinger und Vulkan wissen sollte
Auf dieser Seite werden wichtige Elemente der Grafikarchitektur auf Android-Systemebene beschrieben und wie sie vom App-Framework und Multimediasystem verwendet werden. Der Schwerpunkt liegt darauf, wie Buffers von grafischen Daten durch das System geleitet werden.
Wenn Sie sich schon einmal gefragt haben, warum sich SurfaceView und TextureView so verhalten oder wie Oberflächen und EGLSurface interagieren, sind Sie hier genau richtig.
Es wird vorausgesetzt, dass Sie mit Android-Geräten und der App-Entwicklung vertraut sind.
Sie benötigen keine detaillierten Kenntnisse des App-Frameworks und es werden nur sehr wenige API-Aufrufe erwähnt. Das Material deckt sich jedoch nicht mit anderen öffentlichen Dokumentationen. Ziel ist es, Details zu den wichtigen Ereignissen beim Rendern eines Frames für die Ausgabe anzugeben, damit Sie beim Entwerfen einer App fundierte Entscheidungen treffen können. Dazu gehen wir von unten nach oben vor und beschreiben, wie die UI-Klassen funktionieren, anstatt wie sie verwendet werden können.
Dieser Abschnitt enthält mehrere Seiten mit Hintergrundinformationen, HAL-Details und Anwendungsfällen. Es beginnt mit einer Erklärung der Android-Grafik-Buffers, beschreibt den Kompositionsund Anzeigemechanismus und geht dann zu den Mechanismen höherer Ebene ü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 Buffers mit grafischen Daten generiert (der Erzeuger), mit etwas, das die Daten zur Anzeige oder weiteren Verarbeitung akzeptiert (der Nutzer). Die Pufferzuweisung erfolgt über den Arbeitsspeicher-Allocator gralloc, der über eine anbieterspezifische HAL-Schnittstelle implementiert ist.
- SurfaceFlinger, Hardware Composer und virtuelle Displays SurfaceFlinger empfängt Datenbuffer aus mehreren Quellen, kombiniert sie und sendet sie an das Display. Die Hardware Composer HAL (HWC) bestimmt die effizienteste Methode, Buffers mit der verfügbaren Hardware zu kombinieren. Virtuelle Displays stellen die kombinierte Ausgabe innerhalb des Systems bereit (Aufzeichnen des Bildschirms oder Senden des Bildschirms über ein Netzwerk).
- Surface, Canvas und SurfaceHolder Eine Oberfläche erzeugt eine Pufferwarteschlange, die häufig von SurfaceFlinger verwendet wird. Beim Rendern auf eine Oberfläche wird das Ergebnis in einem Puffer gespeichert, der an den Verbraucher gesendet wird. Canvas-APIs bieten eine Softwareimplementierung (mit Hardwarebeschleunigung) zum Zeichnen direkt auf einer Oberfläche (Low-Level-Alternative zu OpenGL ES). Alles, was mit einer Ansicht zu tun hat, umfasst einen SurfaceHolder, dessen APIs es ermöglichen, Oberflächenparameter wie Größe und Format abzurufen und festzulegen.
- EGLSurface und OpenGL ES OpenGL ES (GLES) definiert eine Grafik-Rendering-API, die mit EGL kombiniert werden kann, einer Bibliothek, mit der Fenster über das Betriebssystem erstellt und darauf zugegriffen werden kann. Zum Zeichnen von texturierten Polygonen werden GLES-Aufrufe verwendet, zum Rendern auf dem Bildschirm EGL-Aufrufe. Auf dieser Seite wird auch ANativeWindow behandelt, das C/C++-Äquivalent der Java-Surface-Klasse, mit der eine EGL-Fensteroberfläche aus nativem Code erstellt wird.
- Vulkan. Vulkan ist eine plattformübergreifende API mit geringem Overhead für leistungsstarke 3D-Grafiken. Ähnlich wie OpenGL ES bietet Vulkan Tools zum Erstellen hochwertiger Echtzeitgrafiken in Apps. Zu den Vorteilen von Vulkan gehören eine Verringerung des CPU-Overheads und die Unterstützung der SPIR-V Binary Intermediate-Sprache.
Allgemeine 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 Rendering in einem separaten Thread/Prozess und die Isolation vom Rendering der App-Benutzeroberfläche ermöglicht.
GLSurfaceView bietet Hilfsklassen zum Verwalten von EGL-Kontexten, zur Kommunikation zwischen Threads und zur Interaktion mit dem Lebenszyklus der Aktivität. Die Verwendung von GLES ist jedoch nicht erforderlich.
- SurfaceTexture
SurfaceTexture kombiniert eine Oberfläche und eine GLES-Textur, um eine BufferQueue zu erstellen, für die Ihre App der Verbraucher ist. Wenn ein Produzent einen neuen Buffer in die Warteschlange stellt, benachrichtigt er Ihre App, die wiederum den zuvor gehaltenen Buffer freigibt, den neuen Buffer aus der Warteschlange abruft und EGL-Aufrufe ausführt, um den Buffer GLES als externe Textur zur Verfügung zu stellen. Android 7.0 unterstützt die Wiedergabe von sicheren Texturenvideos, wodurch eine GPU-Nachbearbeitung geschützter Videoinhalte möglich ist.
- TextureView
TextureView kombiniert eine Ansicht mit einer SurfaceTexture. TextureView umschließt eine SurfaceTexture und ist für die Reaktion auf Rückrufe und das Abrufen neuer Buffers verantwortlich. Beim Zeichnen verwendet TextureView den Inhalt des zuletzt empfangenen Buffers als Datenquelle und rendert ihn dort und so, wie es der Ansichtsstatus vorgibt. Die Ansichtszusammensetzung wird immer mit GLES ausgeführt. Das bedeutet, dass Aktualisierungen von Inhalten dazu führen können, dass auch andere Ansichtselemente neu gezeichnet werden.
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2025-07-27 (UTC).
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-07-27 (UTC)."],[],[],null,["# Graphics architecture\n\n*What every developer should know about surfaces, SurfaceHolder,\nEGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView,\nSurfaceFlinger, and Vulkan.*\n\nThis page describes essential elements of the Android system-level graphics\narchitecture and how they are used by the app framework and multimedia\nsystem. The focus is on how buffers of graphical data move through the system.\nIf you've ever wondered why SurfaceView and TextureView behave the way they do,\nor how surfaces and EGLSurface interact, you're in the correct place.\n\nSome familiarity with Android devices and app development is assumed.\nYou don't need detailed knowledge of the app framework and very few API calls\nare mentioned, but the material doesn't overlap with other public\ndocumentation. The goal is to provide details on the significant events\ninvolved in rendering a frame for output to help you make informed choices\nwhen designing an app. To achieve this, we work from the bottom up,\ndescribing how the UI classes work rather than how they can be used.\n\nThis section includes several pages covering everything from background\nmaterial to HAL details to use cases. It starts with an explanation of Android\ngraphics buffers, describes the composition and display mechanism, then proceeds\nto the higher-level mechanisms that supply the compositor with data. We\nrecommend reading pages in the order listed below rather than skipping to a\ntopic that sounds interesting.\n\nLow-level components\n--------------------\n\n- [BufferQueue and\n gralloc](/docs/core/graphics/arch-bq-gralloc). BufferQueue connects something that generates buffers of graphical data (the *producer* ) to something that accepts the data for display or further processing (the *consumer* ). Buffer allocations are performed through the *gralloc* memory allocator implemented through a vendor-specific HAL interface.\n- [SurfaceFlinger,\n Hardware Composer, and virtual displays](/docs/core/graphics/arch-sf-hwc). SurfaceFlinger accepts buffers of data from multiple sources, composites them, and sends them to the display. The Hardware Composer HAL (HWC) determines the most efficient way to composite buffers with the available hardware, and virtual displays make composited output available within the system (recording the screen or sending the screen over a network).\n- [Surface, canvas, and\n SurfaceHolder](/docs/core/graphics/arch-sh). A surface produces a buffer queue that is often consumed by SurfaceFlinger. When rendering onto a surface, the result ends up in a buffer that gets shipped to the consumer. Canvas APIs provide a software implementation (with hardware-acceleration support) for drawing directly on a surface (low-level alternative to OpenGL ES). Anything having to do with a view involves a SurfaceHolder, whose APIs enable getting and setting surface parameters such as size and format.\n- [EGLSurface and\n OpenGL ES](/docs/core/graphics/arch-egl-opengl). [OpenGL ES (GLES)](https://www.khronos.org/opengles/) defines a graphics-rendering API designed to be combined with [EGL](https://www.khronos.org/egl), a library that can create and access windows through the operating system (to draw textured polygons, use GLES calls; to put rendering on the screen, use EGL calls). This page also covers ANativeWindow, the C/C++ equivalent of the Java Surface class used to create an EGL window surface from native code.\n- [Vulkan](/docs/core/graphics/arch-vulkan). Vulkan is a low-overhead, cross-platform API for high-performance 3D graphics. Like OpenGL ES, Vulkan provides tools for creating high-quality, real-time graphics in apps. Vulkan advantages include reductions in CPU overhead and support for the [SPIR-V Binary Intermediate](https://www.khronos.org/spir) language.\n\nHigh-level components\n---------------------\n\n- [SurfaceView and\n GLSurfaceView](/docs/core/graphics/arch-sv-glsv). SurfaceView combines a surface and a view. SurfaceView's view components are composited by SurfaceFlinger (and not the app), enabling rendering from a separate thread/process and isolation from app UI rendering. GLSurfaceView provides helper classes to manage EGL contexts, interthread communication, and interaction with the activity lifecycle (but isn't required to use GLES).\n- [SurfaceTexture](/docs/core/graphics/arch-st). SurfaceTexture combines a surface and GLES texture to create a BufferQueue for which your app is the consumer. When a producer queues a new buffer, it notifies your app, which in turn releases the previously-held buffer, acquires the new buffer from the queue, and makes EGL calls to make the buffer available to GLES as an external texture. Android 7.0 added support for secure texture video playback enabling GPU post-processing of protected video content.\n- [TextureView](/docs/core/graphics/arch-tv). TextureView combines a view with a SurfaceTexture. TextureView wraps a SurfaceTexture and takes responsibility for responding to callbacks and acquiring new buffers. When drawing, TextureView uses the contents of the most recently received buffer as its data source, rendering wherever and however the view state indicates it should. View composition is always performed with GLES, meaning updates to contents may cause other view elements to redraw as well."]]
