המסגרת של אנדרואיד מציעה מגוון של ממשקי API לעיבוד גרפי עבור דו-ממד ותלת-ממד המקיימים אינטראקציה עם יישומי יצרן של מנהלי התקנים גרפיים, כך שחשוב שתהיה הבנה טובה של איך ממשקי API אלה עובדים ברמה גבוהה יותר. דף זה מציג את שכבת ההפשטה של החומרה הגרפית (HAL) שעליה בנויים מנהלי התקנים אלה. לפני שתמשיך בסעיף זה, הכר את המונחים הבאים:
Canvas (אלמנט API)Surface . Canvas יש שיטות לציור מחשב סטנדרטי של מפות סיביות, קווים, עיגולים, מלבנים, טקסט וכן הלאה, והוא קשור למפת סיביות או למשטח. קנבס הוא הדרך הפשוטה והקלה ביותר לצייר אובייקטים דו-ממדיים על המסך. מחלקת הבסיס היא Canvas .android.graphics.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)widget , אך הרחיבו את מחלקת ViewGroup .android.widget .Window (אלמנט API)Window המציינת את האלמנטים של חלון גנרי, כגון המראה והתחושה, טקסט שורת הכותרת ומיקום ותוכן של תפריטים. דיאלוגים ופעילויות משתמשים ביישום של המחלקה Window כדי לעבד אובייקט Window . אינך צריך ליישם את מחלקת Window או להשתמש בחלונות באפליקציה שלך.מפתחי אפליקציות מציירים תמונות למסך בשלוש דרכים: עם Canvas , OpenGL ES או Vulkan .
לא משנה באיזה רינדור משתמשים מפתחי API, הכל מעובד על פני משטח. המשטח מייצג את צד המפיק של תור חיץ שנצרך לעתים קרובות על ידי SurfaceFlinger. כל חלון שנוצר בפלטפורמת אנדרואיד מגובה במשטח. כל המשטחים הגלויים המעובדים מורכבים על הצג על ידי SurfaceFlinger.
התרשים הבא מראה כיצד מרכיבי המפתח פועלים יחד:
איור 1. כיצד משטחים מעובדים.
המרכיבים העיקריים מתוארים להלן:
מפיק זרם תמונה יכול להיות כל דבר שמייצר מאגרים גרפיים לצריכה. דוגמאות כוללות OpenGL ES, Canvas 2D ומפענחי וידאו של שרת מדיה.
הצרכן הנפוץ ביותר של זרמי תמונות הוא SurfaceFlinger, שירות המערכת שצורך את המשטחים הנראים כעת ומרכיב אותם על גבי התצוגה באמצעות מידע המסופק על ידי מנהל החלונות. SurfaceFlinger הוא השירות היחיד שיכול לשנות את תוכן התצוגה. SurfaceFlinger משתמש ב-OpenGL וב-Hardware Composer כדי להרכיב קבוצה של משטחים.
אפליקציות אחרות של OpenGL ES יכולות לצרוך זרמי תמונות גם כן, כמו אפליקציית המצלמה שצורכת זרם תמונה של תצוגה מקדימה של המצלמה. גם אפליקציות שאינן GL יכולות להיות צרכנים, למשל מחלקת ImageReader.
הפשטת החומרה עבור תת-מערכת התצוגה. SurfaceFlinger יכול להאציל עבודת קומפוזיציה מסוימת ל-Hardware Composer כדי להוריד עבודה מ-OpenGL ומה-GPU. SurfaceFlinger פועל כעוד לקוח OpenGL ES. אז כאשר SurfaceFlinger מרכיב באופן פעיל מאגר אחד או שניים לשלישי, למשל, הוא משתמש ב-OpenGL ES. זה הופך את החיבור להספק נמוך יותר מאשר שה-GPU מנהל את כל החישובים.
Hardware Composer HAL מנהל את החצי השני של העבודה ומהווה את הנקודה המרכזית לכל עיבוד גרפי אנדרואיד. ה-Hardware Composer חייב לתמוך באירועים, אחד מהם הוא VSYNC (אחר הוא hotplug לתמיכה ב-plug-and-playHDMI).
יש צורך במקצי הזיכרון הגרפי (Galloc) כדי להקצות זיכרון המבוקש על ידי יצרני תמונות. לפרטים, ראה Gralloc HAL .
עיין בתרשים הבא לתיאור של צינור הגרפיקה של אנדרואיד:
איור 2. זרימת נתונים גרפיים דרך אנדרואיד
האובייקטים בצד שמאל הם מעבדים המייצרים מאגרים גרפיים, כגון מסך הבית, שורת המצב וממשק המשתמש של המערכת. SurfaceFlinger הוא המלחין ו- Hardware Composer הוא המלחין.
BufferQueues מספקים את הדבק בין הרכיבים הגרפיים של אנדרואיד. מדובר בצמד תורים שמתווכים את מחזור החוצצים הקבוע מהיצרן לצרכן. ברגע שהמפיקים מוסרים את המאגרים שלהם, SurfaceFlinger אחראית להרכיב הכל על הצג.
עיין בתרשים הבא עבור תהליך התקשורת BufferQueue.
איור 3. תהליך תקשורת BufferQueue
BufferQueue מכיל את ההיגיון שקושר בין יצרני זרם תמונות וצרכני זרם תמונות יחד. כמה דוגמאות ליצרני תמונות הן התצוגה המקדימה של המצלמה שהופקה על ידי משחקי המצלמה HAL או OpenGL ES. כמה דוגמאות לצרכני תמונות הן SurfaceFlinger או אפליקציה אחרת המציגה זרם OpenGL ES, כמו אפליקציית המצלמה המציגה את עינית המצלמה.
BufferQueue הוא מבנה נתונים המשלב מאגר חיץ עם תור ומשתמש ב-Binder IPC כדי להעביר מאגרים בין תהליכים. ממשק היצרן, או מה שאתה מעביר למישהו שרוצה ליצור מאגרים גרפיים, הוא IGraphicBufferProducer (חלק מ- SurfaceTexture ). BufferQueue משמש לעתים קרובות לעיבוד ל-Surface ולצרוך עם GL Consumer, בין שאר המשימות.
BufferQueue יכול לפעול בשלושה מצבים שונים:
מצב דמוי סינכרוני - BufferQueue כברירת מחדל פועל במצב דמוי סינכרוני, בו כל חוצץ שנכנס מהיצרן יוצא אל הצרכן. אף מאגר לא מושלך במצב זה. ואם המפיק מהיר מדי ויוצר מאגרים מהר יותר ממה שהם מתנקזים, הוא יחסום וימתין למאגרים פנויים.
מצב לא חוסם - BufferQueue יכול לפעול גם במצב לא חוסם שבו הוא יוצר שגיאה במקום לחכות למאגר באותם מקרים. אף מאגר לא מושלך אף פעם במצב זה. זה שימושי כדי להימנע ממבוי סתום פוטנציאלי בתוכנת יישומים שאולי לא מבינים את התלות המורכבת של המסגרת הגרפית.
מצב מחיקה - לבסוף, BufferQueue עשוי להיות מוגדר להשליך מאגרים ישנים במקום ליצור שגיאות או להמתין. לדוגמה, אם מבצעים רינדור GL לתצוגת מרקם ומשרטטים מהר ככל האפשר, יש לשחרר מאגרים.
כדי לבצע את רוב העבודה הזו, SurfaceFlinger פועל כעוד לקוח OpenGL ES. אז כאשר SurfaceFlinger מרכיב באופן פעיל מאגר אחד או שניים לשלישי, למשל, הוא משתמש ב-OpenGL ES.
ה- Hardware Composer HAL מנהל את החצי השני של העבודה. HAL זה משמש כנקודה המרכזית לכל עיבוד גרפי אנדרואיד.