2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
하드웨어 컴포저 HAL
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
하드웨어 컴포저(HWC) HAL은 버퍼를 가용한 하드웨어와 합성하기 위한 가장 효율적인 방식을 파악합니다. HAL로서 구현은 기기별로 이루어지며 일반적으로 디스플레이 하드웨어 OEM에서 실행합니다.
이러한 접근 방식의 가치는 여러 개의 버퍼를 GPU가 아닌 디스플레이 하드웨어에 합성하는 오버레이 플레인을 고려할 때 쉽게 알 수 있습니다. 예를 들어, 상단에 상태 표시줄이, 하단에 탐색 메뉴가 있고 다른 모든 곳에 앱 콘텐츠가 있는 세로 방향의 일반적인 Android 휴대전화를 가정해 보겠습니다. 각 레이어의 콘텐츠는 별도의 버퍼에 있습니다. 다음 방법 중 하나를 사용하여 구성을 처리할 수 있습니다.
- 앱 콘텐츠를 스크래치 버퍼에 렌더링한 다음 그 위에 상태 표시줄을, 그 위에 탐색 메뉴를 렌더링하고 마지막으로 스크래치 버퍼를 디스플레이 하드웨어에 전달합니다.
- 3개의 버퍼를 모두 디스플레이 하드웨어에 전달하고 화면의 여러 부분과 관련된 여러 버퍼에서 데이터를 읽도록 지시합니다.
두 번째 접근 방식이 상당히 더 효율적일 수 있습니다.
디스플레이 프로세스 기능에는 상당한 차이가 있습니다. 오버레이 수, 레이어의 회전 또는 혼합 가능 여부, 배치 및 중첩에 관한 제한은 API를 통해 표현하기가 어려울 수 있습니다. 이러한 옵션을 수용하기 위해 HWC는 다음과 같은 계산을 실행합니다.
- SurfaceFlinger가 HWC에 전체 레이어 목록을 제공하고 목록을 어떻게 처리하고 싶은지 물어봅니다.
- HWC가 각 레이어를 기기 또는 클라이언트 구성으로 표시하는 방식으로 응답합니다.
- SurfaceFlinger가 모든 클라이언트를 처리하고 출력 버퍼를 HWC에 전달한 다음 HWC가 나머지를 처리하도록 합니다.
하드웨어 공급업체는 의사결정 코드를 맞춤설정할 수 있으므로 모든 기기에서 최고의 성능을 얻을 수 있습니다.
화면에 아무런 변화가 없는 경우에는 오버레이 플레인이 GL 구성보다 효율성이 떨어질 수 있습니다. 특히 오버레이 콘텐츠에 투명 픽셀이 있고 중첩된 레이어가 혼합된 경우에는 효율성이 떨어질 가능성이 훨씬 높습니다. 이러한 경우 HWC는 일부 레이어 또는 모든 레이어를 위해 GLES 구성을 요청한 후 합성된 버퍼를 유지할 수 있습니다. SurfaceFlinger가 같은 버퍼 집합을 합성하도록 요구하는 경우 HWC는 이전에 합성한 스크래치 버퍼를 표시할 수 있습니다. 이렇게 하면 유휴 기기의 배터리 수명을 개선할 수 있습니다.
Android 기기는 일반적으로 4개의 오버레이 플레인을 지원합니다.
오버레이보다 더 많은 레이어를 합성하려고 시도하면 시스템이 일부 레이어에 GLES 구성을 사용할 수 있습니다. 즉, 앱에서 사용하는 레이어 수가 전력 소모 및 성능에 눈에 띄는 영향을 미칠 수 있습니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 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."]]