ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
สถาปัตยกรรมกราฟิก
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
สิ่งที่นักพัฒนาแอปทุกคนควรทราบเกี่ยวกับ Surface, SurfaceHolder, EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView, SurfaceFlinger และ Vulkan
หน้านี้อธิบายองค์ประกอบสําคัญของสถาปัตยกรรมกราฟิกระดับระบบของ Android และวิธีที่เฟรมเวิร์กแอปและระบบมัลติมีเดียใช้องค์ประกอบดังกล่าว โดยเน้นที่วิธีที่บัฟเฟอร์ของข้อมูลกราฟิกเคลื่อนผ่านระบบ
หากคุณเคยสงสัยว่าทำไม SurfaceView และ TextureView จึงทํางานในลักษณะดังกล่าว หรือสงสัยว่าพื้นผิวและ EGLSurface โต้ตอบกันอย่างไร คุณมาถูกที่แล้ว
ถือว่าผู้สมัครมีความคุ้นเคยกับอุปกรณ์ Android และการพัฒนาแอปบ้าง
คุณไม่จำเป็นต้องมีความรู้เชิงลึกเกี่ยวกับเฟรมเวิร์กแอปและมีการกล่าวถึงการเรียก API เพียงไม่กี่รายการ แต่เนื้อหาจะไม่ทับซ้อนกับเอกสารประกอบอื่นๆ ที่เผยแพร่ต่อสาธารณะ เป้าหมายของเราคือการให้รายละเอียดเกี่ยวกับเหตุการณ์ที่สําคัญซึ่งเกี่ยวข้องกับการแสดงผลเฟรมสําหรับเอาต์พุตเพื่อช่วยให้คุณตัดสินใจได้อย่างมีข้อมูลเมื่อออกแบบแอป เราทํางานจากล่างขึ้นบน โดยอธิบายวิธีทํางานของคลาส UI แทนที่จะอธิบายวิธีใช้
ส่วนนี้ประกอบด้วยหน้าเว็บหลายหน้าซึ่งครอบคลุมตั้งแต่เนื้อหาเบื้องหลังไปจนถึงรายละเอียด HAL และกรณีการใช้งาน โดยเริ่มจากคำอธิบายบัฟเฟอร์กราฟิก Android, อธิบายกลไกการแสดงผลและองค์ประกอบ จากนั้นจะไปยังกลไกระดับสูงขึ้นซึ่งให้ข้อมูลแก่โปรแกรมจัดองค์ประกอบ เราขอแนะนำให้อ่านหน้าเว็บตามลำดับที่ระบุไว้ด้านล่างแทนการข้ามไปยังหัวข้อที่ฟังดูน่าสนใจ
คอมโพเนนต์ระดับล่าง
- BufferQueue และ
gralloc BufferQueue จะเชื่อมต่อสิ่งที่สร้างบัฟเฟอร์ของข้อมูลกราฟิก (ผู้ผลิต) กับสิ่งที่ยอมรับข้อมูลเพื่อแสดงผลหรือประมวลผลเพิ่มเติม (ผู้บริโภค) การจัดสรรบัฟเฟอร์จะดำเนินการผ่านตัวจัดสรรหน่วยความจำ gralloc ที่ติดตั้งใช้งานผ่านอินเทอร์เฟซ HAL เฉพาะของผู้ให้บริการ
- SurfaceFlinger,
Hardware Composer และจอแสดงผลเสมือนจริง SurfaceFlinger ยอมรับบัฟเฟอร์ข้อมูลจากแหล่งที่มาหลายแห่ง จากนั้นจะคอมโพสและส่งไปยังจอแสดงผล HAL (HWC) ของเครื่องมือจัดเรียงฮาร์ดแวร์จะกำหนดวิธีที่มีประสิทธิภาพมากที่สุดในการคอมโพสบัฟเฟอร์ด้วยฮาร์ดแวร์ที่มีอยู่ และจอแสดงผลเสมือนจริงจะแสดงเอาต์พุตที่คอมโพสภายในระบบ (การบันทึกหน้าจอหรือการส่งหน้าจอผ่านเครือข่าย)
- Surface, canvas และ SurfaceHolder พื้นผิวจะสร้างคิวบัฟเฟอร์ที่มักใช้โดย
SurfaceFlinger เมื่อแสดงผลบนพื้นผิว ผลลัพธ์จะปรากฏในบัฟเฟอร์ที่จะส่งไปยังผู้บริโภค Canvas API ให้บริการการใช้งานซอฟต์แวร์ (รองรับการเร่งด้วยฮาร์ดแวร์) สำหรับการวาดบนพื้นผิวโดยตรง (ทางเลือกระดับล่างสำหรับ OpenGL ES) ทุกอย่างที่เกี่ยวข้องกับมุมมองจะเกี่ยวข้องกับ SurfaceHolder ซึ่ง API ของ SurfaceHolder ช่วยให้รับและตั้งค่าพารามิเตอร์ของพื้นผิวได้ เช่น ขนาดและรูปแบบ
- EGLSurface และ
OpenGL ES OpenGL ES (GLES) กำหนด API การเรนเดอร์กราฟิกซึ่งออกแบบมาเพื่อใช้ร่วมกับ EGL ซึ่งเป็นไลบรารีที่สร้างและเข้าถึงหน้าต่างผ่านระบบปฏิบัติการได้ (หากต้องการวาดรูปหลายเหลี่ยมที่มีพื้นผิว ให้ใช้การเรียก GLES หากต้องการแสดงการเรนเดอร์บนหน้าจอ ให้ใช้การเรียก EGL) หน้านี้ยังครอบคลุม ANativeWindow ซึ่งเป็น C/C++ ที่เทียบเท่าคลาส Java Surface ที่ใช้สร้างพื้นผิวหน้าต่าง EGL จากโค้ดเนทีฟ
- Vulkan Vulkan เป็น API แบบข้ามแพลตฟอร์มที่มีค่าใช้จ่ายต่ำสำหรับกราฟิก 3 มิติที่มีประสิทธิภาพสูง เช่นเดียวกับ OpenGL ES ทาง Vulkan มีเครื่องมือสำหรับสร้างกราฟิกคุณภาพสูงแบบเรียลไทม์ในแอป ข้อดีของ Vulkan ได้แก่ การลดค่าใช้จ่ายเพิ่มเติมของ CPU และรองรับภาษาSPIR-V Binary Intermediate
คอมโพเนนต์ระดับสูง
- SurfaceView และ GLSurfaceView SurfaceView รวมพื้นผิวและมุมมองเข้าด้วยกัน คอมโพเนนต์ของมุมมอง SurfaceView จะประกอบกันโดย SurfaceFlinger (ไม่ใช่แอป) ซึ่งช่วยให้สามารถแสดงผลจากเธรด/กระบวนการแยกต่างหากและแยกจากการแสดงผล UI ของแอป
GLSurfaceView มีคลาสตัวช่วยในการจัดการบริบท EGL, การสื่อสารระหว่างเธรด และการโต้ตอบกับวงจรของกิจกรรม (แต่ไม่จำเป็นต้องใช้ GLES)
- SurfaceTexture
SurfaceTexture รวมพื้นผิวและพื้นผิว GLES เพื่อสร้าง BufferQueue ซึ่งแอปของคุณเป็นผู้ใช้งาน เมื่อผู้ผลิตจัดคิวบัฟเฟอร์ใหม่ ระบบจะแจ้งให้แอปของคุณทราบ ซึ่งจะปล่อยบัฟเฟอร์ที่เก็บไว้ก่อนหน้านี้ รับบัฟเฟอร์ใหม่จากคิว และเรียกใช้ EGL เพื่อให้ GLES ใช้บัฟเฟอร์เป็นพื้นผิวภายนอกได้ Android 7.0 เพิ่มการรองรับการเล่นวิดีโอพื้นผิวที่ปลอดภัย ซึ่งช่วยให้ GPU ประมวลผลเนื้อหาวิดีโอที่ได้รับการปกป้องได้
- TextureView
TextureView รวมมุมมองเข้ากับ SurfaceTexture TextureView จะรวม SurfaceTexture และรับผิดชอบในการตอบสนองต่อคอลแบ็กและรับบัฟเฟอร์ใหม่ เมื่อวาด TextureView จะใช้เนื้อหาของบัฟเฟอร์ที่ได้รับล่าสุดเป็นแหล่งข้อมูล โดยแสดงผลที่ใดและอย่างไรก็ได้ตามที่สถานะมุมมองระบุ การจัดองค์ประกอบของมุมมองจะดำเนินการด้วย GLES เสมอ ซึ่งหมายความว่าการอัปเดตเนื้อหาอาจทําให้องค์ประกอบมุมมองอื่นๆ วาดใหม่ด้วย
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ Oracle และ/หรือบริษัทในเครือ
อัปเดตล่าสุด 2025-07-27 UTC
[[["เข้าใจง่าย","easyToUnderstand","thumb-up"],["แก้ปัญหาของฉันได้","solvedMyProblem","thumb-up"],["อื่นๆ","otherUp","thumb-up"]],[["ไม่มีข้อมูลที่ฉันต้องการ","missingTheInformationINeed","thumb-down"],["ซับซ้อนเกินไป/มีหลายขั้นตอนมากเกินไป","tooComplicatedTooManySteps","thumb-down"],["ล้าสมัย","outOfDate","thumb-down"],["ปัญหาเกี่ยวกับการแปล","translationIssue","thumb-down"],["ตัวอย่าง/ปัญหาเกี่ยวกับโค้ด","samplesCodeIssue","thumb-down"],["อื่นๆ","otherDown","thumb-down"]],["อัปเดตล่าสุด 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."]]
