Medición y Mejora del Rendimiento de React Native

¿Qué significa que una aplicación móvil tenga un buen rendimiento? Bueno, según este video de Google, que estará disponible en las diapositivas, tus aplicaciones deben poder funcionar a 60 fps, 60 imágenes por segundo. Esto significa que tu aplicación debe poder dibujar 60 imágenes por segundo cuando te desplazas hacia abajo, por ejemplo, para dar una impresión de suavidad al usuario. Básicamente, es como una película. Son imágenes animadas, básicamente.

La pregunta es, ¿qué pasa con las aplicaciones de React Native? Bueno, esto también se aplica a las aplicaciones de React Native, pero hay una complejidad añadida, el hilo JS. Debido a que la mayoría de tu lógica se ejecutará en el JS, es probable que la mayor parte de tu lógica empresarial resida en el lado del JS, debes asegurarte de que no esté demasiado ocupado. Por ejemplo, aquí tengo esta aplicación con un botón Haz clic en mí. Cuando hago clic en él, se actualiza el estado. He hecho clic una, dos, tres veces, pero Kill.js es demasiado costoso, así que cuando hago clic en él, el lado del JS se bloquea. Así que, incluso si hago clic en Haz clic en mí muchas veces después de hacer clic en Kill.js, no sucede nada, y no es hasta que Kill.js ha terminado que el JS realmente vuelve a responder, y puedes ver que se actualiza de cuatro a 12 veces así. Así que es muy importante echar un vistazo también al lado del JS, porque tu aplicación podría estar funcionando nativamente a 60 FPS pero ser completamente irresponsiva. Es por eso que React Native ofrece esta vista, el Monitor de Rendimiento de React Native, que muestra FPS de la interfaz de usuario y del JS, y es por eso que creamos este complemento Flipper, para poder mostrarlo en un gráfico. Además, como bonificación adicional, te proporciona una puntuación agradable para que puedas ejecutar pruebas de rendimiento. Pero, lo más probable es que esta puntuación pueda depender de muchos factores, en realidad, así que permíteme darte algunos consejos generales sobre medidas de rendimiento.

El primero es este. Debes realizar pruebas en un dispositivo de gama baja. Quiero decir, si solo pruebas en un dispositivo de gama alta, es probable que te pierdas la mayoría de los problemas que tus usuarios podrían estar experimentando. Un iPhone 13 puede ejecutar JavaScript o algún cálculo 10 veces más rápido que un Samsung Galaxy A21s, así que, bueno, ya sabes qué hacer. Definitivamente deberías probar en un dispositivo Android de gama baja. El segundo consejo es este. Debes hacer que tus medidas sean lo más deterministas posible. Las medidas de rendimiento son difícilmente deterministas, así que puedes hacer varias iteraciones y promediar el resultado. También puedes asegurarte de mantener las mismas condiciones tanto como sea posible para cada medida, por ejemplo, la red, los datos que estabas cargando, etc. Y, quiero decir, si quieres reproducir las mismas condiciones, es ideal poder automatizar el comportamiento que deseas probar. Y para eso, no necesariamente necesitas un marco de pruebas de extremo a extremo.

Puedes usar ADB en Android, por ejemplo. Aquí, con ADB Shell Input Swipe, puedes activar un desplazamiento en tu aplicación. El tercer consejo es este. Desactiva JSDev si quieres tener medidas de rendimiento reales en el lado del JS, debes desactivar esto, porque podrías encontrar un problema que en realidad no verás en producción. Y el cuarto consejo es, bueno, debes encontrar algunos problemas al medir. Simplemente utiliza las mejores herramientas de análisis. En el hilo JS, eso sería React Devtools, o incluso ejecutar un JS Flame Graph con el perfilador Hermes. Y en el lado de la interfaz de usuario, utiliza herramientas nativas como Android Studio, Systrace Profiler o Xcode Instrument en iOS.

Muy bien, vamos a sumergirnos en un ejemplo concreto ahora. TF1 es un canal de noticias de televisión y estamos construyendo su aplicación de noticias, y queríamos asegurarnos de que el rendimiento estuviera a la altura de nuestros estándares de calidad. Así que revisamos el feed de inicio y nuestro objetivo era que cuando desplazáramos hacia abajo, básicamente en un dispositivo de gama baja, deberíamos tener JSFPS siempre por encima de 0 para mantener la capacidad de respuesta del lado de JS, y el UIFPS siempre a 60 para poder ser muy fluido.

Siguiendo los cuatro consejos esenciales que mencioné antes, básicamente utilizamos un Samsung J3 del 2017, es nuestro dispositivo de gama baja favorito, es bastante básico. Configuramos la medición durante 10 segundos, arbitrariamente, pero es importante mantener el mismo tiempo para cada medición para poder comparar. Recargamos con el modo JSDev desactivado. Esperamos a que se cargue el feed y pulsamos Iniciar medición en el complemento Flipper. Ejecutamos ADB shell y PutsWide, blah, blah, blah, y esperamos hasta el final de los 10 segundos, y luego repetimos esto 5 veces solo para poder ver si obtenemos un resultado similar y promediarlo. Y el resultado fue este. El complemento nos dio una puntuación de 40 sobre 100, JS estuvo inactivo durante unos 4 segundos, el hilo de la interfaz de usuario estaba más o menos bien. Pero básicamente, esto significa que la aplicación en realidad no respondió durante unos 4 segundos, lo cual, no hace falta decirlo, era completamente inaceptable.

Dado que el problema estaba principalmente en el lado de JS, ejecutamos dos React DevTools, y está disponible de forma predeterminada en Flippr, lo cual es genial. Lo primero que debes hacer es hacer clic en este botón en la parte superior derecha, y allí puedes marcar la casilla, grabar por qué se renderizó cada componente con el perfilado en vivo. Esta es una opción interesante para activar. Veremos por qué muy pronto. Luego, simplemente haz clic en el botón azul aquí para comenzar a grabar. Realiza algunas acciones, en nuestro caso sería reproducir el mismo desplazamiento exacto con adb shell input swipe blah blah blah. Y luego presionamos el botón Detener grabación, y nos da un resultado similar a este.

Muy bien. Lo primero que quieres hacer es verificar esto. Esta es la lista de comentarios. Estas son las fases en las que React aplica realmente los cambios. Y por lo general, cuando se trata de problemas de rendimiento, quieres encontrar los comentarios más costosos en términos de cuánto tiempo tardaron. Y en nuestro caso, este sería el número 11. Es la barra más grande aquí. Así que hagamos clic en él, y esto es lo que nos muestra.

Bastante. Hay muchos colores aquí, pero básicamente esta es la jerarquía de tu componente React. En gris aquí, verás componentes que en realidad no se están renderizando, pero en nuestro caso la pantalla roja y algunos otros colores se están renderizando. Así que si nos acercamos un poco a esta parte, por ejemplo, verás la jerarquía de componentes que comienza con flatlist aquí en gris. Así que no se está renderizando. Entonces nuestro feed de inicio se implementó con flatlist, así que esto es. Y es una implementación interna en el código de React Native. Su hijo se llama lista virtualizada. Así que aquí está. Luego tenemos context.consumer, su hijo es virtualized list.contactProvider, etc., todos hasta llegar a context.provider, básicamente una lista de hijos. Y este chico tiene varios hijos llamados renderizadores de celdas. Básicamente, esto es lo que envuelve las cosas que pasas en tus elementos de renderizado. Entonces, en esencia, los renderizadores de celdas son nuestros elementos de lista de flatlist. También notarás que en cada componente tienes dos métricas. Tienes esta en el lado izquierdo, por ejemplo, aquí 4.9 milisegundos en nuestra lista virtualizada. Es el tiempo propio, es el tiempo que el componente tardó en renderizarse sin ninguno de sus hijos. Y el de la derecha es el tiempo total, es el tiempo total que el componente tardó en renderizarse incluyendo a todos sus hijos.

Así que básicamente aquí tenemos una lista virtualizada que tarda 3 segundos en renderizarse. Y podemos ver que básicamente todos los elementos de la lista también se están renderizando. Así que nuestra lista se está renderizando, todos los elementos de nuestra lista se están renderizando, y esto lleva un total de 3 segundos. Lo cual es un poco loco. Quiero decir, ¿recuerdas cuando hablamos de que el JS estaba bloqueado durante unos 3 o 4 segundos? Esto lo explica completamente, tenemos 3 segundos para eso.

Entonces, ¿qué debemos hacer? Bueno, lo primero que debes hacer es diferenciar entre la renderización inicial, y cuando pasas el cursor sobre un componente, ya que activamos esta nueva opción anteriormente, verás algo como esto. Esta es la primera vez que se renderiza el componente. ¿O esos componentes realmente se están volviendo a renderizar? Han sido montados inicialmente, pero ¿se están renderizando una segunda vez o más veces? Y en este caso verás algo como esto, una lista virtualizada, es un cambio de estado, un último cambio, del cual realmente no sabemos nada porque es la implementación interna de FlatList.

En nuestro caso, en realidad, todos los componentes aquí se estaban volviendo a renderizar porque, recuerda, dije que habíamos cargado nuestro feed anteriormente, por lo que ya se estaban renderizando algunos elementos en el feed, por lo que cuando nos desplazamos hacia abajo, básicamente se están volviendo a renderizar incluso los elementos superiores en el feed. Y esto es una locura, ¿verdad? No es necesario que se rendericen. ¿Entonces qué está pasando? Bueno, la primera iteración que hicimos para solucionarlo fue esta. Y todos deberían saber esto. Entonces, FlatList es una lista virtualizada y la virtualización funciona más o menos así. Tienes una larga lista de elementos, por ejemplo, no sé, 10,000, pero por supuesto, por razones de rendimiento, no podrás mostrarlos todos al mismo tiempo. Utilizas una lista virtualizada para mostrar solo lo que el usuario ve y algunos elementos arriba y algunos elementos abajo para garantizar un desplazamiento suave. Es importante tener en cuenta que en React Native, esta es la propiedad de FlatList llamada tamaño de la ventana y en React Native, en realidad, va a renderizar 10 pantallas de elementos por encima del área de visualización actual y 10 pantallas por debajo de ella. Por lo tanto, en realidad renderiza muchos elementos. Es algo importante a tener en cuenta. Pero, ¿cómo funciona esto? Bueno, básicamente, FlatList mantiene un estado en su implementación interna del primer elemento a renderizar y el último elemento a renderizar. Entonces, cuando nos desplazamos hacia abajo, bueno, esos cambian. Y esto desencadena una nueva renderización de la lista virtualizada, lo cual es normal. Básicamente, esto significa que renderItem, lo que pasas en tu renderItem, se llama enScroll. Esto es por diseño, lo que significa que debes seguir absolutamente las mejores prácticas definidas en la documentación de React Native sobre FlatList, y debes memoizar todos los elementos de tu lista. Y eso es lo que hicimos, y pasamos de esto a esto.

La gran diferencia que debes notar es esta. Básicamente, tenemos mucho gris aquí. Los elementos que memoizamos ahora no se vuelven a renderizar, y eso es lo que queremos. Todavía tenemos algunas cosas verdes arriba. Esto es básicamente la implementación interna de las listas virtualizadas, cambios de estado, etc. Por lo tanto, no podemos evitar que se rendericen, y lo que realmente es costoso aquí son los hijos, y todavía tenemos algunas cosas verdes aquí. Llegaremos a eso en un minuto, porque primero, ya tenemos algunas cosas menos verdes, tenemos algunas cosas más, quiero decir, tenemos menos cosas renderizándose, así que solo revisemos nuestra puntuación de rendimiento. Revisemos nuestras medidas, como antes en el complemento Flipper, y esto es lo que nos muestra ahora. Pasamos de 40 a 52, Chase solo está inactivo durante unos 3 segundos, y el hilo de la interfaz de usuario sigue alrededor de 60. Ok, no es fantástico, pero solo con un simple memo, hemos logrado una mejora muy buena para el rendimiento.

Pero vayamos más a fondo. En la segunda iteración, lo titulé La Alegría de las Listas Anidadas, y pronto entenderás por qué, porque, sí, ¿recuerdas esas cosas verdes en la parte inferior? Acerquémonos para ver qué es esto. Tenemos nuestra celda de renderizado en la parte superior, esto envuelve lo que pasamos en nuestro elemento de renderizado, luego tenemos las cosas grises, porque las memoizamos, pero aquí tenemos algo que aún se renderiza en verde. Y no es una lista virtualizada. Esto se debe a que tenemos carruseles horizontales implementados con carruseles Snap de React Native, que a su vez utiliza una lista plana. Entonces, básicamente aquí puedes ver nuestros siete carruseles que se muestran en nuestro feed de inicio, volviéndose a renderizar. ¿Pero por qué se vuelven a renderizar cuando nos desplazamos hacia abajo? Bueno, ¿recuerdas el estado, el estado de la ventana del que hablamos antes para la lista principal? Lo pasa como contexto a la lista secundaria anidada. Por lo tanto, podemos ver aquí que las listas virtualizadas se vuelven a renderizar debido a un cambio de contexto. Y esto significa que cuando nos desplazamos por la lista principal, las listas anidadas, incluso las horizontales, también se llamará al elemento de renderizado. Por lo tanto, tenemos que memoizar todo, y en nuestro caso serían los elementos de las diapositivas. Y eso es lo que hicimos, y pasamos de esto a esto. Puede ser difícil de ver, pero ahora tenemos mucho más gris en la parte inferior.

Oh, tenemos algunas cosas que aparecen en el lado derecho. Podemos verificar qué es esto. Bien, en realidad se están volviendo a renderizar por primera vez, lo que significa que probablemente son nuevos elementos de lista que aparecen al desplazarnos hacia abajo. Esto está bien.

Veamos primero el excesivo renderizado. Ahora tenemos esto. Muchos elementos grises en la parte inferior. Verifiquemos más puntaje. Y pasamos de 52 a 54. Básicamente, casi lo mismo. No es una mejora muy significativa. Así que necesitamos profundizar más.

Muy bien, veamos un poco más esos carruseles. Si nos acercamos a este aquí, podemos ver que básicamente es una lista virtualizada que se vuelve a renderizar. De acuerdo con nuestro carrusel, hemos trabajado con 10 diapositivas. Espera, ¿10 diapositivas? No, en realidad nuestros carruseles solo tienen 4 diapositivas. Oh, pero eso es correcto. Agregamos la propiedad 'loop' en el carrusel Snap de React Native, lo que significa que en realidad agrega 3 diapositivas en cada diapositiva de tu carrusel al principio y al final para lograr el efecto de bucle infinito. Los más astutos habrán notado que esto suma 10. Así que decidimos desactivar esta propiedad por razones de rendimiento.

Ahora pasamos de esto a esto. Podemos ver que en efecto solo tenemos 4 diapositivas que se renderizan. Así que verifiquemos nuestro puntaje. Nuestro puntaje es mucho mejor. Hemos llegado a 70. C, GS, es solo eso por un segundo. Genial, genial. Aún está bien. Muy bien. Estamos llegando allí, pero aún no es perfecto.

Entonces, vamos aún más profundo. Haz clic en este primer carrusel, esta lista virtualizada. Podemos ver todos los elementos. Si nos acercamos al primero, esto es lo que vemos. Aquí tenemos nuestra lista virtualizada. Aún tarda 75 milisegundos en no hacer nada, básicamente. Pero notamos este componente animado en color naranja. React DevTools imprimirá, en un color diferente, como naranja aquí, los elementos que tienen un tiempo propio muy largo. Por lo tanto, son muy costosos de renderizar en comparación con sus hijos. Y este componente aquí es costoso de renderizar.

Pero, ¿de dónde viene? La parte superior aquí es del código de FlatList, de la lista virtualizada al renderizar la celda. Esta parte gris es nuestra diapositiva. Está memoizada. Entonces, aquí, esto proviene de la celda natural de React Native. En realidad, el componente animado está aquí para tener una transición genial y agradable. Pero no solo es bastante costoso de renderizar, ni siquiera está memoizado, y debería estarlo. Podríamos solucionar el código de la celda natural de React Native. O en este punto, nos damos cuenta de que la anidación de listas virtualizadas es complicada. Entonces, la pregunta es, ¿podemos evitarla? Y la respuesta es sí, porque recuerda lo que dije sobre la virtualización de forma predeterminada en React Native, mostrando el equivalente a 21 pantallas de elementos. En nuestro caso, solo tenemos cuatro elementos, por lo que la virtualización aquí para el carrusel no aporta ningún beneficio. Así que decidimos recodificarlo nosotros mismos con una vista de desplazamiento y la propiedad 'paging enable', básicamente. Y ahora solo tenemos gris aquí cuando nos desplazamos hacia abajo. Nada se vuelve a renderizar en exceso.

Verifiquemos nuestro puntaje. Ahora estamos en 90, y el JS nunca está en cero, y el hilo de la interfaz de usuario siempre está bien. ¡Lo logramos! Te animo a que lo pruebes, mide el rendimiento de tu aplicación, toma un dispositivo Android de gama baja, encuentra áreas con el complemento con FPS en cero en el lado de JS o por debajo de 60, analiza esos problemas y soluciónalos, y verifica la mejora en tu puntaje. Eso es todo. Gracias por ver, espero que hayas disfrutado de la charla. Si tienes alguna pregunta, no dudes en contactarme en Twitter o seguirme, tuiteo principalmente sobre el rendimiento de React Native. ¡Gracias!