Profiling React Native on Android with System Tracing

WHY IT EXISTS: Android runs on thousands of different devices, so UI performance isn't always guaranteed. When animations stutter or interactions feel slow (known as "jank"), it's because a frame took longer than the 16ms budget to render. System Tracing was created to answer the fundamental question: where is that time being spent?

THE MENTAL MODEL: Think of System Tracing like a musical score for your app's performance. Each thread is an instrument, and the trace shows what each one is "playing" over time. You're looking for the instrument that's out of sync and causing the whole orchestra to lag, pushing a frame past its 16ms deadline.

HOW IT WORKS: First, ensure Development Mode is off. Then, you connect your device and run your app as "profileable" from Android Studio. In the profiler, you start a "Capture System Activities" task, perform the laggy interaction in your app, and then stop the recording. This generates a detailed trace file you can inspect in Android Studio or a tool like Perfetto.

WHEN TO USE IT: Use System Tracing whenever you observe stuttering, dropped frames, or slow animations in your React Native Android app. It's the primary tool for diagnosing UI performance bottlenecks that might originate from the JavaScript thread, the native UI thread, or native modules.

WHEN NOT TO USE IT: Do not use this tool with Development Mode enabled; the extra overhead will pollute your results and lead to incorrect conclusions. It is also not the right tool for debugging pure JavaScript logic errors that don't impact the UI thread. For those, a standard JS debugger is more appropriate.

ONE CANONICAL EXAMPLE: To find a culprit for jank, you open a trace and enable VSync highlighting to see the 16ms frame boundaries. You then find your app's process and focus on three key threads. First, the UI Thread, where Android's standard measure and layout work happens. Second, the JS Thread (often named mqt_js), where your React code executes. Third, the Native Modules Thread (mqt_native_modules), where native code is run. If you see a long-running task on any of these threads that crosses a 16ms boundary, you have found a likely source of your performance issue.