Вопросы на собеседовании: Flutter-разработчик

Я бы построил граф пакетов по фичам с единой точкой композиции приложения и проверял его связи в CI.

• Каждая бизнес-фича публикует небольшой пакет api, а виджеты, провайдеры Riverpod или BLoC, репозитории и DTO держит в пакете реализации, за который отвечает одна команда.
• Общие доменные типы Dart находятся в редко меняющихся core-пакетах, а код Swift, Kotlin и плагинов скрыт за platform-пакетом, поэтому фичи не импортируют детали хоста.
• CODEOWNERS и проверка графа зависимостей запрещают импорты между реализациями, а тесты затронутых пакетов удерживают p95 проверки pull request ниже 12 минут.
• Дополнительные модели на границах оправданы только там, где они позволяют 5 командам выпускать изменения без правок чужой реализации.

Я бы разорвал циклы через узкие контракты, а затем оптимизировал измеренные пакеты с большим числом зависимых модулей, не объединяя всё подряд.

• Я бы составил карту импортов и частоты изменений, затем вынес контракты маршрутов, результатов и домена из минимальной стабильной границы, разрывающей каждый из 11 циклов.
• Часто меняющиеся общие UI- и utility-пакеты разделил бы по владельцам либо вернул потребителям; более 15 зависимых пакетов допустимы только у стабильных примитивов.
• Проверка графа в CI запрещала бы циклы, недопустимые связи между фичами и публичные импорты каталога src другого пакета.
• Новая схема принимается только при отсутствии циклов и инкрементальном анализе затронутой фичи быстрее 90 секунд.

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

• Команда checkout владеет состоянием, UI, аналитикой и оркестрацией, а платежи, идентификация и каталог публикуют узкие возможности с явными владельцами и тестами совместимости.
• CODEOWNERS требует владельца для изменений реализации, но для контракта достаточно одного ревьюера от потребителя и одного от поставщика вместо всех 5 команд.
• Ежеквартальный отчет отслеживает пакеты без владельца, задержку согласований и межкомандные правки с целью не более одного внешнего согласования для обычного изменения checkout.
• Общий код получает платформенного владельца лишь после того, как минимум 3 фичам понадобится одинаковое стабильное поведение, а не просто похожий синтаксис.

Я бы держал типизированные маршруты в API-пакетах, а конкретные builders разрешал в оболочке приложения.

• Каждая фича публикует sealed-типы Dart 3 для входных данных маршрута и типизированных результатов со стабильными ID, но без классов Widget, экземпляров GoRouter и типов репозиториев.
• Точка композиции приложения регистрирует все 24 обработчика и направляет 8 проверенных deep links через тот же парсер маршрутов с учетом аутентификации и предварительных условий.
• Контрактные тесты проверяют сериализацию маршрута, неизвестные версии, поведение Back и однозначное разрешение каждой регистрации.
• Проверка графа пакетов гарантирует отсутствие связей между реализациями, а централизованная сборка принимается ради прозрачной навигации.

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

• Плагин оправдан, когда фича владеет API на Swift или Kotlin; он не дает независимого развертывания Dart-кода и добавляет работу с версиями платформ.
• Отложенные компоненты Android могут сократить базовую загрузку, но на iOS код всё равно входит в приложение, поэтому я измерю размер и p95 первого открытия отдельно по платформам.
• Микрофронтенд в рантайме добавляет отказы маршрутизации, зависимостей, наблюдаемости и совместимости, не обеспечивая доставку iOS-кода в обход App Store.
• Я вынесу фичу в отложенную доставку только при p95 первого открытия ниже 4 секунд, иначе уменьшу ресурсы или включу ее в приложение.

Я бы опубликовал единый Dart-контракт возможностей, а обе нативные реализации скрыл за границей федеративного плагина.

• Пакет для приложения определяет типизированные команды камеры, результаты, ошибки и состояния жизненного цикла без типов AVFoundation или CameraX.
• Пакеты Swift и Kotlin реализуют контракт и отвечают за переключение потоков, разрешения, освобождение ресурсов и нативные тестовые фикстуры.
• Dart-адаптер унифицирует только обязательное общее поведение, а платформенные возможности оставляет явными, не сводя их к ложному общему знаменателю.
• Интеграционные бенчмарки измеряют p95 полного цикла команды ниже 50 мс на обеих платформах, включая сериализацию и переключение на главный поток.

Я бы выбрал Pigeon, потому что сгенерированные типизированные интерфейсы лучше выполняют требование compile-time контракта, чем написанные вручную карты MethodChannel.

• Схема Pigeon задает nullable-поля, enum, структурированные ошибки и асинхронные host-методы, а CI генерирует согласованный код Dart, Swift и Kotlin.
• Тонкий адаптер не пропускает сгенерированные типы в доменный слой, поэтому обновление схемы не расходится по 14 местам вызова.
• MethodChannel подходит для одного небольшого экспериментального вызова, но строковые имена методов и динамические карты переносят ошибки в рантайм.
• CI повторно генерирует код и падает при diff, а тесты совместимости запускают предыдущий Dart-клиент с текущим нативным хостом.

Я бы разделил нативное состояние передачи и частоту обновления UI, явно задав срок жизни подписки.

• Нативный код отправляет типизированные снимки с ID файла, монотонным номером, числом байтов и конечным состоянием в одной последовательной очереди, а не создает канал на каждый тик.
• Dart-адаптер объединяет обновления каждого файла до частоты не более 10 в секунду, но всегда доставляет завершение и ошибку.
• onListen регистрирует одного наблюдателя, onCancel удаляет его, а повторная подписка возвращает последний снимок, чтобы пересоздание view не сбрасывало прогресс.
• Тест длительностью 60 секунд проверяет ограниченную память, отсутствие потерянных конечных событий и возраст UI-данных ниже 150 мс для всех 20 файлов.

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

• FFI устраняет повторную сериализацию кодеком, а NativeCallable или узкий C ABI сохраняет стабильную границу для оберток Swift, Kotlin и Dart.
• Буферы имеют явное владение и переиспользуют нативные области памяти; каждое выделение и освобождение покрывается нагрузочными тестами и AddressSanitizer в нативных сборках.
• Вызовы выполняются вне UI isolate, если могут превысить бюджет кадра, потому что сам по себе FFI не делает CPU-работу асинхронной.
• Нативная сложность принимается только при p95 полного цикла ниже 16,7 мс и отсутствии роста памяти после 100 000 вызовов.

Я бы версионировал контракт возможностей отдельно от пакета плагина и явно моделировал переходы жизненного цикла.

• Dart-интерфейс согласует версию контракта и возможности, отклоняет неподдерживаемую major-версию и допускает добавочные optional-поля внутри одной major-линии.
• Android привязывает ресурсы к ActivityAware callbacks и освобождает их при detachment из-за конфигурации; iOS реагирует на активацию и отключение сцен, не предполагая одно глобальное окно.
• При потере хоста незавершенные вызовы получают типизированный результат unavailable или cancelled, а повторное подключение восстанавливает наблюдателей без дублей.
• Перед публикацией матрица проверяет 3 линии Flutter, пересоздание Activity, 2 сцены iOS и совместимость старого Dart-клиента с новым хостом.

Я бы считал 16,7 мс полным интервалом кадра и отдельно профилировал UI- и raster-работу, поскольку любая из них может пропустить vsync.

• Графики кадров DevTools в profile- или release-сборке показывают, где задержка: build, layout, paint, растеризация или отправка команд GPU.
• Я бы удерживал p95 UI- и raster-длительности примерно ниже 8 мс каждую, оставляя запас планировщику, а не отдавая одной стороне весь интервал.
• Timeline-события вокруг анимации связывают конкретное взаимодействие с затратами shader, декодирования изображения, saveLayer или layout на целевом устройстве.
• Изменение проходит проверку только при доле медленных кадров ниже 2 процентов в 20 одинаковых прогонах, а не при одном улучшении среднего.

Я бы сузил обновление конфигурации на уровне element и инвалидацию рисования на уровне render, не оптимизируя вслепую всё дерево.

• Неизменяемые widgets описывают конфигурацию, elements сохраняют идентичность и состояние, а render objects выполняют layout и paint, поэтому стабильные keys и const-поддеревья сокращают лишние обновления elements.
• Значение счетчика выбирается у самого узкого потребителя через Riverpod select или точечный ListenableBuilder, оставляя конфигурации остальных 599 виджетов неизменными.
• RepaintBoundary изолирует анимированную область, только если визуализация repaint в DevTools подтверждает перерисовку окружающих пикселей; избыток границ расходует слои и память.
• Я сравню число build и время raster на 100 обновлениях, требуя перестройки только поддерева счетчика и p95 paint ниже 4 мс.

Я бы составил ленивые slivers и сохранил стабильную идентичность элементов, чтобы viewport создавал только ближайшие строки.

• CustomScrollView объединяет SliverPersistentHeader для месяцев со SliverList или SliverVariedExtentList, если размеры можно дешево узнать, без shrinkWrap и вложенных прокручиваемых списков.
• Строки используют стабильные backend ID, готовые presentation-модели и ограниченный keep-alive только для тех контролов, которым действительно нужно локальное UI-состояние.
• Пагинация удерживает окно вокруг viewport, а декодированные изображения удаляются через image cache вместо хранения render-детей для всех 50 000 моделей.
• Бенчмарк прокрутки должен удерживать peak RSS ниже 120 МБ и p95 кадра ниже 16,7 мс на самом слабом поддерживаемом устройстве.

Я бы создал собственный RenderObject лишь после доказательства, что готовые slivers не обеспечивают двухосевую виртуализацию в заданном бюджете.

• Render object вычисляет видимые диапазоны строк и столбцов по constraints и смещениям прокрутки, затем раскладывает только ячейки viewport и небольшого cache extent.
• Он отделяет layout-входы от изменений выделения, требующих только paint, реализует hit testing и semantics и не делает intrinsic measurement всех 2 000 ячеек.
• Сначала я проверю готовые примитивы двухмерной прокрутки, потому что собственный layout несет долг по accessibility, жестам и обновлениям фреймворка.
• Собственная реализация принимается только при p95 layout ниже 8 мс и semantics-тестах навигации с клавиатурой и screen reader.

Я бы профилировал путь Impeller и нагрузку ресурсов, не предполагая, что все задержки, связанные с shaders, исчезли автоматически.

• Profile-сборка с Perfetto и Flutter timeline разделяет Dart-работу, загрузку текстур, создание pipeline, raster-время и завершение GPU во время первой анимации.
• Я упрощу неподдерживаемые или дорогие эффекты, сокращу большие области saveLayer и прогрею лишь небольшой предсказуемый путь анимации, если главным фактором доказано создание pipeline.
• Все 3 модели GPU останутся в матрице бенчмарков, потому что драйверы и лимиты текстур могут различаться даже при модели предварительно скомпилированных shaders в Impeller.
• Релиз требует p95 первого запуска ниже 16,7 мс либо осознанный fallback с reduced motion без визуальных расхождений в golden- или screenshot-проверках.

Я бы отделил стабильный дорогой контент от движущихся маркеров и оставил только те границы, для которых измерена экономия raster-работы.

• Статичные метки и оформление карты могут делить один RepaintBoundary, если не меняются при обновлении маркеров, а анимированные маркеры рисуются в отдельном легком слое.
• Я проверю записи raster cache и repaint rainbow, удалив отдельные границы меток, чьи кэшированные текстуры дороже повторного рисования простого текста.
• Большие изображения декодируются близко к размеру показа и переиспользуются по ключу кэша, а временные трансформированные слои не кэшируются принудительно без окупаемости на повторных кадрах.
• Цель: рост raster cache менее 15 МБ и p95 raster-времени ниже 8 мс за 60 секунд анимации.

Я бы разделил модель сцены, преобразование viewport, слой взаимодействия и семантическое представление, чтобы они обновлялись с разной частотой.

• CustomPainter или render object рисует видимые узлы из пространственного индекса, а рамки выделения и курсоры перерисовываются отдельно без перестройки модели из 500 узлов.
• События указателя, клавиатуры и focus поступают в один детерминированный reducer с sealed actions Dart 3 и записями undo, а не напрямую изменяют объекты canvas.
• Semantics представляет выбранные и ближайшие узлы как доступные controls, хотя визуальный canvas кастомный, а reduced-motion отключает необязательные переходы.
• Бенчмарки pan, zoom, множественного выбора и undo требуют p95 кадра ниже 16,7 мс и задержки hit test ниже 50 мс.

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

• Flutter integration- или нативные macrobenchmarks выполняют минимум 30 холодных запусков в profile- или release-режиме с одинаковым состоянием устройства, разделяя запуск engine, инициализацию Dart, регистрацию плагинов и первый кадр.
• Синхронно остаются только crash reporting и критичная для запуска конфигурация; аналитика, remote config, прогрев БД и не начальные маршруты инициализируются при первом использовании.
• Первый экран использует небольшие локальные ресурсы и не блокируется сетью, а startup-код Dart 3 не создает заранее весь граф провайдеров.
• Gate требует p95 ниже 1,5 секунды и не допускает ухудшения p95 теплого старта более чем на 5 процентов.

Я бы разделил утечки удерживаемых объектов, нагрузку декодированных изображений и нативные allocations до изменения лимитов кэша.

• Heap snapshots и retaining paths в DevTools сравнивают посещения 2 и 10, а Android Studio или Instruments показывает, находится ли пропавшая память в Dart, GPU-текстурах или нативных плагинах.
• Controllers, подписки streams и Riverpod auto-dispose scopes должны освобождаться вместе с маршрутом; повторный тест требует ноль удерживаемых владельцев галереи после сборки мусора.
• Для декодированных изображений задается измеренный лимит ImageCache в байтах и декодирование до целевого размера с допустимыми повторами ради peak RSS ниже 210 МБ.
• Цикл по галерее длительностью 15 минут проходит, только если память после GC возвращается в пределах 10 МБ от уровня второго посещения и процесс не завершается из-за OOM.

Я бы запрашивал, декодировал и кэшировал thumbnails в размере показа, а не пропускал 12 МП изображения через UI-путь.

• CDN отдает варианты по ширине, формату и качеству, а cacheWidth или ResizeImage ограничивает локальное декодирование, если серверного варианта нет.
• Список предзагружает лишь небольшое окно viewport, ограничивает параллельные загрузки и отменяет работу для строк, ушедших из окна до декодирования.
• Memory cache хранит декодированные thumbnails в рамках байтового бюджета, disk cache хранит сжатые ответы, а полное разрешение загружается только на detail-экране.
• Бенчмарки требуют первые видимые thumbnails за 500 мс, peak RSS ниже 220 МБ и не более 8 одновременных декодирований.