Skip to main content

Rendering Performance Evaluation - Android SDK vs React Native

UI rendering speed has always been a key factor in evaluating a new technology. The lower the rendering time, the more preferable the technology. In recent times, React Native has become very popular for developing native apps. Such apps are truly native and significantly different from other similar technologies like Xamarin and Cordova. I recently had some time to evaluate how React Native compares to the Android SDK.

TLDR: As you might expect, the Android SDK outperforms React Native by a significant margin. However, React Native technology is slowly catching up (most of the credit goes to the amazing diff rendering technology, which forms the core of React). React Native is efficient enough for apps with a small number of UI components that can be rendered within a reasonable time.

Performance Comparison

Emulator

Model - Google Pixel 2
API Level - 24
Resolution - 1080 x 1920 (420 dpi)
CPU - x86
Target - Android 7.0
RAM - 1536 MB

Evaluation Criteria

We will be creating a large number of text views for evaluating the performance of the Android SDK and React Native. These text views are very simple and do not contain more than 17 characters.

Code

Let's jump to the code for Android SDK.

So, we have a text box where you can enter the number of text views to be rendered. When the button is clicked, it displays the rendered text views along with the time taken for rendering. Remember that every time you click the button, all the text views are being re-created.

Here is the output produced:

Time taken: 1.366
Sample Text: 0
Sample Text: 1
Sample Text: 2
...

Let's look at an equivalent code in React Native.

Don't worry if the code looks unfamiliar. The code is written in TypeScript, which compiles down to JavaScript. Remember that componentDidUpdate() is called whenever the component is re-rendered, i.e., whenever the state of the app is updated. To make the code only evaluate the creation of text views, we have a special state called evaluateViewRendering which is set to true only when the views (containing an array of text views) changes. The UI is similar to the one developed on the Android SDK. Here is the output generated:

Time taken: 0.913
Sample Text: 0
Sample Text: 1
Sample Text: 2
...

Note that you need to reload the entire React Native app each time before the input can be made. This is because React Native makes use of diff rendering to render only the changed content, i.e., only the updated views are created, and not everything.

The following figure shows the rendering time of the two apps:

Chart showing the time taken by Android SDK and React native app

As one can see, there is a huge disparity between the rendering times of the Android SDK and React Native. React Native is at least 30 times slower than the Android SDK when compared directly. This was expected as React Native translates the components into Android native components at runtime.

Diffing Performance Comparison

Based on the previous evaluation, one might deduce that React Native has a very large rendering time and should therefore not be preferred over the Android SDK. However, we are missing out on a very important part of the React framework: the diff calculation of components that have actually changed. In a user interface, the rendering time of updates (how quickly updates are rendered to the UI) is even more crucial.

To conduct a more accurate evaluation, we are going to make some minor changes to the code. We will no longer use an input from the user. Instead, we will render 10,000 text views in chunks of 1000.

Here are the Android SDK and React Native implementations of the same.

As one can see in the code above, we are calculating the time taken to add 1000 text views to the UI. In the case of React Native, we are adding 1000 text views and then updating the state to reflect the change.

Here is the output produced by the Android code:

Time taken: 0.048
Time taken: 0.042
Time taken: 0.045
Time taken: 0.04
Time taken: 0.046
Time taken: 0.039
Time taken: 0.043
Time taken: 0.046
Time taken: 0.042
Time taken: 0.044

Sample Text: 0
Sample Text: 1
Sample Text: 2
...

Here is the output produced by the React Native code:

Time taken: 1.31
Time taken: 1.626
Time taken: 1.619
Time taken: 1.577
Time taken: 1.618
Time taken: 1.761
Time taken: 1.678
Time taken: 1.773
Time taken: 1.923
Time taken: 2.001

Sample Text: 0
Sample Text: 1
Sample Text: 2
...

As one can see, the update rendering time is still far too low in the case of the Android SDK (almost negligible). Whereas, in the case of React Native, the update rendering time is still large, but it is now within an acceptable range. Each update is rendered in almost the same time, regardless of how many views were already present. This clearly demonstrates the power of diff rendering and how React leverages it to speed up performance.

Feel free to experiment with the code. For example, convert the views to a RecyclerView (Android SDK) and a FlatList (React Native) and observe how quickly they render. 

Conclusion

React Native is slowly catching up in terms of speed. The creators of React Native dream of making React Native at least as fast as Android. Although this might seem to be a far-fetched dream for now, they do have a lot of improvements planned for the future. I am sharing two videos from React Conf 2018 and 2016 where the team shares their plans:


Comments

Popular posts from this blog

Architecture of High Performance Computing Server at BIT Mesra

A High-Performance Computing (HPC) server was installed a few years back. It was a replacement for PARAM 10000, the supercomputer that is no longer available for use. Initially, the HPC was under the Department of Computer Science. The Department of Chemical Engineering and Biotechnology was the primary user of the HPC (mostly for simulation purposes), and so the administration decided to move it under the Central Instrumentation Facility (CIF). You need permission from the CIF to access the HPC. HPC is only available for research purposes, and you need to provide a good reason along with a proper recommendation from a professor to gain access to the HPC. The HPC is at least 20 times more powerful than the most powerful PC that anyone has on campus. Also, I recently checked the usage and realized that not even 10% of its power is being utilized. I hope this blog post will help you in understanding the core architecture of the HPC. Architecture The Architecture of High Performance Compu...

Setting up Machine Learning Environment on High Performance Computing Server

In the last article, I discussed the architecture of the HPC. If you have not read that article, I would recommend that you read it before proceeding with this one. Architecture of High-Performance Computing Server at BIT Mesra  The power of HPC can be utilized for its most important application in the field of computer science: Machine Learning. I am assuming that you already have obtained your SSH credentials to log on to the master node. Also, we will be setting up the environment in Python. Let's jump straight to the steps. How To? Step 1: Download and Install Anaconda on the Master Node Note that you are not the root user of the HPC. You are just a regular user, and therefore, administrative commands (such as sudo or su) will not work. Anaconda has made it much easier to install Python packages for non-root users, and we will be using Anaconda for setting up Python 3 and installing the required packages. Log in to the master node     > ssh be1005815@172.16.23.1 Go...