กราฟิก

เฟรมเวิร์ก Android นำเสนอ API การเรนเดอร์กราฟิกที่หลากหลายสำหรับ 2D และ 3D ที่โต้ตอบกับการใช้งานไดรเวอร์กราฟิกของผู้ผลิต ดังนั้นจึงเป็นสิ่งสำคัญที่จะต้องมีความเข้าใจที่ดีว่า API เหล่านั้นทำงานอย่างไรในระดับที่สูงขึ้น หน้านี้แนะนำ graphic hardware abstraction layer (HAL) ที่ใช้สร้างไดรเวอร์เหล่านั้น

นักพัฒนาแอปพลิเคชันวาดภาพลงบนหน้าจอได้สามวิธี: ด้วย Canvas , OpenGL ES หรือ Vulkan

ส่วนประกอบกราฟิกของ Android

ไม่ว่านักพัฒนา API จะใช้การเรนเดอร์แบบใดก็ตาม ทุกอย่างจะถูกเรนเดอร์บน พื้นผิว พื้นผิวแสดงถึงด้านผู้ผลิตของคิวบัฟเฟอร์ที่ SurfaceFlinger มักใช้งาน ทุกหน้าต่างที่สร้างขึ้นบนแพลตฟอร์ม Android จะได้รับการสนับสนุนจากพื้นผิว พื้นผิวที่มองเห็นได้ทั้งหมดที่ถูกเรนเดอร์จะถูกประกอบเข้ากับจอแสดงผลโดย SurfaceFlinger

แผนภาพต่อไปนี้แสดงวิธีการทำงานร่วมกันของส่วนประกอบหลัก:

รูปที่ 1 วิธีการเรนเดอร์พื้นผิว

ส่วนประกอบหลักมีการอธิบายไว้ด้านล่าง:

ผู้ผลิตสตรีมรูปภาพ

ผู้ผลิตสตรีมรูปภาพสามารถเป็นอะไรก็ได้ที่สร้างบัฟเฟอร์กราฟิกสำหรับการบริโภค ตัวอย่าง ได้แก่ OpenGL ES, Canvas 2D และตัวถอดรหัสวิดีโอมีเดียเซิร์ฟเวอร์

ผู้บริโภคสตรีมรูปภาพ

ผู้ใช้สตรีมรูปภาพที่พบบ่อยที่สุดคือ SurfaceFlinger ซึ่งเป็นบริการของระบบที่ใช้พื้นผิวที่มองเห็นได้ในปัจจุบันและรวมเข้ากับจอแสดงผลโดยใช้ข้อมูลที่ Window Manager ให้ไว้ SurfaceFlinger เป็นบริการเดียวที่สามารถปรับเปลี่ยนเนื้อหาของจอแสดงผลได้ SurfaceFlinger ใช้ OpenGL และ Hardware Composer เพื่อจัดกลุ่มพื้นผิว

แอป OpenGL ES อื่นๆ สามารถใช้สตรีมรูปภาพได้เช่นกัน เช่น แอปกล้องที่ใช้สตรีมรูปภาพตัวอย่างจากกล้อง แอปพลิเคชันที่ไม่ใช่ GL ก็สามารถเป็นแบบผู้บริโภคได้เช่นกัน เช่น คลาส ImageReader

นักแต่งเพลงฮาร์ดแวร์

นามธรรมฮาร์ดแวร์สำหรับระบบย่อยการแสดงผล SurfaceFlinger สามารถมอบหมายงานองค์ประกอบบางอย่างให้กับ Hardware Composer เพื่อถ่ายโอนงานจาก OpenGL และ GPU SurfaceFlinger ทำหน้าที่เป็นไคลเอนต์ OpenGL ES อื่น ดังนั้น เมื่อ SurfaceFlinger กำลังรวมบัฟเฟอร์หนึ่งหรือสองลงในบัฟเฟอร์ที่สาม ตัวอย่างเช่น บัฟเฟอร์นั้นกำลังใช้ OpenGL ES ทำให้การประกอบพลังงานต่ำกว่าการให้ GPU ทำการคำนวณทั้งหมด

Hardware Composer HAL ดำเนินการอีกครึ่งหนึ่งของงานและเป็นจุดศูนย์กลางสำหรับการเรนเดอร์กราฟิก Android ทั้งหมด Hardware Composer ต้องรองรับเหตุการณ์ ซึ่งหนึ่งในนั้นคือ VSYNC (อีกอันคือ hotplug สำหรับการสนับสนุน Plug-and-Play HDMI)

กราลอค

จำเป็นต้องใช้ตัวจัดสรรหน่วยความจำกราฟิก (Gralloc) เพื่อจัดสรรหน่วยความจำที่ผู้ผลิตรูปภาพร้องขอ สำหรับรายละเอียด โปรดดูที่ Gralloc HAL

การไหลของข้อมูล

ดูไดอะแกรมต่อไปนี้สำหรับการพรรณนาของไปป์ไลน์กราฟิก Android:

รูปที่ 2 ข้อมูลกราฟิกไหลผ่าน Android

ออบเจ็กต์ทางด้านซ้ายคือตัวเรนเดอร์ที่สร้างบัฟเฟอร์กราฟิก เช่น หน้าจอหลัก แถบสถานะ และ UI ของระบบ SurfaceFlinger เป็นผู้เรียบเรียงและ Hardware Composer เป็นผู้แต่ง

บัฟเฟอร์คิว

BufferQuuees เป็นตัวเชื่อมระหว่างส่วนประกอบกราฟิกของ Android เหล่านี้เป็นคู่ของคิวที่เป็นสื่อกลางในวงจรบัฟเฟอร์คงที่จากผู้ผลิตไปยังผู้บริโภค เมื่อผู้ผลิตแจกบัฟเฟอร์ 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 นี้ทำหน้าที่เป็นจุดศูนย์กลางสำหรับการเรนเดอร์กราฟิก Android ทั้งหมด