What is bridge traffic and what causes dropped frames?
understanding the legacy async bridge.
the bridge passes batched, serialized JSON messages between JS and native asynchronously; high-frequency events flood it.
WHAT THIS TESTS: A clear mental model of the legacy bridge and why it became React Native's primary performance bottleneck.
A GOOD ANSWER COVERS: In the legacy architecture, JavaScript and native code run on separate threads and cannot share memory or call each other directly. They communicate over an asynchronous bridge that serializes every message into JSON, batches messages, and passes them across the thread boundary. Bridge traffic is the total volume of these serialized messages. Because the channel is async and serialization has cost, a flood of messages queues up, so native and JS fall out of sync and frames are missed. The danger is high-frequency, per-frame communication.
COMMON WRONG ANSWERS: Describing the bridge as a synchronous function call. Saying JS and native share memory. Believing batching eliminates cost; batching only amortizes scheduling, not serialization. Confusing bridge traffic with network traffic.
LIKELY FOLLOW-UPS: How the new architecture and JSI remove serialization, what useNativeDriver does for animations, why large initial prop payloads also count as traffic, and how to measure bridge saturation.
ONE CONCRETE EXAMPLE: An animation that ties a value to scroll position by reading onScroll in JS and writing a transform back sends two serialized messages every frame. At sixty frames per second on a busy thread, the queue backs up and the animation stutters. Driving the same animation with the native driver keeps the values on the native side, eliminating per-frame bridge crossings and restoring smoothness.
Read the original → reactnative.dev
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.