Wszystko, co deweloper powinien wiedzieć o powierzchniach, SurfaceHolder, EGLSurface, SurfaceView, GLSurfaceView, SurfaceTexture, TextureView, SurfaceFlinger i Vulkan.
Na tej stronie opisujemy najważniejsze elementy architektury grafiki na poziomie systemu Android i sposób, w jaki są one wykorzystywane przez platformę aplikacji i system multimedialny. Skupia się na tym, jak bufory danych graficznych przemieszczają się w systemie. Jeśli zastanawiasz się, dlaczego SurfaceView i TextureView działają w określony sposób lub jak powierzchnie i EGLSurface wchodzą ze sobą w interakcje, to jesteś we właściwym miejscu.
Zakładamy, że masz podstawową wiedzę o urządzeniach z Androidem i tworzeniu aplikacji. Nie musisz mieć szczegółowej wiedzy o strukturze aplikacji, a w materiałach jest niewiele wywołań interfejsu API, ale nie pokrywają się one z inną publiczną dokumentacją. Celem jest przedstawienie szczegółów dotyczących ważnych zdarzeń związanych z renderowaniem klatki na potrzeby wyjścia, aby pomóc Ci w podejmowaniu świadomych decyzji podczas projektowania aplikacji. W tym celu w tym dokumencie opisujemy działanie klas interfejsu, a nie sposób ich używania.
Ta sekcja zawiera kilka stron, na których znajdziesz wszystko, od materiałów wprowadzających po szczegóły HAL i przypadki użycia. Zaczyna się od wyjaśnienia buforów graficznych Androida, opisuje mechanizm kompozycji i wyświetlania, a następnie przechodzi do mechanizmów wyższego poziomu, które dostarczają kompozytorowi dane. Zalecamy czytanie stron w podanej kolejności, a nie pomijanie ich i przechodzenie do tematów, które Cię interesują.
Komponenty niskiego poziomu
- BufferQueue i gralloc. BufferQueue łączy element, który generuje bufory danych graficznych (producent), z elementem, który akceptuje dane do wyświetlenia lub dalszego przetwarzania (konsument). Przydzielanie buforów odbywa się za pomocą alokatora pamięci gralloc, który jest implementowany za pomocą interfejsu HAL specyficznego dla dostawcy.
- SurfaceFlinger, Hardware Composer i wyświetlacze wirtualne. SurfaceFlinger akceptuje bufory danych z wielu źródeł, łączy je i wysyła na wyświetlacz. Interfejs HAL kompozytora sprzętowego (HWC) określa najbardziej wydajny sposób łączenia buforów za pomocą dostępnego sprzętu, a wirtualne wyświetlacze udostępniają złożone dane wyjściowe w systemie (nagrywanie ekranu lub przesyłanie go 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, który jest wysyłany do konsumenta. Interfejsy API Canvas zapewniają implementację oprogramowania (z obsługą akceleracji sprzętowej) do rysowania bezpośrednio na powierzchni (alternatywa niskiego poziomu dla OpenGL ES). Wszystko, co ma związek z widokiem, obejmuje element 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) to interfejs API renderowania grafiki przeznaczony do łączenia z EGL, czyli biblioteką, która może tworzyć okna i uzyskiwać do nich dostęp za pomocą systemu operacyjnego (do rysowania teksturowanych wielokątów używaj wywołań GLES, a do wyświetlania renderowania na ekranie – wywołań EGL). Na tej stronie omówiono też ANativeWindow, czyli odpowiednik klasy Surface w języku C/C++, która służy do tworzenia powierzchni okna EGL z kodu natywnego.
- Vulkan Vulkan to wieloplatformowy interfejs API o niskim narzucie do obsługi wydajnej grafiki 3D. Podobnie jak OpenGL ES, Vulkan udostępnia narzędzia do tworzenia wysokiej jakości grafiki w czasie rzeczywistym w aplikacjach. Zalety interfejsu Vulkan to m.in. zmniejszenie obciążenia procesora i obsługa języka SPIR-V Binary Intermediate.
Komponenty wysokiego poziomu
- SurfaceView i GLSurfaceView. SurfaceView łączy powierzchnię i widok. Komponenty widoku SurfaceView są łączone przez SurfaceFlinger (a nie przez aplikację), co umożliwia renderowanie z osobnego wątku lub procesu i izolację od renderowania interfejsu aplikacji. GLSurfaceView udostępnia klasy pomocnicze do zarządzania kontekstami EGL, komunikacją między wątkami i interakcjami z cyklem życia aktywności (ale nie jest wymagany do korzystania z GLES).
- SurfaceTexture SurfaceTexture łączy powierzchnię i teksturę GLES, aby utworzyć kolejkę buforów, której Twoja aplikacja jest odbiorcą. Gdy producent umieści w kolejce nowy bufor, powiadomi o tym aplikację, która zwolni poprzedni bufor, pobierze z kolejki nowy bufor i wykona wywołania EGL, aby udostępnić bufor GLES jako teksturę zewnętrzną. W Androidzie 7.0 dodano obsługę bezpiecznego odtwarzania wideo z teksturami, co umożliwia przetwarzanie końcowe chronionych treści wideo przez procesor graficzny.
- TextureView TextureView łączy widok z elementem SurfaceTexture. TextureView opakowuje SurfaceTexture i odpowiada za wywoływanie zwrotne oraz pozyskiwanie nowych buforów. Podczas rysowania TextureView używa zawartości ostatnio otrzymanego bufora jako źródła danych, renderując obraz w miejscu i w sposób wskazany przez stan widoku. Kompozycja widoku jest zawsze tworzona za pomocą GLES, co oznacza, że aktualizacje treści mogą powodować ponowne rysowanie innych elementów widoku.