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

Я буду поэтапно выпускать отдельный обновлённый бинарник, потому что Fabric и Bridgeless действуют на весь React Native runtime, а не на выбранные экраны или пользователей.

• Я опишу все 180 экранов, 46 нативных зависимостей и 18 собственных модулей, затем проверю каждую зависимость в чистых Release-сборках iOS и Android.
• Кандидат на React Native 0.82 или новее будет рендерить все React Native-поверхности через Fabric; route flags смогут выбирать совместимую или переписанную реализацию экрана, но обе используют один renderer.
• Релизы 1-6 проведут обновлённый бинарник через 500 внутренних устройств, 1%, 5%, 25%, 50% и 100% с наблюдением не менее 48 часов перед каждым расширением.
• Я остановлю rollout при crash-free ниже 99,7%, росте ошибок критического флоу больше 0,2 процентного пункта или ухудшении startup p95 свыше 10%; приложение на React Native 0.81 или старше останется отдельной группой предыдущего бинарника.

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

• Нативная оболочка checkout владела бы навигацией UIViewController или Fragment, а каждая React Native-поверхность отвечала бы за layout, события и accessibility ниже своего корня.
• Нативные контролы внутри поверхности я бы публиковал как Codegen Fabric-компоненты, а не оборачивал через произвольное вложение view controller.
• Данные через границу передавались бы небольшими типизированными props и событиями, без общих изменяемых ссылок на view и императивного обхода.
• Время монтирования и переходов я бы измерил на 3 классах устройств, потому что множество мелких поверхностей добавляет стоимость инициализации.

Я бы сделал типизированную Codegen-спецификацию источником истины и развивал её только добавочными изменениями в окне совместимости из 8 релизов.

• Каждый модуль получил бы узкую TypeScript-спецификацию с явными nullable-значениями, enum, поведением promise и структурированными кодами ошибок для iOS и Android.
• Сгенерированный Codegen-код компилировался бы в обоих нативных проектах в CI, а diff API запрещал бы удаление методов и смену смысла полей.
• Новые возможности были бы опциональными и обнаруживались через версию или capability-метод, чтобы старый бинарник безопасно отклонял неподдерживаемый вызов.
• Синхронные методы я бы оставил только для ограниченной работы в памяти до 2 мс, а хранилище, сеть и разрешения сохранил асинхронными.

Я бы привязал каждый JSI-объект к его runtime, а нативные буферы кадров сделал явно reference-counted и отменяемыми.

• Host object в области runtime владел бы shared нативным процессором, а задачи держали бы weak-ссылки, чтобы teardown запрещал поздние callback.
• Я бы никогда не сохранял и не обращался к jsi::Runtime с потоков камеры; результаты возвращались бы через runtime scheduler в поток JavaScript runtime.
• Буферы освобождались бы детерминированно после обработки, а ограниченная очередь из 2 кадров отбрасывала бы устаревшую работу вместо роста памяти.
• Unmount поверхности отменял бы producers и инвалидировал host objects, после чего проходил бы тест на утечки из 100 циклов mount и unmount на обеих платформах.

Я бы использовал один React Native host на процесс и монтировал изолированные поверхности в существующую нативную навигацию только при запросе React Native-маршрута.

• UIViewController на iOS и Fragment на Android получали бы типизированные параметры маршрута и размещали поверхность, не удерживая бизнес-состояние в нативном контейнере.
• Нативная оболочка продолжала бы отвечать за auth-gates, universal links, Android app links и системную навигацию назад.
• После первого нативного экрана я бы заранее загрузил только Hermes и минимальную оболочку, а выполнение уже встроенных не начальных feature-модулей отложил, не отдавая React Native весь 2-секундный бюджет.
• Контрактные тесты запускали бы все 60 React Native-маршрутов из нативного кода и проверяли возврат результата, восстановление состояния и восстановление после завершения процесса.

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

• Каждый pull request собирал бы текущий minor React Native на минимальной и текущей iOS и Android в Debug и Release нативных конфигурациях.
• Ночные тесты покрывали бы предыдущий minor React Native, все 3 major iOS, Android API 26 и 2 репрезентативных современных API, а также физические arm64-устройства.
• Для каждой из 46 библиотек machine-readable манифест фиксировал бы поддержку New Architecture и ограничения по OS, Xcode, Gradle, Kotlin и CocoaPods.
• Обновление React Native или toolchain выходило бы только после нативной компиляции, 20 критических end-to-end флоу и 30-минутного soak-теста на каждой рискованной линии.

Я разделю пакеты на pure JavaScript, legacy native пакеты для interop и пакеты, которым нужна миграция на TurboModule или Fabric component.

• Pure JavaScript-пакет не требует переписывания нативной архитектуры, но всё равно проверяется на текущем Hermes, удалённые API и вклад в bundle.
• Legacy native module или view может временно остаться, если interop layer целевого React Native его поддерживает, а чистые Release-сборки iOS и Android и runtime smoke tests проходят.
• Вызываемые нативные API я перенесу на TurboModules, а нативные view на Codegen Fabric components только при отказе interop, неподдерживаемой семантике или доказанной измерениями стоимости границы.
• Каждый критический пакет будет 100 раз смонтирован, вызван, переведён в background и уничтожен в обеих Release-сборках, а до rollout получит владельца и план замены.

Я буду считать Bridgeless частью обновлённого New Architecture-бинарника, а не отдельным runtime-переключателем для 10% пользователей.

• Вызовы TurboModule вернут promises или ограниченные по времени синхронные значения, а упорядоченные потоки событий получат sequence numbers и описанную семантику доставки.
• Общее нативное состояние будет использовать собственный serial executor, actor или lock вместо удалённой bridge queue как случайного mutex.
• Чистые Release-сборки iOS и Android смонтируют, вызовут, переведут в background и уничтожат все 12 пакетов, включая временно работающие через interop layer.
• Я проведу обновлённый бинарник через 1%, 5%, 25% и 100% минимум по 24 часа, останавливаясь при crash-free ниже 99,7% или росте ошибок пакетов на 0,2 пункта, пока legacy-приложение остаётся отдельной store-группой.

Я бы централизовал объявления нативных версий и коммитил все lock-файлы resolver, чтобы одна ревизия давала одинаковый граф iOS и Android.

• Версии CocoaPods жили бы в одном podspec или helper с закоммиченным Podfile.lock, а Android использовал бы Gradle version catalog и dependency locking.
• React Native, Hermes, Reanimated, Kotlin, AGP и iOS toolchain двигались бы как единый проверенный набор платформы, а не как независимые обновления.
• Еженедельная автоматизация предлагала бы сгруппированные обновления, собирала 2 варианта приложения и публиковала diff графа зависимостей и размера бинарника.
• Для security-фиксов был бы ускоренный путь, но до 14 млн пользователей всё равно доходили бы неизменяемые lock-файлы и подписанный build artifact.

Я разделю rollout бинарника и flags реализаций маршрута, потому что все React Native-поверхности обновлённого бинарника используют Fabric.

• Каждый из 30 маршрутов получит один типизированный контракт входа, выхода, сохранения и аналитики для совместимой и переписанной реализаций, которые обе рендерятся через Fabric.
• Кешируемый kill switch сможет за 10 минут направить новые флоу в совместимую реализацию без смены renderer и загрузки нативного кода.
• Распространение обновлённого бинарника останавливается отдельно; установленный New Architecture-бинарник нельзя удалённым флагом превратить в legacy-бинарник на React Native 0.81 или старше.
• Добавочные схемы состояния и 1000 тестов переключения и восстановления докажут переживание process death обеими реализациями, а прошлый store-бинарник останется нативной fallback-группой.

Я федерализую владение исходниками и build-time packages, не считая web-style загрузку модулей в runtime допустимой на мобильных платформах.

• Проверенный бинарник будет содержать все 9 доменных модулей, а одна оболочка станет владельцем navigation, authentication, design tokens, telemetry и контракта нативных возможностей.
• React, React Native, Reanimated, navigation и библиотеки вокруг Hermes будут точными host-owned singletons с одним разрешённым набором нативных зависимостей.
• При старте выполнятся только оболочка и начальный маршрут; выполнение встроенных некритичных модулей можно отложить до navigation с бюджетом loading state 200 мс.
• Загружаемый JavaScript сможет обновляться только при разрешении текущих review и runtime policies и в рамках уже встроенных и проверенных возможностей; новая функциональность или нативный код потребуют store-бинарник.

Я сделаю еженедельным результатом версионированный build-time package и признаю, что production-активация фич следует за ежемесячным проверенным host-бинарником.

• Каждый package откроет одну registration entry с маршрутами, требованиями к host capabilities, версией схемы аналитики, lifecycle hooks и health check.
• CI проверит точный content hash с текущим и следующим host, после чего ежемесячный host встроит утверждённые версии в один подписанный кандидат iOS и Android.
• iOS не будет загружать исполняемые feature-модули, вводящие или меняющие функциональность, а нативная dynamic delivery Android пойдёт только через store-механизмы, связанные с версией приложения.
• Runtime JavaScript update сможет исправить уже проверенную встроенную возможность только при разрешении review policy и runtime compatibility; flags скроют плохой встроенный модуль до следующего бинарника.

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

• Каждый домен публиковал бы public index с маршрутами, командами и типами данных, а deep imports в другой домен запрещались бы lint и правилами графа.
• Общие пакеты ограничивались бы стабильными задачами вроде UI primitives, telemetry, networking и test utilities, без бизнес-логики для 2 доменов.
• Нативные пакеты явно объявляли бы входы iOS и Android, чтобы JavaScript-only изменение не инвалидировало все нативные targets.
• CI по affected graph проверял бы изменённые пакеты и обратные зависимости, а ночная полная сборка ловила бы ошибки вне 15-минутного пути.

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

• Brand manifest со schema validation задавал бы semantic tokens, bundles текстов, feature entitlements, API endpoints и доступные точки навигации.
• Bundle identifiers, signing, associated domains, push credentials и privacy manifests генерировались бы для каждого бренда при нативной сборке.
• Runtime-переключение бренда касалось бы только возможностей общего бинарника и никогда не меняло бы native entitlements или отсутствующие SDK.
• CI собирал бы все 12 брендов и запускал visual, deep-link и configuration contract tests минимум на 2 платформах до публикации SDK.

Я бы один раз определил семантические токены и генерировал из одного проверяемого источника типизированные представления для React Native, iOS и Android.

• Компоненты использовали бы роли вроде surfacePrimary и textCritical вместо названий цветов бренда и сырых hex-значений.
• Генератор отклонял бы отсутствующие токены в любом из 12 брендов и рассчитывал contrast всех сочетаний текста и состояния по WCAG AA.
• Изменения typography и spacing проходили бы snapshot-тесты в 6 локалях, потому что длинный текст обнаруживает clipping даже при правильных цветах.
• Theme objects мемоизировались бы и переключались на границе приложения, чтобы 180 экранов не пересчитывали стили внутри кадра.

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

• У каждого маршрута был бы стабильный ID, schema сериализуемых параметров, требования authentication и опциональный контракт результата.
• Universal links, Android app links и push targets нормализовались бы в один внутренний route intent до загрузки любого модуля.
• Неизвестная или удалённая версия маршрута вела бы на безопасный экран и отправляла метрику вместо падения при восстановлении состояния.
• Контрактные тесты воспроизводили бы 100 самых частых внешних ссылок на текущем и предыдущем месячных host-бинарниках iOS и Android.

Я бы разделил зависимости на host singletons, централизованно выровненные библиотеки и действительно приватные leaf-зависимости.

• React, React Native, Reanimated, navigation, gesture handling и query client были бы точными host-owned singletons без копий внутри модулей.
• Общие TypeScript-библиотеки подчинялись бы единой workspace version policy, а приватные pure JavaScript utilities могли бы отличаться только при доказанной bundle-изоляции.
• Module manifests объявляли бы peer ranges, а публикация падала бы, если диапазон не пересекается с платформенным набором host.
• Ежеквартальный upgrade train переносил бы singleton-набор вместе и удерживал рост bundle в пределах 1 МБ.

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

• Apple App Store Review Guideline 2.5.2 запрещает загружать, устанавливать или выполнять код, вводящий или меняющий функции приложения, поэтому iOS-бинарник должен уже содержать проверенную возможность.
• OTA-доставка JavaScript ограничивается текущей review policy, совпадающим runtime и поведением внутри контракта встроенных возможностей установленного бинарника.
• Нативные dynamic features Android могут использовать Play Feature Delivery, но остаются управляемыми store-артефактами, связанными с версией приложения из Play, а не произвольными загрузками.
• За 10 минут можно изменить flags, configuration и content или применить policy-compliant исправление; 5 новых исполняемых модулей, permissions, SDK или native API требуют store review и rollout.

Я вычислю один типизированный flag на границе оболочки и направлю новый checkout в одну из двух полных встроенных реализаций.

• Flag будет содержать ID реализации, audience rules, срок удаления и минимальную версию возможностей бинарника, но не URL загружаемого исполняемого модуля.
• Последняя валидная подписанная конфигурация сохранится для cold start, а проверенный checkout станет default при offline или malformed config.
• Exposure запишется один раз до checkout, а этапы 1% и 10% будут наблюдаться по 24 часа, этап 50% 48 часов до перехода к 100%.
• Я остановлю rollout при completion ниже 99,9%, crash-free ниже 99,7% или росте ошибок оплаты больше 0,2 пункта; kill switch затронет новые checkout, не переключая незавершённую транзакцию.

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

• Контракт включал бы регистрацию, типизированные маршруты, требования capabilities, lifecycle callbacks, декларации telemetry и структурированные результаты ошибок.
• Добавочные поля были бы опциональными с defaults, а удаление или смена семантики требовали бы нового major-контракта и параллельного compatibility adapter.
• Consumer-driven tests от 3 host запускались бы против кандидата, а fixtures host проверяли бы его текущую и предыдущую версии.
• Публикация падала бы при недокументированном global state, прямом импорте из shell или вызове native capability вне объявленного диапазона.