React Native se incluye con múltiples ventajas, como soporte multiplataforma, actualizaciones OTA, recarga en vivo, rentabilidad, etc., pero el mayor cuello de botella al escalar las aplicaciones nativas de React ha sido el rendimiento a medida que agrega más módulos, cuando la aplicación se vuelve intensiva en datos o cuando hay múltiples pases requeridos sobre el puente.

Pero, ¿cómo funciona la arquitectura actual?

La arquitectura de React Native depende de tres subprocesos: a) Subproceso de interfaz de usuario: este es el subproceso principal de la aplicación que se utiliza para representar las vistas de Android e iOS. b) Subproceso de sombra: es una especie de subproceso de fondo que calcula el diseño de los elementos (usando Yoga ) antes de renderizarlos en la plataforma host. c) Subproceso JS: JS incluido que es responsable de manejar toda la lógica en su aplicación nativa de reacción.

La interacción entre estos subprocesos no es directa y cada vez que un subproceso necesita interactuar con otro subproceso, tiene que pasar por la ardua tarea de serialización y deserialización de datos a JSON para cruzar el puente. Esto da como resultado una copia innecesaria de datos y este puente puede llenarse con bastante facilidad ya que las operaciones son asíncronas y no hay tipificaciones estrictas.

Algunas limitaciones de la arquitectura actual:
1. Javascript y el lado nativo no se conocen entre sí y dependen de mensajes JSON asíncronos.
2. Todos los módulos se cargan al inicio, lo que aumenta el tiempo de interacción.
3. Sin priorización de acciones: las interacciones importantes del usuario no se pueden priorizar sobre las demás acciones.
4. Serialización de puente
5. Los elementos de la interfaz de usuario no son accesibles directamente desde el subproceso JS.

Presentamos JSI

JSI trae un gran cambio en cómo interactúan JavaScript y la parte nativa. Proporciona una comunicación directa entre los dos reinos con la ayuda de una interfaz entre JS y C++. Usando la interfaz de JavaScript, JS puede contener referencias a objetos host y métodos de llamada en ellos. Con la ayuda del objeto host, ahora podemos usar objetos nativos en el contexto de JavaScript. El puente que era el mayor cuello de botella se divide en partes:

Tela

El nuevo sistema de renderizado creado por Facebook, que es la nueva arquitectura del administrador de UI. Este renderizador está implementado en C++ y el núcleo se comparte entre plataformas. En la implementación anterior, la creación del diseño implicaba varios pasos, como la serialización de JSON y los saltos a través del puente, que tenían problemas importantes cuando el puente se bloqueaba, por ejemplo: Caídas de fotogramas mientras se desplaza por una lista infinita. La nueva implementación permite que el administrador de la interfaz de usuario cree el Shadow Tree directamente en C++, lo que mejora enormemente la experiencia al reducir la cantidad de saltos entre reinos. Las operaciones son síncronas y seguras para subprocesos y se ejecutan desde React (JavaScript) en el renderizador (C++), generalmente en el subproceso de JavaScript. También implica una menor serialización de datos, ya que los valores de JavaScript se pueden seleccionar directamente de JSI. Este control directo también ayuda en la priorización de las acciones, el renderizador ahora puede priorizar ciertas interacciones del usuario para garantizar que se manejen de manera oportuna. Esto mejorará en gran medida el rendimiento en las listas, la navegación y el manejo de gestos.

Módulos turbo

En la implementación anterior, no teníamos la referencia a los módulos nativos, por lo que cada módulo se cargó al inicio, lo que aumenta el TTI (Tiempo para interactuar), pero con los módulos turbo podemos cargar los módulos de forma diferida cuando sea necesario, lo que ayudará. en la mejora del tiempo de arranque. Por ejemplo: si tiene un módulo para imprimir un documento desde un enlace, ahora podríamos cargar este módulo cuando aterrizamos en la pantalla de impresión y no al iniciar la aplicación que se estaba haciendo en la arquitectura anterior. La capacidad de escribir el módulo en C++ también se suma a la ventaja, ya que reduce la implementación duplicada entre plataformas.

Codegen

Para unir todo esto y hacer que ambos reinos sean compatibles, el equipo de React Native creó un verificador de tipos para automatizar la compatibilidad entre JS y el lado nativo. Esta herramienta se llama Codegen. Utiliza un enfoque modular, lo que significa que cualquier lenguaje Javascript de tipo estático podría ser compatible con el analizador para ese sistema. Mediante el uso de JavaScript escrito como fuente de la verdad, este generador puede definir los archivos de interfaz que necesitan Fabric y TurboModules para enviar mensajes a través de los reinos con confianza. Codegen también proporciona seguridad de tipo de tiempo de compilación, lo que significa que ambos entornos pueden ejecutar comandos sin ninguna verificación de tiempo de ejecución, lo que significa un tamaño de código más pequeño para enviar y una ejecución más rápida.
Dado que ahora tenemos código C++ y C++ está fuertemente tipado, estamos obligando a escribir nuestro código JS, porque tenemos que definir tipos y no podemos escribir ninguno en ninguna parte del código. Básicamente, crea una interfaz para usted y ahora, dado que se generan y están en C ++, ahora podemos confiar básicamente en los datos que se envían y no tenemos que ir y venir para verificar los datos. Esto también significa que al usar las comprobaciones de tipo podemos identificar fácilmente problemas durante la fase de desarrollo que podrían haber resultado en bloqueos fatales o una mala experiencia del usuario.

Algunas de las principales ventajas de JSI

1. El código Javascript puede contener una referencia a cualquier elemento de la interfaz de usuario nativa y llamar a los métodos en él (similar a la manipulación DOM en la Web)
2. Enlaces rápidos y directos al código nativo que pueden mejorar en gran medida el rendimiento, por ejemplo, MMKV usa JSI, que es aproximadamente 30 veces más rápido que Asyncstorage.
3. Se pueden utilizar motores distintos de JavaScript Core.
4. Los módulos nativos se pueden cargar cuando sea necesario.
5. Comprobación de tipos estáticos para hacer compatibles JS y código nativo.

React Native JSI se encuentra actualmente en la fase de implementación experimental y, a medida que más proyectos adopten este cambio, sabremos más sobre las limitaciones y el impacto de la nueva arquitectura, pero una cosa es segura: el futuro del desarrollo de aplicaciones nativas y multiplataforma de React. parece emocionante.