Middle React Native Developer — Вопросы на собеседовании React Native

Проведите через то, что реально происходит при вызове нативного метода из JS — в старой и новой архитектуре.

На старом мосту вызов сериализуется в JSON, ставится в очередь, батчируется, асинхронно отправляется на нативную сторону, выполняется, и результат сериализуется обратно — каждый переход стоит времени, и ничего не синхронно. С JSI TurboModule — реальный C++-объект, на который JS хранит прямую ссылку; вызов метода идёт через C++-биндинг без JSON-сериализации и без очереди, и может быть синхронным, если это нужно. Плата — сложность: написать TurboModule как надо значит иметь дело с кодогенерацией и C++, тогда как модуль на старом мосту был ближе к обычному JS-подобному клеевому коду.

`FlatList` на несколько сотен строк подтормаживает при скролле — как подступиться?

Сначала профилировать — профайлер Flipper/React DevTools или встроенный perf monitor покажет, стоимость в JS (ре-рендеры, тяжёлый renderItem) или в нативном потоке (layout, изображения). Затем проверить базовое: стабильный keyExtractor, React.memo на строке, чтобы изменение состояния родителя не каскадировалось на каждую строку, и отсутствие инлайновых стрелочных функций и объектных литералов в пропсах строки. Если проблема в дёргании layout, getItemLayout избавляет от прохода измерения на элемент, а если узкое место — сам список при большом масштабе, переход на FlashList часто прагматичнее дальнейшей ручной настройки FlatList.

Фиче нужна возможность, которую React Native не предоставляет — как добраться до нативного кода, и что придётся дублировать?

Пишете нативный модуль — реализацию на Swift/Objective-C для iOS и на Kotlin/Java для Android, — с одинаковой сигнатурой метода на обеих сторонах, потому что JS вызывает один JS-фейсинг API, который должен разрешиться в реальную реализацию на той платформе, где выполняется. Пропуск одной платформы означает, что приложение там упадёт или молча ничего не сделает, поэтому обе реализации должны реально делать одно и то же, а не просто носить одинаковое имя. Тестировать нужно на реальном устройстве или симуляторе каждой платформы, а не доверять тому, что «оно собралось».

Как надёжно обрабатывать deep link, включая холодный старт?

Зарегистрировать URL-схему или universal link/app link в нативном конфиге (Info.plist / AndroidManifest.xml) и в конфиге linking навигатора, сопоставив паттерны URL с экранами и параметрами. Сложность — холодный старт: если приложение не было запущено, при старте нужно проверить Linking.getInitialURL() и использовать его для начального состояния навигации, потому что слушатель события Linking сам по себе ловит только ссылки, пришедшие пока приложение уже открыто. Universal links дополнительно требуют файлы associated-domains / assetlinks.json, размещённые на вашем домене, чтобы ОС доверяла приложению обработку этого URL вместо открытия браузера.

В чём разница между OTA-обновлением и релизом через стор, и когда что использовать?

OTA-обновление (CodePush, Expo Updates) отправляет новый JS-бандл прямо на установленные приложения без ревью в сторе, и пользователи получают его при следующем запуске или фоновой проверке — хорошо для чисто JS-багфиксов и изменений контента. Всё, что затрагивает нативный код — новый нативный модуль, добавление разрешения, обновление нативной зависимости, — вообще не входит в JS-бандл, поэтому OTA это не доставит; нужна настоящая сборка и отправка в стор. Правила Apple прямо запрещают OTA «существенно менять основное назначение приложения», так что команда, полагающаяся на OTA сверх быстрых фиксов, рискует аккаунтом в сторе, а не только обновлением.