מסגרת Android מציעה מגוון ממשקי API לעיבוד גרפיקה 2D ו-3D, שמקיימים אינטראקציה עם הטמעות של יצרנים של מנהלי גרפיקה. לכן חשוב להבין היטב איך ממשקי ה-API האלה פועלים ברמה גבוהה יותר. בדף הזה נסביר על שיטת הפשטת החומרה (HAL) של הגרפיקה, שעליה מבוססים מנהלי ההתקנים האלה. לפני שממשיכים בחלק הזה, כדאי להכיר את המונחים הבאים:
Canvas (רכיב API)Surface. לכיתה Canvas יש שיטות לשרטוט סטנדרטי במחשב של בייטים, קווים, עיגולים, מלבנים, טקסט וכו', והיא מקושרת לבייטים או למשטח. קנבס הוא הדרך הפשוטה והקלה ביותר לצייר אובייקטים דו-ממדיים במסך. המחלקה הבסיסית היא Canvas.
android.graphics.drawable.
מידע נוסף על רכיבי drawable ומשאבים אחרים זמין במאמר סקירה כללית על משאבי אפליקציות.
android.opengl ו-javax.microedition.khronos.opengles חושפות את הפונקציונליות של OpenGL ES.Surface (רכיב API)Surface. משתמשים בכיתה SurfaceView במקום בכיתה Surface ישירות.
SurfaceView (רכיב API)View שמקיף אובייקט Surface לצורך ציור, ומציג שיטות לציון הגודל והפורמט שלו באופן דינמי. תצוגת פני השטח מספקת דרך לצייר ללא תלות בשרשור של ממשק המשתמש, לפעולות שצורכות הרבה משאבים, כמו משחקים או תצוגות מקדימות במצלמה, אבל כתוצאה מכך היא צורכת יותר זיכרון. תצוגת משטח תומכת גם בקנבס וגם בגרפיקה של OpenGL ES. המחלקה הבסיסית של אובייקט SurfaceView היא
SurfaceView.
R.style ומתחילים ב-Theme_.View (רכיב API)View היא הכיתה הבסיסית של רוב רכיבי הפריסה של פעילות או מסך דו-שיח, כמו תיבות טקסט וחלונות. אובייקט View מקבל קריאות מהאובייקט ההורה שלו (ראו ViewGroup) כדי לצייר את עצמו, ומעדכן את אובייקט ההורה לגבי המיקום והגודל המועדפים עליו, שיכול להיות שההורה לא יתייחס אליהם. מידע נוסף זמין במאמר View.
ViewGroup (רכיב API)android.widget, אבל הן מורשות מהקלאס ViewGroup.
android.widget. Window (רכיב API)Window, שמציינת את הרכיבים של חלון כללי, כמו המראה והתחושה, הטקסט בשורת הכותרת והמיקום והתוכן של התפריטים. כדי להציג אובייקט Window, בתי שיחה ופעילויות משתמשים בהטמעה של הכיתה Window. אין צורך להטמיע את הכיתה Window או להשתמש בחלונות באפליקציה.מפתחי אפליקציות מציירים תמונות במסך בשלוש דרכים: באמצעות Canvas, OpenGL ES או Vulkan.
רכיבי גרפיקה של Android
לא משנה באיזה API לעיבוד תמונה המפתחים משתמשים, כל התמונות עוברות עיבוד על גבי משטח. ה-surface מייצג את הצד של היוצר בתור של מאגר, ש-SurfaceFlinger משתמש בו לעיתים קרובות. כל חלון שנוצר בפלטפורמת Android מגובה על ידי משטח. כל הפנים הגלויים שעבר עיבוד משולב על המסך על ידי SurfaceFlinger.
בתרשים הבא מוצג אופן הפעולה המשותף של הרכיבים העיקריים:
איור 1. איך מתבצע העיבוד של הפלטפורמות.
הרכיבים העיקריים מתוארים בקטעים הבאים.
יוצרים של זרמי תמונות
מפיץ של מקור נתונים של תמונות יכול להיות כל דבר שיוצר מאגרי גרפיקה לשימוש. דוגמאות לכך הן OpenGL ES, Canvas 2D ו-mediaserver video decoders.
צרכני מקור תמונות
הצרכן הנפוץ ביותר של זרמי תמונות הוא SurfaceFlinger, שירות המערכת שמשתמש במשטחים שגלויים כרגע ומרכיב אותם במסך באמצעות מידע שמסופק על ידי מנהל החלונות. SurfaceFlinger הוא השירות היחיד שיכול לשנות את התוכן במסך. SurfaceFlinger משתמש ב-OpenGL וב-Hardware Composer (HWC) כדי ליצור קומפוזיציה של קבוצת משטחים.
אפליקציות OpenGL ES אחרות יכולות לצרוך גם סטרימינג של תמונות, כמו אפליקציית המצלמה שמשתמשת בסטרימינג של תמונות תצוגה מקדימה מהמצלמה. אפליקציות שאינן GL יכולות להיות גם צרכן, למשל הכיתה ImageReader.
Hardware Composer
הפשטת החומרה של מערכת המשנה של המסך. SurfaceFlinger יכול להעביר משימות מסוימות של קומפוזיציה ל-HWC כדי להפחית את העומס על OpenGL ועל ה-GPU. SurfaceFlinger פועל כלקוח OpenGL ES נוסף. לדוגמה, כש-SurfaceFlinger מבצע באופן פעיל שילוב של מאגר אחד או שניים למאגר שלישי, הוא משתמש ב-OpenGL ES. כך נעשה שימוש בפחות חשמל בזמן הרכבת התמונות, בהשוואה למצב שבו המעבד הגרפי מבצע את כל החישובים.
Hardware Composer HAL מנהל את החצי השני של העבודה, והוא הנקודה המרכזית לכל העיבוד הגרפי של Android. ה-HWC חייב לתמוך באירועים, אחד מהם הוא VSync (אירוע אחר הוא hotplug לתמיכה ב-HDMI מסוג plug-and-play).
Gralloc
מנהל הקצאת הזיכרון של הגרפיקה (Gralloc) נדרש כדי להקצות זיכרון לבקשות של יצרני התמונות. פרטים נוספים זמינים במאמר BufferQueue ו-Gralloc.
זרימת נתונים
בתרשים הבא מוצג צינור עיבוד הנתונים של הגרפיקה ב-Android:
איור 2. זרימת נתונים גרפיים דרך Android.
האובייקטים בצד ימין הם מנועי עיבוד גרפיים שיוצרים מאגרי גרפיקה, כמו מסך הבית, שורת הסטטוס וממשק המשתמש של המערכת. SurfaceFlinger הוא המאגר וה-HWC הוא המלחין.
BufferQueue
BufferQueues משמשים כמקשר בין רכיבי הגרפיקה של Android. אלה שתי תורים שמווסתים את המחזור המתמיד של מאגרי נתונים מהבעלים לצרכנים. אחרי שהיוצרים מעבירים את המאגרים שלהם, SurfaceFlinger אחראי על שילוב הכול במסך.
התרשים הבא מדגים את תהליך התקשורת של BufferQueue:
איור 3. תהליך התקשורת של BufferQueue.
BufferQueue מכיל את הלוגיקה שמקשרת בין יצרני מקור של זרמי תמונות לבין צרכני מקור של זרמי תמונות. דוגמאות לגורמים שמפיקים תמונות הן התצוגות המקדימות של המצלמה שנוצרות על ידי HAL של המצלמה או משחקי OpenGL ES. דוגמאות לצרכן תמונות הן SurfaceFlinger או אפליקציה אחרת שמוצג בה שידור של OpenGL ES, כמו אפליקציית המצלמה שמוצג בה העינית של המצלמה.
BufferQueue הוא מבנה נתונים שמשלב מאגר מאגרים עם תור, ומשתמש ב-Binder IPC כדי להעביר מאגרים בין תהליכים. ממשק הבעלים, או מה שמעבירים למישהו שרוצה ליצור מאגרי גרפיקה, הוא IGraphicBufferProducer (חלק מ-SurfaceTexture). בין היתר, BufferQueue משמש לעיתים קרובות לעיבוד (רנדרינג) ב-Surface ולשימוש ב-GL Consumer.
אפשר להפעיל את BufferQueue בשלושה מצבים שונים:
כדי לבצע את רוב העבודה הזו, SurfaceFlinger פועל כעוד לקוח OpenGL ES. למשל, כש-SurfaceFlinger משלב באופן פעיל מאגר אחד או שניים למאגר שלישי, הוא משתמש ב-OpenGL ES.
ה-HAL של Hardware Composer מבצע את מחצית העבודה השנייה. ה-HAL הזה משמש כנקודה המרכזית לכל רינדור הגרפיקה של Android.