ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release
แทน aosp-main
เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
การจัดการเฟรมบัฟเฟอร์ของลูกค้า
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
ตั้งแต่ Android 13 เป็นต้นไป ระบบจะจัดสรรเฟรมบัฟเฟอร์ใหม่ที่ใช้ในระหว่างการคอมโพสิชันของไคลเอ็นต์ทุกครั้งที่มีการเปลี่ยนแปลงความละเอียดของการแสดงผล SurfaceFlinger จะดำเนินการจัดสรรนี้ในรอบลบล้างถัดไปหลังจากการเปลี่ยนแปลงความละเอียด
การจัดการเฟรมบัฟเฟอร์ระหว่างการเปลี่ยนความละเอียด
การเปลี่ยนแปลงความละเอียดเกิดขึ้นเนื่องจากสถานการณ์อย่างใดอย่างหนึ่งต่อไปนี้
เหตุการณ์การเสียบปลั๊กที่เริ่มต้นโดยเครื่องมือจัดระเบียบฮาร์ดแวร์ (HWC) ซึ่งเกิดขึ้นเมื่อเปลี่ยนจากจอแสดงผลภายนอกหนึ่งเป็นจอแสดงผลภายนอกอีกจอหนึ่งที่มีความละเอียดเริ่มต้นต่างกัน
ในระหว่างเหตุการณ์การเสียบปลั๊กร้อน ระบบจะปล่อยแฮนเดิลไปยังเฟรมบัฟเฟอร์เก่าเมื่อมีการยกเลิกการจัดสรรข้อมูลการแสดงผลเก่า
การเปลี่ยนโหมดการแสดงผลที่ SurfaceFlinger เริ่มต้น ซึ่งเกิดขึ้นเมื่อผู้ใช้เปลี่ยนความละเอียดด้วยการตั้งค่าผู้ใช้ หรือแอปเปลี่ยนความละเอียดด้วย preferredDisplayModeId
ในระหว่างการเปลี่ยนโหมดการแสดงผล SurfaceFlinger จะปล่อยแฮนเดิลไปยังเฟรมบัฟเฟอร์ไคลเอ็นต์ที่มีอยู่ก่อนที่จะเรียกใช้ setActiveConfig
หรือ setActiveConfigWithConstraints
เพื่อป้องกันปัญหาร้ายแรง เช่น หน่วยความจำกระจัดกระจาย ในอุปกรณ์ที่ไม่ได้จองหน่วยความจำไว้เพียงพอสำหรับเฟรมบัฟเฟอร์เก่าและใหม่ สิ่งสำคัญคือ HWC ต้องหยุดใช้เฟรมบัฟเฟอร์เก่าและปล่อยตัวแฮนเดิลสำหรับเฟรมบัฟเฟอร์เหล่านี้ตามที่แสดงในเคสต่อไปนี้
การปลดแฮนเดิลช่วยให้ระบบยกเลิกการจัดสรรหน่วยความจำเฟรมบัฟเฟอร์ได้ทั้งหมดก่อนที่จะจัดสรรเฟรมบัฟเฟอร์ใหม่ซึ่ง SurfaceFlinger ดำเนินการในรอบลบล้างถัดไป
คําแนะนําสําหรับการจัดการ Framebuffer
หาก HWC ไม่ได้ปล่อยแฮนเดิลไปยังเฟรมบัฟเฟอร์เก่าให้ทันเวลา การจัดสรรเฟรมบัฟเฟอร์ใหม่จะเกิดขึ้นก่อนการจัดสรรเฟรมบัฟเฟอร์เก่า ซึ่งอาจทำให้เกิดปัญหาร้ายแรงเมื่อการจัดสรรใหม่ไม่สําเร็จเนื่องจากมีการแยกส่วนหรือปัญหาอื่นๆ ที่แย่กว่านั้นคือ หาก HWC ไม่ปล่อยแฮนเดิลเหล่านี้เลย ปัญหาหน่วยความจำรั่วอาจเกิดขึ้นได้
ทําตามคําแนะนําต่อไปนี้เพื่อหลีกเลี่ยงการกระจายที่ไม่สําเร็จ
หาก HWC ต้องใช้เฟรมบัฟเฟอร์ไคลเอ็นต์เดิมต่อไปจนกว่าจะมีเฟรมบัฟเฟอร์ไคลเอ็นต์ใหม่ คุณจะต้องจองหน่วยความจำเพียงพอสำหรับทั้งเฟรมบัฟเฟอร์เก่าและใหม่ และอาจต้องเรียกใช้อัลกอริทึมการจัดเรียงข้อมูลในหน่วยความจำเฟรมบัฟเฟอร์
จัดสรรพูลหน่วยความจำเฉพาะสำหรับเฟรมบัฟเฟอร์ที่แยกจากหน่วยความจำบัฟเฟอร์กราฟิกที่เหลือ ซึ่งสำคัญเนื่องจากระหว่างการยกเลิกการจัดสรรและการจัดสรร Framebuffer ใหม่ กระบวนการของบุคคลที่สามอาจพยายามจัดสรรหน่วยความจำกราฟิก หากเฟรมบัฟเฟอร์ใช้พูลหน่วยความจำกราฟิกเดียวกันและหน่วยความจำกราฟิกเต็ม กระบวนการของบุคคลที่สามอาจใช้หน่วยความจำกราฟิกซึ่งเฟรมบัฟเฟอร์จัดสรรไว้ก่อนหน้านี้ ส่งผลให้หน่วยความจำไม่เพียงพอที่จะจัดสรรเฟรมบัฟเฟอร์ใหม่ หรืออาจทำให้พื้นที่หน่วยความจำกระจัดกระจาย
ทดสอบการจัดการ Framebuffer
เราขอแนะนำให้ OEM ทดสอบการจัดการหน่วยความจำ Framebuffer ของลูกค้าอย่างเหมาะสมในอุปกรณ์ของตนเมื่อสลับความละเอียด ดังนี้
สำหรับเหตุการณ์การเสียบปลั๊กร้อน เพียงถอดปลั๊กและเสียบจอแสดงผล 2 จอที่มีความละเอียดต่างกันอีกครั้ง
สําหรับการเปลี่ยนโหมด ให้ใช้การทดสอบ ModeSwitchingTestActivity
CTS
Verifier เพื่อเริ่มการเปลี่ยนโหมดเพื่อทดสอบลักษณะการทํางานของหน่วยความจํา framebuffer
การทดสอบนี้สามารถระบุปัญหาที่ตรวจจับได้ยากทางโปรแกรม
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา 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,["# Client framebuffer management\n\nStarting with Android 13, new framebuffers, used during\n[client](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/DisplayCommand.aidl#113)\ncomposition, are allocated whenever the display resolution changes. This\nallocation is performed by SurfaceFlinger on the next *invalidate* cycle\nafter a resolution change.\n\nFramebuffer management during resolution switches\n-------------------------------------------------\n\nResolution changes occur due to one of the following\ntwo scenarios:\n\n- A [hotplug event](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerCallback.aidl#41),\n initiated by Hardware Composer (HWC), which occurs when swapping from one external\n display to a different external display that has a different default resolution.\n\n During a hotplug event, the handles to the old framebuffers are released\n when the old display data is deallocated.\n- A display mode switch initiated by SurfaceFlinger, which occurs when the\n user changes the resolution with [user settings](https://android.googlesource.com/platform/frameworks/base/+/refs/heads/android16-release/core/java/android/hardware/display/DisplayManager.java#1209),\n or an app changes the resolution with [`preferredDisplayModeId`](https://developer.android.com/reference/android/view/WindowManager.LayoutParams#preferredDisplayModeId).\n\n During a display mode switch, the handles to existing client framebuffers\n are released by SurfaceFlinger before calling [`setActiveConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#550)\n or [`setActiveConfigWithConstraints`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#577).\n\nTo avoid catastrophic problems, such as memory fragmentation, on devices that\ndon't reserve enough memory for the old and new framebuffers, it's critical\nthat HWC ceases to use the old framebuffers and releases any\nhandles to these framebuffers as shown in the following cases:\n\n- For hotplug events, immediately before calling [`onHotplug`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerCallback.aidl#41).\n\n- For mode switches, immediately after the call to [`setActiveConfig`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#550)\n or [`setActiveConfigWithConstraints`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/graphics/composer/aidl/android/hardware/graphics/composer3/IComposerClient.aidl#577).\n\nReleasing the handles allows the framebuffer memory to be fully deallocated\nprior to the allocation of new framebuffers that SurfaceFlinger performs\nduring the next *invalidate* cycle.\n\n### Recommendations for framebuffer management\n\nIf HWC doesn't release handles to old framebuffers in time,\nthe new framebuffer allocation takes place before the old framebuffer\ndeallocation. This can cause catastrophic problems when the new allocation fails\ndue to fragmentation or other issues. Even worse, if\nHWC doesn't release these handles at all, a memory leak can\noccur.\n\nTo avoid catastrophic allocation failures, follow these recommendations:\n\n- If HWC needs to continue using the old client framebuffers until the new\n client framebuffers are provided, then it's critical to reserve enough memory\n for both the old and new framebuffers, and possibly run defragmentation\n algorithms on the framebuffer memory space.\n\n- Allocate a dedicated memory pool for the framebuffers that's separate from\n the rest of the graphic buffer memory. This is important because between\n deallocation and reallocation of the framebuffers, a third-party process can\n attempt to allocate graphics memory. If the same graphics memory pool is\n used by the framebuffer and if the graphics memory is full, the third-party\n process can occupy the graphics memory previously allocated by a framebuffer,\n thus leaving insufficient memory for the framebuffer reallocation or, possibly\n fragmenting the memory space.\n\nTest framebuffer management\n---------------------------\n\nOEMs are advised to test for proper client framebuffer memory management across\nresolution switches for their device, described as follows:\n\n- For hotplug events, simply unplug and reconnect two different displays with\n different resolutions.\n\n- For mode switches, use the [`ModeSwitchingTestActivity`](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/apps/CtsVerifier/src/com/android/cts/verifier/tv/display/ModeSwitchingTestActivity.java;l=47-53;drc=c80d948aff1e7df5c2dc0ddba0d1cd63a90e4d9c) CTS\n Verifier test to initiate a mode switch for testing framebuffer memory behavior.\n This test can visually identify problems that are hard to detect\n programmatically."]]