ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
HAL ของเครื่องมือแต่งเพลงฮาร์ดแวร์
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
HAL ของเครื่องมือแต่งภาพฮาร์ดแวร์ (HWC) จะกำหนดวิธีคอมโพสิทบัฟเฟอร์ที่มีประสิทธิภาพสูงสุดด้วยฮาร์ดแวร์ที่มีอยู่ ในฐานะ HAL การใช้งานจะเจาะจงอุปกรณ์และมักจะดำเนินการโดย OEM ฮาร์ดแวร์จอแสดงผล
คุณจะเห็นคุณค่าของแนวทางนี้ได้ง่ายเมื่อพิจารณาถึงระนาบการวางซ้อน ซึ่งจะประกอบบัฟเฟอร์หลายรายการในฮาร์ดแวร์การแสดงผลแทน GPU ตัวอย่างเช่น ลองพิจารณาโทรศัพท์ Android ทั่วไปในแนวตั้ง ซึ่งมีแถบสถานะด้านบน แถบนําทางด้านล่าง และเนื้อหาแอปในส่วนอื่นๆ เนื้อหาของเลเยอร์แต่ละเลเยอร์จะอยู่ในบัฟเฟอร์แยกกัน คุณจัดการการจัดองค์ประกอบได้โดยใช้วิธีใดวิธีหนึ่งต่อไปนี้
- การแสดงผลเนื้อหาแอปลงในบัฟเฟอร์สแคช จากนั้นแสดงผลแถบสถานะเหนือบัฟเฟอร์นั้น แสดงผลแถบนําทางเหนือแถบสถานะ และสุดท้ายส่งบัฟเฟอร์สแคชไปยังฮาร์ดแวร์การแสดงผล
- ส่งบัฟเฟอร์ทั้ง 3 รายการไปยังฮาร์ดแวร์การแสดงผลและสั่งให้อ่านข้อมูลจากบัฟเฟอร์ต่างๆ สำหรับส่วนต่างๆ ของหน้าจอ
แนวทางหลังมีประสิทธิภาพมากกว่าได้อย่างมาก
ความสามารถของหน่วยประมวลผลการแสดงผลจะแตกต่างกันอย่างมาก จำนวนการวางซ้อน ความสามารถในการหมุนหรือผสมเลเยอร์ และข้อจำกัดด้านตำแหน่งและการซ้อนทับอาจแสดงผ่าน API ได้ยาก HWC จะทําการคํานวณต่อไปนี้เพื่อรองรับตัวเลือกเหล่านี้
- SurfaceFlinger จะระบุรายการเลเยอร์ทั้งหมดให้กับ HWC และถามว่า "คุณต้องการจัดการเรื่องนี้อย่างไร"
- HWC จะตอบสนองด้วยการทําเครื่องหมายเลเยอร์แต่ละเลเยอร์เป็นองค์ประกอบอุปกรณ์หรือไคลเอ็นต์
- SurfaceFlinger จะจัดการกับไคลเอ็นต์ทั้งหมด โดยส่งบัฟเฟอร์เอาต์พุตไปยัง HWC และปล่อยให้ HWC จัดการส่วนที่เหลือ
เนื่องจากผู้ให้บริการฮาร์ดแวร์สามารถปรับแต่งโค้ดการตัดสินใจได้ คุณจึงใช้อุปกรณ์ทุกเครื่องได้อย่างมีประสิทธิภาพสูงสุด
ระนาบการวางซ้อนอาจมีประสิทธิภาพน้อยกว่าการคอมโพสิชัน GL เมื่อไม่มีการเปลี่ยนแปลงใดๆ บนหน้าจอ โดยเฉพาะอย่างยิ่งเมื่อเนื้อหาวางซ้อนมีพิกเซลที่โปร่งใสและมีการผสมผสานเลเยอร์ซ้อนทับ ในกรณีเช่นนี้ HWC สามารถขอการคอมโพสิชัน GLES สำหรับเลเยอร์บางส่วนหรือทั้งหมดและเก็บบัฟเฟอร์ที่คอมโพสิต์ไว้ หาก SurfaceFlinger ขอให้คอมโพสิทชุดบัฟเฟอร์เดียวกัน HWC จะแสดงบัฟเฟอร์สำหรับสแครชที่คอมโพสิทไว้ก่อนหน้านี้ได้ ซึ่งจะช่วยเพิ่มอายุการใช้งานแบตเตอรี่ของอุปกรณ์ที่ไม่ได้ใช้งาน
โดยทั่วไปอุปกรณ์ Android จะรองรับการวางซ้อน 4 ระนาบ
การพยายามคอมโพสเลเยอร์มากกว่าการวางซ้อนจะทำให้ระบบใช้การคอมโพส 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,["# Hardware Composer HAL\n\nThe Hardware Composer (HWC) HAL determines the most efficient\nway to composite buffers with the available hardware. As a HAL, its\nimplementation is device-specific and usually done by the display hardware OEM.\n\nThe value of this approach is easy to recognize when you consider *overlay\nplanes*, which composite multiple buffers in\nthe display hardware rather than the GPU. For example, consider a typical\nAndroid phone in portrait orientation, with the status bar on top, navigation\nbar at the bottom, and app content everywhere else. The contents for each layer\nare in separate buffers. You can handle composition using either of the\nfollowing methods:\n\n- Rendering the app content into a scratch buffer, then rendering the status bar over it, the navigation bar on top of that, and finally passing the scratch buffer to the display hardware.\n- Passing all three buffers to the display hardware and instructing it to read data from different buffers for different parts of the screen.\n\nThe latter approach can be significantly more efficient.\n\nDisplay processor capabilities vary significantly. The number of overlays,\nwhether layers can be rotated or blended, and restrictions on positioning and\noverlap can be difficult to express through an API. To accommodate these options, the HWC performs\nfollowing calculations:\n\n1. SurfaceFlinger provides HWC with a full list of layers and asks, \"How do you want to handle this?\"\n2. HWC responds by marking each layer as device or client composition.\n3. SurfaceFlinger takes care of any client, passing the output buffer to HWC, and lets HWC handle the rest.\n\nBecause hardware vendors can custom tailor decision-making code, it's possible\nto get the best performance out of every device.\n\nOverlay planes may be less efficient than GL composition when nothing on the\nscreen is changing. This is particularly true when overlay contents have\ntransparent pixels and overlapping layers are blended. In such cases,\nthe HWC can request GLES composition for some or all layers and retain\nthe composited buffer. If SurfaceFlinger asks to composite the same\nset of buffers, the HWC can show the previously composited scratch\nbuffer. This can improve the battery life of an idle device.\n\nAndroid devices typically support four overlay planes.\nAttempting to composite more layers than overlays causes the system to use GLES\ncomposition for some of them, meaning the number of layers used by an app can\nhave a measurable impact on power consumption and performance."]]
