2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
클라이언트 프레임 버퍼 관리
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Android 13부터 디스플레이 해상도가 변경될 때마다 클라이언트 구성 중에 사용되는 프레임 버퍼가 새로 할당됩니다. 이 할당은 해상도 변경 후 다음 무효화 주기에 SurfaceFlinger에서 실행합니다.
해상도 전환 중 프레임 버퍼 관리
해상도 변경은 다음 두 시나리오 중 하나로 인해 발생합니다.
메모리 조각화와 같은 치명적인 문제를 피하려면 기존 프레임 버퍼와 새 프레임 버퍼를 위해 충분한 메모리를 예약하지 않는 기기에서는 다음 사례에서 보는 바와 같이 HWC가 기존 프레임 버퍼 사용을 중단하고 이러한 버퍼의 모든 핸들을 해제하는 것이 중요합니다.
핸들을 해제하면 다음 무효화 주기 중 SurfaceFlinger가 새 프레임 버퍼를 할당하기 전에 프레임 버퍼 메모리를 완전히 할당 해제할 수 있습니다.
프레임 버퍼 관리를 위한 권장사항
HWC가 시간 내에 기존 프레임 버퍼의 핸들을 해제하지 않으면 새 프레임 버퍼 할당이 기존 프레임 버퍼 할당 해제 전에 발생합니다. 이런 경우 파편화 또는 다른 문제로 새 할당이 실패하면 치명적인 문제가 발생할 수 있습니다. 게다가 HWC에서 이러한 핸들을 전혀 해제하지 않으면 메모리 누수가 발생할 수 있습니다.
치명적인 할당 실패를 방지하려면 다음 권장사항을 따르세요.
새 클라이언트 프레임 버퍼가 제공될 때까지 HWC가 기존 클라이언트 프레임 버퍼를 계속 사용해야 하는 경우, 기존 프레임 버퍼 및 새 프레임 버퍼 모두를 위해 메모리를 충분히 예약하는 것이 중요하며 프레임 버퍼 메모리 공간에서 단편화 알고리즘을 실행할 수도 있습니다.
그래픽 버퍼 메모리의 나머지 부분에서 분리된 프레임 버퍼에 전용 메모리 풀을 할당합니다. 이는 프레임 버퍼를 할당 해제하고 재할당하는 사이에 서드 파티 프로세스가 그래픽 메모리 할당을 시도할 수 있으므로 중요합니다. 프레임 버퍼에서 같은 그래픽 메모리 풀을 사용하는 경우와 그래픽 메모리가 가득 찬 경우 서드 파티 프로세스는 이전에 프레임 버퍼에서 할당한 그래픽 메모리를 차지할 수 있으므로 프레임 버퍼 재할당(또는 메모리 공간 분할일 수도 있음)을 위한 메모리가 부족해집니다.
프레임 버퍼 관리 테스트
OEM은 다음 설명과 같이 기기의 해상도 전환에 관해 클라이언트 프레임 버퍼 메모리 관리를 적절하게 테스트하는 것이 좋습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2024-04-26(UTC)
[null,null,["최종 업데이트: 2024-04-26(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."]]