Mulai 27 Maret 2025, sebaiknya gunakan android-latest-release, bukan aosp-main, untuk mem-build dan berkontribusi pada AOSP. Untuk mengetahui informasi selengkapnya, lihat Perubahan pada AOSP.
Arsitektur grafis
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Hal yang harus diketahui setiap developer tentang platform, SurfaceHolder,
EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView,
SurfaceFlinger, dan Vulkan.
Halaman ini menjelaskan elemen penting dari arsitektur grafis
level sistem Android dan cara penggunaannya oleh framework aplikasi dan sistem
multimedia. Fokusnya adalah pada cara buffering data grafis bergerak melalui sistem.
Jika Anda pernah bertanya-tanya mengapa SurfaceView dan TextureView berperilaku seperti itu,
atau bagaimana interaksi antara platform dan EGLSurface, Anda berada di tempat yang tepat.
Pemahaman tentang perangkat Android dan pengembangan aplikasi dianggap sudah ada.
Anda tidak memerlukan pengetahuan mendetail tentang framework aplikasi dan sangat sedikit panggilan API
yang disebutkan, tetapi materi tersebut tidak tumpang-tindih dengan dokumentasi publik
lainnya. Tujuannya adalah untuk memberikan detail tentang peristiwa signifikan
yang terlibat dalam merender frame untuk output guna membantu Anda membuat pilihan yang tepat
saat mendesain aplikasi. Untuk mencapai hal ini, kita bekerja dari bawah ke atas,
menjelaskan cara kerja class UI, bukan cara menggunakannya.
Bagian ini mencakup beberapa halaman yang membahas segala hal, mulai dari
materi latar belakang hingga detail HAL hingga kasus penggunaan. Pembahasan ini dimulai dengan penjelasan buffering
grafik Android, menjelaskan mekanisme komposisi dan tampilan, lalu melanjutkan
ke mekanisme tingkat tinggi yang menyediakan data untuk kompositor. Sebaiknya
baca halaman dalam urutan yang tercantum di bawah, bukan langsung ke
topik yang terdengar menarik.
Komponen tingkat rendah
- BufferQueue dan
gralloc. BufferQueue menghubungkan sesuatu yang menghasilkan buffering data
grafis (produser) ke sesuatu yang menerima data untuk ditampilkan atau
diproses lebih lanjut (konsumen). Alokasi buffering dilakukan
melalui alokator memori gralloc yang diimplementasikan melalui
antarmuka HAL khusus vendor.
- SurfaceFlinger,
Hardware Composer, dan layar virtual. SurfaceFlinger menerima buffer
data dari beberapa sumber, menggabungkannya, dan mengirimkannya ke layar. HAL
Hardware Composer (HWC) menentukan cara paling efisien untuk menggabungkan
buffer dengan hardware yang tersedia, dan layar virtual membuat output gabungan
tersedia dalam sistem (merekam layar atau mengirim layar melalui
jaringan).
- Surface, kanvas, dan
SurfaceHolder. Platform menghasilkan antrean buffering yang sering digunakan oleh
SurfaceFlinger. Saat merender ke platform, hasilnya akan berakhir di buffering
yang dikirim ke konsumen. Canvas API menyediakan implementasi software
(dengan dukungan akselerasi hardware) untuk menggambar langsung di platform
(alternatif level rendah untuk OpenGL ES). Semua hal yang berkaitan dengan tampilan melibatkan
SurfaceHolder, yang API-nya memungkinkan mendapatkan dan menetapkan parameter platform seperti
ukuran dan format.
- EGLSurface dan
OpenGL ES. OpenGL ES (GLES)
menentukan API rendering grafis yang dirancang untuk
digabungkan dengan EGL, library yang
dapat membuat dan mengakses jendela melalui
sistem operasi (untuk menggambar poligon bertekstur, gunakan panggilan GLES; untuk menempatkan
rendering di layar, gunakan panggilan EGL). Halaman ini juga membahas ANativeWindow,
C/C++ yang setara dengan class Java Surface yang digunakan untuk membuat platform jendela
EGL dari kode native.
- Vulkan. Vulkan adalah
API lintas platform dengan overhead rendah untuk grafis 3D berperforma tinggi. Seperti OpenGL
ES, Vulkan menyediakan alat untuk membuat grafis real-time berkualitas tinggi di
aplikasi. Keunggulan Vulkan mencakup pengurangan overhead CPU dan dukungan
untuk bahasa
SPIR-V Binary Intermediate.
Komponen tingkat tinggi
- SurfaceView dan
GLSurfaceView. SurfaceView menggabungkan platform dan tampilan. Komponen tampilan
SurfaceView digabungkan oleh SurfaceFlinger (bukan aplikasi), sehingga memungkinkan
rendering dari thread/proses terpisah dan isolasi dari rendering UI aplikasi.
GLSurfaceView menyediakan class helper untuk mengelola konteks EGL, komunikasi
antar-thread, dan interaksi dengan siklus proses aktivitas (tetapi tidak diperlukan
untuk menggunakan GLES).
- SurfaceTexture.
SurfaceTexture menggabungkan tekstur platform dan GLES untuk membuat BufferQueue yang
aplikasi Anda adalah konsumennya. Saat produsen mengantrekan buffer baru, produsen akan memberi tahu
aplikasi Anda, yang pada gilirannya akan merilis buffer yang sebelumnya disimpan, memperoleh buffer
baru dari antrean, dan melakukan panggilan EGL untuk membuat buffer tersedia untuk GLES
sebagai tekstur eksternal. Android 7.0 menambahkan dukungan untuk pemutaran video tekstur
aman yang memungkinkan pascapemrosesan GPU konten video yang dilindungi.
- TextureView.
TextureView menggabungkan tampilan dengan SurfaceTexture. TextureView menggabungkan
SurfaceTexture dan bertanggung jawab untuk merespons callback dan
mendapatkan buffering baru. Saat menggambar, TextureView menggunakan konten buffer
yang baru saja diterima sebagai sumber datanya, yang dirender di mana pun dan bagaimanapun
status tampilan menunjukkannya. Komposisi tampilan selalu dilakukan dengan GLES,
yang berarti pembaruan pada konten juga dapat menyebabkan elemen tampilan lainnya digambar ulang.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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."]]
