Optimizing React Native with C++

Hola, con esta charla, espero inspirarte a construir módulos nativos de C++ para React Native. Es difícil, pero se está volviendo más fácil y no es tan difícil como podrías pensar. Mi nombre es Cain Hansen, trabajo para MongoDB, construyendo herramientas para desarrolladores. En mi trabajo en MongoDB, también mantengo una biblioteca de React Native para una base de datos móvil de código abierto llamada Realm.

Hablando de Realm, también tengo que mencionar que MongoDB ha decidido descontinuar Realm para enfocar su energía. Así que basta de hablar de mí, basta de hablar de Realm. ¿Qué es un módulo nativo? Vamos a desglosarlo, comenzando con nativo. Es el nativo en React Native. Es todo lo que se ejecuta en el dispositivo y no está escrito en JavaScript. ¿Qué es un módulo entonces? Piensa en esto como un contenedor de código nativo relacionado. Debe ser descubrible por la aplicación cuando la compilas, utilizando la vinculación automática a través de CocoaPods y Gradle, pero también en tiempo de ejecución cuando el código JavaScript de la biblioteca lo necesita.

¿Por qué construir un módulo nativo? Bueno, puedes escribir código de módulo nativo en varios lenguajes diferentes. Puedes usar Kotlin y Java, Swift o Objective-C para lograr una integración más estrecha con la plataforma, como acceder a periféricos del dispositivo, cámaras, etc. C++ y Rust puedes usarlos para acceder y construir código de rendimiento independiente de la plataforma. Me enfocaré en el resto de mi charla en C++. Entonces, ¿por qué no un módulo nativo de C++? Te da tiempos de compilación más largos, no es tan fácil ni rápido como JavaScript, que es mucho más rápido que reconstruir y volver a lanzar una aplicación. También presenta más problemas cuando se producen fallas catastróficas y bloqueos, porque no siempre obtienes una pila agradable, de la misma manera que estás acostumbrado en JavaScript. Gestionar las dependencias de paquetes entre tu código y tus dependencias de C++ también puede ser doloroso a veces, y tiene una curva de aprendizaje más alta, según dicen muchas personas. Y esto, en última instancia, a menudo conduce a una menor productividad del desarrollador. Pero como con cualquier cosa en el software, es un compromiso y depende.

Entonces, ¿cómo llegamos hasta aquí? No creo que una charla sobre React Native en estos días sea una charla sobre el React Native anterior a menos que aclaremos la arquitectura antigua y la nueva. Así que repasemos la arquitectura antigua aquí. En realidad es extraño llamarla antigua, porque recién se desactivó de forma predeterminada en la versión 0.76 de React Native. Solíamos realizar análisis de mensajes sobre lo que llamábamos el puente, y esto resultaba en copias costosas y un aumento en el uso de memoria, ya que JSON no almacena datos binarios de manera eficiente. Y esto ha tenido un impacto en el diseño de muchos de los primeros módulos nativos para React Native, dejando amplias oportunidades para innovar.

Y uno de los pilares de la nueva arquitectura es la interfaz de JavaScript, JSI abreviado. Es una abstracción sobre los motores de JavaScript, JavaScript Core y Hermes. Y el puntero de tiempo de ejecución de JSI es inicializado por React Native. El objetivo del módulo nativo es interactuar con él, ya sea directamente o a través de algún código generado, llamando a C++ y traduciendo los valores de retorno y los argumentos en y desde los valores de JSI. Este es el encabezado de JSI, y al menos las clases exportadas por el encabezado de JSI. Y solo tiene 1,500 líneas de código, pero tiene muchos comentarios. Y esta es la lista de todas las clases, ¿verdad? Sumergámonos en el tiempo de ejecución. La API pública del tiempo de ejecución es bastante simple. Obtienes la capacidad de preparar y evaluar JavaScript, gestionar microtareas. Esto es el bucle de eventos. Y también acceder al objeto global en el tiempo de ejecución. Luego el valor de JSI aquí. Puedes construirlos a partir de primitivas de C++, o puedes proporcionar una cadena de JSON y creará un valor a partir de ella. También puedes comparar la igualdad de estos valores usando la igualdad de JavaScript. Y finalmente, puedes leer los valores primitivos nuevamente en C++. Aquí vamos.

De acuerdo. Objeto JSI. Este es un tipo especial de valor y tiene métodos para obtener y establecer propiedades. También puedes almacenar estado nativo en ellos. Comparte punteros con algún objeto de C++ que controlas. Puedes usar otro método para comunicar la presión de memoria externa desde este estado nativo que has asociado con el objeto JSI. Esto permite que el motor de JavaScript realice una recolección de basura eficiente. Este es mi método. Esto es lo que voy a hacer.

Voy a presentar dos criterios que creo que son importantes cuando decides qué alternativa elegir. Y luego {{^}}voy a presentar las alternativas disponibles tal como las veo ahora. Así que el primer criterio, necesitas decidir si quieres soportar la arquitectura antigua, la nueva, o ambas arquitecturas. ¿Tienes, por ejemplo, usuarios existentes y quieres facilitar una transición suave? ¿O estás de acuerdo con una actualización importante y forzada donde dices que esta es solo la nueva arquitectura? En última instancia, es un compromiso entre la disponibilidad para los usuarios frente a obtener tu mantenimiento como autor de la biblioteca. Si envías para la arquitectura antigua, también podrías necesitar probar en la arquitectura antigua y obtendrás errores en la arquitectura antigua. Como ya mencioné, la nueva arquitectura acaba de convertirse en predeterminada.

Segundo criterio, ¿necesitas una tipificación fuerte entre tu JavaScript y tu código nativo? Y probablemente sí, para limitar los fallos catastróficos por bloqueos. También reducirá tu carga de mantenimiento para mantener estos dos lados sincronizados. He visto dos enfoques para la generación de código. Así que algunas alternativas, permitirán la generación de código desde TypeScript o Flow en paradas que necesitas implementar en el lado nativo. Otras alternativas, que es la que usa Realm, es generar declaraciones de TypeScript desde el código C++ o algún lenguaje específico de dominio, ya sea algo personalizado o algo como WebIDL. Y no solo generará paradas que necesitas implementar, sino código de enlace real entre la biblioteca C++ y JSI. Luego se basa en el código generado para fallar la compilación si los dos no coinciden.

Bien, así que la primera y ahora la alternativa predeterminada es TurboNativeModules. Requiere que la nueva arquitectura esté habilitada. Logra la seguridad de tipos a través de una herramienta de generación de código desde declaraciones de TypeScript o Flow en paradas que necesitas implementar en el lado nativo. TypeScript es bastante limitado en la expresividad en comparación con otras alternativas en términos de qué tipos puedes comunicar a través de este límite. Y genera estas paradas para C++, Objective-C y Java, pero los módulos puros de C++ no son compatibles en iOS todavía, mientras grabo esto.

La segunda alternativa es LegacyNativeModules. Está obsoleto una vez que se considera estable la nueva arquitectura, y supongo que eso es ahora que se convirtió en predeterminada. Y aún no es compatible con Forge, lo que significa que no requiere que la nueva arquitectura esté deshabilitada. Y esto se debe a una capa de compatibilidad. Así que puedes usar estos en la arquitectura antigua y nueva. No proporciona ninguna seguridad de tipos, y es anterior a JSI, lo que lo hace un poco más complicado acceder al puntero de tiempo de ejecución de JSI. La tercera alternativa, combina los dos. Así que el módulo Legacy y el Turbo. Es un patrón anunciado para facilitar la adopción de la nueva arquitectura. Utiliza macros y configuración de Gradle para cambiar entre la implementación en el momento de la compilación para elegir la implementación correcta para la aplicación que está utilizando la biblioteca. Y probablemente podrás llamar a algún tipo de implementación compartida entre los dos. Así que la cuarta alternativa, XperModules, tengo que mencionar esto para completar, pero solo para resumir de sus propios documentos y también de los equipos de React que he visto en los marcos de React Native, se afirma que si tienes la intención de usar C++ en tu módulo nativo, usa Turbo modules.

Tampoco soporta la generación de código para garantizar la seguridad de tipos de extremo a extremo. Bien, mencioné que obtener el puntero de tiempo de ejecución de JSI era difícil desde un módulo Legacy, y quiero explicar eso ahora. Este es un enfoque que Realm ha estado usando durante mucho tiempo, y fue bien codificado por Ditto, también, en su blog. Y he enlazado a eso en esta diapositiva.

Los principales inconvenientes son que se basa en APIs privadas, que podrían romperse en cualquier momento, y necesitas traer tu propia generación de código para obtener esta seguridad de tipos de extremo a extremo. Como un extra, puedes diferir la carga del módulo nativo real en la aplicación en Android hasta que realmente se acceda desde JavaScript.

Bien, así que voy a explicar esto en Android primero. Comenzamos registrando un método sincrónico bloqueante, invocable desde JavaScript. Y cargamos el archivo de objeto compartido justo a tiempo. Accedemos al contenedor de contexto de JavaScript, y luego sincronizamos en eso para asegurar que ningún otro hilo de Java lo acceda mientras inicializamos. Y esto es importante porque no es seguro para hilos. Luego llamamos a get, que devuelve una dirección de memoria del puntero de tiempo de ejecución de JSI. Y finalmente llamamos a injectModuleIntoJSGlobal, que es un método nativo que implementamos en el lado de C++ usando JNI, lo cual veremos en la siguiente diapositiva aquí. Idealmente, simplemente devolveríamos el valor ahora mismo, como el enlace inicializado, pero el problema aquí es que los módulos nativos legacy son anteriores a JSI.

Bien, entonces en el lado de C++ JNI, implementamos este método nativo injectModuleIntoJSGlobal. Toma esta dirección de memoria del puntero de tiempo de ejecución como argumento, y luego lo reinterpret convierte. Luego crea un objeto que podemos usar para almacenar nuestro enlace. Y luego llamamos a una función que hemos generado llamada RealmJSIInit. Es mucho C++ generado que básicamente almacenará el enlace entre nuestra biblioteca C++ y JSI. Y finalmente, establecemos una propiedad en el global a la que podemos acceder desde JavaScript después.

En iOS, tenemos que hacerlo un poco más sucio en el sentido de que necesitamos acceder al campo de tiempo de ejecución del puente RCT CXX, que es una API privada, y declaramos esto con un simple puntero. Y más tarde, básicamente, de nuevo, declaramos una función sincrónica bloqueante que podemos llamar desde JavaScript. Obtenemos el puntero de tiempo de ejecución de JSI desde el puente, y luego lo convertimos, y luego creamos el sujeto de exportación. Nuevamente, llamamos a la función RealmJSIInit para poblarlo, y finalmente, lo almacenamos en el global para que podamos acceder a él desde JavaScript. Luego finalmente retornamos.

Bien, la última y más reciente alternativa que voy a presentar es NitroModules. Es el nuevo en el bloque introducido por Marcello y Mark Rosevie. Es muy rápido en benchmarks sintéticos. Soporta C++, Swift, Kotlin. Es mucho más expresivo en la parte de generación de código que las otras alternativas. Aprovecha el estado nativo de JSI y establece correctamente la presión de memoria externa. También soporta tanto la nueva como la antigua arquitectura desde hace unos días, a lo cual volveré. El único inconveniente que puedo ver ahora mismo al usar esto es que requiere que los desarrolladores de aplicaciones como tus usuarios de biblioteca instalen una dependencia de pares llamada React Native NitroModules, pero creo que esto es solucionable en el futuro.

Bien, así que mi conclusión es que, o al menos hasta hace unos días, sería usar el patrón de módulo TurboNative compatible hacia atrás. Esta es la forma oficial bendecida de hacer las cosas, pero NitroModules cambió y ya no solo soporta la nueva arquitectura. Así que diría que uses NitroModules si te sientes aventurero, pero entonces ¿a quién estoy engañando? Estás usando React Native, así que por supuesto te sientes aventurero. Así que básicamente, el último consejo antes de irme, pre-construir es una forma de tomar una parte de tu código nativo y construirlo en tu máquina en lugar de en la máquina del usuario final. El beneficio de esto es reducir el tiempo de construcción en las máquinas de tus usuarios de biblioteca y también la complejidad en sus cadenas de construcción. Otro beneficio es que obtienes fallos de tipo en tu tiempo de desarrollo en lugar de hacerlo en las máquinas de los desarrolladores, como las máquinas de tus usuarios. Una limitación de Xcode y CocoaPods es que no pueden manejar un proyecto CMake. Y esta es una forma de solucionar eso, básicamente usar CMake para generar un proyecto Xcode que básicamente pueda pre-construir un marco XE, por ejemplo. Eso es lo que estamos haciendo en Realm. Luego, una limitación aquí en el lado de Android es que estos están en decay, como todos estos pre-construidos son específicos de ABI en decay, lo que significa que tienes que enviar múltiples pre-construidos, uno por en decay, pero generalmente no es un problema muy grande porque las versiones en decay no cambian tan a menudo. O eso, necesitas entonces, si no envías múltiples, entonces necesitas declarar, supongo, con qué versión en decay es compatible tu biblioteca.

Y luego, asume o afirma eso en el momento de la construcción. Bien, otra limitación es que, y esto es súper importante, no deberías acceder a las APIs de React Native desde tus pre-construcciones. Y esto se debe a que el límite de ABI o el ABI no es estable a través de las versiones de React Native. Súper importante.

Bien, por último, si sientes que está tomando demasiado tiempo compilar cosas, entonces en Android puedes usar una caché de compilador o puedes hacerlo tanto en Android como en iOS, pero usa una caché de compilador. En Android, es bastante simple. Son solo estas líneas en tu archivo CMakeList. En iOS, solía ser un poco más difícil, pero luego con esta solicitud de extracción que realicé, es más fácil. Solo puedes declarar usar C cache uno al instalar el pod. Si tienes C cache instalado, eso va a dirigir y hacer que el compilador compile a través de C cache. Y luego, las compilaciones subsiguientes de tu módulo nativo serán mucho más rápidas.

Bien, así que la conclusión final. Usa módulos Nitro. Si tu proyecto C++ es complejo, puedes usar pre-construcciones, pero ten cuidado. Si te cansas de esperar, usa una caché de compilador. Esa es mi conclusión por ahora. Si quieres aprender más, he incluido un par de enlaces aquí. Muchas gracias por tu tiempo y atención. Es un bien escaso en estos días. Contacta si tienes alguna pregunta o comentario sobre esta charla y nos vemos más tarde.