Android SurfaceFlinger
Я просто хотел бы спросить, всегда ли SurfaceFlinger вызывается для любого типа рисования на экране? Пример, отображение JPG файла на экран.
3 ответов
SurfaceFlinger составляет не что рисует ваше окно. Он выделяет буфер кадров для вашего окна, к которому фреймворк, запущенный в вашем приложении, обращается непосредственно без взаимодействия с SurfaceFlinger. Единственное взаимодействие SurfaceFlinger участвует, когда вы рисуете окно, чтобы составить окончательный новый буфер кадров на экран, как только вы закончите рисовать кадр.
да, SurfaceFlinger-это композитор Android, поэтому он берет все, что будет отображаться, выясняет, как будет выглядеть результирующий кадр, а затем отправляет его для отображения на экране через интерфейс EGL видеокарты.
вы можете получить представление о том, что он контролирует результат всего, что вы видите в сообщении разработчика Android Джеффа Шарки, где он оттенки весь экран для nightmode. Я также нашел презентацию beamer, которая выглядит хорошо этой теме.
SurfaceFlinger-это системная служба Android, ответственная за compositing все поверхности применения и системы в одиночное буфер, который, наконец, будет отображаться дисплейным контроллером.
давайте увеличим выше заявление.
SurfaceFlinger-это общесистемный сервис, но он не является прямым доступно разработчику приложений как Датчик или другие обслуживания могут быть. Каждый раз, когда вы хотите обновить свой пользовательский интерфейс, SurfaceFlinger ударит в. Это объясняет, почему SurfaceFlinger является дренажом батареи.
SurfaceFlinger отвечает за композицию всех этих поверхностей. Ля распространенное недоразумение заключается в том, что SurfaceFinger предназначен для рисования. Это не правильный. Рисование-это работа OpenGL. Интересно, что SurfaceFlinger также использовал openGL для композитинга.
результат композиции будет помещен в системный буфер или собственный окно, которое является источником для контроллера дисплея чтобы получить данные. Вот что вы видите на экране.
Русские Блоги
Прочтите содержание
Графический интерфейс Android примерно разделен на 4 части.
3) Просмотр механизма
В этом материале много контента, но после его понимания его можно понять по аналогии.На самом деле, текущие основные системы, включая andorid, ios, хорошо знакомы с архитектурой.
Давайте сначала поговорим о SurfaceFlinger
1.OpenGL & OpenGL ES
Сначала посмотрите на фреймовую диаграмму между 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?
Конструктор FramebufferNativeWindow был опубликован выше, и дальнейший анализ выглядит следующим образом:
1) Загрузите модуль, который был проанализирован выше.
2) Откройте fb & gralloc, который тоже был проанализирован.
3) Получите количество буферов в соответствии с атрибутами устройства в fb. Этот буфер будет объяснен позже.
4) Инициализируйте каждый буфер и выделите место. Здесь new NativeBuffer только указывает тип буфера или выделяет указатель, но память не выделяется, поэтому необходима операция выделения.
5) Назначьте значения свойствам локального окна.
3, технология 3 буферов будет представлена позже, и 3 буфера будут использоваться.
Технология двойного буфера:
Чтобы нарисовать группу картинок на экране, нужно время. Если временной интервал большой, картинки рисуются на экране одно за другим, и они будут выглядеть застрявшими.
Если вы сначала поместите изображение в буферный буфер, а затем отобразите буфер непосредственно на экране после того, как все изображения будут нарисованы, это технология двойной буферизации.
4.2dequeuebuffer
Кода немного, но это основная функция, с помощью которой получается рендеринг-буфер.
1) Получите объект FramebufferNativeWindow. Почему бы не использовать это, а использовать метод ANativeWindow, здесь нам все равно.
2) Получите блокировку Autolock, функция завершится, и она автоматически разблокируется.
3) Получите переменную mBufferHead, которая здесь увеличивается, то есть используется следующий буфер.Всего их всего 3 (причина объяснена выше), поэтому значение зацикливается.
4) Если буфер недоступен, дождитесь освобождения очереди буферов. После получения доступный буфер уменьшается.
5.Surface
Можно предположить, что поверхность должна решать следующие проблемы:
1) Предоставьте доску для рисования, обращенную к верхнему слою (слой Java). Кто будет выделять эту память
2) Какая связь с SurfaceFlinger
sp & bufferProducer выделяет поверхностную память. Что именно?
Хотя поверхность обслуживает уровень приложения, в основном она управляется 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 () объекта.
Процесс создания поверхности
Процесс создания поверхности:
После того, как 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 имеет три ключевых момента:
Когда кросс-процесс createSurface () завершает возврат объекта ISurface, объект SurfaceControl создается следующим образом:
Класс SurfaceControl можно рассматривать как класс-оболочку, который инкапсулирует некоторые функции, с помощью которых вы можете легко вызывать функции, предоставляемые mClient или ISurface.
Наконец, он выполняет copyFrom () для возврата клиенту приложения:
В период copyFrom входят три ключевых объекта:
Тот, что передан в переменную-член 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 о перерисовке частоты кадров дисплея управления.
Приведенное выше понимание относится к моей личной точке зрения, и мои возможности ограничены. Если есть ошибки, пожалуйста, укажите, добро пожаловать на обмен и изучение, и делать успехи вместе.
Русские Блоги
7.SurfaceFlinger
SurfaceFlinger находится в предыдущем пространстве, и он задействован.
SurfaceFlinger является ядром обновления пользовательского интерфейса GUI, поэтому любые улучшения SurfaceFlinger окажут значительное влияние на систему пользовательского интерфейса Android.
SurfaceFlinger в основном разделен на 4 части.
3) Связь между SurfaceFlinger и BufferQueue
4) Обработка сигнала Vsync
Это должно придать системе Android слой «масла» на картинке. Давайте посмотрим, как andorid наносил этот слой масла на SurfaceFlinger.
Масло состоит из 2 компонентов: Vsync и Triple buffer.
Вышеупомянутая технология двойного буфера, а также упоминалось, что FrameBufferNativeWindow может быть 2 или 3 при подаче заявки на буфер.
Это 3 технология Triple Buffer, о которой мы скоро расскажем.
Сначала мы рассмотрим технологию двойной буферизации.
Как упоминалось ранее, двойная буферизация предназначена для размещения буфера в битовой карте.После того, как все элементы готовы, битовая карта мигает на экране.
Это решит проблему запаздывания.
Я уже говорил о технологии двойной буферизации раньше, поэтому кратко рассмотрю ее здесь.
Буфер кадра представляет собой кадр изображения.
На данный момент буфер готов для данных, и монитор отображает только 2/3 изображения.
На мониторе показан первый кадр изображения, а буфер заполнен на 1/3 второго кадра.
Буфер подготовил второй кадр, и с дисплеем возникла проблема: 1/3 содержимого принадлежит второму кадру, а 2/3 содержимого принадлежит первому кадру.
Вот почему Android представил технологию двойной буферизации.
Что делать, если время подготовки буфера меньше, чем скорость обновления изображения на экране?
Каждый раз, когда экран дисплея обновляется, это сканирование экрана дисплея, но есть интервал (физическое оборудование, этот интервал должен быть).
Типичная частота обновления экрана монитора ПК составляет 60 Гц, потому что 60 кадров в секунду, с человеческой точки зрения, кажутся очень плавными.
Таким образом, интервал составляет 1/60 секунды, что составляет 16 мсек. Если время подготовки
Интеллектуальная рекомендация
зеркало Zynq
1. Профиль кнопки кнопки 1. 2. Результаты видов и виджет 3. Контейнер для контейнера Добавьте страницу: сначала выберите текущую страницу, затем выберите Щелкните правой кнопкой мыши StackedWidget, чт.
Самые ценные цветы в горшках известны как «Цветы долголетия», красочные и легко выращиваемые, цветущие в течение многих лет.
Цветок долголетия Рождественская гирлянда, капуста, всемирно известный цветок, после того, как она была завезена в Китай, получила название «цветок долголетия» Цветок долголетия Цветки огр.
Руководство по установке MySQL5.7.21 под Linux
Руководство по установке MySQL5.7.21 под Linux В этой статье в основном рассказывается, как установить MySQL 5.7.21 под Linux. Требуемая среда: CentOS 6.9 mysql-5.7.21-linux-glibc2.12-x86_64.tar.gz Уд.
Найдите простые числа в пределах 1 миллиона с помощью Python
Русские Блоги
SurfaceFlinger и хореограф в Android
SurfaceFlinger и Choreographer являются основными частями графической системы Android. Они оба являются подписчиками сигнала VSYNC; SurfaceFlinger интегрирует различные источники данных, которые он получает, и, наконец, обновляет буфер кадра для отображения; а Choreographer, наконец, отправляет сообщение в ViewRootImpl для измерения интерфейса. и рисовать и т. д.
SurfaceFlinger
SurfaceFlinger’s role is to accept buffers of data from multiple sources, composite them, and send them to the display. Once upon a time this was done with software blitting to a hardware framebuffer (e.g. /dev/graphics/fb0), but those days are long gone.
Официальная документация GoogleЗдесь четко указаны обязанности SurfaceFlinger и способы их выполнения.
запускать
Когда Android запускает процесс SystemServer, он вызывает функцию system_init в frameworks \ base \ cmds \ system_server \ library \ system_init.cpp
И если атрибут system_init.startsurfaceflinger равен 0, служба SurfaceFlinger будет настроена в init.rc, и первый процесс инициализации Linux запустит SurfaceFlinger как независимый процесс.
Генерация и распространение VSYNC
Независимо от того, как вы запускаете SurfaceFlinger, метод init будет вызываться после создания экземпляра SurfaceFlinger:
Метод init сначала инициализирует устройство отображения по умолчанию, а затем создает два экземпляра EventThread и HWComposer.
После Android4.4 центром распределения сигнала VSYNC стал SurfaceFlinger. После получения сигнала VSYNC, сгенерированного аппаратным или программным моделированием HWComposer, он вызывает собственный метод onVSyncReceived для инициализации EventControlThread и других задач. EventControlThread в основном используется SurfaceFlinger для управления сигналом VSYNC, генерируемым оборудованием.
Затем инициализируйте отображаемую информацию.В setPowerMode или setPeriod будет установлен период обновления Period для mPrimaryDispSync. После инициализацииDisplays модуль отображения готов, и вызывается startBootAnim для запуска анимации загрузки.
VSYNC прием
В SurfaceFlinger метод onFirstRef вызывается при первом создании экземпляра:
Прием VSYNC SurfaceFlinger достигается через MessageQueue, а его метод инициализации выглядит следующим образом:
Как мы упоминали выше, в методе инициализации SurfaceFlinger mSFEventThread соответствует обработке VSYNC самого SurfaceFlinger, поскольку вызывается метод mEventQueue.setEventThread (mSFEventThread).
BitTube создает два дескриптора Socket через SocketPair и метод getFd:
Возвращается mReceiveFd, MessageQueue добавляет дескриптор в Looper с помощью метода addFD Looper. Когда указанное выше время VSYNC распределяется, когда данные записываются в mSendFd с помощью метода отправки, он запускает механизм epoll в Looper, таким образом вызывая обратный вызов MessageQueue :: cb_eventReceiver метод. Если вы не знаете о Looper, см. ЗдесьLooper и epoll в Android。
Наконец, с помощью метода handleMessageRefresh SurfaceFlinger последний слой, заполненный приложением, вычисляется и синтезируется в фреймбуфер для отображения графической картой.
Choreographer
Как хореограф, Хореограф находится непосредственно в ViewRootImpl и контролирует ритм рисования пользовательского интерфейса приложения.
В конструкторе Choreographer он определит, следует ли включить механизм Vsync, оценив значение debug.choreographer.vsync в файле системных свойств. Если он включен, он создаст тип FrameDisplayEventReceiver и вызовет конструктор его родительского класса DisplayEventReceiver.java. :
Затем вызовите метод nativeInit в android_view_DisplayEventReceiver.cpp через jni nativeInit, вызовите его родительский DisplayEventDispatcher, создав NativeDisplayEventReceiver, и получите Looper основного потока приложения через MessageQueue, переданный в nativeInit, и передайте его DisplayEventDispatcher, а затем вызовите инициализацию метода DisplayEventDispatcher:
Можно видеть, что он также отслеживает поступление сигнала VSYNC через addFd. А mReceiver соответствует DisplayEventReceiver, который можно понимать как локальный агент удаленных объектов между процессами.
DisplayEventReceiver сначала создает локальный агент SurfaceFlinger через ComposerService, а затем получает соединение, удерживаемое EventThread, через createDisplayEventConnection.Метод подписки BitTube, поддерживаемый этим соединением, такой же, как SurfaceFlinger выше.
Метод createDisplayEventConnection находится в SurfaceFlinger:
Как видите, это действительно соединение, установленное через mEventThread, а не через mSFEventThread. Таким образом, хореограф успешно подписался на сигнал VSYNC.
Когда приходит сигнал Vsync, поскольку DisplayEventDispatcher наследует LooperCallback, он вызывает свой метод handleEvent, а затем вызывает метод dispatchVsync для NativeDisplayEventReceiver:
Сторона jni вызовет метод dispatchVsync DisplayEventReceiver на стороне java через метод CallVoidMethod, затем вызовет метод onVsync FrameDisplayEventReceiver и, наконец, начнет работу по рисованию пользовательского интерфейса на стороне приложения, вызвав метод doFrame из Choreographer.
подводить итоги
Application and SurfaceFlinger render loops should be synchronized to the hardware VSYNC. On a VSYNC event, the display begins showing frame N while SurfaceFlinger begins compositing windows for frame N+1. The app handles pending input and generates frame N+2.
Synchronizing with VSYNC delivers consistent latency. It reduces errors in apps and SurfaceFlinger and the drifting of displays in and out of phase with each other. This, however, does assume application and SurfaceFlinger per-frame times don’t vary widely. Nevertheless, the latency is at least two frames.
To remedy this, you may employ VSYNC offsets to reduce the input-to-display latency by making application and composition signal relative to hardware VSYNC. This is possible because application plus composition usually takes less than 33 ms.