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