Série d'optimisation des performances iOS 05 ｜ Pratiques efficaces pour l'optimisation du démarrage iOS

L’optimisation des startups est un sujet qui peut facilement être transformé en un « ensemble de morceaux ».

Les gens se souviennent généralement de nombreuses expériences :

• Faire moins d’initialisation
• Chargement paresseux
• Rendre le premier écran simple
• Ne faites pas trop de requêtes au démarrage

Bien sûr, ces suggestions sont toutes correctes, mais si le jugement fondamental n’est pas compris, il finit souvent par dire : « Nous semblons avoir changé beaucoup de choses, mais le démarrage n’est toujours pas significativement plus rapide ».

La véritable clé de l’optimisation d’une startup est une question très simple :

Quelles tâches appartiennent réellement au chemin critique et doivent être accomplies avant que l’utilisateur ne voie le premier écran, et quelles tâches sont simplement insérées dans la phase de démarrage pour des raisons de commodité ?

1. La cause première d’un démarrage lent est généralement que le chemin critique s’allonge.

De nombreux projets ne tardent pas à démarrer au départ. Le véritable ralentissement est généralement dû au fait qu’à mesure que les fonctionnalités augmentent, de plus en plus de logique s’entasse par défaut sur « faites-le dès que l’application démarre » :

• Initialisation des configurations
• Initialisation du point enterré
• Préparation de l’environnement réseau
• Restauration du statut de l’utilisateur
• Demande de page d’accueil
• Lecture du cache local
• Divers enregistrements SDK

Tout semble raisonnable en soi, mais le problème est que lorsqu’ils sont empilés dans la phase de démarrage, le chemin critique devient de plus en plus lourd.

Ainsi, les problèmes réels les plus courants liés à l’optimisation des startups sont : **Le travail qui n’aurait pas dû être confiné à ce moment s’est accumulé en ce moment depuis longtemps. **

2. Distinguez d’abord le démarrage à froid, le démarrage à chaud et le « temps disponible » que les utilisateurs perçoivent réellement.

Si cette couche n’est pas clairement distinguée, l’optimisation ultérieure sera facilement biaisée.

Car le « démarrage lent » évoqué par les utilisateurs peut faire référence à différentes choses :

• Il n’y a pas d’écran pendant longtemps après avoir cliqué sur l’icône
• La page d’accueil sort, mais elle n’est pas encore opérationnelle.
• Le cadre de la page d’accueil est sorti en premier, et il a fallu beaucoup de temps pour terminer le contenu.

Celles-ci correspondent en réalité à différents stades de lenteur.

D’un point de vue technique, il faut au moins distinguer :

• Démarrage à froid : processus à partir de zéro
• Démarrage à chaud : le processus a repris en mémoire
• Le moment où l’utilisateur est réellement disponible : le moment où l’utilisateur peut voir et commencer à interagir

Pour démarrer l’optimisation, vous devez savoir exactement où vous perdez du temps.

3. La première étape la plus intéressante consiste à superposer le travail lors de la phase de démarrage.

Je divise généralement le travail de la phase de démarrage en trois catégories :

1. Doit être complété avant le premier écran

Par exemple :

• Le squelette d’interface le plus basique
• Initialisation des dépendances principales
• Statut de l’utilisateur clé qui doit être connu immédiatement après le démarrage

2. Terminé dès que possible après l’apparition du premier écran

Par exemple :

• Prélecture des données secondaires
• Quelques rafraîchissements de configuration
• Contenu supplémentaire de l’interface utilisateur non critique

3. Il peut être retardé ou mis en arrière-plan

Par exemple :

• Préparation de certains lieux de sépulture
• N’affecte pas le nettoyage du cache de la page actuelle
• Échauffement des ressources de la page secondaire

Cette étape est plus précieuse que n’importe quelle astuce en un point car elle mène directement à voir : Il s’avère qu’une grande partie de la lenteur est due au fait que « nous ne devrions pas le faire maintenant ».

4. La raison pour laquelle de nombreuses optimisations de démarrage n’ont aucun avantage est qu’elles écrivent uniquement le code local plus rapidement mais ne modifient pas le chemin critique.

C’est un malentendu très courant.

Par exemple, optimiser une certaine période d’initialisation de 40 ms à 10 ms semble une bonne chose. Mais si cette initialisation ne doit pas apparaître sur le chemin critique, alors l’optimisation la plus efficace pourrait être de « ne pas le faire du tout ici ».

Alors pour juger si une optimisation de startup vaut la peine d’être faite, ce que je regarde le plus souvent est :

• Est-ce un travail sur le chemin critique ?
• Peut-il être sorti du chemin critique ?
• Est-ce quelque chose sur lequel les utilisateurs doivent actuellement s’appuyer ?

C’est plus important que de simplement regarder la fonction prendre du temps.

5. Le chargement du contenu de la page d’accueil ralentit souvent l’expérience de démarrage

De nombreuses applications semblent démarrer lentement, pas nécessairement parce que le processus est vraiment lent, mais parce que le contenu disponible sur le premier écran apparaît trop tard.

Par exemple :

• Le squelette de la page d’accueil a été rendu
• Mais il faut attendre que plusieurs demandes reviennent avant que ce soit comme “vraiment disponible”
• Certains modules s’attendent
• Le cache local n’est pas chargé en premier

La lenteur rencontrée par les utilisateurs à l’heure actuelle est en réalité plus proche d’un « problème de stratégie de contenu sur le premier écran » que d’un simple problème technique de démarrage.

Par conséquent, l’optimisation du démarrage est souvent liée à la stratégie du premier écran :

• Quels modules doivent apparaître simultanément
• Quels modules peuvent être utilisés comme écrans squelettes ?
• Quel contenu peut afficher les résultats mis en cache en premier ?

De nombreux démarrages dits lents sont en réalité causés par une organisation déraisonnable du contenu sur le premier écran.

6. Un jugement plus proche du combat réel : ce qui est actuellement lent, c’est “l’initialisation” ou le “premier montage d’écran”

Les deux se confondent souvent.

Initialisation lente

La question est plus biaisée :

-SDK

• Prestations mondiales
• Lecture des configurations
• Injection de dépendances

L’assemblage du premier écran est lent

La question est plus biaisée :

• Le module de la page d’accueil est trop lourd
• Faire trop de travail dès que la page apparaît
• La chaîne de dépendance des données du premier écran est trop longue

L’optimisation dans ces deux directions est complètement différente. Le premier nécessite le démantèlement de l’initialisation et une exécution retardée, tandis que le second nécessite de réexaminer la structure de la page et la stratégie de contenu.

7. Conclusion : La prémisse pour que l’optimisation soit réellement rentable est de commencer par tracer le chemin critique.

Pour le dire sous une forme plus courte, je dirais :

L’optimisation des startups est vraiment rentable. À première vue, il semble qu’il existe de nombreuses compétences. En fait, il s’agit plutôt de distinguer d’abord : quelles tâches appartiennent au chemin critique qui doivent être accomplies avant le premier écran, et lesquelles ne sont que des fardeaux qui ont été commodément insérés dans la phase de démarrage depuis longtemps.

Une fois que le chemin critique n’est pas clair, l’optimisation peut facilement se transformer en diligence partielle. Une fois le chemin critique clair, de nombreuses directions d’optimisation seront très claires.