Debugging RN Android Performance

Hi everyone. I'm Alex. I'm excited to talk to you at React Summit. I'm a take lead at BAM and we're a company based in Paris. We develop mobile apps in Kotlin, Swift, Flutter and of course React Native.

Today I want to talk to you about the performance of React Native apps. Now one of the key metrics to analyze the performance of your app is the frame rate. You want your app to run at 60 frames per second. One of the good things that come with React Native out of the box is this tool. The performance monitor. You get the frame rates of the UI thread and also of the JS thread.

So now one of the issues we're facing in our app is the UI thread rate was consistently low after starting the app even when the user was doing absolutely nothing. The question was how to find out what is actually happening under the hood. And the solution to that was Systrace. Systrace is short for System Trace. It's available out of the box on the Android SDK in the Platform Tools folder. Essentially, it's a script so you can connect your app to the computer and you just start the script, you do some stuff on your app, you stop the script and it will print out a huge HTML file, a trace file. You can open that file in Chrome and when you open it, it looks like this. Wow. It is daunting, right? Very colorful, but quite daunting.

The first thing you want to do is on the left side, you want to find your app. In my case, my bundle ID was myapp.debug so this is where I found it. And then below it, since we're talking about frame rates, what is really interesting is the frames line. If you zoom in a little bit, on the frames line, you will notice a lot of Fs. There are red Fs, yellow Fs, and green Fs. You might guess that a red F is bad and a green F is good. Indeed, a green F is actually a frame that was able to be calculated under 16 milliseconds that the app can actually run at 60 frames per second. Yellow Fs and red Fs not so much. So if you're trying to analyze performance issues, you want to take a look at sources of red Fs and yellow Fs. In our app, we actually had two major sources of red Fs.

Let's take a look at the first one. If we zoom in on a single frame, this is about 20 milliseconds of time, and we can see our friend, the UI thread. So this is what was actually reported in the performance monitor, right? We can see that actually on a single frame, it's doing a lot of calculations, so it's not able to fit in the 16 milliseconds set of time. So now the question is, what is it actually doing? So we can take a look. We can actually click inside, and we can see a bit more details, but it's very low level. For example, we see that we have a draw function that is taking a lot of time, but this is the OS basically redrawing stuff. So something is actually needed to be redrawn, and it takes a lot of time, but we don't really know what it is. We can actually scroll down a little bit and find the render thread. The render thread is running on the GPU, and it runs expensive calculation on the GPU, and on this one we're a bit luckier, because see here, we have actually something about Lottie animation view. Now, Lottie is an animation framework, and we actually had a Lottie animation at the start of our app, and we found out that it needed to be optimized, and that was the performance issue. So that's one performance issue solved, one issue to go. Let's look at the second one.