Optimizations in React Native

I've observed that we frequently overlook relatively simple React component performance optimizations. I'll review a few quick solutions to fundamental performance issues in this piece. Let's get started.

When rendering a long list, FlatList is the go-to tool. However, there are some performance issues even though it offers excellent control via the removedClippedSubviews, maxToRenderPerBatch, windowSize and getItemLayout props.

But look no further because here comes the rescue!

FlatList and FlashList seem similar and have similar syntax. If you are familiar with the FlatList properties, there won't be many changes.

Do you see how simple that is?

FlashList uses this estimatedItemSize to compute how many items should be drawn on screen before the initial load and when scrolling.

How does it work? Well, instead of destroying the component when an item gets out of the viewport, FlashList re-renders the same component with different item props. Another thing to keep in mind while using FlashList is to avoid adding key props to the item component, which React recommends. It will prohibit views from being recycled, negating all of the advantages of FlatList.

We have a Parent component that has a Child component in the code snippet below. To keep this article brief, I will not discuss how the Child component is constructed. Instead, we must suppose that our Child component is large and resource intensive. As a result, we must exercise caution in how we approach a few issues. Let's start with the code:

Everything looks fine, right?

Not really; we are missing something fundamental here.

Because the Child component is expensive, we don't want it to have unnecessary re-renders. What are we going to do about it, then? Yes, you guessed it, we will use React.memo(). Now, we are wrapping our Child component with memo that will return a memoized React component, allowing us to use the memoized child component in our Parent component.

Because our heavy component is now memoized, we may anticipate the Child component to not re-render excessively; however, that is not the case. Why?

It is because React.memo() compares props shallowly, and we are supplying an update function as props, which will have a new reference on each re-render of the Parent component. To avoid this, we must also memoize the function. Previously we were passing a function directly as props. But now we are wrapping the same function with useCallback, which will return a memoized function. It's reference would not change across re-renders of the Parent component.

This will help our memo to compare and prevent further re-rendering of the Child component.

The component and the function have both been memoized. A quick visual comparison will help you understand better. Carefully notice the console logs.

without any memoization

As you can see, when the state of the Parent component changes, the Child component also renders

with memoization

Only the Parent component is now rendered on each state update.

Too many large picture assets can raise the size of the app bundle, and the time it takes to load such images. Images in jpeg and png formats can be rather large. We may use webp instead. The following are some advantages:

• Reduces image size by 25-34%
• Supports both lossy and lossless compression modes
• Supported on Android 4.2.1 or higher
• Supported on iOS 14 or higher

If you're familiar with browser caching, you'll know that after an asset is downloaded, it may be cached locally for a set period. Until then, successive requests to the same URL will not retrieve the asset from the server but will be served from the cache. This aids in the faster loading of materials from frequently visited pages.

To achieve similar caching on both Android and iOS, we can use this excellent package.

react-native-fast-image

• Fairly simple API
• Have priority options
• Supports preload
• Supports memory and disk cache clearance features

Here is an essential component for rendering an image with FastImage. We must provide a URL, a priority, and any necessary headers. And, of course, the image size. That is sufficient to have a cached image component.

You can even preload some images before you visit the next screen.

Hermes is an open-source JavaScript engine created to ramp up app launch time. It's pretty simple to use and is the default engine in react-native v0.70. Hermes comes with this set of features:-

Adapting Trash Collection

Improved garbage collection processes that prevent the operating system from terminating the app due to inadequate memory on low-end devices. A few examples of garbage collection techniques are:

Replacing JIT (just-in-time) Compiler with AOT (ahead-of-time) Compiler

Significantly reduces load time. JIT parses and compiles code at runtime to begin execution. This causes delays when loading. In AOT, both parsing and compilation are shifted to the build process. This means both jobs will be performed while developing the app. Yes, it will lengthen the build time, but it is still better than a slower load time.

Precompiling Source Code into Bytecode

A Javascript engine will parse the source after it is loaded, generating bytecode. This step delays the execution process. Precompiling source code into bytecode during build time helps in improving the load time by a greater margin.

Setting up Hermes is very simple. This is how you can enable Hermes

This is what we get after enabling Hermes.

In our component, we must avoid using inline styles. Because these inline styles send new object references on each re-render, they can impact performance.

In this code, we pass objects directly in the JSX styles.

Instead, we must use StyleSheet Object and send a reference to it to the styles prop. Now on each re-render, a new object won't be created. The same reference will be passed.

A large app size might also be an issue, especially for low-end Android devices. However, there are techniques to reduce its size dramatically.

Android App Bundle (.aab)

Instead of creating a universal apk to support all the CPU architectures, such as armeabi-v7a, arm64-v8a, x86, x86_64, we can generate a .aab file.

An app with just a single page and text will be around 25MB for it’s .apk file. A .aab file for the same would be around 3MB. These two lines of syntax can help you achieve that!

Enable Resource Shrinking

As the name suggests, resource shrinking categorizes and removes unnecessary resources. Make this change in the android/app/build.gradle file.

Enable Proguard

Proguard helps in obfuscating our code, which makes reverse engineering of our bundle more difficult. Apart from that, it also helps in reducing the app size.

To enable proguard, set the following in android/app/build.gradle file to true.

Add your proguard rules in android/app/proguard-rules.pro file. Here is a preview of the same.

Using this tool, we can determine the bundle size of each package in our application. The bundle visualiser shows which package uses the most space in our bundle. You wouldn't want to send the client a bulky package; therefore, perhaps there's a better way for the same package that doesn't add as much code to the bundle.

We have an excellent tool for that in react-native-bundle-visualizer which is very easy to integrate and run.

The information above makes it apparent which module is occupying the most space. Once you've located the largest bundle, you may determine whether or not to replace it by looking attentively.

Console.log() is used a lot. According to statistics, we utilise console.log() more than debugger. But why is that the case? Well, in production, too many console statements can lead to poor performance.

Should we abandon the console statement entirely? Not really, instead, we have a plugin that can remove all of our console statements from the production build. What a fantastic idea!!!

We can use this babel plugin babel-plugin-transform-remove-console

Installation

Babel configuration file

To maintain a better watch of our apps, we need a tool that can offer better insights and data. Such instruments are accessible to us. Here are a few examples:

• Sentry.io
• Firebase performance monitor
• React-native-performance-monitor
• Instabug

In this section, I'll be showing you an example of Firebase performance monitoring. We can use this React Native Firebase module. The installation and configuration can be found at the aforementioned URL. It's quite basic.

Let's take a look at the analytics board in the Firebase console.

This data pertains to an API endpoint utilised in the app. We can observe that it is 4% slower than it was 7 days ago. This level of detail can assist you in guiding and pinpointing the source of the problem.

We learned that a few simple tools and a different approach of coding may significantly improve our performance. We can use the majority of these from the start of our development. It might be tough to resolve key performance concerns, but to proceed with the best remedy, we must first identify the problem at its root. These instruments will undoubtedly provide us with some advantages.

Would love to learn about any additional helpful tools from you guys.