Struktura systemu Android oferuje różnorodne interfejsy API do renderowania grafiki 2D i 3D, które współdziałają z implementacjami sterowników graficznych producenta, dlatego ważne jest, aby dobrze zrozumieć, jak te interfejsy API działają na wyższym poziomie. Na tej stronie przedstawiono warstwę abstrakcji sprzętu graficznego (HAL), na której zbudowane są te sterowniki.
Twórcy aplikacji rysują obrazy na ekranie na trzy sposoby: za pomocą Canvas , OpenGL ES lub Vulkan .
Komponenty graficzne Androida
Niezależnie od tego, z jakiego interfejsu API korzystają programiści renderowania, wszystko jest renderowane na powierzchni . Powierzchnia reprezentuje stronę producenta kolejki buforów, która jest często używana przez SurfaceFlinger. Każde okno utworzone na platformie Android jest wspierane przez powierzchnię. Wszystkie wyrenderowane widoczne powierzchnie są łączone na wyświetlaczu przez SurfaceFlinger.
Poniższy diagram pokazuje, jak kluczowe komponenty współpracują ze sobą:
Rysunek 1. Sposób renderowania powierzchni
Główne komponenty opisano poniżej:
Producenci strumieni obrazu
Producentem strumienia obrazu może być wszystko, co produkuje bufory graficzne do wykorzystania. Przykłady obejmują dekodery wideo OpenGL ES, Canvas 2D i mediaserver.
Konsumenci strumienia obrazów
Najpopularniejszym konsumentem strumieni obrazów jest SurfaceFlinger, usługa systemowa, która zużywa aktualnie widoczne powierzchnie i łączy je na wyświetlaczu przy użyciu informacji dostarczonych przez Menedżera okien. SurfaceFlinger to jedyna usługa, która może modyfikować zawartość wyświetlacza. SurfaceFlinger używa OpenGL i Hardware Composer do komponowania grupy powierzchni.
Inne aplikacje OpenGL ES również mogą wykorzystywać strumienie obrazów, na przykład aplikacja aparatu zużywająca strumień obrazu podglądu z kamery. Aplikacje inne niż GL również mogą być konsumentami, na przykład klasa ImageReader.
Kompozytor sprzętu
Abstrakcja sprzętowa dla podsystemu wyświetlania. SurfaceFlinger może delegować pewne prace związane z kompozycją do Hardware Composer, aby odciążyć OpenGL i GPU. SurfaceFlinger działa jak kolejny klient OpenGL ES. Na przykład, gdy SurfaceFlinger aktywnie łączy jeden lub dwa bufory w trzeci, używa OpenGL ES. To sprawia, że komponowanie zużywa mniej energii niż wykonywanie wszystkich obliczeń przez procesor graficzny.
Drugą połowę pracy wykonuje Hardware Composer HAL , który stanowi centralny punkt renderowania grafiki w systemie Android. Program Hardware Composer musi obsługiwać zdarzenia, z których jedno to VSYNC (inne to hotplug obsługujący technologię plug-and-playHDMI).
Graloc
Do przydzielania pamięci wymaganej przez producentów obrazów potrzebny jest moduł alokacji pamięci graficznej (Gralloc). Aby uzyskać szczegółowe informacje, zobacz Gralloc HAL .
Przepływ danych
Poniższy diagram przedstawia potok graficzny systemu Android:
Rysunek 2. Graficzny przepływ danych przez Androida
Obiekty po lewej stronie to moduły renderujące tworzące bufory graficzne, takie jak ekran główny, pasek stanu i interfejs użytkownika systemu. SurfaceFlinger jest kompozytorem, a Hardware Composer jest kompozytorem.
Kolejka buforowa
BufferQueues zapewniają spoiwo pomiędzy komponentami graficznymi Androida. Są to pary kolejek, które pośredniczą w stałym cyklu buforów od producenta do konsumenta. Gdy producenci przekażą swoje bufory, SurfaceFlinger jest odpowiedzialny za umieszczenie wszystkiego na wyświetlaczu.
Zobacz poniższy diagram przedstawiający proces komunikacji BufferQueue.
Rysunek 3. Proces komunikacji BufferQueue
BufferQueue zawiera logikę, która łączy producentów strumieni obrazów i konsumentów strumieni obrazów. Przykładami producentów obrazów są podglądy z kamer tworzone przez kamery HAL lub gry OpenGL ES. Przykładami konsumentów obrazu są SurfaceFlinger lub inna aplikacja wyświetlająca strumień OpenGL ES, na przykład aplikacja aparatu wyświetlająca wizjer aparatu.
BufferQueue to struktura danych, która łączy pulę buforów z kolejką i wykorzystuje Binder IPC do przekazywania buforów pomiędzy procesami. Interfejs producenta, czyli to, co przekazujesz komuś, kto chce wygenerować bufory graficzne, to IGraphicBufferProducer (część SurfaceTexture ). BufferQueue jest często używany między innymi do renderowania na urządzeniu Surface i korzystania z niego przez konsumenta GL.
BufferQueue może działać w trzech różnych trybach:
Tryb synchroniczny — BufferQueue domyślnie działa w trybie synchronicznym, w którym każdy bufor przychodzący od producenta jest wysyłany do konsumenta. W tym trybie żaden bufor nie jest nigdy odrzucany. A jeśli producent będzie zbyt szybki i utworzy bufory szybciej, niż są opróżniane, zablokuje się i będzie czekał na wolne bufory.
Tryb nieblokujący — BufferQueue może również działać w trybie nieblokującym, w którym w takich przypadkach generuje błąd, zamiast czekać na bufor. W tym trybie żaden bufor nie jest nigdy odrzucany. Jest to przydatne, aby uniknąć potencjalnych zakleszczeń w oprogramowaniu, które może nie rozumieć złożonych zależności struktury graficznej.
Tryb odrzucania — na koniec BufferQueue można skonfigurować tak, aby odrzucał stare bufory zamiast generować błędy lub czekać. Na przykład, jeśli przeprowadzasz renderowanie GL do widoku tekstury i rysujesz tak szybko, jak to możliwe, bufory muszą zostać usunięte.
Aby wykonać większość tej pracy, SurfaceFlinger działa jako kolejny klient OpenGL ES. Na przykład, gdy SurfaceFlinger aktywnie łączy jeden lub dwa bufory w trzeci, używa OpenGL ES.
Drugą połowę pracy wykonuje Hardware Composer HAL. Ta warstwa HAL działa jako centralny punkt całego renderowania grafiki Androida.