Depuración del rendimiento de RN en Android

Hola a todos. Soy Alex. Estoy emocionado de hablarles en la Cumbre de React. Soy líder en BAM y somos una empresa con sede en París. Desarrollamos aplicaciones móviles en Kotlin, Swift, Flutter y, por supuesto, React Native. Hoy quiero hablarles sobre el rendimiento de las aplicaciones de React Native. Ahora, una de las métricas clave para analizar el rendimiento de su aplicación es la tasa de fotogramas. Desea que su aplicación se ejecute a 60 fotogramas por segundo. Una de las cosas buenas que vienen con React Native de serie es esta herramienta. El monitor de rendimiento. Puede obtener las tasas de fotogramas del hilo de UI y también del hilo de JS. Ahora, uno de los problemas a los que nos enfrentamos en nuestra aplicación es que la tasa del hilo de UI era consistentemente baja después de iniciar la aplicación, incluso cuando el usuario no estaba haciendo absolutamente nada. La pregunta era cómo descubrir qué está sucediendo realmente bajo el capó. Y la solución para eso fue Systrace. Systrace es la abreviatura de System Trace. Está disponible de serie en el SDK de Android en la carpeta Platform Tools. Básicamente, es un script para que pueda conectar su aplicación a la computadora y simplemente iniciar el script, hacer algunas cosas en su aplicación, detener el script y se imprimirá un archivo HTML enorme, un archivo de traza. Puede abrir ese archivo en Chrome y cuando lo abra, se verá así. Wow. Es intimidante, ¿verdad? Muy colorido, pero bastante intimidante. Lo primero que desea hacer es en el lado izquierdo, encontrar su aplicación. En mi caso, mi ID de paquete era myapp.debug, así es donde lo encontré. Y luego, debajo de él, dado que estamos hablando de tasas de fotogramas, lo que es realmente interesante es la línea de fotogramas. Si haces zoom un poco, en la línea de fotogramas, notarás muchas F. Hay F rojas, F amarillas y F verdes. Puedes suponer que una F roja es mala y una F verde es buena. De hecho, una F verde es en realidad un fotograma que se pudo calcular en menos de 16 milisegundos para que la aplicación pueda ejecutarse a 60 fotogramas por segundo. Las F amarillas y las F rojas no tanto. Entonces, si estás tratando de analizar problemas de rendimiento, debes echar un vistazo a las fuentes.

de Fs rojas y Fs amarillas. En nuestra aplicación, en realidad teníamos dos fuentes principales de Fs rojas. Echemos un vistazo al primero. Si hacemos zoom en un solo fotograma, esto es aproximadamente 20 milisegundos de tiempo, y podemos ver a nuestro amigo, el hilo de UI. Esto es lo que se informó en el monitor de performance, ¿verdad? Podemos ver que en un solo fotograma, está realizando muchos cálculos, por lo que no puede ajustarse al conjunto de tiempo de 16 milisegundos. Ahora la pregunta es, ¿qué está haciendo realmente? Así que podemos echar un vistazo. En realidad, podemos hacer clic dentro y ver un poco más de detalles, pero es muy detallado. Por ejemplo, vemos que tenemos una función de dibujo que está llevando mucho tiempo, pero esto es básicamente el sistema operativo redibujando cosas. Entonces, algo necesita ser redibujado y lleva mucho tiempo, pero realmente no sabemos qué es. Podemos desplazarnos hacia abajo un poco y encontrar el hilo de renderizado. El hilo de renderizado se ejecuta en la GPU y realiza cálculos costosos en la GPU, y en este caso tenemos un poco de suerte, porque aquí vemos algo sobre la vista de animación Lottie. Ahora, Lottie es un marco de animación y en realidad teníamos una animación Lottie al inicio de nuestra aplicación, y descubrimos que necesitaba ser optimizada, y ese fue el problema de performance. Así que ese es un problema de performance resuelto, queda un problema más por resolver. Veamos el segundo. El segundo ocurría cerca del final del archivo de traza. Aquí podemos ver muchas Fs rojas, ¿verdad? Y esto sucedía cuando el usuario no estaba haciendo nada en absoluto. Esto era muy intrigante. Si hacemos zoom como antes en los fotogramas, podemos ver que muchas cosas suceden en el hilo de UI y el hilo de renderizado. Están ocupados con cálculos, pero no tenemos tanta suerte como antes porque todas las tareas parecen ser muy detalladas. Realmente no podemos entender qué está sucediendo. Sabemos que algo costoso necesita ser redibujado cada vez, pero realmente no sabemos qué es. ¿Qué podemos hacer? Bueno, podemos echar un vistazo a lo que está sucediendo allí. Si nos desplazamos un poco hacia arriba, la sección de CPU es bastante interesante. Podemos ver en cualquier momento dado qué está ejecutando cada una de las CPUs para su aplicación en su dispositivo. Por ejemplo, si hacemos zoom, podemos ver que en este momento, la CPU 4 estaba ejecutando MQTJS. Ese es el hilo JS, y este estaba ejecutando Fresco, que se encarga de las imágenes, porque Fresco es una biblioteca utilizada para manejar imágenes en React Native. Entonces, en este momento, ¿qué está sucediendo realmente? Lo bueno de Systrace es que puedes dibujar un rectángulo, una gran selección de todo lo que está sucediendo en el conjunto de tiempo en la CPU, y en la parte inferior, verás básicamente todas las tareas que se han ejecutado. Si haces clic en la duración de la pared puedes ordenar las tareas según el tiempo de CPU más alto. Y aquí, la primera es el hilo de renderizado. Eso ya lo sabíamos. El hilo de renderizado estaba haciendo algo costoso, pero no sabíamos qué era. El segundo era bastante interesante, porque se llama Chrome inprogre, y una búsqueda rápida nos hizo darnos cuenta de que esto estaba relacionado con las vistas web, así que pensamos en qué vistas web teníamos, y resulta que teníamos anuncios ejecutándose al inicio de nuestra aplicación, y esos anuncios se ejecutan en una vista web, y también necesitaban ser optimizados. Esa fue nuestra segunda fuente de problema de performance. Y ahora, una vez que se resolvieron, solo hay aplicaciones verdes por todas partes. Mucho mejor, ¿verdad? Eso es todo. Espero que hayan aprendido muchas cosas, y no duden en hacerme preguntas. Gracias por ver.