Profiling: Finding Jank, Bridge Traffic and Memory Leaks

A screen that renders correctly and a screen that feels good to use are not the same achievement. An app can pass every functional test and still make a user's thumb feel like it is dragging a list through wet sand, because correctness and smoothness are measured by completely different instruments. Smoothness is measured in dropped frames, and dropped frames are invisible to a developer who only ever checks whether the data on screen is right — they show up as a stutter on a mid-range device under real load, not as a failing assertion in a test suite.

This is why profiling is a distinct discipline from debugging. Debugging asks whether the code is correct; profiling asks where the code is spending time and memory, and whether that spending is visible to the user as a missed frame, a laggy gesture, or a process the operating system eventually kills for using too much memory. A React Native app has three places that time can disappear — the JavaScript thread, the native UI thread, and, in the older architecture, the serialization layer between them — and a jank symptom that looks identical on screen can trace back to completely different causes in each of those three places.

Skipping profiling and guessing at a fix is expensive twice over: the guess is frequently wrong, because intuition about where JavaScript time goes is unreliable even for experienced engineers, and a wrong fix adds complexity to the codebase without removing the actual bottleneck, which is still there waiting to reappear on the next device that is slightly slower than the one the fix was tested on.

Analogy🏏Cricket

🏏 Think of it like cricket: A team's fielding coach does not decide a player is slow between the wickets by watching one run from the stands and guessing. The coach times the actual sprint with a stopwatch, splits it into the reaction to the call, the acceleration phase, and the dive at the crease, and only then knows whether the fix is footwork, reaction time, or simply calling the run later. Rohit Sharma's teams have had fielding coaches do exactly this kind of split-timing work during training camps, because a player who looks slow on television might actually have a fast sprint and a slow reaction to the call, and those need entirely different drills to fix. Just as timing the actual sprint tells the coach which phase of the run is costing time, profiling a screen tells an engineer which thread — JavaScript, native UI, or the bridge between them — is actually costing the missed frame. Just as guessing that a player 'needs more fitness work' without splitting the run risks fixing the wrong phase entirely, guessing that a jank symptom needs 'more memoization' without profiling risks patching a component that was never the bottleneck. The insight is that a symptom visible from the outside — a slow run, a stuttering scroll — always has a specific, measurable cause inside, and the fix is only correct once that specific cause is found, not assumed.