Google은 흑인 공동체를 위한 인종 간 평등을 진전시키기 위해 노력하고 있습니다. Google에서 어떤 노력을 하고 있는지 확인하세요.

하드웨어 컴포저 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 구성을 사용하는 원인이 될 수 있습니다. 즉, 앱에서 사용하는 레이어 수가 전력 소모 및 성능에 눈에 띄는 영향을 미칠 수 있습니다.