Surfaceflinger что за процесс android

Русские Блоги

SurfaceFlinger системы Android Gui (1) — Введение в SurfaceFlinger [поворот]

Прочтите содержание

GUI — важная часть любой системы.

Графический интерфейс Android примерно разделен на 4 части.

3) Просмотр механизма

В этом материале много контента, но после его понимания его можно понять по аналогии.На самом деле, текущие основные системы, включая andorid, ios, хорошо знакомы с архитектурой.

Давайте сначала поговорим о SurfaceFlinger

1.OpenGL & OpenGL ES

OPenGL ES — это основа покраски системы android. О OpenGL вы можете узнать на Baidu.

Сначала посмотрите на фреймовую диаграмму между OpenGL и SurfaceFlinger:

2. Аппаратный интерфейс Android HAL

2.1 Абстракция аппаратного интерфейса

2.2 Стабильность интерфейса

Android единообразно определила все аппаратные интерфейсы:

libhardware / include / hardware / Конкретный код может ссылаться на: https://github.com/CyanogenMod/android_hardware_libhardware/tree/cm-12.0/include/hardware

3. Устройство отображения Android: Gralloc и FrameBuffer.

3.1 Загрузка модуля Gralloc

Продолжаем смотреть глубже:

В конечном итоге родительский класс galloc:

Есть только один открытый метод, то есть всем производителям необходимо реализовать метод для открытия устройства.

Посмотрите открытый код fb:

Сначала проверьте правильность названия устройства.

Затем устанавливается связь между оболочкой и ядром.

Это открывает устройство fb.

Вернувшись в FrameBufferNativeWindow, вы увидите:

Информация о драйвере, открытая fb, находится в fbDev, а информация, открываемая gralloc, находится в grDev.

fbDev отвечает за главный экран, а grDev отвечает за выделение и освобождение графического буфера.

Итак, FrameBufferNativeWindow контролирует основу SurfaceFlinger.

4.FrameBufferNativeWindow

4.1FramebufferNativeWindow

Что такое ANativeWindow?

ANativeWindow — это тип отображения OpenGL на платформе Android.

Итак, FramebufferNativeWindow — это тип, который может отображать Open GL.

Конструктор FramebufferNativeWindow был опубликован выше, и дальнейший анализ выглядит следующим образом:

1) Загрузите модуль, который был проанализирован выше.

2) Откройте fb & gralloc, который тоже был проанализирован.

3) Получите количество буферов в соответствии с атрибутами устройства в fb. Этот буфер будет объяснен позже.

4) Инициализируйте каждый буфер и выделите место. Здесь new NativeBuffer только указывает тип буфера или выделяет указатель, но память не выделяется, поэтому необходима операция выделения.

5) Назначьте значения свойствам локального окна.

Текущее значение буфера по умолчанию — 2

3, технология 3 буферов будет представлена ​​позже, и 3 буфера будут использоваться.

Технология двойного буфера:

Чтобы нарисовать группу картинок на экране, нужно время. Если временной интервал большой, картинки рисуются на экране одно за другим, и они будут выглядеть застрявшими.

Если вы сначала поместите изображение в буферный буфер, а затем отобразите буфер непосредственно на экране после того, как все изображения будут нарисованы, это технология двойной буферизации.

4.2dequeuebuffer

Кода немного, но это основная функция, с помощью которой получается рендеринг-буфер.

1) Получите объект FramebufferNativeWindow. Почему бы не использовать это, а использовать метод ANativeWindow, здесь нам все равно.

2) Получите блокировку Autolock, функция завершится, и она автоматически разблокируется.

3) Получите переменную mBufferHead, которая здесь увеличивается, то есть используется следующий буфер.Всего их всего 3 (причина объяснена выше), поэтому значение зацикливается.

4) Если буфер недоступен, дождитесь освобождения очереди буферов. После получения доступный буфер уменьшается.

5.Surface

Поверхность — еще одно локальное окно, которое в основном взаимодействует с приложением. Примечание. Код Java на уровне приложения не может напрямую вызывать поверхность, но концептуально поверхность принадлежит уровню приложения.

Прежде всего, Surface — это подкласс ANativeWindow.

Можно предположить, что поверхность должна решать следующие проблемы:

1) Предоставьте доску для рисования, обращенную к верхнему слою (слой Java). Кто будет выделять эту память

2) Какая связь с SurfaceFlinger

sp & bufferProducer выделяет поверхностную память. Что именно?

SurfaceFlinger — это подкласс BnSurfaceComposer. Это реализация ISurfaceComposer.

Хотя поверхность обслуживает уровень приложения, в основном она управляется SurfaceFlinger.

Для того, как SurfaceFlinger создает поверхность и управляет ею, требуется BufferQueue, о чем пойдет речь в следующей статье.

«Глубокое понимание идей проектирования ядра Android» Линь Сюэсен

Источник

Русские Блоги

В статье рассматривается связь между Surface и SurfaceFlinger, графической системой Android

В статье рассматривается связь между Surface и SurfaceFlinger, графической системой Android

08 марта 2018 13:49:11 Количество просмотров: 623 Теги:SurfaceFlingerSurfaceAndroidГрафическая системаболее

Заявление об авторском праве: эта статья является оригинальной статьей блоггера и не может быть воспроизведена без разрешения блоггера. https://blog.csdn.net/freekiteyu/article/details/79483406

Android-SurfaceFlinger графическая система

очертание

Благодаря предыдущим знаниям, мы знаем, что процесс системы Android от нажатия кнопки включения на рабочем столе и нажатия значка приложения с рабочего стола до отображения активности. Но как активность появляется на экране? Давайте обсудим этот процесс.

Процесс запуска SurfaceFlinger

Процесс запуска SurfaceFlinger:

Процесс SurfaceFlinger создается процессом init и выполняется в отдельном процессе SurfaceFlinger. Процесс init считывает файл init.rc для запуска SurfaceFlinger.

Создание SurfaceFlinger выполнит метод main ():
main_surfaceflinger.cpp

Создание экземпляра SurfaceFlinger будет выполняться для: onFirstRef ()

Обработчик создается и инициализируется в onFirstRef ().
MessageQueue.cpp：

Затем он будет выполнен для SurfaceFlinger :: init ():

Основными функциями этого метода являются:
1. Инициализируйте EGL
2. Создайте HWComposer
3. Инициализация не виртуального дисплея
4. Запустите поток EventThread
5. Запустите загрузочную анимацию

HWComposer представляет аппаратное устройство отображения и регистрирует обратный вызов сигнала VSYNC. Сам сигнал VSYNC генерируется драйвером дисплея.Если аппаратное обеспечение не поддерживает VSYNC, будет создан поток «VSyncThread» для имитации синхронизирующего сигнала VSYNC.

Когда аппаратное обеспечение генерирует сигнал VSYNC, оно отправляет сообщение, и обработчик получает сообщение для обработки. После того как процесс SurfaceFlinger получает сигнал VSync, он вызывается слой за слоем и, наконец, вызывает метод handleMessageRefresh () объекта.

Процесс создания поверхности

Процесс создания поверхности:

Процесс создания Surface — это процесс отображения Activity. Activity.makeVisible () вызывается в ActivityThread.handleResumeActivity (). Посмотрим, как отображается Activity.

После того, как Binder записывает данные обратно в процесс приложения, получается прокси-объект IWindowSession.

После создания объекта ViewRootImpl метод setView () объекта вызывается следующим.
ViewRootImpl：

Создает объект SurfaceSession и добавляет текущий сеанс в переменную-член WMS.mSessions.
Session.java：

Создание SurfaceSession вызывает JNI, а nativeCreate () вызывается в JNI.
android_view_SurfaceSession.cpp：

Создайте объект SurfaceComposerClient как прокси-объект для связи с SurfaceFlinger.

Клиент поддерживает до 31 слоя отображения. Темпы производства / потребления каждого слоя дисплея контролируются соответствующим SharedBufferStack. И он использует несколько переменных-членов для управления позициями чтения и записи.

Клиент в SF выделяет объект SharedClient, который используется всеми процессами. Этот объект имеет 31 элемент SharedBufferStack, и каждый SharedBufferStack соответствует слою отображения.

Слой отображения создаст два буфера, и последующее PageFlipping будет основано на этих двух буферах.

Затем посмотрите на функцию _init в SurfaceComposerClient:

После создания объекта ViewRootImpl метод setView () объекта вызывается следующим. Метод requestLayout () вызывается в setView () Давайте посмотрим на этот метод:

Когда ViewRoot создан, создается Surface, который использует конструктор без параметров, и код выглядит следующим образом:

Поверхность, созданная в этой точке, пуста и не имеет ничего. Затем продолжите анализ relayoutWindow (). В relayoutWindow () вызывается relayout () IWindowSession. Это межпроцессный метод, который вызывает Session.relayout () в WMS и, наконец, вызывает WindowManagerService.relayoutWindow ().

Построить объект Surface:

Внутри createSurface связь Binder используется для отправки запросов в SurfaceFlinger:

Функция createNormalSurfaceLocked имеет три ключевых момента:

• Создает объект Layer.
• Вызовите функцию setBuffers объекта Layer.
• Вызовите функцию SF addLayer_l.

Когда кросс-процесс createSurface () завершает возврат объекта ISurface, объект SurfaceControl создается следующим образом:

Класс SurfaceControl можно рассматривать как класс-оболочку, который инкапсулирует некоторые функции, с помощью которых вы можете легко вызывать функции, предоставляемые mClient или ISurface.

Наконец, он выполняет copyFrom () для возврата клиенту приложения:

В период copyFrom входят три ключевых объекта:

• SurfaceComposerClient
• SurfaceControl
• Surface, этот объект Surface относится к собственному слою и соответствует Surface уровня Java

Тот, что передан в переменную-член ViewRoot mSurface, является последним объектом Surface.

В процессе SurfaceFlinger слой клиента будет использовать элемент массива SharedBufferStack и будет управлять этим элементом через структуру SharedBufferServer. Мы знаем, что SurfaceFlinger является потребителем, поэтому SharedBufferServer может контролировать чтение данных.

Соответственно, у клиентского процесса также будет объект для использования этого SharedBufferStack, но он управляется через другую структуру, называемую SharedBufferClient. Клиент предоставляет данные для SurfaceFlinger, поэтому запись данных может контролироваться с помощью SharedBufferClient.

Процесс отображения поверхности

Как показано на рисунке, ViewRoot создается после создания PhoneWindow в процессе приложения. Создание ViewRoot создает поверхность. Эта поверхность фактически пуста. Она взаимодействует с WindowManagerService с помощью copyFrom () и NativeSurface. При взаимодействии с SurfaceFlinger создается раздел SharedClient разделяемой памяти, в котором хранится SharedBufferStack, соответствующий SurfaceLayer в SurfaceFlinger, каждый слой фактически является FrameBuffer, и в каждом FrameBuffer есть два GraphicBuffer, которые записываются как FrontBuffer и BackBuffer.

SharedBufferServer в SurfaceFlinger для управления FrameBuffer. В то же время, когда CopyFrom () на стороне приложения выходит из NativeSurface, создается SharedBufferClient для связи с SharedClient. Когда клиенту addView () или нужно обновить View, он будет записывать данные в ShareClient через SharedBufferClient, а SharedBufferServer в SurfaceFlinger получает уведомление и передает данные в FrameBuffer на экран.

HWComposer основан на аппаратном обеспечении для генерации сигналов VSync для уведомления SurfaceFlinger о перерисовке частоты кадров дисплея управления.

Приведенное выше понимание относится к моей личной точке зрения, и мои возможности ограничены. Если есть ошибки, пожалуйста, укажите, добро пожаловать на обмен и изучение, и делать успехи вместе.

Источник

Android SurfaceFlinger

Я просто хотел бы спросить, всегда ли SurfaceFlinger вызывается для любого типа рисования на экране? Пример, отображение JPG файла на экран.

3 ответов

SurfaceFlinger составляет не что рисует ваше окно. Он выделяет буфер кадров для вашего окна, к которому фреймворк, запущенный в вашем приложении, обращается непосредственно без взаимодействия с SurfaceFlinger. Единственное взаимодействие SurfaceFlinger участвует, когда вы рисуете окно, чтобы составить окончательный новый буфер кадров на экран, как только вы закончите рисовать кадр.

да, SurfaceFlinger-это композитор Android, поэтому он берет все, что будет отображаться, выясняет, как будет выглядеть результирующий кадр, а затем отправляет его для отображения на экране через интерфейс EGL видеокарты.

вы можете получить представление о том, что он контролирует результат всего, что вы видите в сообщении разработчика Android Джеффа Шарки, где он оттенки весь экран для nightmode. Я также нашел презентацию beamer, которая выглядит хорошо этой теме.

SurfaceFlinger-это системная служба Android, ответственная за compositing все поверхности применения и системы в одиночное буфер, который, наконец, будет отображаться дисплейным контроллером.

давайте увеличим выше заявление.

SurfaceFlinger-это общесистемный сервис, но он не является прямым доступно разработчику приложений как Датчик или другие обслуживания могут быть. Каждый раз, когда вы хотите обновить свой пользовательский интерфейс, SurfaceFlinger ударит в. Это объясняет, почему SurfaceFlinger является дренажом батареи.

кроме ваших поверхностей применения, поверхности системы, включая строку состояния, панель навигации и, когда вращение происходит, поверхности, созданные системой для анимации вращения. Наиболее применения имеют только одну активную поверхность — одно течения активность переднего плана, другие имеют больше, чем один, когда SurfaceView не является используется в иерархии представлений или режиме представления.

SurfaceFlinger отвечает за композицию всех этих поверхностей. Ля распространенное недоразумение заключается в том, что SurfaceFinger предназначен для рисования. Это не правильный. Рисование-это работа OpenGL. Интересно, что SurfaceFlinger также использовал openGL для композитинга.

результат композиции будет помещен в системный буфер или собственный окно, которое является источником для контроллера дисплея чтобы получить данные. Вот что вы видите на экране.

Источник