Preamble
React Native was first introduced in 2015 as a solution to develop cross-platform applications with native component compatibility using the ReactJS framework. Although the initial design of this platform has a few flaws and drawbacks, it is still strongly supported by the community and has become popular due to how to build web-friendly applications for web developers.
First announced in 2018, React Native redesign is an attempt by the Facebook team to make the platform stronger and address some of the common issues developers have encountered over the years.
We will see how this will affect the performance and speed of application development.
Old architecture
In essence, React Native is a platform-agnostic solution ( platform independent). In this context, the main goal of the framework is to allow developers to write JavaScript code with ReactJS while under React Native uses its own mechanisms to compile React Elements so that the operating system can understand. OK. This means:
- Display the user interface correctly
- Access to native components of the operating system.
Normally, for Android / iOS operating systems, the mechanism of operation will look like this:
There are 3 threads running in parallel and separately in each React Native application:
- JS thread : is where all Javascript code is read and compiled, which handles most of the application’s business logic. Metro will package all Javascript code into a single file. This code will be transferred to JavascriptCore (JSC) to be able to run.
- Native thread : is the place where native code is handled. It communicates with JS Thread whenever there is a need to change the UI or access native functions. We can divide Native Thread into Native UI and Native Modules . All Native Modules are started when we use the application. That means the Bluetooth module will always be activated by React Native even when there is no need to use it.
- Shadow Thread : is where the layout will be calculated. It uses Facebook’s own Layout Engine called Yoga to calculate the flexbox layout, then sends the results to the Native UI.
To communicate between the JS thread and the Native thread we will use a Bridge . Below, this C ++ Module is mostly built around with an asynchronous queue . Whenever it receives data from either side ( JS thread or Native thread ), it will serialize the data in JSON format and pass it through the queue, eventually decoded as it arrives.
This means that all threads that are based on a JSON signal stream are transmitted asynchronously over a Bridge , and they will be sent to either side with the desired (but not guaranteed) response. Future. You may also experience information congestion and not receive a response.
A common example of why this causes performance problems when seen when scrolling a large list of data: Whenever the onScroll event occurs on the Native thread , information will be sent asynchronously to the JS thread , but the Native thread doesn’t wait for the JS thread to finish but it returns it in another way. This creates a delay, there will be a space before information appears on the screen.
Similarly, the layout calculation calculation needs to take many rounds before it can be displayed on the screen, because it needs to go through the Yoga engine before it can be calculated by the Native thread and of course they are. will also have to cross the Bridge to get to JS Thread .
We can see how asynchronously sending JSON data creates performance problems. But is there any other way for our JavaScript to communicate with Native code? This is where JSI works.
New architecture
React Native’s reengineering will gradually eliminate Bridge and replace it with a new component called Javascript Interface (JSI) .
JSI has some very interesting new improvements, the first is that the JS bundle no longer depends on the JS core. In other words, the JSC engine can now be easily interchangeable with other JavaScript engines – which can work better – like the Chrome Engine V8.
The second improvement of this new architecture is that By using JSI , JavaScript can hold references to C ++ Host Objects and access methods on them. From there JavaScript and Native components will recognize and communicate with each other.
In other words, JSI will allow full interoperability between all threads. With the concept of shared ownership , JavaScript code can communicate with Native components directly from the JS thread and skip JSON message serialization between components, eliminating all congestion and asynchronous issues on the Bridge .
In addition to significantly improving communication between threads, this new architecture also allows direct control of Native modules . This means that it is possible to use Native modules when we need them, without activating them all at application launch. This brings a markedly improved performance.
This new mechanism is flexible, can also benefit many different use cases. For example, now that we have the power of C ++ in our hands, it’s easy to see React Native that can be used in a very large system.
That is not all
Over the years, React Native has accumulated a lot of parts that are now obsolete, no longer used or otherwise used. With the main goal of cleaning up non-essential components as well as improving maintenance, the React Native framework has removed some components from the system. For example, core components like Webview or AsyncStorage are gradually being removed from the React Native core to turn them into community-managed repositories.
With a new mechanism, clean core and impressive interoperability between Javascript code and Native code, React Native’s new architecture is set to achieve many improvements in developer performance and workflow. .
With the roadmap towards refactoring done over the next few years, it will be interesting to see how our applications work smoother, more efficiently, as well as the experience of our developers becoming better. .
Link to article: https://medium.com/swlh/react-natives-re-architecture-in-2020-9bb82659792c
Reference: Lorenzo S. https://t.co/wDaXRvLtlA?amp=1