Middle React Native Developer — React-Native-Interviewfragen

Geh durch, was tatsächlich passiert, wenn JS eine native Methode aufruft — alte vs. neue Architektur.

Auf der alten Bridge wird der Call zu JSON serialisiert, in eine Queue gestellt, gebatcht, asynchron zur nativen Seite geschickt, ausgeführt, und das Ergebnis zurück serialisiert — jeder Hop kostet Zeit, und nichts ist synchron. Mit JSI ist ein TurboModule ein echtes C++-Objekt, auf das JS eine direkte Referenz hält; ein Methodenaufruf läuft über ein C++-Binding ohne JSON-Serialisierung und ohne Queue und kann synchron sein, wenn das gebraucht wird. Der Preis ist Komplexität — ein TurboModule richtig zu schreiben bedeutet, sich mit Codegen und C++ auseinanderzusetzen, während ein Modul im alten Bridge-Stil eher normalem, JS-nahem Klebecode ähnelte.

Eine `FlatList` mit ein paar hundert Zeilen ruckelt beim Scrollen — wie gehst du vor?

Erst profilen — der Flipper-/React-DevTools-Profiler oder der eingebaute Perf-Monitor zeigt, ob die Kosten in JS liegen (Re-Renders, schweres renderItem) oder im nativen Thread (Layout, Bilder). Dann die Basics prüfen: stabiler keyExtractor, React.memo auf der Row, damit eine State-Änderung des Parents nicht in jede Zeile kaskadiert, und keine inline Arrow-Functions oder Objekt-Literale als Props der Row. Wenn Layout-Thrash das Problem ist, spart getItemLayout einen Messdurchlauf pro Item, und wenn die Liste selbst bei großem Umfang der Flaschenhals ist, ist der Wechsel zu FlashList oft der pragmatischere Fix, statt FlatList noch weiter von Hand zu tunen.

Ein Feature braucht eine Fähigkeit, die React Native nicht anbietet — wie kommst du an nativen Code, und was muss dupliziert werden?

Du schreibst ein natives Modul — eine Swift/Objective-C-Implementierung für iOS und eine Kotlin/Java-Implementierung für Android — mit derselben Methodensignatur auf beiden Seiten, weil JS eine einzige JS-seitige API aufruft, die sich in eine echte Implementierung auf der jeweils laufenden Plattform auflösen muss. Eine Plattform auszulassen bedeutet, dass die App dort abstürzt oder still nichts tut, weshalb beide Implementierungen wirklich dasselbe tun müssen, nicht nur denselben Namen tragen. Testen heißt, auf einem echten Gerät oder Simulator pro Plattform zu laufen, nicht nur darauf zu vertrauen, dass "es gebaut hat".

Wie behandelst du Deep Links zuverlässig, einschließlich Cold Start?

Registriere das URL-Schema oder den Universal Link/App Link in der nativen Config (Info.plist / AndroidManifest.xml) und in der linking-Config des Navigators, indem du URL-Muster auf Screens und Parameter mappst. Der schwierige Teil ist der Cold Start — wenn die App nicht lief, muss Linking.getInitialURL() beim Start geprüft und für den initialen Navigationszustand genutzt werden, weil der Linking-Event-Listener allein nur Links fängt, die eintreffen, während die App schon offen ist. Universal Links brauchen zusätzlich die associated-domains-/assetlinks.json-Dateien auf deiner Domain, damit das OS der App vertraut, diese URL zu behandeln, statt einen Browser zu öffnen.

Was ist der Unterschied zwischen einem OTA-Update und einem Store-Release, und wann nutzt du welches?

Ein OTA-Update (CodePush, Expo Updates) pusht ein neues JS-Bundle direkt auf installierte Apps, ohne App-Store-Review, und Nutzer bekommen es beim nächsten App-Start oder einem Background-Check — gut für reine JS-Bugfixes und Content-Änderungen. Alles, was nativen Code betrifft — ein neues natives Modul, eine hinzugefügte Permission, ein Bump einer nativen Dependency — steckt gar nicht im JS-Bundle, deshalb kann OTA es nicht ausliefern; es braucht einen echten Build und eine Store-Einreichung. Apples Guidelines beschränken OTA ausdrücklich darauf, "den primären Zweck der App nicht wesentlich zu verändern", weshalb ein Team, das sich über schnelle Fixes hinaus auf OTA verlässt, den Store-Account riskiert, nicht nur das Update.