Serie de optimización del rendimiento de iOS 07 ｜ Un proceso de convergencia de causa raíz para la solución de problemas de rendimiento de iOS

Al solucionar problemas de rendimiento de iOS, lo más molesto es que la escena suele ser confusa desde el principio.

El producto dijo que la página de inicio estaba bloqueada, la prueba dijo que se estaban cayendo fotogramas en la lista, el desarrollo pensó que podrían ser las imágenes y el backend sospechó que la interfaz era lenta. Todo el mundo habla como una pregunta, pero cuando empiezas a mirarla, a menudo descubres que no describen lo mismo en absoluto.

Después de hacer este tipo de trabajo varias veces, mi mayor sentimiento es: **La solución de problemas de rendimiento comienza con problemas de convergencia, seguidos del análisis de datos. **

Si el problema no converge primero, cuantas más herramientas abra, más fácil será extraviarse. Porque cada indicador que ves parece tener información, pero cada información no es suficiente para llegar a una conclusión.

El siguiente artículo no habla de “cómo solucionar problemas teóricamente”, sino que escribe de acuerdo con el ritmo que sucederá en un proyecto real: ¿Cómo pasó el problema de la caída de fotogramas en el flujo de información de la página de inicio desde “sentirse un poco atascado” paso a paso hasta el punto en que se puede solucionar manualmente?

Clave la escena primero; de lo contrario, se perderá todo el análisis posterior.

La descripción inicial de ese problema fue muy común:

• La página de inicio no se desliza suavemente.
• Algunos modelos son más obvios
• La última versión parece aún más estancada.

Esta descripción parece información, pero en realidad es casi imposible utilizarla directamente para solucionar problemas. Porque está mezclado con al menos tres capas de cosas:

*El rango de páginas no está claro. *El tipo de fenómeno no está claro. *Las condiciones para la reaparición no están claras.

La descripción que realmente empezó a funcionar se redujo finalmente a esto:

iPhone 13 Pro, iOS 18, inicie sesión en la cuenta A, inicie en frío para ingresar al flujo de recomendaciones de la página de inicio, cambie a la pestaña “Seguir” después de cargar la primera pantalla y luego vuelva al flujo de recomendaciones, deslice hacia arriba 4 pantallas seguidas y continúe soltando fotogramas a partir de la tercera pantalla. El problema ocurre principalmente en la disposición mixta de gráficos y texto y en la disposición mixta de las tarjetas de video.

La importancia de este pasaje no es que esté escrito como un caso de prueba, sino que elimina muchas ambigüedades a la vez:

*Es la tarjeta de flujo recomendada en la página de inicio. *Es más obvio la segunda vez que entras. *se desplaza y suelta fotogramas *Es más evidente la zona donde se mezclan imágenes y textos.

El verdadero comienzo de la investigación a menudo comienza con este “clavar el alcance”. Sin este paso, todo “análisis” posterior puede ser simplemente perseguir la propia imaginación.

No se apresure a mirar las herramientas primero, primero determine si se trata de una congelación ocasional o una velocidad de cuadros baja continua.

Las cuatro palabras “no se desliza suavemente” en realidad pueden corresponder a problemas completamente diferentes.

Lo primero que hice esa vez fue grabar la pantalla y deslizarla varias veces para caracterizar el fenómeno.

Al final, esta es una velocidad de cuadros baja sostenida muy típica:

• Una vez que ingresa a un área de contenido específica, varias pantallas consecutivas no se desarrollarán sin problemas. *es pesado durante toda la fase de rodadura *El sentimiento subjetivo del usuario es que “esta sección no puede deslizarse”

Esta distinción es muy importante.

Porque los retrasos ocasionales suelen parecerse más a:

• Cierta imagen decodificada de repente llegó al hilo principal.
• El tiempo de inicialización de un objeto grande es incorrecto.
• Cierto pase de diseño ocasionalmente se vuelve pesado

Y los fotogramas bajos sostenidos se parecen más a:

• Hacer trabajo repetitivo en cada fotograma.
• La estructura celular en sí es demasiado pesada.
• Los resultados asincrónicos se completan continuamente durante el desplazamiento
• El rango de actualización del estado de la lista es demasiado grande

Si estos dos tipos de cuestiones no se separan al principio, cualquier dato posterior será fácilmente malinterpretado.

La ruta de reproducción debe estar escrita, de lo contrario las palabras “cambiado” no tendrán significado.

Uno de los síntomas más comunes de los problemas de rendimiento es “Era obvio hace un momento, pero ya no está”.

Entonces, en esa solución de problemas, el primer paso que hice fue estúpido, pero muy valioso: escribir la ruta de recurrencia en pasos fijos.

Lo que se resolvió en ese momento fue:

1. Cierra la aplicación y vuelve a iniciarla en frío.
2. Inicie sesión en la cuenta A
3. Ingrese al flujo de recomendaciones de la página de inicio y espere a que la primera pantalla esté completamente estable.
4. Cambie a la pestaña “Seguir”
5. Vuelva al flujo de recomendaciones.
6. Desliza hacia arriba 4 pantallas en rápida sucesión
7. Observe el rendimiento de la velocidad de fotogramas y la ocupación del hilo principal a partir de la tercera pantalla.

Recuerda también el entorno:

*Modelo de equipo

• Versión del sistema *Condiciones de la red
• Nivel de datos
• Si se debe activar el interruptor de depuración

La importancia de esto no es sólo facilitar la reproducción de otros, sino, más importante aún, facilitar la verificación posterior.

Porque la frase más inútil en la optimización del rendimiento es:

Me siento mejor que antes.

No existe un camino fijo y la palabra “evitar” no tiene valor analítico. Puede ser simplemente porque los datos son diferentes, la red es diferente, la página no se desliza al mismo párrafo o incluso el dedo no se desliza tan rápido esta vez.

La primera ronda de juicio no encuentra la causa raíz, solo determina en qué enlace se encuentra el problema.

Cuando empiezo a lidiar con este tipo de problema, quiero preguntar:

• ¿Qué línea de código es lenta?
• ¿Qué función requiere más tiempo?
• ¿Qué biblioteca es el problema?

Pero en una investigación real, esto suele ser demasiado pronto para preguntar.

Lo primero que hice esa vez fue una segmentación aproximada de enlaces:

¿Es un problema de datos o de renderizado?

Este paso es fundamental, porque una página de inicio lenta puede fácilmente hacer que la gente dude instintivamente de la interfaz.

Primero hice una verificación muy directa: Intente arreglar los resultados de la red tanto como sea posible, de modo que los datos al ingresar al flujo de recomendación por segunda vez provengan de resultados existentes en lugar de cambios de la red.

El resultado es claro: Los datos han regresado y el desplazamiento aún es intenso y constante.

Este paso básicamente puede eliminar el “desplazamiento atascado debido a una interfaz lenta” del problema principal.

La interfaz lenta afectará el tiempo de la primera pantalla, pero no explica “después de ingresar por segunda vez, cierto contenido comienza a tener fotogramas bajos continuos”.

¿Es el hilo principal el que está ocupado o es que el trabajo en segundo plano sigue regresando al hilo principal?

Lo siguiente que hay que observar es qué hace el hilo principal cuando la tarjeta está atascada.

El objetivo de este paso también es determinar primero la forma del problema:

• El hilo principal sigue ocupado.
• O las devoluciones de llamada en segundo plano son demasiado densas y el hilo principal se interrumpe uno tras otro.

Lo último que vi fue más de lo primero: El hilo principal no siempre se centra en la fase de desplazamiento.

Esto muestra que la dirección está empezando a quedar clara:

• El foco no está en la red.
• La atención no se centra en una sola gran tarea
• El enfoque se parece más a un enlace de visualización de lista en sí mismo, es demasiado pesado

¿Es un punto único de excepción o una sobrecarga sistémica?

Este es un juicio que valoro siempre.

Si solo una función se agota ocasionalmente durante 200 ms, es fácil de manejar, simplemente cógela. Pero ese no fue el caso esa vez.

Lo realmente problemático de esa época fue que no había ningún punto que fuera tan escandaloso como para ser “un verdadero asesino de un vistazo”, pero muchos gastos pequeños que no eran exagerados se acumularon y todos cayeron en el camino crítico de desplazamiento.

Este tipo de problema es el más molesto porque no tiene una pila particularmente clara como un bloqueo. Es más como si el sistema le dijera que cada pequeña decisión que estaba “escrita así” en el pasado ahora se carga en conjunto.

Sólo vale la pena abrir Instrumentos en este punto, y debe hacerse con sospecha.

Nunca me ha gustado mucho el enfoque de solución de problemas de “abrir todas las herramientas primero y luego hablar”. Es muy fácil utilizar herramientas como sustitutos del pensamiento.

Antes de ingresar a Instrumentos en ese momento, tenía varias dudas en mente:

Sospecha 1: El enlace de la imagen coloca en el período móvil trabajos que no deben colocarse en el período móvil.

Este es el sospechoso más común en escenarios de flujo de información.

Especialmente:

• El tamaño de la imagen de portada no es uniforme
• Disposición mixta de tarjetas gráficas, de texto y de vídeo.
• El ritmo de relleno de la imagen es inestable
• Antes de la visualización, también se realizan procesamientos como esquinas redondeadas, sombras y escalado.

Si todo este trabajo se realiza realmente durante el desplazamiento, será difícil estabilizar la velocidad de fotogramas.

Sospecha 2: La presentación de la célula se preparó demasiado tarde

Muchas listas parecen “lógicamente claras” al principio, pero cuando se desplaza por el equipo, quedará expuesto un viejo problema:

Se realiza una gran cantidad de trabajo de preparación de la visualización cuando la celda está a punto de mostrarse.

Por ejemplo:

• Montaje de texto enriquecido *Recorte de redacción publicitaria
• Formato de hora *Cálculo de altitud
• Juicio del estado de la interfaz de usuario *Preparación de objetos enterrados

Cada elemento no es tan grande por sí solo, pero una vez que todos estén incluidos en la ruta crítica de desplazamiento, pasará de “aceptable” a “la lista completa es pesada”.

Sospecha 3: el rango de actualización de estado es demasiado grande

Esta situación es particularmente común en arquitecturas reactivas.

A primera vista, es solo un cambio de estado de la tarjeta, pero lo que realmente se activa es:

• Reencuadernación a nivel de sección
• Demasiadas diferencias locales
• Combinación de informes de exposición y actualización de la interfaz de usuario
• Las devoluciones de llamadas de precarga regresan con frecuencia al hilo principal

Este tipo de problema es el más molesto, porque no necesariamente causa un pico particularmente alto en una determinada función, pero la experiencia general siempre será mala.

Lo que realmente reduce la dirección son algunas rondas de experimentos baratos.

Esa vez realmente redujimos el problema a unas cuantas rondas de experimentos muy simples.

Experimento 1: reemplazar todas las imágenes con imágenes de marcador de posición

Este experimento es muy tosco, pero extremadamente útil.

Una vez que se reemplaza la imagen, el desplazamiento obviamente vuelve. Este paso no explica directamente que la causa raíz es “demasiadas imágenes”, pero es suficiente para mostrar que los enlaces de imágenes deben ser una de las direcciones principales.

Si continúas preguntando en este momento, ya no será un “sí” general sino más específico:

• Si la decodificación recae en el hilo principal
• ¿La estrategia de tamaño es inconsistente?
• ¿El relleno de imágenes provoca un cambio de diseño?
• ¿Se realiza demasiado procesamiento adicional antes de mostrarlo?

Experimento 2: preprocesar parte del texto dinámico de la celda

Con este cambio, el desplazamiento también se ha mejorado significativamente.

Esto muestra que la otra dirección también es cierta: De hecho, es demasiado tarde para preparar la lista antes de presentarla, y hay más de una o dos de estas tareas.

En otras palabras, el problema es que el enlace de la imagen y el enlace de la presentación están duplicados.

Experimento 3: desactive temporalmente estas acciones marginales, como exposición, precarga y reproducción automática

Después de esta ronda de experimentos, la velocidad de cuadros continuó estabilizándose.

Llegados a este punto el problema está básicamente claro: Es el flujo de información de la página de inicio el que conlleva demasiado trabajo de “simplemente hazlo” durante la etapa de desplazamiento.

Estas tareas suelen parecer razonables por sí solas:

• Las imágenes deben ser rellenadas *La exposición debe ser reportada
• Es necesario realizar una precarga
• Es necesario calentar la tarjeta de video.

Pero cuando se juntan en el camino crítico de desplazamiento, hacen caer toda la lista.

La verdadera causa raíz al final es un conjunto de malas decisiones.

Cuando finalmente aterrizó, el verdadero problema probablemente fue esta combinación de golpes:

• La estrategia de tamaño de imagen no es uniforme, lo que genera costos de procesamiento antes de su visualización.
• Algunas imágenes se decodifican demasiado tarde.
• El trabajo de preparación de la pantalla celular se realiza en el sitio en el hilo principal.
• Las devoluciones de llamada de exposición y precarga son demasiado densas durante el período de desplazamiento
• Los cambios de estado locales de la lista activan un rango de actualización mayor de lo esperado

Así es como se ven realmente muchos problemas de rendimiento.

No es el final de “línea 357 encontrada”, Pero al final, encontrará que el diseño de varias capas no está lo suficientemente restringido y finalmente se asentarán juntos en la etapa de laminado.

Por lo tanto, me disgusta cada vez más el argumento de que “debe haber una función clave para los problemas de rendimiento”. Por supuesto, esto sucede en proyectos reales, pero la mayoría de las veces se trata de “un conjunto de malos resultados que se han acumulado durante mucho tiempo”.

La fase de verificación tiene más miedo a los sentimientos subjetivos. Debes volver al mismo camino para comparar.

Después de la modificación, el problema no se resolvió directamente, sino que se retomó la ruta de recurrencia original.

El mismo dispositivo, la misma cuenta, el mismo método de cambio, el mismo deslizamiento al área de contenido, y luego mira:

• ¿Se siguen produciendo caídas de fotogramas de forma estable?
• ¿El hilo principal sigue centrándose en el mismo período de tiempo?
• ¿Los comportamientos de relleno y borde de la imagen siguen compitiendo con el desplazamiento para competir con el hilo principal?

En este paso, también eché un vistazo a los efectos secundarios:

• Después de conectar el enlace de la imagen, ¿hay algún aumento significativo en la memoria?
• Si realiza demasiado preprocesamiento, ¿la primera pantalla se volverá más lenta?
• Los informes de exposición están retrasados. ¿Se verán afectadas las estadísticas?

Un error que se comete a menudo en la optimización del rendimiento: Sólo se centran en “si un indicador se ve bien”, pero no analizan si ha reemplazado otros problemas.

Pero en el trabajo real, la optimización siempre tiene que ver con el intercambio en la experiencia general. El intercambio aceptable se llama optimización, el intercambio de otros problemas no se llama optimización.

Es más probable que este tipo de artículo se escriba como una charla vacía, pero también es el lugar más realista para solucionar problemas de rendimiento.

Muchos artículos resumidos terminarán escribiendo:

*Defina el problema primero

• Establecer una hipótesis *Para verificar los resultados

Estas palabras son ciertamente ciertas, pero fácilmente pueden convertirse en verdaderas tonterías.

La diferencia en la experiencia real no es si puedes decir estas palabras, sino si has experimentado los siguientes momentos:

• Al principio todos dijeron que parecía el mismo problema, pero en realidad no era el mismo problema en absoluto.
• La dirección que más se parece a la causa raíz a primera vista es sólo una pista falsa al final.
• Todos los indicadores de la herramienta parecen anormales, pero solo hay una línea principal real
• La respuesta final es un conjunto de pequeños gastos generales que se acumulan con el tiempo.

Una vez que haya hecho estas cosas varias veces, naturalmente comprenderá una cosa:

**El valor real de la resolución de problemas de rendimiento es “¿puedo convertir una escena caótica en un vínculo viable?” **Esto no se puede hacer, cuantas más herramientas haya, más complicado será. Al hacer esto, podrá acercarse cada vez más a la causa raíz de muchos problemas sin tener que revisar todos los gráficos.

Cuando analizo los problemas de rendimiento ahora, lo que más me importa es si podemos lograr que el equipo llegue a un acuerdo sobre lo siguiente lo antes posible:

Ahora estamos investigando el mismo problema y ya sabemos en qué enlace se produce principalmente.

Siempre que esto se establezca, las reparaciones posteriores no suelen ser demasiado confusas. Lo realmente difícil es siempre reunir el problema en una forma que pueda abordarse.