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

Изучаем принципы взаимодействия Ubuntu Touch и Android

Привет, хабр.

Данная статья поможет заинтересованным лицам найти стартовую точку, с которой можно начать близкое знакомство с UT.

Стиль изложения далёк от технического, но если вы не против, то
приглашаю под кат.

Введение

Что такое libhybris

libhybris — прослойка, позволяющая подгружать в Glibc userspace библиотеки из Bionic userspace, на лету заменяя некоторые символы вариантами из Glibc. Проще говоря, данное решение позволяет использовать проприетарные библиотеки для Android в Linux-пространстве. Наибóльшая польза, конечно же, в возможности использовать проприетарные GPU-драйвера, собранные производителем только под Android.

Что такое surfaceflinger

surfaceflinger — нативный сервис андроида, композитный менеджер графических слоёв.

Ubuntu Touch

Ubuntu Touch Developer Preview сама по себе основана на Android, заимствует необходимые сервисы для работы с железом. Общий обзор зависимости можно почитать здесь — Ubuntu Touch Porting или в заметке на OpenNet.

Компоненты Ubuntu Touch

Ubuntu Platform API

Ubuntu platform API — низкоуровневый API для выполнения базовых операций с использованием возможностей платформы (Android).

Из файла debian/control узнаём, что:

Ага, значит, судя по android/hybris/Android.mk, реализация platform API собирается в виде библотеки libubuntu_application_api с линковкой с нативными либами андроида и помещается в android userspace:

Есть один-единственный файл с кодом — ubuntu_application_api.cpp, заглянув в которой мы увидим:
— использование процедур libhybris для динамической загрузки символов из shared-либы из android userspace.

Ubuntu Application Manager

В platform-api/android/hybris помимо реализации Ubuntu platform API находятся исходники ubuntuappmanager — сервиса приложений Ubuntu, он живёт в android userspace и, судя по Android.mk, активно использует libubuntu_application_api и общается через Binder IPC с сервисами андроида.

Решает кучу задач управления приложениями и сессиями, быстрый взгляд на default_application_manager.h:

QtUbuntu

Разбираемся с частью UT, отвечающей за взаимодействие между Ubuntu platform API и Qt/QML приложениями.

Если вы не знакомы с Qt Platform Abstraction, то, в кратце, это возможность абстрагироваться от платформы, на которой запускаются приложения Qt с помощью специально написанных QPA-плагинов.

В данном случае мы будем иметь дело с QPA плагином для работы с Ubuntu application API.

Судя по содержимому ubuntu.pro, платформа линкуется с glibc-версией libubuntu_application_api.so
Обратим внимание на следующие вызовы методов из набора platform API, использованные в integration.cc и window.cc:

Теперь понятно, что когда наше Qt приложение захочет создать окошко, то оно вызовет метод из QPA платформы qubuntu — QUbuntuIntegration::createPlatformWindow из файла integration.cc:

Заглядывая в конструктор QUbuntuWindow в файле window.cc, находим вызов метода QUbuntuWindow::createWindow() :

Перематываем, находим UbuntuSurface :

Возвращаясь назад по цепочке, понимаем, что же на самом деле происходит, когда мы запускаем очередное Qt приложение с QPA платформой Ubuntu.

Заключение

Через неделю приедет телефон на Firefox OS, распотрошу его…

Источник

Android SurfaceFlinger

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

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

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

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

Давайте увеличим выражение выше.

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

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

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» Линь Сюэсен

Источник

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

Прежде чем задавать вопросы прочитайте полностью «шапку» темы, в противном случае ваши посты могут быть оценены как оффтоп и удалены. Если после прочтения шапки у вас остались вопросы, воспользуйтесь формой написания поста в конце статьи. И не забывайте пользоваться поиском по теме, т.к. 80% вновь задаваемых вопросов уже обсуждались.

В начале рассмотрим основную и не всегда очевидную причину быстрого разряда аппарата, нарушение его «сна». Дело в том, что после отключения экрана ваш аппарат старается перейти в режим максимального энергосбережения (в так называемый «глубокий сон») в котором уменьшается частота процессора, отключаются «лишние» его ядра, максимально снижается активность приложений и т.п. (энергопотребление в таком режиме может составить всего 1-2% заряда за 8-12 часов). Однако, некоторые приложения/процессы могут выводить устройство из такого сна, пробуждая его своими запросами (так называемыми wakelock’ами), при этом они могут начать загружать процессор, использовать беспроводные сети и геолокацию по своему усмотрению, бесцеременно расходуя энергию при выключенном экране. Поэтому, для начала проверим, есть ли у вашего аппарата проблемы с режимом «сна».

Чтобы понять есть ли у аппарата проблемы с его режимом сна, после дня умеренного использования аппарата в звонилке набираем код *#*#4636#*#* (или пользуемся программой SpareParts), и смотрим пункт «Battery history» («Журнал аккумулятора» или «Журнал сведений о батарее»). Тут сводится вся информация о потреблении устройством энергии.

Активность аппарата (показатель «Running») складывается из двух составляющих, «видимой» и «невидимой».
— «Видимая» составляющая формируется из всех действий которые происходят когда экран устройства включён, соответственно она ровна показателю «Screen on».
— «Невидимая» составляющая в свою очередь формируется когда экран устройства выключен. В идеале «невидимой» активности вообще не должно быть, если же она есть, значит аппарат что-то будит когда он «спит»и на это тратится энергия заряда.

Таким образом, определить есть ли проблемы с энергопотреблением устройства в режиме «сна» можно следующем образом:
Из показателя «Running» вычитаем показатель «Screen on» и получаем ту самою «Невидимую» составляющую. Если она получается больше 10% (в идеале она должна составлять до 5%), и находится в таком состоянии несколько дней значит надо искать будящую программу способами описанными в пункте 9.

Следует учесть, что прослушивание музыки при выключенном экране, активные мэссенджеры и другие приложения работающий в фоне также увеличивает значение «невидимой» составляющей, поэтому не надо этому удивляться, это нормально. Если же вы знаете, что не используете приложения в фоновом режиме, а «невидимая» составляющая в режиме сна растёт, это верный признак того, что аппарат что-то постоянно «будит» и он не может нормально находится в режиме энергосбережения.

Если тапнуть на верхнюю часть, то мы попадём в пункт с графиками разряда. Большой график показывает динамику снижения уровня заряда аккумулятора (по оси Y- уровень заряда, по оси Х-время).

Вся активность аппарата складывается из двух составляющих, «видимой» и «невидимой».
«Видимая» составляющая формируется из всех действий которые происходят когда экран устройства включён, т.е. когда полоска «Экран включён», а над ней и полоска «Рабочий режим», залиты синим;
«Невидимая» составляющая формируется когда экран устройства выключен, т.е. когда полоска «Рабочий режим» залита синим, а полоска «Экран включён» под ней нет. В идеале «невидимой» активности вообще не должно быть, если же она есть, значит аппарат что-то будит когда он «спит»и на это тратится энергия заряда.

На скриншоте приведённым выше как раз хорошо видна «невидимая» активность. За ночь наблюдений (идеальный период наблюдения, так как графики строятся довольно медленно), часть времени аппарат не спал. Если такая «невидимая» активность появляется слишком часто, продолжительна по времени (составляет более 10% от всей полоски «Рабочий режим») и приводит к значительной потери заряда, значит надо искать будящую программу способами описанными в пункте 9.

Уровень приёма сотовой связи оказывает значительное влияние на сохранение заряда. Чем слабее уровень принимаемого сигнала (меньше делений индикатора антенны на экране) тем больше аппарат тратит энергии на его усиление. Поэтому, в зонах неуверенного приёма сети (к примеру в поездке) лучше отключать радиомодуль аппарата, переводя его в режим «в самолете».

Современные мобильные устройства буквально напичканы всевозможными датчиками, которые естественно, требуют энергии для своей работы. Посмотреть, какие датчики есть в вашем аппарате и сколько они потребляют очень просто, достаточно установить приложение Android System Info, зайти во вкладку System и выбрать пункт Sensor. В первых Android-устройствах обычный акселерометр (датчик, определяющих положение устройства) потреблял до 15 мАч, в современных аппаратах это значение как правило в 100 раз меньше, порядка 0.1-0.15 мАч. Если у вас примерно такие же цифры, то нет особого смысла отключать «автоматическую ориентацию экрана» или «автоматическую яркость» (датчик освещённости), каким-либо значительным образом это не отразится на общем энергопотребление аппарата.
Однако, следует помнить, что многие приложения (прежде всего игры), в которых задействовано управление наклонами аппарата, могут использовать сразу несколько датчиков (акселерометр, гироскоп, датчик вращения, датчик ускорения, датчик ориентации, датчик гравитации и т.д.), что в сумме может дать потребление до 50 мАч.

Уменьшение напряжения процессора (андервольтинг).

Экран является одним из основных потребителей энергии в мобильном устройстве, при этом его потребление зависит от следующих основных параметров: размера и разрешения, типа, выставленного уровня яркости, таймаута подсветки (времени горения подсветки после прекращения активности).

Источник

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

В статье рассматривается связь между 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 о перерисовке частоты кадров дисплея управления.

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

Источник

• ← Как выглядит яйцеклетка под микроскопом
• Uvo kia что это →