Platforma Android oferuje różne interfejsy API renderowania grafiki dla 2D i 3D, które współdziałają z implementacjami sterowników graficznych producentów, dlatego ważne jest, aby dobrze zrozumieć, jak te interfejsy API działają na wyższym poziomie. Ta strona przedstawia 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
Bez względu na to, jakiego interfejsu używają programiści renderowania, wszystko jest renderowane na powierzchni . Powierzchnia reprezentuje stronę producenta kolejki bufora, 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ą wkomponowane w wyświetlacz przez SurfaceFlinger.
Poniższy diagram pokazuje, jak współpracują ze sobą kluczowe komponenty:
Rysunek 1. Jak renderowane są powierzchnie
Główne komponenty zostały opisane poniżej:
Producenci strumienia obrazu
Producentem strumienia obrazu może być wszystko, co produkuje bufory graficzne do wykorzystania. Przykładami są dekodery wideo OpenGL ES, Canvas 2D i mediaserver.
Konsumenci strumienia obrazu
Najczęstszym konsumentem strumieni obrazu 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. Konsumentami mogą być również aplikacje inne niż GL, na przykład klasa ImageReader.
Kompozytor sprzętu
Abstrakcja sprzętowa dla podsystemu wyświetlania. SurfaceFlinger może delegować niektóre prace związane z kompozycją do Hardware Composer, aby odciążyć pracę z OpenGL i GPU. SurfaceFlinger działa jak kolejny klient OpenGL ES. Kiedy więc SurfaceFlinger aktywnie łączy jeden lub dwa bufory w trzeci, na przykład używa OpenGL ES. To sprawia, że komponowanie jest mniejsze niż w przypadku, gdy GPU przeprowadza wszystkie obliczenia.
Hardware Composer HAL wykonuje drugą połowę pracy i jest centralnym punktem całego renderowania grafiki Androida. Hardware Composer musi obsługiwać zdarzenia, z których jedno to VSYNC (inne to hotplug do obsługi HDMI typu plug-and-play).
Gralloc
Alokator pamięci graficznej (Gralloc) jest potrzebny do alokacji pamięci wymaganej przez producentów obrazów. Aby uzyskać szczegółowe informacje, zobacz Gralloc HAL .
Przepływ danych
Zobacz poniższy diagram, aby zapoznać się z obrazem potoku graficznego systemu Android:
Rysunek 2. Graficzny przepływ danych przez system Android
Obiekty po lewej stronie to renderery produkujące bufory graficzne, takie jak ekran główny, pasek stanu i interfejs użytkownika systemu. Kompozytorem jest SurfaceFlinger, a kompozytorem Hardware Composer.
Kolejka buforów
BufferQueues zapewniają klej między składnikami graficznymi systemu Android. Są to pary kolejek, które pośredniczą w stałym cyklu buforów od producenta do konsumenta. Gdy producenci oddają bufory, SurfaceFlinger jest odpowiedzialny za komponowanie wszystkiego na wyświetlaczu.
Zobacz poniższy diagram dla procesu komunikacji BufferQueue.
Rysunek 3. Proces komunikacji BufferQueue
BufferQueue zawiera logikę, która łączy ze sobą producentów strumienia obrazu i odbiorców strumienia obrazu. Przykładami producentów obrazu są podglądy kamer produkowane przez kamery HAL lub gry OpenGL ES. Niektóre przykłady konsumentów obrazu to SurfaceFlinger lub inna aplikacja, która wyświetla 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 używa Binder IPC do przekazywania buforów między procesami. Interfejs producenta, czyli to, co przekazujesz komuś, kto chce generować bufory graficzne, to IGraphicBufferProducer (część SurfaceTexture ). BufferQueue jest często używany między innymi do renderowania na powierzchni i korzystania z 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 wychodzi na konsumenta. W tym trybie żaden bufor nie jest odrzucany. A jeśli producent jest zbyt szybki i tworzy bufory szybciej niż są one 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 generuje błąd, zamiast czekać na bufor w tych przypadkach. Również w tym trybie bufor nie jest odrzucany. Jest to przydatne, aby uniknąć potencjalnych zakleszczeń w oprogramowaniu aplikacji, które może nie rozumieć złożonych zależności struktury graficznej.
Tryb odrzucania — wreszcie 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 rysunku tak szybko, jak to możliwe, bufory muszą zostać usunięte.
Aby przeprowadzić większość tych prac, SurfaceFlinger działa jako kolejny klient OpenGL ES. Kiedy więc SurfaceFlinger aktywnie łączy jeden lub dwa bufory w trzeci, na przykład używa OpenGL ES.
Drugą połowę prac prowadzi Hardware Composer HAL. Ta warstwa HAL działa jako centralny punkt dla całego renderowania grafiki w systemie Android.