החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.
ארכיטקטורת גרפיקה
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
מה כל מפתח צריך לדעת על surfaces, SurfaceHolder, EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView, SurfaceFlinger ו-Vulkan
בדף הזה מתוארים רכיבים חיוניים בארכיטקטורת הגרפיקה ברמת המערכת של Android, ואיך הם משמשים את מסגרת האפליקציה ואת מערכת המולטימדיה. הדגש הוא על האופן שבו מאגרי נתונים גרפיים עוברים במערכת.
אם תהיתם אי פעם למה SurfaceView ו-TextureView מתנהגים כפי שהם מתנהגים, או איך מתבצעת האינטראקציה בין surfaces ל-EGLSurface, הגעתם למקום הנכון.
נדרשת היכרות מסוימת עם מכשירים של Android ופיתוח אפליקציות.
אין צורך בידע מפורט על מסגרת האפליקציה, ומצוינות בה מעט מאוד קריאות ל-API, אבל החומר לא חופף למסמכים ציבוריים אחרים. המטרה היא לספק פרטים על האירועים המשמעותיים שקשורים לעיבוד של מסגרת לפלט, כדי לעזור לכם לבצע בחירות מושכלות בתכנון האפליקציה. כדי לעשות זאת, אנחנו עובדים מלמטה למעלה, ומתארים איך הכיתות של ממשק המשתמש פועלות ולא איך משתמשים בהן.
הקטע הזה כולל כמה דפים שכוללים מידע מגוון, החל מחומר רקע ועד לפרטים של HAL ותרחישי לדוגמה. המאמר מתחיל בהסבר על מאגרי הגרפיקה של Android, מתאר את המנגנון של הרכבת התמונה והצגתה, ולאחר מכן עובר למנגנונים ברמה גבוהה יותר שמספקים ל-Compositor נתונים. מומלץ לקרוא את הדפים בסדר שמופיע בהמשך, ולא לדלג לנושא שנשמע מעניין.
רכיבים ברמה נמוכה
- BufferQueue ו-gralloc. BufferQueue מחבר בין רכיב שיוצר מאגרים של נתונים גרפיים (הבעלים) לבין רכיב שמקבל את הנתונים להצגה או לעיבוד נוסף (הצרכן). הקצאות של מאגרי נתונים זמניים מתבצעות באמצעות מנהל הזיכרון gralloc שמוטמע דרך ממשק HAL ספציפי לספק.
- SurfaceFlinger, Hardware Composer ומסכים וירטואליים. SurfaceFlinger מקבל מאגרי נתונים ממקורות מרובים, משלבים אותם ושולח אותם למסך. Hardware Composer HAL (HWC) קובע את הדרך היעילה ביותר לשילוב מאגרים עם החומרה הזמינה, ומסכים וירטואליים מאפשרים להציג פלט משולב בתוך המערכת (הקלטת המסך או שליחת המסך ברשת).
- Surface, canvas ו-SurfaceHolder. פני השטח יוצרים תור של מאגר, ש-SurfaceFlinger משתמש בו לעיתים קרובות. כשמבצעים עיבוד (רינדור) על גבי משטח, התוצאה נשלחת למאגר (buffer) ומשם לצרכן. ממשקי Canvas API מספקים הטמעת תוכנה (עם תמיכה בהאצה בחומרה) לציור ישירות על משטח (חלופה ברמה נמוכה ל-OpenGL ES). כל מה שקשור לתצוגה כרוך ב-SurfaceHolder, שממשקי ה-API שלו מאפשרים לקבל ולקבוע פרמטרים של משטח, כמו גודל ופורמט.
- EGLSurface ו-OpenGL ES. OpenGL ES (GLES) מגדיר ממשק API לעיבוד גרפיקה שמיועד לשילוב עם EGL, ספרייה שיכולה ליצור חלונות ולגשת אליהם דרך מערכת ההפעלה (כדי לצייר פוליגונים עם טקסטורה, משתמשים בקריאות ל-GLES. כדי להציג עיבוד על המסך, משתמשים בקריאות ל-EGL). בדף הזה מוסבר גם על ANativeWindow, המקבילה ב-C/C++ לכיתה Surface ב-Java, שמשמשת ליצירת פני שטח של חלון EGL מקוד מקומי.
- Vulkan. Vulkan הוא ממשק API לפלטפורמות שונות עם תקורה נמוכה, שמאפשר ליצור גרפיקה תלת-ממדית עם ביצועים גבוהים. בדומה ל-OpenGL ES, Vulkan מספק כלים ליצירת גרפיקה באיכות גבוהה בזמן אמת באפליקציות. היתרונות של Vulkan כוללים הפחתה בעלויות העל של המעבד ותמיכה בשפה SPIR-V Binary Intermediate.
רכיבים ברמה גבוהה
- SurfaceView ו-GLSurfaceView. SurfaceView משלבת בין משטח לתצוגה. רכיבי התצוגה של SurfaceView מורכבים על ידי SurfaceFlinger (ולא על ידי האפליקציה), וכך מתאפשר עיבוד באמצעות שרשור/תהליך נפרד והפרדה מהעיבוד של ממשק המשתמש של האפליקציה.
GLSurfaceView מספק כיתות עזר לניהול הקשרים של EGL, תקשורת בין חוטים ואינטראקציה עם מחזור החיים של הפעילות (אבל לא נדרש להשתמש ב-GLES).
- SurfaceTexture.
SurfaceTexture משלבת בין משטח לבין טקסטורה של GLES כדי ליצור BufferQueue שהאפליקציה שלכם היא הצרכן שלו. כשבעל תוכן דיגיטלי מוסר מאגר חדש לתור, הוא שולח התראה לאפליקציה, והיא בתורה משחררת את המאגר הקודם, מקבלת את המאגר החדש מהתור ומבצעת קריאות ל-EGL כדי להפוך את המאגר לזמין ל-GLES כטקסטורה חיצונית. ב-Android 7.0 נוספה תמיכה בהפעלה מאובטחת של סרטונים עם טקסטורה, שמאפשרת עיבוד לאחרי הפעלה (post-processing) של תוכן וידאו מוגן על ידי GPU.
- TextureView.
TextureView משלבת תצוגה עם SurfaceTexture. TextureView עוטף את SurfaceTexture ומקבל אחריות על תגובה להודעות חזרה (callbacks) ועל יצירת מאגרים חדשים. כשמתבצעת ציור, 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."]]
