Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release
thay vì aosp-main
để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.
Quản lý vùng đệm khung hình của ứng dụng
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Kể từ Android 13, vùng đệm khung hình mới (dùng trong quá trình kết hợp ứng dụng) sẽ được phân bổ mỗi khi độ phân giải màn hình thay đổi. SurfaceFlinger thực hiện việc phân bổ này trong chu kỳ vô hiệu hoá tiếp theo sau khi thay đổi độ phân giải.
Quản lý vùng đệm khung hình trong quá trình chuyển đổi độ phân giải
Thay đổi về độ phân giải xảy ra do một trong hai trường hợp sau:
Sự kiện hotplug do Trình tổng hợp phần cứng (HWC) khởi tạo, xảy ra khi hoán đổi từ một màn hình ngoài sang một màn hình ngoài khác có độ phân giải mặc định khác.
Trong sự kiện hotplug, các tay điều khiển đến vùng đệm khung hình cũ sẽ được giải phóng khi dữ liệu hiển thị cũ được giải phóng.
Nút chuyển chế độ hiển thị do SurfaceFlinger khởi tạo, xảy ra khi người dùng thay đổi độ phân giải bằng chế độ cài đặt người dùng hoặc một ứng dụng thay đổi độ phân giải bằng preferredDisplayModeId
.
Trong quá trình chuyển đổi chế độ hiển thị, SurfaceFlinger sẽ giải phóng các tay điều khiển đến vùng đệm khung hình của ứng dụng hiện có trước khi gọi setActiveConfig
hoặc setActiveConfigWithConstraints
.
Để tránh các sự cố nghiêm trọng, chẳng hạn như phân mảnh bộ nhớ, trên các thiết bị không dành đủ bộ nhớ cho vùng đệm khung hình cũ và mới, điều quan trọng là HWC ngừng sử dụng vùng đệm khung hình cũ và giải phóng mọi tay điều khiển đến các vùng đệm khung hình này như trong các trường hợp sau:
Việc giải phóng các tay điều khiển cho phép bộ nhớ vùng đệm khung hình được giải phóng hoàn toàn trước khi phân bổ vùng đệm khung hình mới mà SurfaceFlinger thực hiện trong chu kỳ vô hiệu hoá tiếp theo.
Đề xuất về việc quản lý vùng đệm khung hình
Nếu HWC không giải phóng kịp thời các tay điều khiển cho vùng đệm khung hình cũ, thì việc phân bổ vùng đệm khung hình mới sẽ diễn ra trước khi giải phóng vùng đệm khung hình cũ. Điều này có thể gây ra các sự cố nghiêm trọng khi quá trình phân bổ mới không thành công do phân mảnh hoặc các vấn đề khác. Tệ hơn nữa, nếu
HWC không giải phóng các tay điều khiển này, thì tình trạng rò rỉ bộ nhớ có thể xảy ra.
Để tránh các lỗi phân bổ nghiêm trọng, hãy làm theo các đề xuất sau:
Nếu HWC cần tiếp tục sử dụng vùng đệm khung hình ứng dụng cũ cho đến khi vùng đệm khung hình ứng dụng mới được cung cấp, thì điều quan trọng là phải dành đủ bộ nhớ cho cả vùng đệm khung hình cũ và mới, đồng thời có thể chạy các thuật toán phân mảnh trên không gian bộ nhớ vùng đệm khung hình.
Phân bổ một nhóm bộ nhớ chuyên dụng cho vùng đệm khung hình tách biệt với phần còn lại của bộ nhớ vùng đệm đồ hoạ. Điều này rất quan trọng vì giữa việc giải phóng và phân bổ lại vùng đệm khung hình, một quy trình của bên thứ ba có thể cố gắng phân bổ bộ nhớ đồ hoạ. Nếu vùng nhớ đồ hoạ giống nhau được vùng đệm khung hình sử dụng và nếu bộ nhớ đồ hoạ đã đầy, thì quy trình của bên thứ ba có thể chiếm bộ nhớ đồ hoạ do vùng đệm khung hình phân bổ trước đó, do đó không đủ bộ nhớ để phân bổ lại vùng đệm khung hình hoặc có thể phân mảnh không gian bộ nhớ.
Kiểm thử tính năng quản lý vùng đệm khung hình
Các nhà sản xuất thiết bị gốc (OEM) nên kiểm thử việc quản lý bộ nhớ vùng đệm khung hình của ứng dụng một cách thích hợp trên các nút chuyển đổi độ phân giải cho thiết bị của họ, được mô tả như sau:
Đối với các sự kiện hotplug, bạn chỉ cần rút phích cắm và kết nối lại hai màn hình khác nhau có độ phân giải khác nhau.
Đối với các nút chuyển chế độ, hãy sử dụng quy trình kiểm thử Trình xác minh CTS ModeSwitchingTestActivity
để bắt đầu chuyển đổi chế độ nhằm kiểm thử hành vi của bộ nhớ vùng đệm khung hình.
Quy trình kiểm thử này có thể xác định trực quan các vấn đề khó phát hiện bằng cách lập trình.
Nội dung và mã mẫu trên trang này phải tuân thủ các giấy phép như mô tả trong phần Giấy phép nội dung. Java và OpenJDK là nhãn hiệu hoặc nhãn hiệu đã đăng ký của Oracle và/hoặc đơn vị liên kết của Oracle.
Cập nhật lần gần đây nhất: 2025-07-27 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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."]]