하드웨어 컴포저 HAL

하드웨어 컴포저(HWC) HAL은 버퍼를 가용한 하드웨어와 합성하기 위한 가장 효율적인 방식을 파악합니다. HAL로서는 구현이 기기와 관련이 있으며 보통 디스플레이 하드웨어 OEM에 의해 수행됩니다.

이 접근 방식의 가치는 여러 개의 버퍼를 GPU가 아닌 디스플레이 하드웨어에서 합성하는 오버레이 플레인을 생각해 보면 쉽게 인지할 수 있습니다. 예를 들면 상태 표시줄이 상단에, 탐색 메뉴가 하단에, 그리고 앱 콘텐츠가 다른 모든 곳에 위치한 세로 방향의 일반적인 Android를 생각해 보세요. 각 레이어의 콘텐츠는 별개의 버퍼에 있습니다. 다음 방법 중 하나를 사용하여 구성을 처리할 수 있습니다.

  • 앱 콘텐츠를 스크래치 버퍼에 렌더링한다음 그 위에 상태 표시줄을 렌더링하고 마지막으로 스크래치 버퍼를 디스플레이 하드웨어에 전달합니다.
  • 3개의 버퍼를 전부 디스플레이 하드웨어에 전달하고 화면의 여러 부분과 관련된 다양한 버퍼의 데이터를 읽도록 지시합니다.

두 번째 접근 방식이 상당히 더 효율적일 수 있습니다t.

디스플레이 프로세스 기능에는 상당한 차이가 있습니다. 오버레이 수, 레이어의 회전 또는 블렌딩 가능 여부와 배치 및 중첩에 대한 제한은 API를 통해 표현하기가 어려울 수 있습니다. 이러한 옵션을 수용하기 위해 HWC는 다음과 같은 계산을 수행합니다.

  1. SurfaceFlinger가 HWC에 전체 레이어 목록을 제공하고 목록을 어떻게 처리하고 싶은지 물어봅니다.
  2. HWC가 각 레이어를 기기 또는 클라이언트 구성으로 표시하는 방식으로 응답합니다.
  3. SurfaceFlinger가 모든 클라이언트를 처리하고 출력 버퍼를 HWC에 전달한 다음 HWC가 나머지를 처리하도록 합니다.

하드웨어 공급업체는 의사결정 코드를 맞춤설정할 수 있으므로 모든 기기에서 최고의 성능을 얻을 수 있습니다.

화면에 아무런 변화가 없는 경우에는 오버레이 플레인이 GL 구성보다 효율성이 떨어질 수 있습니다. 특히 오버레이 콘텐츠에 투명 픽셀이 있고 중첩된 레이어가 블렌딩된 경우에는 효율성이 떨어질 가능성이 훨씬 높습니다. 이러한 경우 HWC는 모든 레이어의 일부에 대해 GLES 구성을 요청한 후 합성된 버퍼를 유지할 수 있습니다. SurfaceFlinger가 같은 버퍼 집합을 합성하도록 요구하는 경우 HWC는 이전에 합성한 스크래치 버퍼를 표시할 수 있습니다. 이렇게 하면 유휴 기기의 배터리 수명을 개선할 수 있습니다.

Android 기기는 일반적으로 4개의 오버레이 플레인을 지원합니다. 오버레이보다 더 많은 레이어를 합성하려고 시도하면 시스템이 일부 레이어에 GLES 구성을 사용하는 원인이 될 수 있습니다. 즉, 앱에서 사용하는 레이어 수가 전력 소모 및 성능에 눈에 띄는 영향을 미칠 수 있습니다.