Serie de optimización del rendimiento de iOS 05 ｜ Prácticas efectivas para la optimización del inicio de iOS

La optimización del inicio es un tema que puede convertirse fácilmente en una “colección de fragmentos”.

La gente suele recordar muchas experiencias:

• Hacer menos inicialización
• Carga diferida
• Haz que la primera pantalla sea simple.
• No hagas demasiadas solicitudes al inicio

Por supuesto, todas estas sugerencias son correctas, pero si no se capta el criterio central, a menudo termina convirtiéndose en “Parece que hemos cambiado muchas cosas, pero la puesta en marcha todavía no es significativamente más rápida”.

La verdadera clave para la optimización de una startup es una pregunta muy simple:

¿Qué tareas pertenecen realmente a la ruta crítica que debe completarse antes de que el usuario vea la primera pantalla y qué tareas se incluyen convenientemente en la fase de inicio por conveniencia?

1. La causa principal del inicio lento suele ser que la ruta crítica se está volviendo más gruesa.

Muchos proyectos no tardan en comenzar inicialmente. La verdadera desaceleración generalmente se debe a que a medida que aumenta la funcionalidad, cada vez se introduce más lógica en “hacerlo tan pronto como se inicie la aplicación” de forma predeterminada:

• Inicialización de la configuración
• Inicialización del punto enterrado
• Preparación del entorno de red.
• Restauración del estado del usuario.
• Solicitud de página de inicio
• Lectura de caché local
• Varios registros de SDK

Todo parece razonable por sí solo, pero el problema es que cuando se apilan en la fase de inicio, el camino crítico se vuelve cada vez más pesado.

Entonces, los problemas reales más comunes con la optimización del inicio son: **El trabajo que no debería haberse exprimido en este momento se ha acumulado en este momento durante mucho tiempo. **

2. Primero distinga entre arranque en frío, arranque en caliente y el “tiempo disponible” que realmente perciben los usuarios.

Si esta capa no se distingue claramente, la optimización posterior fácilmente estará sesgada.

Porque el “inicio lento” mencionado por los usuarios puede referirse a diferentes cosas:

• No aparece ninguna pantalla durante mucho tiempo después de hacer clic en el icono
• Sale la página de inicio, pero aún no está operativa.
• El marco de la página de inicio apareció primero y tomó mucho tiempo completar el contenido.

En realidad, estos corresponden a diferentes etapas de lentitud.

Desde el punto de vista de la ingeniería, al menos deberíamos distinguir:

• Arranque en frío: proceso desde cero
• Inicio en caliente: el proceso se ha reanudado en la memoria.
• El momento en el que el usuario está realmente disponible: el momento en el que el usuario puede ver y empezar a interactuar.

Para iniciar la optimización, necesita saber exactamente dónde está perdiendo tiempo.

3. El primer paso que vale la pena es estratificar el trabajo en la fase de inicio.

Normalmente divido el trabajo en la fase de inicio en tres categorías:

1. Debe completarse antes de la primera pantalla.

Por ejemplo:

• El esqueleto de interfaz más básico.
• Inicialización de dependencia central
• Estado del usuario clave que debe conocerse inmediatamente después del inicio

2. Completar lo antes posible después de que aparezca la primera pantalla

Por ejemplo:

• Captación previa de datos secundarios
• Algunas actualizaciones de configuración
• Contenido complementario de la interfaz de usuario no crítico

3. Puede retrasarse o quedar en segundo plano

Por ejemplo:

• Preparación para ciertos puntos de entierro.
• No afecta la limpieza de caché de la página actual
• Calentamiento de recursos de la página secundaria

Este paso es más valioso que cualquier truco de un solo punto porque lleva directamente a ver: Resulta que gran parte de la lentitud se debe a que “no deberíamos hacerlo ahora”.

4. La razón por la que muchas optimizaciones de inicio no tienen beneficios es que solo escriben código local más rápido pero no cambian la ruta crítica.

Este es un malentendido muy común.

Por ejemplo, optimizar un determinado período de inicialización de 40 ms a 10 ms suena bien. Pero si esta inicialización no aparece en la ruta crítica, entonces la optimización más efectiva puede ser “no hacerlo aquí en absoluto”.

Entonces, para juzgar si vale la pena realizar una optimización de inicio, lo que miro con mayor frecuencia es:

• ¿Se trata de un trabajo en la ruta crítica?
• ¿Se puede sacar del camino crítico?
• ¿Es algo en lo que los usuarios deben confiar actualmente?

Esto es más importante que simplemente ver cómo la función toma tiempo.

5. La carga del contenido de la página de inicio a menudo ralentiza la experiencia de inicio

Muchas aplicaciones parecen iniciarse lentamente, no necesariamente porque el proceso sea realmente lento, sino porque el contenido disponible en la primera pantalla aparece demasiado tarde.

Por ejemplo:

• Se ha renderizado el esqueleto de la página de inicio.
• Pero tienes que esperar a que vuelvan varias solicitudes antes de que esté “realmente disponible”
• Algunos módulos se esperan unos a otros.
• El caché local no se carga primero.

La lentitud experimentada por los usuarios en este momento está más cerca de un “problema de estrategia de contenido de primera pantalla” que de un simple problema técnico de inicio.

Por lo tanto, la optimización del inicio suele estar vinculada a la estrategia de la primera pantalla:

• Qué módulos deben aparecer simultáneamente
• ¿Qué módulos se pueden utilizar como pantallas esqueleto?
• ¿Qué contenido puede mostrar primero los resultados almacenados en caché?

Muchos de los llamados inicios lentos en realidad se deben a una organización poco razonable del contenido en la primera pantalla.

6. Un juicio más cercano al combate real: lo que actualmente es lento es la “inicialización” o “ensamblaje de la primera pantalla”

Los dos a menudo se confunden.

Inicialización lenta

La pregunta es más sesgada:

-SDK

• Servicios globales
• Lectura de configuración
• Inyección de dependencia

El montaje de la primera pantalla es lento

La pregunta es más sesgada:

• El módulo de la página de inicio es demasiado pesado.
• Trabajar demasiado tan pronto como aparece la página.
• La cadena de dependencia de datos de la primera pantalla es demasiado larga.

La optimización en estas dos direcciones es completamente diferente. El primero requiere desmantelar la inicialización y retrasar la ejecución, mientras que el segundo requiere reexaminar la estructura de la página y la estrategia de contenido.

7. Conclusión: La premisa para que la optimización inicial sea verdaderamente rentable es trazar primero el camino crítico.

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

La optimización del inicio es realmente rentable. En la superficie, parece que hay muchas habilidades. De hecho, está más cerca de distinguir primero: qué tareas pertenecen a la ruta crítica que debe completarse antes de la primera pantalla y cuáles son simplemente cargas que se han insertado convenientemente en la fase de inicio durante mucho tiempo.

Una vez que el camino crítico no está claro, la optimización puede convertirse fácilmente en una diligencia parcial. Una vez que el camino crítico esté claro, muchas direcciones de optimización quedarán muy claras.