Get in touch
or send us a question?
CONTACT

React Native’s New Architecture

React Native’s new architecture was still considered experimental and not yet fully stable for production use. However, the React Native team had been actively working on improving and refining this new architecture, with the goal of eventually making it the default architecture for React Native projects.

You can migrate your existing React Native project to the new architecture. However, migrating to the new architecture can require some changes to your existing codebase and project structure. The migration process may also involve updating dependencies, modifying native code, and adjusting your project’s build process.

Current Architecture(JSC):

In React Native, the bridge is responsible for enabling communication between the JavaScript code running in the JavaScriptCore engine and the native code running on the device. The bridge creates a communication channel between the two codebases, allowing messages to be sent back and forth between them.

In React Native, there are typically three threads that are used to manage the different aspects of the application:

  1. The UI thread (or main thread): This thread is responsible for handling user input and updating the UI components of the application. It’s also responsible for executing JavaScript code, but only one task can be executed at a time, so it’s important to keep long-running tasks off of this thread.
  2. The JavaScript thread: This thread is responsible for running the JavaScript code that makes up the logic of the application. It’s separate from the UI thread, so it can execute long-running tasks without affecting the responsiveness of the UI.
  3. The native module thread: This thread is used to handle communication between the JavaScript code and the native code of the device. When a native module is called from JavaScript, it’s executed on this thread.

In addition to these threads, React Native also uses a “shadow thread” to manage the UI component hierarchy. This thread is used to calculate the layout and size of UI components and to manage the rendering of changes to the UI.

The way that these threads work together in a React Native application is as follows:

  1. The UI thread handles user input and updates to the UI components. When the user interacts with a component, such as by tapping a button, this thread receives the input and triggers the appropriate action.
  2. The JavaScript thread runs the application’s business logic, such as handling network requests or updating the state of the application. When the logic requires updating the UI, the JavaScript thread sends a message to the shadow thread, which calculates the layout and size of the updated UI component.
  3. The shadow thread sends a message back to the UI thread with the updated layout information, which triggers a redraw of the component on the screen.
  4. If the business logic requires native functionality, such as accessing the device camera or GPS, the JavaScript thread sends a message to the native module thread, which executes the appropriate native code and returns the result back to the JavaScript thread.

Drawback

  1. Asynchronous communication: The bridge uses asynchronous communication between the JavaScript and the native code of an application. While this can improve the performance of the application in some cases, it can also introduce additional complexity and make it more difficult to debug issues that arise in the application.
  2. Unnecessary copying of data: Because the bridge communicates between the JavaScript and native code of an application, it may copy data back and forth between these two layers unnecessarily. This can lead to increased memory usage and reduced performance.
  3. Slow data transfer: Because the bridge may need to transfer large amounts of data between the JavaScript and native code of an application, it can potentially slow down the responsiveness of the application. This can be particularly problematic in cases where real-time data is required

New Architecture(JSI):

JSI stands for JavaScript Interface, and it is a feature in React Native that allows for a more direct interaction between JavaScript and native code. JSI (JavaScript Interface) is a low-level native module interface that allows JavaScript code to interact with native code without going through the React Native bridge. JSI is used in conjunction with Fabric, TurboModules, and Codegen to provide high-performance, efficient communication between JavaScript and native code.

Fabric

Fabric is a re-architecture of the React Native framework that is designed to improve performance, stability, and reliability. It is a lightweight, optimized, and extensible framework that enables high-performance layout and rendering of native UI components.

TurboModules

TurboModules is a module system for React Native that replaces the legacy NativeModules system. TurboModules are pre-compiled native modules that can be loaded and executed more quickly than legacy NativeModules.

Codegen

Codegen is a code-generation tool that generates native code for TurboModules based on a declarative specification of the module’s interface. Codegen reduces the overhead of runtime type-checking and enables more efficient communication between JavaScript and native code.

JSI

JSI is a low-level native module interface that allows JavaScript code to interact with native code without going through the React Native bridge. JSI enables direct communication between JavaScript and native code, reducing the overhead of marshaling and unmarshaling data between the two environments.

Javascript Engine:

V8 and Hermes are both JavaScript engines used in mobile app development, with V8 being primarily used in Android and Hermes being used in React Native applications. Here are some differences between V8 and Hermes:

  1. Performance: V8 is known for its high performance and is used in a variety of applications, including Google Chrome. Hermes, on the other hand, is designed specifically for mobile app development and is optimized for React Native.
  2. Memory usage: Hermes is designed to minimize memory usage in mobile apps, which is crucial for devices with limited memory resources. V8 is more flexible in terms of memory usage, but may not be as optimized for mobile devices as Hermes.
  3. Start-up time: Hermes has a faster start-up time compared to V8, which is important for mobile apps that need to launch quickly and provide a seamless user experience.
  4. Garbage collection: V8 uses a generational garbage collector, while Hermes uses a concurrent garbage collector. Both approaches have their advantages and disadvantages, but the key difference is that V8’s approach may be more optimized for long-running server applications, while Hermes’ approach may be more optimized for mobile app development.

Leave a Reply

Your email address will not be published. Required fields are marked *