Co każdy programista powinien wiedzieć o SurfaceHolder, EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, StructureView, SurfaceFlinger i Vulkan.
Na tej stronie opisano podstawowe elementy architektury graficznej na poziomie systemu Android oraz sposób ich wykorzystania przez platformę aplikacji i system multimedialny. Nacisk położony jest na sposób, w jaki bufory danych graficznych przemieszczają się w systemie. Jeśli kiedykolwiek zastanawiałeś się, dlaczego SurfaceView i StructureView zachowują się w ten sposób lub w jaki sposób powierzchnie i EGLSurface wchodzą w interakcję, jesteś we właściwym miejscu.
Zakłada się pewną znajomość urządzeń z systemem Android i tworzenia aplikacji. Nie potrzebujesz szczegółowej wiedzy na temat frameworku aplikacji i wspomina się o bardzo niewielu wywołaniach API, ale materiał nie pokrywa się z inną publiczną dokumentacją. Celem jest dostarczenie szczegółowych informacji na temat istotnych zdarzeń związanych z renderowaniem ramki w celu uzyskania danych wyjściowych, aby ułatwić podejmowanie świadomych wyborów podczas projektowania aplikacji. Aby to osiągnąć, pracujemy oddolnie, opisując, jak działają klasy interfejsu użytkownika, a nie jak można z nich korzystać.
Ta sekcja zawiera kilka stron obejmujących wszystko, od materiału podstawowego, przez szczegóły HAL, po przypadki użycia. Zaczyna się od wyjaśnienia buforów graficznych Androida, opisuje kompozycję i mechanizm wyświetlania, a następnie przechodzi do mechanizmów wyższego poziomu, które dostarczają dane kompozytorowi. Zalecamy czytanie stron w podanej poniżej kolejności, zamiast przeskakiwać do tematu, który brzmi interesująco.
Komponenty niskiego poziomu
- BufferQueue i graloc . BufferQueue łączy coś, co generuje bufory danych graficznych ( producent ) z czymś, co akceptuje dane do wyświetlenia lub dalszego przetwarzania ( konsument ). Przydzielanie buforów odbywa się poprzez alokator pamięci gralloc zaimplementowany poprzez specyficzny dla dostawcy interfejs HAL.
- SurfaceFlinger, Hardware Composer i wyświetlacze wirtualne . SurfaceFlinger akceptuje bufory danych z wielu źródeł, składa je i wysyła na wyświetlacz. Hardware Composer HAL (HWC) określa najbardziej efektywny sposób łączenia buforów z dostępnym sprzętem, a wirtualne wyświetlacze udostępniają złożone dane wyjściowe w systemie (nagrywanie ekranu lub wysyłanie ekranu przez sieć).
- Surface, canvas i SurfaceHolder . Powierzchnia tworzy kolejkę buforów, która jest często wykorzystywana przez SurfaceFlinger. Podczas renderowania na powierzchnię wynik trafia do bufora wysyłanego do konsumenta. Interfejsy API Canvas zapewniają implementację oprogramowania (z obsługą akceleracji sprzętowej) do rysowania bezpośrednio na powierzchni (niskopoziomowa alternatywa dla OpenGL ES). Wszystko, co ma związek z widokiem, obejmuje SurfaceHolder, którego interfejsy API umożliwiają pobieranie i ustawianie parametrów powierzchni, takich jak rozmiar i format.
- EGLSurface i OpenGL ES . OpenGL ES (GLES) definiuje interfejs API do renderowania grafiki, zaprojektowany do połączenia z EGL , biblioteką, która może tworzyć okna i uzyskiwać do nich dostęp za pośrednictwem systemu operacyjnego (aby rysować wielokąty z teksturą, użyj wywołań GLES; aby umieścić renderowanie na ekranie, użyj wywołań EGL ). Na tej stronie opisano także ANativeWindow, odpowiednik klasy Java Surface w języku C/C++ używany do tworzenia powierzchni okna EGL z kodu natywnego.
- Wulkan . Vulkan to niedrogi, wieloplatformowy interfejs API zapewniający wysoką wydajność grafiki 3D. Podobnie jak OpenGL ES, Vulkan zapewnia narzędzia do tworzenia wysokiej jakości grafiki w czasie rzeczywistym w aplikacjach. Zalety Vulkan obejmują zmniejszenie obciążenia procesora i obsługę języka pośredniego binarnego SPIR-V .
Komponenty na wysokim poziomie
- SurfaceView i GLSurfaceView . SurfaceView łączy powierzchnię i widok. Składniki widoku SurfaceView są komponowane przez SurfaceFlinger (a nie aplikację), umożliwiając renderowanie z oddzielnego wątku/procesu i izolację od renderowania interfejsu użytkownika aplikacji. GLSurfaceView udostępnia klasy pomocnicze do zarządzania kontekstami EGL, komunikacją między wątkami i interakcją z cyklem życia aktywności (ale nie jest to wymagane do korzystania z GLES).
- Tekstura powierzchni . SurfaceTexture łączy teksturę powierzchni i GLES, tworząc BufferQueue, dla którego Twoja aplikacja jest konsumentem. Kiedy producent ustawia w kolejce nowy bufor, powiadamia o tym twoją aplikację, która z kolei zwalnia wcześniej trzymany bufor, pozyskuje nowy bufor z kolejki i wykonuje wywołania EGL, aby udostępnić bufor GLES jako teksturę zewnętrzną. W systemie Android 7.0 dodano obsługę bezpiecznego odtwarzania wideo z teksturami, umożliwiając przetwarzanie końcowe chronionej zawartości wideo przez procesor graficzny.
- Widok tekstury . StructureView łączy widok z SurfaceTexture. StructureView otacza SurfaceTexture i bierze odpowiedzialność za odpowiadanie na wywołania zwrotne i pozyskiwanie nowych buforów. Podczas rysowania, StructureView wykorzystuje zawartość ostatnio otrzymanego bufora jako źródło danych, renderując gdziekolwiek i jakkolwiek wskazuje stan widoku. Kompozycja widoku jest zawsze wykonywana za pomocą GLES, co oznacza, że aktualizacje zawartości mogą powodować przerysowanie również innych elementów widoku.