自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
图形架构
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
每位开发者都应了解有关 Surface、SurfaceHolder、EGLSurface、SurfaceView、GLSurfaceView、SurfaceTexture、TextureView、SurfaceFlinger 和 Vulkan 的知识。
本页将介绍 Android 系统级图形架构的基本元素,以及应用框架和多媒体系统如何使用这些元素。我们会重点介绍图形数据的缓冲区是如何在系统中移动的。
如果您想了解 SurfaceView 和 TextureView 为何采用相应行为方式,或者 Surface 和 EGLSurface 的交互方式,这里可以为您提供正确解答。
理解这些内容的前提是您对 Android 设备和应用开发有一定了解。您不需要掌握有关应用框架的详细知识,本文也很少提及 API 调用,但本材料与其他公开文档互不重叠。本文旨在详细介绍渲染帧以进行输出涉及的重要事件,从而帮助您在设计应用时做出明智的选择。为此,我们将从基本原理出发,介绍 UI 类的工作方式,而不是其使用方法。
本部分包括多个页面,从背景材料到 HAL 细节再到用例,进行了全面介绍。首先是对 Android 图形缓冲区进行了解释,并说明了合成和显示机制,然后继续介绍为合成器提供数据的更高级别的机制。我们建议您按照下列顺序阅读相关页面,而不要直接跳到感兴趣的主题。
低级别组件
- BufferQueue 和 gralloc。BufferQueue 将可生成图形数据缓冲区的组件(生产者)连接到接受数据以便进行显示或进一步处理的组件(消费者)。通过供应商专用 HAL 接口实现的 gralloc 内存分配器将用于执行缓冲区分配任务。
- SurfaceFlinger、Hardware Composer 和虚拟显示屏。SurfaceFlinger 接受来自多个源的数据缓冲区,然后将它们进行合成并发送到显示屏。Hardware Composer HAL (HWC) 确定使用可用硬件合成缓冲区的最有效的方法,虚拟显示屏使合成输出可在系统内使用(录制屏幕或通过网络发送屏幕)。
- Surface、Canvas 和 SurfaceHolder。Surface 可生成一个通常由 SurfaceFlinger 使用的缓冲区队列。当渲染到 Surface 上时,结果最终将出现在传送给消费者的缓冲区中。Canvas API 提供一种软件实现方法(支持硬件加速),用于直接在 Surface 上绘图(OpenGL ES 的低级别替代方案)。与视图有关的任何内容均涉及到 SurfaceHolder,其 API 可用于获取和设置 Surface 参数(如大小和格式)。
- EGLSurface 和 OpenGL ES。OpenGL ES (GLES) 定义了旨在与 EGL 结合使用的图形渲染 API。EGI 是一个通过操作系统创建和访问窗口的库(要绘制纹理多边形,请使用 GLES 调用;要将渲染应用到屏幕上,请使用 EGL 调用)。此页还介绍了 ANativeWindow,它是 Java Surface 类的 C/C++ 等价类,用于通过原生代码创建 EGL 窗口表面。
- Vulkan。Vulkan 是一种用于高性能 3D 图形的低开销、跨平台 API。与 OpenGL ES 一样,Vulkan 提供用于在应用中创建高质量实时图形的工具。Vulkan 的优势包括降低 CPU 开销以及支持 SPIR-V 二进制中间语言。
高级别组件
- SurfaceView 和 GLSurfaceView。SurfaceView 结合了 Surface 和 View。SurfaceView 的 View 组件由 SurfaceFlinger(而不是应用)合成,从而可以通过单独的线程/进程渲染,并与应用界面渲染隔离。GLSurfaceView 提供了用于管理 EGL 上下文、线程间通信以及与 activity 生命周期的交互的帮助程序类(但不是必须使用 GLES)。
- SurfaceTexture。
SurfaceTexture 将 Surface 和 GLES 纹理相结合来创建 BufferQueue,而您的应用是 BufferQueue 的消费者。当生产者将新的缓冲区排入队列时,它会通知您的应用。您的应用会依次释放先前占用的缓冲区,从队列中获取新缓冲区并执行 EGL 调用,从而使 GLES 可将此缓冲区作为外部纹理使用。Android 7.0 添加了对安全纹理视频播放的支持,以便对受保护的视频内容进行 GPU 后处理。
- TextureView。
TextureView 结合了 View 和 SurfaceTexture。TextureView 对 SurfaceTexture 进行包装,并负责响应回调以及获取新的缓冲区。在绘图时,TextureView 使用最近收到的缓冲区的内容作为其数据源,根据 View 状态指示,在它应该渲染的任何位置和以它应该采用的任何渲染方式进行渲染。View 合成始终通过 GLES 来执行,这意味着内容更新可能会导致其他 View 元素重绘。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-07-27。
[null,null,["最后更新时间 (UTC):2025-07-27。"],[],[],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."]]