rn-performance

Performance triage

Two rules before touching code

1. Profile release builds. Dev mode runs a different engine configuration with dev-only checks; its performance characteristics are fiction. npx expo run:ios --configuration Release or npx expo run:android --variant release before believing any measurement.
2. Name the thread. Everything slow is one of: JS thread saturated, UI thread saturated, or waiting on IO. The fix lives on the thread that is busy, and the profiler tells you which one it is; guessing does not.

Lists

• Long scrollable content belongs in FlashList (or at minimum FlatList), never a ScrollView with .map(). ScrollView mounts everything immediately; past a few dozen items that is the entire problem.
• renderItem must be a stable component reference, not an inline closure creating new component trees per render. Extract it, memo it, and keep item props primitive where possible.
• keyExtractor must return stable ids. Index keys plus insertions equals recycled rows showing the wrong content and pointless re-renders.
• Images inside rows: fixed dimensions, a recycling-aware image component, and correctly sized source assets. Decoding a 4000px image into a 80px avatar slot burns CPU and memory for nothing.
• Measure list health with the blank-area metric while scrolling fast, and by watching JS FPS in the perf monitor, not by feel on a simulator. Simulators lie in both directions.

Re-renders

• Subscribe narrowly. With zustand and friends, select the smallest slice (useStore(s => s.count)), never the whole store object. With context, split fast-changing values out of the provider that wraps the world.
• memo the expensive leaves (list rows, chart bodies, anything with heavy trees), then make sure their props are actually stable, because memo with a fresh object or closure prop every render is a no-op with extra steps.
• useCallback and useMemo are for identity stability where a memoized child or an effect depends on it, not decoration for every function in the file.
• To find offenders, use the React DevTools profiler and look for wide flame bars re-rendering on interactions that should be local. One misplaced subscription at the screen root regularly accounts for the whole problem.