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. Zanim przejdziesz dalej do tej sekcji, zapoznaj się z następującymi terminami:
Canvas (element API)Surface . Canvas zawiera metody standardowego komputerowego rysowania bitmap, linii, okręgów, prostokątów, tekstu itd. i jest powiązana z bitmapą lub powierzchnią. Płótno to najprostszy i najłatwiejszy sposób rysowania obiektów 2D na ekranie. Klasą bazową jest Canvas .android.graphics.drawable . Aby uzyskać więcej informacji na temat rysunków i innych zasobów, zobacz Zasoby .android.opengl i javax.microedition.khronos.opengles udostępniają funkcjonalność OpenGL ES.Surface (element API)Surface . Użyj klasy SurfaceView zamiast bezpośrednio klasy Surface .SurfaceView (element API)View , który otacza obiekt Surface do rysowania i udostępnia metody dynamicznego określania jego rozmiaru i formatu. Widok powierzchniowy umożliwia rysowanie niezależnie od wątku interfejsu użytkownika w przypadku operacji wymagających dużych zasobów, takich jak gry lub podglądy z kamery, ale w rezultacie wymaga dodatkowej pamięci. Widok powierzchni obsługuje zarówno grafikę płótna, jak i grafikę OpenGL ES. Klasą bazową obiektu SurfaceView jest SurfaceView .R.style i poprzedzonych Theme_ .View (element API)View jest klasą bazową dla większości komponentów układu działania lub ekranu okna dialogowego, takich jak pola tekstowe i okna. Obiekt View odbiera wywołania od swojego obiektu nadrzędnego (zobacz ViewGroup ), aby sam się narysować i informuje swój obiekt nadrzędny o preferowanym rozmiarze i lokalizacji, które mogą nie być przestrzegane przez obiekt nadrzędny. Aby uzyskać więcej informacji, zobacz View .ViewGroup (element API)widget , ale należy rozszerzyć klasę ViewGroup .android.widget .Window (element API)Window , który określa elementy okna ogólnego, takie jak wygląd i działanie, tekst paska tytułu oraz lokalizacja i zawartość menu. Okna dialogowe i działania wykorzystują implementację klasy Window do renderowania obiektu Window . Nie musisz implementować klasy Window ani używać okien w swojej aplikacji.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, z jakiego narzędzia renderowania korzystają programiści API, 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 obrazów 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.