Serie de optimización del rendimiento de iOS 01 ｜ Objetivos y alcance de la optimización del rendimiento de iOS

Cuando se menciona el tema de la optimización del rendimiento, la primera reacción suele ser:

• Tartamudeo o no
• Sin caídas de fotogramas
• ¿Es rápido para empezar?

Por supuesto, todos estos son problemas de rendimiento, pero si entiende la optimización del rendimiento solo como “hacer que la página sea más rápida”, será fácil distraerse más adelante. Porque los problemas de desempeño en proyectos reales son básicamente un grupo de problemas de calidad mezclados.

En un mismo producto pueden aparecer problemas de rendimiento como:

• La primera pantalla se abre lentamente.
• La lista no se desliza suavemente.
• Ocasionalmente se caen fotogramas en la página de detalles.
• La memoria no retrocede cuando sube.
• Consumo de energía anormal
• Es muy lento volver a ingresar a la página después de cambiar del fondo al primer plano.

Entonces, la primera pregunta que realmente debe responder la optimización del rendimiento es:

¿Qué tipo de lentitud es la “lentitud” de la que hablamos ahora?

1. La optimización del rendimiento consiste en optimizar la calidad general de la ejecución.

Los problemas reales de rendimiento de iOS se pueden dividir al menos en las siguientes categorías:

• Hora de inicio
• La página se congela y cae el cuadro.
• Uso y reciclaje de memoria.
• Energía y calor
• Eficiencia en el uso de redes y recursos.

Parece que todos estos tipos de problemas se pueden clasificar como “rendimiento”, pero sus causas, métodos de solución de problemas y métodos de optimización son completamente diferentes.

Por ejemplo:

• Inicio lento, a menudo relacionado con enlaces de inicialización y rutas de inicio en frío.
• El retraso de la lista a menudo está relacionado con la carga de trabajo, el diseño y la decodificación de imágenes del hilo principal.
• La memoria alta puede estar relacionada con la estrategia de almacenamiento en caché, el ciclo de vida del objeto y la retención de imágenes.
• La batería alta suele estar relacionada con sondeos frecuentes, tareas en segundo plano y actualizaciones no válidas.

Si no clasificas el problema primero, es fácil que luego aparezca un falso estado de ocupación: Abrí muchas herramientas y observé muchos indicadores, pero nunca me acerqué al problema central.

2. El rendimiento percibido por el usuario y el rendimiento del índice del sistema no son lo mismo, pero ambos son importantes

Los problemas de rendimiento se pueden dividir a grandes rasgos en dos perspectivas:

1. Problemas de rendimiento percibidos por el usuario

Los usuarios pueden sentirlo directamente, como por ejemplo:

• La página se trabó al abrirla.
• Lista de caídas de marcos deslizantes
• Los resultados de la búsqueda aparecen muy lentamente.
• Cuando se abre la aplicación, la pantalla se queda en blanco durante mucho tiempo.

Este tipo de problema suele ser una alta prioridad porque afecta directamente la experiencia y la retención.

2. Problemas de rendimiento del indicador

Es posible que los usuarios no puedan describirlo claramente, pero gradualmente aparecerá como:

• Fiebre
• Consumo de energía
• Frecuentemente asesinado en el fondo.
• La memoria permanece en un nivel alto durante mucho tiempo.

Es posible que este tipo de problema no necesariamente se convierta en una crítica negativa de inmediato, pero poco a poco afectará la calidad de todo el producto.

El problema para muchos equipos es: Sólo concéntrate en lo primero y piensa “simplemente no dejes caer fotogramas”; o simplemente centrarse en los indicadores de la herramienta, olvidando que al usuario en realidad no le importa un determinado número en sí, sino si eventualmente se atascará, generará calor y consumirá energía.

3. Muchas de las llamadas “optimizaciones de rendimiento” son esencialmente cuestiones de límites de ingeniería.

Este es el punto más subestimado.

Finalmente se investigaron muchos problemas de rendimiento y el verdadero problema residía en la pérdida de control a nivel de ingeniería:

• La página requiere demasiado trabajo que debería hundirse.
• Se introduce demasiada lógica innecesaria en la fase de inicialización.
• La carga, el almacenamiento en caché y la decodificación de imágenes no están en capas
• Los límites entre la reutilización de listas y la actualización de datos son borrosos.
• Los mismos datos se procesan varias veces.

Esto significa que la optimización del rendimiento suele ser el “pago de la deuda estructural”.

Por lo tanto, si los límites de responsabilidades de un proyecto son originalmente muy confusos, los problemas de desempeño posteriores a menudo no serán problemas aislados, sino una de las manifestaciones de problemas estructurales.

4. El error de juicio más común en la optimización del rendimiento: atribuir toda la lentitud al “renderizado” o al “dispositivo”

Una situación común es que cuando ves una tarjeta, lo primero que piensas es:

• ¿El equipo es demasiado viejo?
• ¿Hay demasiadas animaciones?
• ¿Es porque SwiftUI en sí no es bueno?

Por supuesto que esto es posible, pero las situaciones más comunes en proyectos reales son:

• Se realiza demasiado procesamiento de datos en el hilo principal.
• Decodificación de imágenes mientras se desplaza por la lista
• Demasiadas actualizaciones no válidas provocadas por un cambio de estado
• Se realizan muchas inicializaciones no críticas cuando se abre la primera pantalla

En otras palabras, el problema a menudo no está en el “marco de renderizado”, sino en “dejar que el hilo principal asuma demasiado trabajo que es desproporcionado con las acciones actuales del usuario”.

Entonces, la optimización del rendimiento debe responder primero:

-¿En qué capa está el cuello de botella actual?

• Este trabajo se realizará en este momento.
• ¿No se suponía que pasaría aquí?

5. La optimización del rendimiento es un conjunto de “capacidades de clasificación de problemas”

Una situación común es que cuando piensa en optimización del rendimiento, busca:

• Consejos de optimización de inicio
• Consejos de optimización de listas
• Consejos para el almacenamiento en caché de imágenes

Las técnicas son ciertamente útiles, pero pueden convertirse fácilmente en mecanografía a ciegas si el problema no se clasifica primero.

Un punto de partida más práctico suele ser:

1. El problema es el inicio, el retraso, la memoria o el consumo de energía.
2. ¿Es este problema un tipo de percepción del usuario o un tipo de indicador?
3. ¿Está concentrado en una página determinada o en toda la aplicación?
4. ¿Se repite constantemente o aparece sólo esporádicamente en determinadas vías?

Este paso no parece ser un “alarde de habilidades”, pero determina si la investigación posterior tendrá sentido.

6. La optimización del rendimiento a menudo vuelve a “responsabilidad y límites”

Porque los problemas de rendimiento esencialmente dicen: En algún momento, el sistema asume demasiado trabajo que no debería.

Por ejemplo:

• Se realizó una inicialización excesiva cuando se abrió la página.
• Los cálculos de decodificación y diseño se realizan simultáneamente al desplazarse por la lista
• Una determinada estrategia de almacenamiento en caché hace que la memoria esté ocupada durante mucho tiempo.
• Un cierto cambio de estado hace que las vistas de múltiples capas se reconstruyan repetidamente

Estas preguntas finalmente obligaron a una nueva respuesta:

• ¿Quién debería hacer este trabajo?
• ¿Cuándo se debe hacer?
• ¿Es necesario hacerlo siempre?
• ¿Se puede aplazar, dividir o almacenar en caché?

Por lo tanto, la optimización del rendimiento a menudo implica “reorganizar la distribución del trabajo del sistema”.

7. Conclusión: Lo que realmente necesita optimizarse en la optimización del rendimiento es el desequilibrio entre la experiencia del usuario y los recursos del sistema.

Para decirlo en forma más breve, diría:

Lo que realmente necesita optimizar el rendimiento de iOS es la falta de coincidencia entre la carga de trabajo del sistema y la percepción del usuario detrás de problemas específicos como el inicio, el retraso, la memoria y el consumo de energía.

Entonces el primer paso es siempre distinguir el tipo de problema:

• ¿Dónde está la lentitud?
• ¿Qué es importante?
• ¿Dónde se gasta?
• Esto sucederá en este momento.

Sólo si estas cuestiones se aclaran primero las optimizaciones posteriores no podrán convertirse en una acumulación inútil de experiencia.