React Native: как объяснить нативные компромиссы

Разговор о React Native быстро скатывается к лозунгам: «одна кодовая база», «почти нативная скорость», «bridge медленный». На техническом интервью ценится другой навык — разложить конкретный пользовательский сценарий на JavaScript, native и системные границы, измерить узкое место и выбрать стоимость поддержки. Компромисс существует не между хорошей и плохой технологией, а между требованиями продукта.

Удобный кейс — экран с длинной лентой, видео-превью, push-навигацией и офлайн-действиями. На старых Android-устройствах появляются dropped frames, iOS-релиз ждёт новый SDK аналитики, а команда планирует переход на New Architecture. Такой сюжет позволяет обсудить render path, модули, lifecycle и выпуск без абстракций.

Сначала бюджет пользовательского сценария

Определите измеряемое ожидание: time to interactive после cold start, стабильные кадры при scroll, задержка нажатия, расход памяти, время ответа offline queue. Среднее на флагманском устройстве скрывает проблему. Нужны классы устройств, версии OS и реальный production trace.

Разделите время между bundle load, выполнение JavaScript, reconciliation, layout, декодирование изображений и native work. React DevTools, профилировщик платформы и системные метрики отвечают на разные вопросы. Один flamegraph без связи с пользовательским лагом легко ведёт к оптимизации невидимого участка.

Сформулируйте performance budget до переписывания. Если пользователь не видит улучшение, сложный native module не окупается. Для редкого тяжёлого действия допустима фоновая обработка; для gesture задержка даже короткого блокирования заметна.

Профилируйте release-сборку на слабом устройстве. Dev mode и симулятор меняют стоимость JavaScript, сети, декодирования и могут показать не тот bottleneck.

Bridge и New Architecture без мифов

В старой архитектуре частые мелкие переходы через асинхронный bridge и сериализация данных способны стать ценой, но не каждый лаг вызван bridge. Fabric меняет renderer, TurboModules — доступ к модулям, JSI — модель взаимодействия. Переход требует проверки библиотек, codegen, threading и поведения lifecycle, а не только переключателя.

Не обещайте синхронный вызов как универсальное ускорение. Он может блокировать критический поток и создавать reentrancy-риск. Контракт модуля должен явно указывать thread, ownership данных, ошибки и отмену. Большой массив разумнее обработать рядом с источником или передать компактный результат.

Миграцию делите по совместимости. Составьте реестр зависимостей, найдите модули без поддержки, включите архитектуру в отдельной сборке, прогоните ключевые устройства и сравните метрики. Fallback должен иметь срок удаления; вечный dual path удваивает тестовую матрицу.

Нативный модуль — продуктовый контракт

Причина для собственного модуля должна быть конкретной: отсутствующий системный API, тяжёлая обработка, требование SDK поставщика или критичный realtime path. Перед разработкой проверьте поддерживаемую библиотеку и возможность узкого адаптера. Каждая строка Swift и Kotlin создаёт две платформенные ветки, release ownership и upgrade cost.

Спроектируйте TypeScript-интерфейс, nullability, коды ошибок, cancellation и события lifecycle. Android Activity может пересоздаться, iOS приложение уйдёт в background, разрешение пользователь отзовёт в настройках. JS-обещание, которое никогда не завершается после этих переходов, станет утечкой состояния.

Для событий задайте подписку и снятие подписки. Повторный mount не должен умножать listener, а медленный consumer — бесконечно накапливать очередь. Тесты охватывают контракт JS, platform unit и один интеграционный маршрут на устройстве.

Релиз мобильного изменения не заканчивается merge

Соберите матрицу: OS, устройство, архитектура CPU, разрешения, cold/warm start, offline и upgrade с прошлой версии. Новый native SDK способен работать в чистой установке и падать после миграции локальной базы. Store review и phased rollout добавляют задержку, поэтому server compatibility держат дольше web-релиза.

Feature flag помогает остановить пользовательский путь, но не удаляет загруженный native code. На cold start удалённая конфигурация ещё может быть не fetched и не activated, особенно при первой установке; синхронная инициализация SDK успеет упасть раньше. Опасный SDK защищают безопасным локальным default, lazy loading и совместимостью по версии приложения.

После выпуска следите за crash-free users, ANR, startup, dropped frames, размером bundle и бизнес-guardrail. Разрез по версии и модели устройства обязателен. Откат в store медленнее server rollback, поэтому заранее подготовьте kill switch для обратимого поведения.

Схема показывает опорные решения кейса «React Native: как объяснить нативные компромиссы».

Как рассказать компромисс на интервью

Нарисуйте путь события от жеста до native API и обратно. Укажите поток выполнения, объём данных, lifecycle и точку измерения. Затем сравните три решения: оставить JS, взять библиотеку, написать модуль. Для выбранного варианта назовите стоимость поддержки и условие пересмотра.

Посмотрите вакансии React Native разработчика и сопоставьте требуемую глубину native с вашим примером. Зарплатный срез помогает выбрать уровень отклика; сильный кейс показывает production-наблюдаемость и релиз, а не только компоненты React.

Hermes влияет на startup и память, но смена engine требует сравнительного замера именно вашего bundle. Размер bytecode, lazy modules и поведение GC зависят от приложения. Результат на benchmark нельзя автоматически переносить на ленту с изображениями.

List virtualization ломается, когда элементы имеют нестабильные ключи, тяжёлый render и непредсказуемую высоту. Увеличение windowSize может скрыть пустые кадры ценой памяти. Сначала измерьте mount cost и повторные render, затем настройте окно под устройства.

Изображения требуют собственного бюджета: размер источника, cache policy, декодирование и reuse. Картинка в четыре раза шире экрана расходует память независимо от маленького CSS-размера. CDN-трансформация и prefetch должны учитывать offline и смену URL.

Deep link проверяют при закрытом, фоновом и уже открытом приложении, с авторизацией и без неё. Дублированная навигация часто возникает, когда initial URL и event listener обрабатывают один intent. Нужна единая политика потребления события.

OTA-обновление JavaScript не может требовать native API, которого нет в установленной версии. Контракт bundle задаёт минимальную native build и fail-safe для старых клиентов. Иначе быстрый выпуск превращается в crash, который нельзя исправить одним JS-флагом.

В рассказе об accessibility включите platform semantics, динамический размер шрифта, focus order и screen reader. Общий компонент не гарантирует одинаковый UX на iOS и Android; platform-specific адаптация иногда правильнее визуальной идентичности.

Мини-кейс: SDK падает раньше remote config

После обновления аналитического SDK crash появился только на cold start части старых Android-устройств. Команда рассчитывала выключить интеграцию удалённым флагом, но native initialization запускалась из Application до старта JavaScript. На первой установке закешированного значения ещё не было, а fetch и activate remote config происходили уже после опасного вызова.

Исправление началось с безопасного локального default: SDK не инициализируется, пока совместимость build и устройства не подтверждена. Загрузку сделали lazy, вызов завернули в узкий native adapter, а backend перестал выдавать новый сценарий версиям без нужного API. Удалённый flag сохранили как kill switch для обратимого поведения после запуска, но больше не считали защитой синхронной инициализации.

Release проверили на clean install, upgrade, cold/warm start и background restore. Crash-free users смотрели по build и модели устройства; startup и размер bundle остались guardrails. OTA bundle получил минимальную native build и fallback для старых клиентов.

Параллельно команда проверила iOS, где SDK запускался позже и crash не воспроизводился. Общий JavaScript-код оставили единым, но lifecycle адаптера различался по платформам. Это было дешевле общей абстракции с ложной гарантией порядка. В contract test зафиксировали состояние до initialization, отказ без активного флага и однократный запуск после подтверждения совместимости; device test прошёл на первой установке без cache.

Fallback также проверили без сети: приложение запускалось без SDK, сохраняло основной маршрут и не ждало remote config бесконечно. После восстановления конфигурации интеграция включалась только при следующей безопасной точке lifecycle, а не посреди уже открытого экрана.

В интервью важно назвать временную линию буквально: process start, native init, JavaScript, fetch, activate. Тогда понятно, почему флаг не успел и где появилась настоящая гарантия. Финальный выбор — небольшой platform-specific guard вместо иллюзии, что любой удалённый переключатель работает до запуска процесса.