Rendering Performance Evaluation - Android SDK vs React Native

By
UI rendering speed has always been a key for evaluating a new technology. The lesser is the rendering time, the more preferable is the technology. In the recent times, React native has become very popular for developing native apps. Such apps are truly native and way different from similar other technologies like Xamarin and Cordava. I got some time to evaluate how React Native compares to Android SDK.

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

Performance comparison

Emulator used for evaluation

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 Android SDK and React native. These text views are very simple and don't contain any 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 and when the button is clicked, it shows the rendered text views along with the time taken for rendering. Remember that, every time you hit the button, all the text views are being re-created. Here is the output produced.

Android SDK output screenshot

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


Don't worry if the code looks unfamiliar. The code is written in Typescript. It 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 Android SDK. Here is the output generated:

React native output screenshot

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 Android SDK and React native. React native is at least 30 times slower as compared to Android SDK when they are compared absolutely. This was expected as React native translates the components into Android native components at run time. 

Diffing Performance Comparison

Going by the previous evaluation, one can deduce that React native has very large rendering time and so must not be preferred at all over Android SDK. But, we are missing out a very important part of the React framework - the diff calculation of components that have really changed. In a User Interface, it is the rendering time of the updates (how fast are the updates rendered to the UI) that is even more important.

To make an evaluation, we are going to make some minor changes in the code. We are no longer going to use an input from the user. Instead, we would be rendering 10,000 text views in the chunk of 1000.

Here is the Android SDK and React native implementation of the same.




As one can see in the code above, we are calculating the time taken for adding 1000 text views to the UI. In 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 code:

Android SDK output for diff rendering

React native output for diff rendering

As one can see that the update rendering time is still far too less in case of Android SDK (almost negligible). Whereas in case of React native, the update rendering time is still large, but, it is now under an acceptable range. Each update is rendered almost in the same time no matter how many views were already present. This clearly explains the power of diff rendering and how React leverages it to speed up. Feel free to play around with the code. For example, convert the views to Recycler view (Android SDK) and flat list (React native) and see how fast do they render. 

Conclusion

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



Comments

Post a Comment

Popular posts from this blog

Popular Ethical Hacking Tricks on LAN

By
Birla Institute of Technology, Mesra has a large Local Area Network. Several computers are connected through hundreds of routers and switches. The local network has served several purposes whether it is file sharing through DC or organizing an online event. Such interconnection has made it vulnerable to attacks. The LAN is based on old ethernet technology. It is a good playground to practice ethical hacking. I am going to list you some working techniques that can be easily tried. I won't be telling you complete steps on how to do it. Please use it for learning purpose only. 1. Brute-force to any local website Everyone has to login to Cyberoam before they can access the fast Internet available on the ethernet. There are several automated scripts written in various languages to login to Cyberoam. Since Cyberoam is available on a local network, it is much faster to get the response for login credentials. Once the path is resolved, it takes a maximum of 5 hops for the packet to re
Read more

Hack-A-BIT 2018

By
A WhatsApp group named "BIT Hackathon" on 9th May 2018. It was an initiative no senior has taken to date. I was supposed to the biggest initiative ever taken by a BITian. Discussion started immediately about the name. Ayush came up with a suggestion - Hack-A-BIT. Everyone immediately accepted the name. At the same time, Ankit formed a separate group of K16 juniors to keep them updated with the Hackathon. No work was done during the entire summer. It seemed like everyone had lost their interest in organizing the Hackathon. Finally, on 20th July, the first meeting was held. All the core members (except girls) were part of that meeting. The initial estimates of the Budget were made. All the points related to the Hackathon was noted. We could not have let the slack loose. On the same day, the core team was finalized and event details were also documented. A permission letter was drafted which was signed by the three presidents - Anuj, Aashray and Aakarshit.  The initial eve
Read more

DDoS Attack on Bitotsav '19 Website

By
Image
This is not a technical write up. This is a story that I want to share which might be a lesson for several Web & App developers out there. Bitotsav is the annual cultural fest of BIT Mesra and the Tech Team was responsible for developing the Website and the Android App. There were 46 events in the fest and we were responsible for sending out updates (announcements, results, etc.) for each event to the app. 16th February 2019, on the 2nd day of the fest, the website started experiencing problems. The website got slower and slower. The website was hosted on Microsoft Azure Virtual Machine. It was evening around at 5:00 PM. I checked the logs for the Virtual Machine. In the past 6 hours, 700 GB of data was uploaded and downloaded from the server. The Virtual Machine had 4 VCPUs and all of them were being rigorously used. Due to such huge traffic, all the APIs stopped responding. The app was no longer usable. No updates could be sent to the participants. What was happening? In the
Read more