Платформа Android предлагает множество API-интерфейсов рендеринга графики для 2D и 3D, которые взаимодействуют с реализацией графических драйверов производителем, поэтому важно хорошо понимать, как эти API работают на более высоком уровне. На этой странице представлен уровень абстракции графического оборудования (HAL), на котором построены эти драйверы.
Разработчики приложений выводят изображения на экран тремя способами: с помощью Canvas , OpenGL ES или Vulkan .
Графические компоненты Android
Независимо от того, какой API рендеринга используют разработчики, все рендерится на поверхность . Поверхность представляет собой сторону производителя буферной очереди, которая часто используется SurfaceFlinger. Каждое окно, созданное на платформе Android, поддерживается поверхностью. Все визуализированные видимые поверхности комбинируются на дисплее с помощью SurfaceFlinger.
На следующей диаграмме показано, как ключевые компоненты работают вместе:
Рисунок 1. Как визуализируются поверхности
Основные компоненты описаны ниже:
Продюсеры потока изображений
Производитель потока изображений может быть кем угодно, что создает графические буферы для потребления. Примеры включают OpenGL ES, Canvas 2D и видеодекодеры медиасервера.
Потребители потока изображений
Наиболее распространенным потребителем потоков изображений является SurfaceFlinger, системная служба, которая использует видимые в данный момент поверхности и компонует их на дисплее, используя информацию, предоставленную диспетчером окон. SurfaceFlinger — единственная служба, которая может изменять содержимое дисплея. SurfaceFlinger использует OpenGL и Hardware Composer для создания группы поверхностей.
Другие приложения OpenGL ES также могут потреблять потоки изображений, например приложение камеры, использующее поток изображения предварительного просмотра камеры. Приложения, отличные от GL, также могут быть потребителями, например, класс ImageReader.
Аппаратный композитор
Аппаратная абстракция для подсистемы отображения. SurfaceFlinger может делегировать определенную работу по композиции аппаратному компоновщику, чтобы разгрузить работу OpenGL и графического процессора. SurfaceFlinger действует как еще один клиент OpenGL ES. Поэтому, когда SurfaceFlinger активно компонует один или два буфера, например, в третий, он использует OpenGL ES. Это снижает энергопотребление композитинга по сравнению с выполнением всех вычислений графическим процессором.
Аппаратный компоновщик HAL выполняет вторую половину работы и является центральной точкой для рендеринга всей графики Android. Hardware Composer должен поддерживать события, одно из которых — VSYNC (другое — горячее подключение для поддержки plug-and-playHDMI).
Граллок
Распределитель графической памяти (Gralloc) необходим для выделения памяти, запрашиваемой производителями изображений. Подробнее см. в Gralloc HAL .
Поток данных
На следующей диаграмме показан графический конвейер Android:
Рисунок 2. Поток графических данных через Android
Объекты слева — это визуализаторы, создающие графические буферы, такие как домашний экран, строка состояния и системный пользовательский интерфейс. SurfaceFlinger — это компоновщик, а Hardware Composer — композитор.
BufferQueue
BufferQueues обеспечивают связь между графическими компонентами Android. Это пара очередей, которые обеспечивают постоянный цикл буферов от производителя к потребителю. Как только производители передают свои буферы, SurfaceFlinger отвечает за композицию всего на дисплее.
На следующей диаграмме показан процесс связи BufferQueue.
Рисунок 3. Процесс связи BufferQueue
BufferQueue содержит логику, которая связывает производителей потоков изображений и потребителей потоков изображений вместе. Некоторыми примерами производителей изображений являются предварительные просмотры камеры, созданные играми HAL или OpenGL ES для камеры. Некоторыми примерами потребителей изображений являются SurfaceFlinger или другое приложение, которое отображает поток OpenGL ES, например приложение камеры, отображающее видоискатель камеры.
BufferQueue — это структура данных, которая объединяет буферный пул с очередью и использует Binder IPC для передачи буферов между процессами. Интерфейс производителя или то, что вы передаете тому, кто хочет генерировать графические буферы, называется IGraphicBufferProducer (часть SurfaceTexture ). BufferQueue часто используется для рендеринга на поверхность и использования с помощью GL Consumer, помимо других задач.
BufferQueue может работать в трех разных режимах:
Синхронно-подобный режим — BufferQueue по умолчанию работает в синхронно-подобном режиме, в котором каждый буфер, поступающий от производителя, отправляется потребителю. В этом режиме буфер никогда не сбрасывается. И если производитель слишком быстр и создает буферы быстрее, чем они сливаются, он будет блокироваться и ждать свободных буферов.
Неблокирующий режим — BufferQueue также может работать в неблокирующем режиме, когда в этих случаях он генерирует ошибку, а не ожидает буфера. В этом режиме буфер никогда не сбрасывается. Это полезно для предотвращения потенциальных взаимоблокировок в прикладном программном обеспечении, которое может не понимать сложные зависимости графической инфраструктуры.
Режим сброса. Наконец, BufferQueue можно настроить на отбрасывание старых буферов, а не на генерацию ошибок или ожидание. Например, при выполнении рендеринга GL в виде текстуры и рисовании как можно быстрее буферы должны быть удалены.
Для выполнения большей части этой работы SurfaceFlinger действует как еще один клиент OpenGL ES. Поэтому, когда SurfaceFlinger активно компонует один или два буфера, например, в третий, он использует OpenGL ES.
Hardware Composer HAL выполняет другую половину работы. Этот HAL действует как центральная точка для всего графического рендеринга Android.