React Native Performance-Profiling
React Native Performance-Profiling
~14 Min. Lesezeit Zuletzt aktualisiert am 8. August 2026
Genau wie in "React für Profis" gilt: erst MESSEN, dann optimieren. React Native bringt dafür eigene, plattformspezifische Werkzeuge mit, die über die reinen React DevTools hinausgehen – sie zeigen auch, was auf dem NATIVE- und dem Shadow-Thread passiert (siehe "React Native Referenz"-Serie, Thema "Threads", für die Grundlagen dieser Drei-Thread-Architektur).
Der eingebaute Performance-Monitor
Öffnen Sie das Entwickler-Menü (Gerät schütteln, oder Cmd+D/Cmd+M im Simulator/Emulator) und wählen Sie "Show Perf Monitor". Ein kleines Overlay zeigt live die JS-Framerate und die UI-Framerate GETRENNT – GENAU diese Trennung macht sichtbar, was "React für Profis" Kapitel 35 (Fiber, Render- vs. Commit-Phase) konzeptionell erklärt hat: der JS-Thread kann langsam sein, während native Animationen auf dem UI-Thread trotzdem flüssig bei 60 fps laufen (und umgekehrt).
React DevTools Profiler – identisch zu React für Profis
Der React DevTools Profiler aus "React für Profis" Kapitel 30 funktioniert IDENTISCH in React Native – dieselbe Flame-Chart-Ansicht, dieselbe "Why did this render"-Funktion. Verbinden Sie die App über npx react-devtools in einem separaten Terminal-Fenster (statt der Browser-Erweiterung, da React Native keinen Browser hat).
npx react-devtoolsStarten Sie danach die App normal (npx expo start) – die eigenständige DevTools-App verbindet sich automatisch und zeigt denselben "⚛️ Profiler"-Tab wie im Browser.
Flipper und das neue "React Native DevTools"
Flipper war lange das Standard-Debugging-Tool für React Native (Netzwerk-Inspektor, Layout-Inspektor, Log-Viewer, alles in EINER Desktop-App) – seit React Native 0.73 wird es zunehmend durch die INTEGRIERTEN React Native DevTools ersetzt (direkt über das Entwickler-Menü erreichbar, "Open DevTools"), die auf demselben Chrome-DevTools-Protokoll wie Web-Debugging basieren. Für neue Projekte empfiehlt sich der integrierte Weg; Flipper bleibt für ältere Projekte relevant.
Praxis: den RenderCounter aus "React für Profis" wiederverwenden
Das Muster aus "React für Profis" Kapitel 27 funktioniert unverändert in React Native – useRef zum Zählen von Renders ohne selbst welche auszulösen:
import { useRef } from 'react';
import { Text } from 'react-native';
function RenderCounter({ label }) {
const renderCount = useRef(0);
renderCount.current += 1;
return (
<Text style={{ fontSize: 10, opacity: 0.5 }}>
???? {label}: {renderCount.current}×
</Text>
);
}
export default RenderCounter;Fügen Sie <RenderCounter label="ProductCard" /> testweise in ProductCard ein und favorisieren Sie ein Produkt in ProductListScreen: Sie werden sehen, dass ALLE sichtbaren ProductCard-Instanzen neu rendern, nicht nur die angeklickte – useSelector liefert bei JEDER toggleFavorite-Aktion ein NEUES favoriteSkus-Array (Kapitel 3), wodurch favoriteSkus.includes(item.sku) für JEDE Karte neu ausgewertet wird UND (ohne React.memo, siehe nächstes Kapitel) jede Karte neu rendert, selbst wenn sich ihr EIGENES isFavorite-Ergebnis gar nicht geändert hat.
Bonus: den JavaScript-Bundle inspizieren
npx expo export erzeugt einen produktionsnahen Export inklusive JS-Bundle – nützlich, um VOR einem echten Store-Release zu prüfen, wie groß das JavaScript-Bundle tatsächlich ist (siehe "React für Profis" Kapitel 46 für die Bundle-Analyse-Technik mit rollup-plugin-visualizer, für Expo/Metro gibt es das analoge Werkzeug source-map-explorer).
Tipp: Faustregel: bevor Sie IRGENDEINE Optimierung aus den nächsten drei Kapiteln (FlatList, Hermes, Bilder) anwenden, messen Sie ZUERST mit dem Perf Monitor UND dem React DevTools Profiler, WELCHER Thread/WELCHE Komponente tatsächlich das Problem ist. Eine ruckelnde FlatList braucht eine andere Lösung als eine langsame JS-Berechnung – beides "fühlt sich langsam an", aber die Ursachen UND Lösungen unterscheiden sich fundamental.