Streaming accelerometer data without bridge overload
High-frequency data on the bridge.
the bottleneck is flooding the async bridge and re-rendering at sensor rate; fix by throttling, processing in worklets or native, and animating via shared values not setState.
What's really being asked
Whether you recognize that a sensor emitting at high frequency will saturate the JS bridge and the React render loop, and that the cure is to keep per-frame work off the JS thread.
The full answer
The primary bottleneck is twofold: the asynchronous bridge serializing hundreds of samples per second from native to JS, and React re-rendering the component on every sample if you naively push each into state. Both starve the JS thread and drop frames. The architecture should minimize and offload. First, reduce the data rate: set the sensor's update interval sensibly and downsample or throttle. Second, move the per-frame work off the JS thread: with Reanimated you read the sensor through its sensor API or feed values into shared values and compute the visual in a useAnimatedStyle worklet, so the UI updates on the UI thread without JS round trips or re-renders. Alternatively, do filtering and aggregation natively and emit only summarized events. You reserve React state for low-frequency, meaningful changes, not raw samples. This keeps the animation smooth even while the JS thread does other work.
The mistakes people make
Calling setState on every accelerometer reading, causing a re-render storm. Letting all raw samples cross the bridge untouched. Trying to fix jank purely by memoizing components while still re-rendering per sample. Animating with the legacy Animated API plus JS event handling, which still hits the bridge each frame. Ignoring the sensor's configurable sampling rate.
What usually comes next
How do shared values avoid re-renders, how would the new architecture and JSI change the bridge picture, when do you push filtering into native code, and how do you decide a sampling rate.
A concrete example
A bubble level that tilts with the device: instead of subscribing in JS and setState-ing each reading, you write the accelerometer values into Reanimated shared values (or use its useAnimatedSensor), then a useAnimatedStyle worklet maps tilt to a transform on the UI thread. The indicator tracks motion at 60 frames per second with zero React re-renders, and only a derived event, like crossing a threshold, is sent to JS to update visible state.
Interview question
An accelerometer view janks badly. Which architectural change most directly removes the bottleneck while keeping the indicator smooth?
- a.Feed sensor values into shared values and animate via a useAnimatedStyle worklet on the UI thread, instead of setState per sampleCorrect
- b.Move the setState calls into a useEffect to batch them
- c.Wrap the component in React.memo so it re-renders less often
- d.Increase the sensor sampling rate so updates are more granular
Why? this is the answer
Driving the visual from shared values in a worklet keeps per-frame work off the JS thread and avoids re-renders entirely. React.memo still re-renders on each state change, raising the rate worsens it, and batching setState does not stop the render storm.
Just read this? Test yourself on what you have been reading.
Read the original → reactnative.dev
- #react-native
- #performance
- #bridge
- #sensors
- #reanimated
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react-native — each one lists the topics its interview covers.
See open roles