Платформа Android предлагает различные API-интерфейсы рендеринга графики для 2D и 3D, которые взаимодействуют с реализациями графических драйверов производителя, поэтому важно хорошо понимать, как эти API работают на более высоком уровне. На этой странице представлен уровень абстракции графического оборудования (HAL), на котором построены эти драйверы. Прежде чем продолжить изучение этого раздела, ознакомьтесь со следующими терминами:
Canvas
(элемент API)Surface
. Canvas
имеет методы для стандартного компьютерного рисования растровых изображений, линий, кругов, прямоугольников, текста и т. д. и привязан к растровому изображению или поверхности. Холст — это самый простой и легкий способ рисовать 2D-объекты на экране. Базовый класс — Canvas
.android.graphics.drawable
. Дополнительные сведения о чертежах и других ресурсах см. в разделе Ресурсы .android.opengl
и javax.microedition.khronos.opengles
предоставляют функциональные возможности OpenGL ES.Surface
(элемент API)Surface
. Используйте класс SurfaceView
вместо класса Surface
напрямую.SurfaceView
(элемент API)View
, который обертывает объект Surface
для рисования и предоставляет методы для динамического указания его размера и формата. Поверхностное представление предоставляет возможность рисовать независимо от потока пользовательского интерфейса для ресурсоемких операций, таких как игры или предварительный просмотр камеры, но в результате используется дополнительная память. Вид поверхности поддерживает как холст, так и графику OpenGL ES. Базовым классом объекта SurfaceView
является SurfaceView
.R.style
и начинающихся с Theme_
.View
(элемент API)View
является базовым классом для большинства компонентов макета действия или диалогового экрана, таких как текстовые поля и окна. Объект View
получает вызовы от своего родительского объекта (см. ViewGroup
) для рисования самого себя и сообщает родительскому объекту о предпочтительном размере и расположении, которые могут не учитываться родителем. Для получения дополнительной информации см. View
.ViewGroup
(элемент API)widget
, но являются расширением класса ViewGroup
.android.widget
.Window
(элемент API)Window
, который определяет элементы общего окна, такие как внешний вид, текст строки заголовка, а также расположение и содержимое меню. Диалоги и действия используют реализацию класса Window
для визуализации объекта Window
. Вам не нужно реализовывать класс Window
или использовать окна в своем приложении.Разработчики приложений рисуют изображения на экране тремя способами: с помощью Canvas , OpenGL ES или Vulkan .
Графические компоненты Android
Независимо от того, какой API-интерфейс рендеринга используют разработчики, все отображается на поверхности. Поверхность представляет собой сторону производителя буферной очереди, которая часто используется SurfaceFlinger. Каждое окно, созданное на платформе Android, имеет поверхность. Все отображаемые видимые поверхности компонуются на дисплей с помощью SurfaceFlinger.
На следующей диаграмме показано, как ключевые компоненты работают вместе:
Основные компоненты описаны ниже:
Производители потока изображений
Производителем потока изображений может быть что угодно, создающее графические буферы для потребления. Примеры включают в себя OpenGL ES, Canvas 2D и видеодекодеры медиасерверов.
Потребители потока изображений
Наиболее распространенным потребителем потоков изображений является SurfaceFlinger, системная служба, которая использует видимые в данный момент поверхности и компонует их на дисплее, используя информацию, предоставленную диспетчером окон. SurfaceFlinger — единственная служба, которая может изменять содержимое дисплея. SurfaceFlinger использует OpenGL и Hardware Composer для составления группы поверхностей.
Другие приложения OpenGL ES также могут использовать потоки изображений, например приложение камеры, использующее поток изображений предварительного просмотра камеры. Приложения, не относящиеся к GL, также могут быть потребителями, например класс ImageReader.
Аппаратный композитор
Аппаратная абстракция для подсистемы дисплея. SurfaceFlinger может делегировать определенную работу по композиции Hardware Composer, чтобы разгрузить работу OpenGL и графического процессора. SurfaceFlinger действует как еще один клиент OpenGL ES. Поэтому, когда SurfaceFlinger активно объединяет один или два буфера, например, в третий, он использует OpenGL ES. Это делает композицию менее энергозатратной, чем выполнение всех вычислений графическим процессором.
Hardware Composer HAL выполняет вторую половину работы и является центральной точкой для всего рендеринга графики Android. Hardware Composer должен поддерживать события, одно из которых — VSYNC (другое — горячее подключение для поддержки Plug-and-PlayHDMI).
Граллок
Распределитель графической памяти (Gralloc) необходим для выделения памяти, запрошенной производителями изображений. Подробности см. в Gralloc HAL .
Поток данных
На следующей диаграмме изображен графический конвейер Android:
Объекты слева — это средства рендеринга, создающие графические буферы, такие как главный экран, строка состояния и системный пользовательский интерфейс. SurfaceFlinger — это композитор, а Hardware Composer — композитор.
БуферОчередь
BufferQueues обеспечивает связующее звено между графическими компонентами Android. Это пара очередей, которые обеспечивают постоянный цикл буферов от производителя к потребителю. Как только производители передают свои буферы, SurfaceFlinger отвечает за компоновку всего на дисплее.
На следующей диаграмме показан процесс связи BufferQueue.
BufferQueue содержит логику, которая связывает вместе производителей потока изображений и потребителей потока изображений. Некоторыми примерами производителей изображений являются предварительные просмотры камеры, созданные играми HAL или OpenGL ES. Некоторыми примерами потребителей изображений являются SurfaceFlinger или другое приложение, отображающее поток OpenGL ES, например приложение камеры, отображающее видоискатель камеры.
BufferQueue — это структура данных, которая объединяет пул буферов с очередью и использует Binder IPC для передачи буферов между процессами. Интерфейс производителя или то, что вы передаете кому-то, кто хочет генерировать графические буферы, — это IGraphicBufferProducer (часть SurfaceTexture ). BufferQueue часто используется для рендеринга на Surface и использования с помощью GL Consumer, помимо других задач.
BufferQueue может работать в трех разных режимах:
Синхронный режим . BufferQueue по умолчанию работает в синхронном режиме, в котором каждый буфер, поступающий от производителя, отправляется потребителю. В этом режиме ни один буфер никогда не отбрасывается. А если производитель слишком быстр и создает буферы быстрее, чем они опустошаются, он заблокируется и будет ждать свободных буферов.
Неблокирующий режим . BufferQueue также может работать в неблокирующем режиме, в котором в таких случаях генерируется ошибка, а не ожидание буфера. В этом режиме буфер никогда не отбрасывается. Это полезно для предотвращения потенциальных взаимоблокировок в прикладном программном обеспечении, которое может не понимать сложные зависимости графической платформы.
Режим сброса . Наконец, BufferQueue можно настроить на удаление старых буферов, а не на генерирование ошибок или ожидание. Например, если GL-рендеринг выполняется в виде текстуры и рисуется как можно быстрее, буферы необходимо удалить.
Для выполнения большей части этой работы SurfaceFlinger действует как еще один клиент OpenGL ES. Поэтому, когда SurfaceFlinger активно объединяет один или два буфера, например, в третий, он использует OpenGL ES.
Hardware Composer HAL выполняет вторую половину работы. Этот HAL действует как центральная точка для всего рендеринга графики Android.