Grafiki

Platforma Androida oferuje różne interfejsy API do renderowania grafiki 2D i 3D, które współpracują z implementacjami sterowników graficznych producentów. Dlatego ważne jest, aby dobrze rozumieć, jak te interfejsy API działają na wyższym poziomie. Na tej stronie przedstawiamy warstwę abstrakcji sprzętowej (HAL), na której są oparte te sterowniki. Zanim przejdziesz dalej, zapoznaj się z tymi terminami:

obszar roboczy (termin ogólny), Canvas (element interfejsu API)

Obszar roboczy to powierzchnia rysowania, która obsługuje komponowanie rzeczywistych bitów z mapą bitową lub obiektem Surface. Klasa Canvas ma metody do standardowego rysowania komputerowego map bitowych, linii, okręgów, prostokątów, tekstu itp. i jest powiązana z mapą bitową lub powierzchnią. Obszar roboczy to najprostszy sposób rysowania obiektów 2D na ekranie. Klasą bazową jest Canvas.

obiekt rysowalny

Element, który można przeciągnąć, to skompilowany zasób wizualny, który może być używany jako tło, tytuł lub inna część ekranu. Obiekt rysowalny jest zwykle wczytywany do innego elementu interfejsu, np. jako obraz tła. Obiekt rysowalny nie może odbierać zdarzeń, ale przypisuje różne inne właściwości, takie jak stan i harmonogram, aby umożliwić korzystanie z podklas, takich jak obiekty animacji lub biblioteki obrazów. Wiele obiektów, które można przeciągnąć, jest wczytywanych z plików zasobów, które można przeciągnąć – plików XML lub map bitowych opisujących obraz. Zasoby, które można przeciągnąć są kompilowane do podklas android.graphics.drawable. Więcej informacji o elementach, które można przeciągnąć, i innych zasobach znajdziesz w artykule Omówienie zasobów aplikacji.

zasób layoutu

Zasób layoutu to plik XML, który opisuje układ ekranu aktywności. Więcej informacji znajdziesz w artykule Zasób layoutu.

nine-patch (9-patch, NinePatch)

Nine-patch to zasób mapy bitowej o zmiennym rozmiarze, który może być używany jako tło lub inne obrazy na urządzeniu. Więcej informacji znajdziesz w artykule Nine-patch.

OpenGL ES

OpenGL ES to interfejs API na wielu platformach do renderowania grafiki 2D i 3D. Android udostępnia biblioteki OpenGL ES do renderowania 3D z akceleracją sprzętową. W przypadku renderowania 2D prostszą opcją jest obszar roboczy. OpenGL ES jest dostępny w pakiecie Android Native Development Kit (NDK). Funkcje OpenGL ES są udostępniane przez pakiety android.opengl i javax.microedition.khronos.opengles.

powierzchnia (termin ogólny), Surface (element interfejsu API)

Powierzchnia reprezentuje blok pamięci, który jest komponowany na ekranie. Powierzchnia zawiera obszar roboczy do rysowania i udostępnia różne metody pomocnicze do rysowania warstw i zmiany rozmiaru obiektu Surface. Zamiast bezpośrednio używać klasy Surface użyj klasy SurfaceView

widok powierzchni (termin ogólny), SurfaceView (element interfejsu API)

Widok powierzchni to obiekt View, który opakowuje obiekt Surface do rysowania i udostępnia metody do dynamicznego określania jego rozmiaru i formatu. Widok powierzchni umożliwia rysowanie niezależnie od wątku UI w przypadku operacji wymagających dużej ilości zasobów, takich jak gry lub podgląd z aparatu, ale w rezultacie zużywa więcej pamięci. Widok powierzchni obsługuje grafikę obszaru roboczego i OpenGL ES. Klasą bazową obiektu SurfaceView jest SurfaceView.

motyw

Motyw to zestaw właściwości, takich jak rozmiar tekstu i kolor tła, które są połączone w celu zdefiniowania różnych domyślnych ustawień wyświetlania. Android udostępnia kilka standardowych motywów wymienionych w R.style i poprzedzonych prefiksem Theme_.

widok (termin ogólny), View (element interfejsu API)

Widok rysuje prostokątny obszar na ekranie i obsługuje kliknięcia, naciśnięcia klawiszy i inne zdarzenia interakcji. Klasa View jest klasą bazową większości komponentów układu ekranu aktywności lub okna dialogowego, takich jak pola tekstowe i okna. Obiekt View odbiera wywołania z obiektu nadrzędnego (patrz ViewGroup), aby się narysować, i informuje obiekt nadrzędny o preferowanym rozmiarze i lokalizacji, które mogą nie być respektowane przez obiekt nadrzędny. Więcej informacji znajdziesz w artykule View.

grupa widoków (termin ogólny), ViewGroup (element interfejsu API)

Grupa widoków grupuje zestaw widoków podrzędnych. Grupa widoków jest odpowiedzialna za określanie położenia widoków podrzędnych i rozmiaru, a także za wywoływanie każdego z nich w celu narysowania się w odpowiednim momencie. Niektóre grupy widoków są niewidoczne i służą tylko do układu, a inne mają wbudowany interfejs, np. przewijane pole listy. Grupy widoków znajdują się w pakiecie android.widget, ale rozszerzają klasę ViewGroup.

hierarchia widoków

Hierarchia widoków to układ obiektów widoków i grup widoków, który definiuje interfejs użytkownika dla każdego komponentu aplikacji. Hierarchia składa się z grup widoków, które zawierają co najmniej 1 widok podrzędny lub grupę widoków. Aby uzyskać wizualną reprezentację hierarchii widoków na potrzeby debugowania i optymalizacji, możesz użyć narzędzia Przeglądarka hierarchii dostarczanego z pakietem Android SDK.

Vulkan

Vulkan to interfejs API na wielu platformach o niskim narzucie do obsługi grafiki 3D o wysokiej wydajności.

widżet

Widżet to jedna z podklas widoków, które są w pełni zaimplementowane i renderują elementy formularza oraz inne komponenty interfejsu, takie jak pole tekstowe lub menu wyskakujące. Ponieważ widżet jest w pełni zaimplementowany, obsługuje pomiar, rysowanie siebie i reagowanie na zdarzenia ekranowe. Widżety znajdują się w pakiecie android.widget.

okno (termin ogólny), Window (element interfejsu API)

W aplikacji na Androida okno to obiekt pochodzący z Window klasy abstrakcyjnej, który określa elementy okna ogólnego, takie jak wygląd, tekst paska tytułu oraz lokalizacja i zawartość menu. Okna dialogowe i aktywności używają implementacji klasy Window do renderowania obiektu Window. Nie musisz implementować klasy Window ani używać okien w swojej aplikacji.

Deweloperzy aplikacji rysują obrazy na ekranie na 3 sposoby: za pomocą obszaru roboczego, OpenGL ES lub Vulkan.

Komponenty graficzne Androida

Niezależnie od tego, jakiego interfejsu API do renderowania używają deweloperzy, wszystko jest renderowane na powierzchni. Powierzchnia reprezentuje stronę producenta kolejki buforów, która jest często wykorzystywana przez SurfaceFlinger. Każde okno utworzone na platformie Androida jest oparte na powierzchni. Wszystkie widoczne renderowane powierzchnie są komponowane na wyświetlaczu przez SurfaceFlinger.

Ten diagram pokazuje, jak współpracują ze sobą kluczowe komponenty:

Rysunek 1. Sposób renderowania powierzchni.

Główne komponenty są opisane w kolejnych sekcjach.

Producenci strumienia obrazów

Producentem strumienia obrazów może być wszystko, co tworzy bufory graficzne do wykorzystania. Przykłady to OpenGL ES, Canvas 2D i dekodery wideo mediaserver.

Konsumenci strumienia obrazów

Najczęstszym konsumentem strumieni obrazów jest SurfaceFlinger, usługa systemowa, która wykorzystuje aktualnie widoczne powierzchnie i komponuje je na wyświetlaczu za pomocą informacji dostarczanych przez Menedżera okien. SurfaceFlinger to jedyna usługa, która może modyfikować zawartość wyświetlacza. SurfaceFlinger używa OpenGL i Hardware Composer (HWC) do komponowania grupy powierzchni.

Inne aplikacje OpenGL ES mogą również wykorzystywać strumienie obrazów, np. aplikacja aparatu, która wykorzystuje strumień obrazów podglądu z aparatu. Aplikacje inne niż GL mogą być również konsumentami, np. klasa ImageReader.

Hardware Composer

Warstwa abstrakcji sprzętu dla podsystemu wyświetlania. SurfaceFlinger może delegować niektóre zadania kompozycji do HWC, aby odciążyć OpenGL i GPU. SurfaceFlinger działa jak zwykły klient OpenGL ES. Gdy na przykład SurfaceFlinger aktywnie komponuje 1 lub 2 bufory w 3., używa OpenGL ES. Dzięki temu komponowanie zużywa mniej energii niż w przypadku, gdy wszystkie obliczenia wykonuje GPU.

Warstwa abstrakcji sprzętu Hardware Composer HAL wykonuje drugą połowę pracy i jest centralnym punktem całego renderowania grafiki w Androidzie. HWC musi obsługiwać zdarzenia, z których jednym jest VSync (drugim jest hotplug do obsługi HDMI typu plug-and-play).

Gralloc

Alokator pamięci graficznej (Gralloc) jest potrzebny do alokowania pamięci wymaganej przez producentów obrazów. Więcej informacji znajdziesz w artykułach BufferQueue i Gralloc.

Przepływ danych

Ten diagram przedstawia potok graficzny Androida:

Rysunek 2. Przepływ danych graficznych w Androidzie.

Obiekty po lewej stronie to renderery tworzące bufory graficzne, takie jak ekran główny, pasek stanu i interfejs systemowy. SurfaceFlinger to kompozytor, a HWC to kompozytor.

BufferQueue

Kolejki buforów zapewniają połączenie między komponentami graficznymi Androida. Są to 2 kolejki, które pośredniczą w stałym cyklu buforów od producenta do konsumenta. Gdy producenci przekazują swoje bufory, SurfaceFlinger odpowiada za komponowanie wszystkiego na wyświetlaczu.

Ten diagram ilustruje proces komunikacji BufferQueue:

Rysunek 3. Proces komunikacji BufferQueue.

BufferQueue zawiera logikę, która łączy producentów i konsumentów strumienia obrazów. Przykładami producentów obrazów są podglądy z aparatu generowane przez warstwę abstrakcji sprzętu aparatu lub gry OpenGL ES. Przykładami konsumentów obrazów są SurfaceFlinger lub inna aplikacja, która wyświetla strumień OpenGL ES, np. aplikacja aparatu wyświetlająca wizjer aparatu.

BufferQueue to struktura danych, która łączy pulę buforów z kolejką i używa komunikacji międzyprocesowej (IPC) Binder do przekazywania buforów między procesami. Interfejs producenta lub to, co przekazujesz komuś, kto chce generować bufory graficzne, to IGraphicBufferProducer (część SurfaceTexture). BufferQueue jest często używany do renderowania na powierzchni i wykorzystywania za pomocą GL Consumer, a także do innych zadań.

BufferQueue może działać w 3 różnych trybach:

tryb synchroniczny

Domyślnie BufferQueue 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 odrzucany. Jeśli producent jest zbyt szybki i tworzy bufory szybciej, niż są one opróżniane, blokuje się i czeka na wolne bufory.

tryb nieblokujący

BufferQueue może też działać w trybie nieblokującym, w którym w takich przypadkach generuje błąd zamiast czekać na bufor. W tym trybie również żaden bufor nie jest odrzucany. Jest to przydatne do unikania potencjalnych zakleszczeń w oprogramowaniu aplikacji, które może nie rozumieć złożonych zależności platformy graficznej.

tryb odrzucania

BufferQueue można skonfigurować tak, aby odrzucał stare bufory zamiast generować błędy lub czekać. Jeśli na przykład renderujesz GL do widoku tekstury i rysujesz tak szybko, jak to możliwe, bufory muszą zostać odrzucone.

Aby wykonać większość tej pracy, SurfaceFlinger działa jak zwykły klient OpenGL ES. Gdy na przykład SurfaceFlinger aktywnie komponuje 1 lub 2 bufory w 3., używa OpenGL ES.

Warstwa abstrakcji sprzętu Hardware Composer wykonuje drugą połowę pracy. Ta warstwa abstrakcji sprzętu jest centralnym punktem całego renderowania grafiki w Androidzie.