Nitro-Module: Wie statische Bindungen React Native TurboModules übertrifft
Erklärt, wie Nitro Modules statische Vorkompilierungen statt dynamischer Abfragen verwenden, um in React Native deutlich bessere Leistungen als TurboModules und Expo Modules zu erbringen.
TurboModules sollten die Lösung sein. Sie ersetzten die veraltete Brückenarchitektur, beseitigten unnötige Overhead-Kosten und etablierten sich als gängiger Ansatz für die Erstellung von Native-Code, der mit JavaScript kommuniziert. Dann kam eine neuere Bibliothek namens Nitro Modules und ließ diese „endgültige Lösung“ veraltet erscheinen.
Veröffentlichte Benchmarks zeigen, dass bei Tests derselben synchronen Funktionsaufrufe Nitro Modules bis zu 59 Mal leistungsfähiger sein können als Expo Modules und etwa 15 Mal schneller als TurboModules. Selbst bei der Verarbeitung von Zeichenketten, die in der Regel zusätzlichen Overhead verursachen, wenn zwischen JavaScript und nativem Code gewechselt wird, hält Nitro weiterhin einen Vorsprung von 5 bis 13 Mal. Bei der Übertragung größerer Datenmengen wie Bilder oder Rohpuffer erreicht Nitro dank eines Zero-Copy-Ansatzes, der das Duplizieren von Daten im Speicher vermeidet, einen weiteren Leistungszuwachs von 8 bis 40 Prozent.
Eine derartige Leistungsdifferenz erfordert eine Erklärung. Was genau tut Nitro im Hintergrund – und warum tauchte dieses Design nicht früher auf?
Das Problem, das niemand sonst gelöst hatte
Nitro wurde nicht als Vergleichsübung konzipiert. Es entstand aus der Arbeit von Marc Rousavy, dem Schöpfer von VisionCamera, als Reaktion auf eine sehr konkrete Einschränkung: Weder TurboModules noch Expo Modules konnten die Frameverarbeitung ordnungsgemäß unterstützen.
Betrachten Sie ein einzelnes Kamerabild in VisionCamera als eine Art 10-Megabyte-Puffer. Dieser Puffer kann nicht über die Brücke übertragen werden, selbst mit TurboModules nicht, und er passt auch nicht in eine einfache JSON-ähnliche Struktur. Was Rousavy tatsächlich brauchte, war eine Möglichkeit, ein komplexes, zustandsbasiertes natives Objekt, das in C++ oder Swift geschrieben ist, direkt an JavaScript weiterzugeben – inklusive funktionierender Methoden und Eigenschaften. TurboModules verfügten über kein Mechanismus für solche Objekte.
Nitro wurde daher speziell entwickelt, um das möglich zu machen, und die erheblichen Geschwindigkeitsvorteile erwiesen sich als Bonus, der letztendlich weitaus mehr Aufmerksamkeit erregte als das ursprüngliche Problem, das es löste.
Eine einzige architektonische Entscheidung
Der eigentliche Unterschied zwischen TurboModules und Nitro lässt sich auf eine einzige Designentscheidung zurückführen: wie jedes System ein natives Objekt darstellt, sobald es sich im JavaScript-Engine befindet.
TurboModules setzen auf jsi::HostObject. Immer dann, wenn JavaScript-Code eine Eigenschaft abruft oder eine Methode auf einem dieser Objekte aufruft, muss die Laufzeit diesen Zugriff dynamisch und sofort lösen. Diese Abfrage findet bei jedem einzelnen Aufruf statt, und dieser wiederholte Aufwand summiert sich schnell für Module, die häufig aufgerufen werden.
Nitro wählt einen anderen Ansatz und verwendet jsi::NativeState. In Kombination mit einem Codegenerierungswerkzeug namens Nitrogen werden alle notwendigen C++, Swift- oder Kotlin-Bindings im Voraus erstellt, noch bevor die Anwendung ausgeführt wird. Im Laufzeitbetrieb wird nichts dynamisch gelöst. Die Umwandlung zwischen JavaScript und nativen Typen erfolgt statisch im Voraus kompiliert, wodurch der Aufruf eines Nitro-Moduls eher wie der Aufruf einer gewöhnlichen Funktion wirkt als wie ein Übergang über eine Laufzeitbrücke.
Diese Veränderung – vorkompilierte statische Bindungen anstelle dynamischer Laufzeitabfragen – erklärt den größten Teil der Leistungsunterschiede, die in den Benchmarks zu beobachten sind.
In Nitro wird jedes native Objekt, unabhängig davon, ob es in C++, Swift oder Kotlin geschrieben ist, als Hybrid Object bezeichnet. Nitrogen analysiert eine TypeScript-Interface-Definition und erzeugt automatisch den erforderlichen Code, um dieses Objekt über die Grenze zwischen JS und nativen Sprachen zu bewegen – einschließlich der Handhabung von Enums, Unions und Strukturen. Gerade diese Werkzeuge ermöglichten es Rousavy, etwas so Unkonventionelles wie ein Live-Kamerabild ohne das manuelle Schreiben separaten Brückencodes für jede der drei Plattformen zur Verfügung zu stellen.
Warum dies über eine einfache Bibliothek hinausgeht
VisionCamera diente als erster Beweis dafür, dass dieser Ansatz funktionierte, doch das Design von Nitro war nie dazu bestimmt, eine einmalige Lösung für einen einzigen Anwendungsfall zu bleiben. Seine Architektur bietet jedem nativen Modul eine integrierte Unterstützung für Array-Puffer, Zustandsobjekte sowie direkte C++-Interoperabilität – Fähigkeiten, die bei den vorherigen Ansätzen bestenfalls unpraktisch oder völlig unbrauchbar waren.
Das umfangreichere React Native-Ecosystem beginnt, dies zu bemerken. Projekte wie react-native-nitro-cache sowie Tools für das Bildcaching, maschinelles Lernen und Spiel Engines werden speziell auf Basis von Nitro neu entwickelt, um die Überheadkosten bei der Umwandlung von JavaScript in natives Code im Bereich zu verringern, wo Leistung am wichtigsten ist. Dies spiegelt eine bereits im Gange befindliche größere Entwicklung in React Native wider, bei der grundlegende Bibliotheken um die Neue Architektur herum neu strukturiert werden, anstatt sie als etwas zu betrachten, das später optional eingeführt werden kann. Die Adoption von Nitro hinkt immer noch stark hinter TurboModules zurück, das weiterhin die Standardwahl für die meisten Bibliotheken bleibt, doch der Trend ist unverkennbar. Wo Rohleistung im Vordergrund steht, wird Nitro zunehmend zum ersten Werkzeug, auf das Entwickler zurückgreifen.
Was dies für Autoren von nativen Modulen bedeutet
Falls Sie derzeit ein natives Modul betreiben, verdient dieser Wandel Ihre Aufmerksamkeit. TurboModules werden vorerst nicht verschwinden, und bei einfachen Modulen wird der Leistungsunterschied für Endbenutzer wahrscheinlich nicht bemerkbar sein. Sollte Ihr Modul jedoch leistungsintensive Aufgaben, eine hohe Aufrufhäufigkeit, große Datenvolumina oder Objekte beinhalten, die sich nicht eindeutig in JSON darstellen lassen, ist Nitro jetzt sehr wahrscheinlich die bessere Grundlage für die Entwicklung.
Die Entscheidung, im Jahr 2026 ein völlig neues natives Modul in TurboModules zu entwickeln, bedeutet im Grunde, auf einer Architektur aufzubauen, die bereits von einer schnelleren und weiter wachsenden Alternative übertroffen wurde. Nitros Codegenerator übernimmt automatisch weitaus mehr der repetitiven Aufgaben auf allen drei Plattformen gleichzeitig, wodurch das Ergebnis schneller läuft und weniger manuell geschriebener Native-Code zur Wartung erforderlich ist. Für Teams, die bereits ein TurboModule besitzen, ist eine Migration kein einfacher Schalterumschlag, doch genau die gleichen Leistungsvergleichsergebnisse, die Nitro attraktiv machen, liefern auch starke Gründe dafür, diese Migration so früh wie möglich durchzuführen.
React Native hat bereits mehrere echte architektonische Wendepunkte erlebt: den Rückzug der alten Architektur, die Einführung der neuen Architektur und nun diesen weiteren Schritt. Nitro entstand nicht aufgrund einer offiziellen Anweisung von Meta, sondern weil ein Entwickler eine Funktion benötigte, die TurboModules einfach nicht bieten konnten; er entwickelte die Lösung öffentlich und ließ die daraus resultierenden Leistungsvergleiche für sich sprechen.
Verwandte Artikel
- React Native, Flutter und mehr: Cross-Platform-Mobilentwicklung im Jahr 2026 — Ein vergleichender Überblick über React Native, Flutter, Kotlin Multiplatform, Ionic, NativeScript und PWA hinsichtlich Leistung, Entwicklererfahrung und Reifegrad des Ökosystems.