Android Graphics 번역 1편 - OverView

안드로이드의 Graphics 챕터의 모든 내용을 번역하고자 한다. 문서에서도 추천하듯, 순서대로 읽을 것을 권장하며 안드로이드 그래픽 아키텍처에 대해 궁금한적이 있다면, 올바르게 찾아왔다. 글을 번역하는 시점은 2022년 7월경이며, 시간이 흐름에 따라 미래에는 상당부분 내용이 달라질 수 있음을 인지해야 한다.

 

참조: https://source.android.com/devices/graphics

그래픽  |  Android 오픈소스 프로젝트  |  Android Open Source Project

 

안드로이드 프레임워크는 그래픽 드라이버 제조업체의 구현과 상호작용하는 다양한 2D 및 3D 그래픽 rendering API를 제공한다. 따라서 이러한 API들이 higher level에서 어떻게 동작하는지 이해하는 것이 중요하다. 이 페이지에서는 이러한 드라이버가 구축되는 graphics hardware abstraction layer(HAL)을 소개한다.

앱 개발자는 3가지의 방법으로 화면에 이미지를 그릴 수 있다. → Canvas, OpenGL ES, Vulkan

Android graphic components

개발자가 어떤 API를 사용하던 간에, 모든 것은 Surface에 rendering 된다. Surface는 SurfaceFlinger에 의해 consume되어지는 buffer queue의 producer 역할을 맡는다. Android platform에서 만들어지는 모든 window는 Surface에 의해 뒷받침 된다. rendering된 모든 가시적인 Surface는 SurfaceFlinger에 의해 display에 합성된다.

 

다음의 다이어그램은 주요 component들이 어떻게 함께 작동하는지 보여준다.

각 구성요소는 다음과 같다.

Image Stream Producers

한 Image Stream Producer는 소비(consume)을 위한 그래픽 buffer를 생성하는 모든 것이 될 수 있다. 예를 들면 OpenGL ES, Canvas 2D, mediaserver video decoder 등이 있다.

Image stream consumers

가장 일반적인 image stream의 consumer는 SurfaceFlinger이다 — Window Manager에 의해 제공 받은 정보를 이용해서 그것들을 display에 합성하고 현재 보이는 Surface를 consume하는 system service이다.

SurfaceFlinger는 display의 내용물을 수정할 수 있는 유일한 service이다. SurfaceFlinger는 Surface 그룹을 합성하기 위해 OpenGL과 Hardware Composer를 사용한다.

다른 OpenGL ES App 또한 image stream을 consume 할 수 있다(ex: camera preview image stream을 consume하는 camera app과 같은). 또한 Non-GL Application(ex: ImageReader)또한 consumer가 될 수 있다.

Hardware Composer

display subsystem을 위한 hardware abstraction 이다. SurfaceFlinger는 OpenGL 및 GPU의 짐을 덜어주기 위해 특정 합성 동작을 Hardware Composer에게 넘겨 줄 수 있다. 이때 SurfaceFlinger는 마치 또다른 OpenGL ES Client인 것처럼 행동한다.

따라서 SurfaceFlinger가 예를 들어 하나 또는 두 개의 버퍼를 세 번째 버퍼로 적극적으로 합성할 때 OpenGL ES를 사용한다. 이것은 GPU가 모든 계산을 수행하도록 하는 것보다 합성을 더 낮은 전력으로 만든다.

Hardware Composer HAL은 남은 다른 일을 수행하며, 이것이 Android Graphic rendering의 중심 포인트다. Hardware Composer는 몇몇 이벤트를 지원해야 하며 그중 하나가 VSYNC이다.

Gralloc

graphics memory allocate(Gralloc)은 image producer에 의해 메모리 할당이 요청될 떄 필요하다. 자세한 사항은 Gralloc을 소개하는 문서에서 살펴본다.

Data flow

다음 다이어그램은 Android graphic pipeline에 대한 묘사이다.

 

 

왼쪽의 각 요소들은 graphic buffer를 생산하는(ex: home screen, status bar, system UI) renderer들이다. SurfaceFlinger는 compositor이고, HWC는 composer이다.

BufferQueue

BufferQueue는 Android graphic componets 사이에 접착제를 제공해준다. 이것은 생산자에서 소비자까지의 buffer의 일정한 주기를 중재하는 한 쌍의 queue이다. 일단 생산자가 그들의 buffer에서 손을 떼면, SurfaceFlinger는 display에 모든 것을 합성 할 책임이 있다.

 

아래는 BufferQueue의 communication 과정을 나타내는 다이어그램이다.

 

 

BufferQueue에는 이미지 스트림 생산자와 이미지 스트림 소비자를 함께 묶는 logic이 포함되어 있다.

BufferQueue는 buffer pool과 queue를 결합하고 Binder IPC를 사용하여 프로세스 간에 buffer를 전달하는 자료구조이다.

BufferQueue는 Synchronous-like mode, Non-blocking mode, Discard mode 각각 3가지 모드로 동작할 수 있다.