Bindings
Запуск каждого Flutter-приложения начинается с вызова функции runApp
. Давайте посмотрим на её реализацию.
void runApp(Widget app) {
final WidgetsBinding binding = WidgetsFlutterBinding.ensureInitialized();
assert(binding.debugCheckZone('runApp'));
binding
..scheduleAttachRootWidget(binding.wrapWithDefaultView(app))
..scheduleWarmUpFrame();
}
В функции происходят три важных действия:
- Получается и инициализируется, если необходимо, объект
binding
с типомWidgetsBinding
. - Вызывается метод
scheduleAttachRootWidget
, в который передаётся переданный в функцию виджет. - Откладывается операция отрисовки первого кадра —
scheduleWarmUpFrame
.
Давайте сфокусируемся на первом действии и разберёмся, какую роль оно играет в запуске нашего приложения.
Bindings (сервисы связи) — это некоторые связующие классы, выполняющие роль «клея» между движком и фреймворком. А если говорить формальным языком — интерфейсы обмена данными между Flutter framework и Flutter engine.
По правде говоря, это не чистая связь между кодом движка на C++ и Dart-кодом, а связь между PlatformDispatcher
из dart:ui и более высокоуровневыми слоями фреймворка, своего рода набор фасадов над PlatformDispatcher
.
Базовый класс для всех bindings — BindingBase
. Конкретные сервисы наследуются от BindingBase
. Они обязуются гарантировать единственность своего экземпляра и инициализируются только один раз (реализуют паттерн «Синглтон»). Каждый сервис отделяет в себе обработку ограниченного набора задач, связанных непосредственно с ним. В сервисе GestureBinding
, например, обрабатываются задачи, связанные со взаимодействием пользователя с экраном устройства.
Всего во Flutter девять наследников класса BindingBase
:
SchedulerBinding
;ServicesBinding
;GestureBinding
;RendererBinding
;SemanticsBinding
;PaintingBinding
;WidgetsBinding
;WidgetsFlutterBinding
;TestWidgetsFlutterBinding
.
Bindings связаны между собой определённой структурой: одни сервисы связи также являются миксинами над другими, более низкоуровневыми. Зависимости между ними можно представить следующей схемой:
Давайте взглянем на каждый сервис связи и его задачи подробнее.
SchedulerBinding
Главная задача этого сервиса — планировка задач, связанных с отрисовкой кадра. Например:
- Вызовы преходящих задач (
transientCallbacks
), которые инициирует система в методеWindow.onBeginFrame
. Например, события тикеров и контроллеров анимации. - Не связанные с рендерингом задачи (
midFrameMicrotasks
), которые должны быть выполнены между кадрами. То есть микротаски, запланированные преходящими задачами. Это может быть очистка очереди событий обработанных жестов, обработка скролла. Микротаски выполняются между подготовкой к новому кадру и его отрисовкой. - Вызовы непрерывных задач (
persistentCallbacks
), которые инициирует система в методеWindow.onDrawFrame
. В частности, это вызов методаbuild
у виджета илиlayout
у рендер-объекта. - Задачи, вызываемые после отрисовки кадра (
postFrameCallbacks
). Обычно это задачи, которые не могут выполниться в процессе рендеринга, например отправка семантических событий (изменение фокуса) или очистка кеша изображений.
Одновременно SchedulerBinding
может работать только с одним типом задач, обработка идёт в том порядке, в котором мы перечислили их выше.
Узнать, какую задачу в данный момент обрабатывает SchedulerBinding
, можно с помощью геттера schedulerPhase
, который возвращает состояние SchedulerPhase
.
Далее поговорим о том, где будет полезен SchedulerBinding
и его методы.
addPostFrameCallback и endOfFrame
Очень часто нам нужно выполнить код после окончания рендеринга текущего кадра, когда станут доступны размеры всех виджетов: например, чтобы получить размер виджета, который не известен заранее.
Для этого мы можем воспользоваться двумя способами — методом addPostFrameCallback
или геттером endOfFrame
. Вот так:
void main() {
for (int i = 0; i < 10; i++) {
print('hello ${i + 1}');
}
}
Ещё один вариант использования SchedulerBinding
— возможность наблюдать за метриками отрисовки вашего приложения.
Наблюдение за производительностью
С помощью SchedulerBinding
вы можете наблюдать за производительностью вашего приложения, используя следующие методы:
// [FrameTiming] — объект с информацией о кадре
typedef TimingsCallback = void Function(List<FrameTiming> timings);
// Добавить [TimingsCallback]
void addTimingsCallback(TimingsCallback callback)
// Удалить [TimingsCallback]
void removeTimingsCallback(TimingsCallback callback)
Здесь FrameTiming
— объект, который содержит метрики отрисовки кадра, такие как:
- длительность фазы build
- длительность фазы отрисовки на GPU
Эти метрики собираются в батчи и отправляются примерно раз в секунду в release-режиме сборки. Разработчики Flutter утверждают, что за каждый зарегистрированный TimingsCallback
использование процессора вырастет примерно на 0,01%, — это замедляет перформанс приложения, и нужно пользоваться этим функционалом с осторожностью.
Батч (англ. batch) — набор данных, собранный в группу. Это позволяет не отправлять данные часто и экономить ресурсы при их частой отправке.
Пример использования TimingsCallback
:
void main() {
for (int i = 0; i < 10; i++) {
print('hello ${i + 1}');
}
}
Сборка мусора
С помощью сервиса SchedulerBinding
можно управлять стратегией работы сборщика мусора.
PerformanceModeRequestHandle? requestPerformanceMode(DartPerformanceMode mode)
Метод просит его перейти в определённый DartPerformanceMode
. Существуют четыре режима работы:
balanced
— стандартный режим работы, идеально оптимизированный для Flutter;latency
— снижение времени задержек за счёт увеличения накладных расходов на память; не рекомендуется находиться в этом режиме длительное время;throughput
— увеличение пропускной способности за счёт увеличения задержек на обработку;memory
— оптимизация для работы в условиях низкой доступной памяти, работает чаще с большим объёмом данных, что понижает перформанс.
На выходе вы получаете nullable-объект PerformanceModeRequestHandle
, который используется для вывода из установленного DartPerformanceMode
: нужно вызвать метод dispose
для освобождения ресурсов. Если возвращается null
, значит, в данный момент какой-то другой код запросил режим работы другого типа.
Используйте requestPerformanceMode
для оптимизации только в том случае, если проблемы производительности приложения возникают из-за сборщика мусора. Помните: это крайняя мера, если другие оптимизации не помогли.
И ещё один совет: всегда замеряйте метрики производительности до и после изменений. Подробнее о производительности приложения — в параграфе Профилирование: Flutter DevTools.
ServicesBinding
Вот за что он отвечает:
- Прослушивание и перенаправление платформенных сообщений в
BinaryMessenger
, сервис, к которому по умолчанию привязываются платформенные каналы: каналы методов (MethodChannel
) и событий (EventChannel
). При получении очередного сообщенияBinaryMessenger
перенаправляет его в соответствующий платформенный канал.BinaryMessenger
умеет не только получать, но и отправлять сообщения в платформу. Подробнее о нём вы можете почитать в параграфе Channels. - Сбор и регистрация лицензий пакетов, которые были в приложении в качестве зависимостей. Лицензии пакетов зашиваются в приложении во время его сборки инструментами Flutter.
- Сохранение ссылки на токен главного изолята. Он может использоваться, если необходимо общаться через платформенные каналы из сторонних изолятов. Подробнее об этом вы прочитаете в параграфе Advanced изоляты и зоны, асинхронное и параллельное программирование.
- Обработка системных событий, которые идут от платформы. Например, запрос на выход из приложения, жизненный цикл приложения, событие out of memory, нажатия клавиатуры и др.
- Создание
RestorationManager
— это сущность, которая отвечает за восстановление состояния приложения. Про него подробно рассказывали в лекции про persistence Школы мобильной разработки Яндекса.
GestureBinding
Главная обязанность сервиса GestureBinding
— это обработка взаимодействия пользователя с экраном устройства, то есть обработка жестов.
Получаемые на вход данные о нажатиях доставляются конкретным потребителям этих событий (кнопки, области со скроллом и т. д.). Процесс распознавания адресата для события называется hitTest
, результат распознавания — hitTestResult
.
GestureBinding
умеет кешировать hitTestResult
для большей эффективности. Помимо обработки событий со стороны устройства, GestureBinding
также открывает возможность посылать «ложные» события нажатий, что используется в TestWidgetsFlutterBinding
. Подробнее про hitTest
вы можете прочитать в параграфе RenderObject.
RendererBinding
Этот сервис — связующее между деревом RenderObject и Flutter engine. У него две основные обязанности:
- Прослушивание событий от engine для информирования об изменении настроек устройства, которые могут затрагивать семантический слой или как-то влиять на визуальное представление вашего приложения (например, тёмная тема или размер текста).
- Передача во Flutter engine изменений на экране с помощью Layer tree. Подробнее — в параграфе RenderObject.
Для того чтобы передавать изменения в engine, этот binding отвечает за управление PipelineOwner
и инициализацию RenderView
.
PipelineOwner
— это такой объект, который знает, какой RenderObject
должен среагировать в ответ на изменения layout. Он же и управляет этой реакцией.
SemanticsBinding
Связывает engine и слой семантики. Отвечает за всё необходимое для accessibility приложения, чтобы им могли пользоваться люди с ограниченными возможностями здоровья:
- упрощение или отключение анимации;
- управление обновлениями семантики и доставка этих событий в
SemanticsNode
, для этого используетсяSemanticsOwner
; - обработка и доставка
SemanticsAction
в нужныйSemanticsNode
.
Подробнее про accessibility вы можете прочитать в параграфе Accessibility.
PaintingBinding
Binding для связи с библиотекой painting, вот за что он отвечает:
- механизм кеширования и вытеснения из кеша (cache eviction) изображений;
- прогрев шейдеров (подробнее о том, зачем нужен прогрев шейдеров, можно почитать в параграфе Профилирование);
- уведомления об изменении шрифтов в системе и их предоставление;
- предоставление кодеков для декодирования изображений.
Вытеснение из кеша (cache eviction) — это процесс удаления данных из кеша компьютерной системы для освобождения места под новые данные. Кеш используется для временного хранения часто используемых данных и для быстрого доступа к ним. Однако кеш имеет ограниченный размер, и, когда он заполняется, новые данные не могут быть добавлены без удаления старых.
WidgetsBinding
Связывает engine и виджеты. У него две основные задачи:
- управление процессом перестроения структуры дерева элементов (для этого используется
BuildOwner
); - вызов рендера в ответ на изменения структуры дерева.
Помимо этого, он объединяет функционал других сервисов связи и переадресовывает его в слушателей — виджеты с миксином WidgetsBindingObserver
. Например, изменения состояния приложения AppLifeCycleState
, которые изначально попадают в ServicesBinding
, перехватываются и отправляются в WidgetsBindingObserver
. Для того чтобы наблюдать за платформенными событиями, вам нужно примиксовать WidgetsBindingObserver
в свой виджет.
Пример:
void main() {
for (int i = 0; i < 10; i++) {
print('hello ${i + 1}');
}
}
Обратите внимание, что в методе dispose
вызывается WidgetsBinding.instance.removeObserver(this)
для освобождения памяти.
С помощью такого механизма работает виджет MediaQuery
— он наблюдает за событием didChangeMetrics
и сообщает подписчикам InheritedWidget
про обновление.
WidgetsFlutterBinding
Этот сервис связи хоть и наследуется от BindingBase
, но не отделяет в себе какую-то конкретную логику общения с engine. Его главная роль — инициализация всех сервисов связи, необходимых фреймворку для корректной работы.
TestWidgetsFlutterBinding
Содержит функционал, полезный при написании интеграционных тестов.
Используется библиотекой flutter_test. Как и WidgetsFlutterBinding
, отвечает за инициализацию основных сервисов связи. Так же зависит от TestDefaultBinaryMessengerBinding
, который переопределяет defaultBinaryMessenger
на TestDefaultBinaryMessenger
. Он имеет доступ к данным, отправленным со стороны плагинов, что полезно для тестовых фреймворков, мониторинга и синхронизации с сообщениями платформы.
Рендеринг и bindings
Давайте вспомним с вами несколько фактов об устройстве вёрстки во Flutter, о которых рассказывалось в параграфе Elements:
- виджет — неизменяемая конфигурация для
Element
; - из виджетов получается дерево элементов, элемент содержит ссылку на виджет, который его создал;
- элементы связаны друг с другом как parent и child;
- элемент может содержать
RenderObject
.
Для того чтобы обновить картинку на устройстве, Element
и RenderObject
в начале проходят фазу аннулирования.
Аннулирование (англ. invalidate) — это проверка, что элементы или рендер-объекты не устарели. Например, при получении новой конфигурации элемент может ей не соответствовать, и тогда требуется обновление дерева элементов.
Для Element
этот процесс запускается в следующих двух сценариях:
- Первый сценарий — в случае вызова метода
setState
: проверяется, не устарел лиStatefulElement
. - Второй сценарий — в случае, если
Element
подписан наProxyElement
, который отправляет уведомление об изменении его конфигурации —InheritedWidget
.
Результатом фазы аннулирования элементов является список элементов, помеченных флагом dirty
.
Для RenderObject
сценарии следующие:
- Изменения геометрии
RenderObject
(позиция, размер и т. д.). - Необходимость перерисовки (если поменялся только цвет, стиль шрифта и т. д.).
В результате фазы аннулирования получается список RenderObject
, который необходимо перерисовать.
После фазы аннулирования в ход вступает сервисSchedulerBinding
и отправляет запрос в Flutter engine на планировку следующего кадра.
После того как engine будет готов отрисовать следующий кадр, он обращается к SchedulerBinding
и вызывает метод onDrawFrame
.
На схеме ниже показано, что происходит после получения SchedulerBinding
сигнала onDrawFrame
от engine:
Scheduler делегирует вызов в сервис WidgetsBinding
, вызывая метод drawFrame
.
В первую очередь WidgetsBinding
рассматривает изменения, произошедшие в дереве элементов: вызывает уBuildOwner
метод buildScope
, в котором проходится список элементов, помеченных как dirty. У каждого элемента вызывается метод rebuild
, что, как правило, ведёт к вызову метода build
и получению нового виджета. Далее есть два варианта поведения:
- Если у элемента не инициализировано поле
child
, вызывается методinflate
, что ведёт к созданию нового элемента. - Если поле инициализировано, происходит проверка по ключу и типу: можно ли оставить существующий элемент (child). Если оставить можно, то элемент остаётся, если нет — он выбрасывается, вызывается
inflate
для получения нового элемента на местоchild
.
После обработки элементов подходит очередь рендер-объектов, которые требуют перерисовки. Сервис WidgetsBinding
по цепочке вызывает метод drawFrame
у RendererBinding
, и происходит следующее:
- у каждого
RenderObject
, помеченного dirty, вызывается методperformLayout
, который считает геометрию объекта (размер, отступы и т. д.); - происходит перерисовка
RenderObject
, у которого флагneedsPaint
принимает значение true; - полученная сцена отправляется в
RenderView
с помощью методаcompositeFrame
, затем эта сцена доставляется во Flutter engine для отрисовки; - затем происходит обновление слоя семантики.
Наконец, новый кадр появляется на экране устройства.
Совместив весь процесс отрисовки кадра, получаем следующую схему:
Знаем, было нелегко, но мы справились!
В этом параграфе мы узнали, что такое Bindings
и как они связывают Flutter engine с Flutter framework. Изучили, какие бывают типы сервисов связи и какую функцию имеет каждый из них, а также познакомились с тем, какую роль они принимают в процессе рендеринга.
В следующем параграфе мы приступим к изучению сливеров (англ. slivers) — инструментов, с помощью которых можно делать интерактивные списки элементов и разнообразить функциональность интерфейса вашего приложения.