Série d'optimisation des performances iOS 01｜Objectifs et portée de l'optimisation des performances iOS

Lorsque le sujet de l’optimisation des performances est évoqué, la première réaction est généralement :

• Bégaiement ou pas
• Pas de perte d’image
• Est-ce que c’est rapide pour démarrer ?

Bien sûr, ce sont tous des problèmes de performances, mais si vous comprenez l’optimisation des performances uniquement comme « rendre la page plus rapide », il sera facile de vous laisser distraire plus tard. Parce que les problèmes de performances dans les projets réels sont essentiellement un groupe de problèmes de qualité mélangés.

Dans le même produit, des problèmes de performances peuvent apparaître comme :

• Le premier écran s’ouvre lentement
• La liste ne glisse pas facilement
• Images parfois perdues sur la page de détails
• La mémoire ne retombe pas lorsqu’elle augmente
• Consommation d’énergie anormale
• Il est très lent de revenir sur la page après être passé de l’arrière-plan au premier plan.

La première question à laquelle l’optimisation des performances doit réellement répondre est donc :

De quelle sorte de lenteur est la « lente » dont nous parlons maintenant ?

1. L’optimisation des performances consiste à optimiser la qualité globale de fonctionnement.

Les vrais problèmes de performances iOS peuvent au moins être divisés dans les catégories suivantes :

• Temps de démarrage
• La page se fige et les images chutent
• Utilisation et recyclage de la mémoire
• Puissance et chaleur
• Efficacité de l’utilisation du réseau et des ressources

Il semble que ces types de problèmes puissent tous être classés comme « performances », mais leurs causes, méthodes de dépannage et méthodes d’optimisation sont complètement différentes.

Par exemple :

• Démarrage lent, souvent lié aux liens d’initialisation et aux chemins de démarrage à froid
• Le retard de la liste est souvent lié à la charge de travail du thread principal, à la mise en page et au décodage des images.
• Une mémoire élevée peut être liée à la stratégie de mise en cache, au cycle de vie des objets et à la conservation des images.
• Une batterie élevée est souvent liée à des interrogations fréquentes, à des tâches en arrière-plan et à des actualisations non valides.

Si vous ne classifiez pas le problème en premier, il est facile qu’une fausse activité apparaisse plus tard : J’ai ouvert de nombreux outils et examiné de nombreux indicateurs, mais je ne me suis jamais vraiment rapproché du cœur du problème.

2. Les performances perçues par l’utilisateur et les performances de l’index système ne sont pas la même chose, mais les deux sont importantes

Les problèmes de performances peuvent être grossièrement divisés en deux perspectives :

1. Problèmes de performances perçus par l’utilisateur

Les utilisateurs peuvent le ressentir directement, comme :

• La page est restée bloquée à l’ouverture.
• Liste des chutes de cadres coulissants
• Les résultats de recherche apparaissent très lentement
• Lorsque l’application est ouverte, l’écran reste vide pendant un long moment

Ce type de problème est généralement hautement prioritaire car il a un impact direct sur l’expérience et la rétention.

2. Problèmes de performances des indicateurs

Les utilisateurs ne seront peut-être pas en mesure de le décrire clairement, mais il apparaîtra progressivement comme :

• Fièvre
• Consommation d’énergie
• Fréquemment tué en arrière-plan
• La mémoire reste longtemps à un niveau élevé

Ce type de problème ne se transformera pas nécessairement immédiatement en un avis négatif, mais il se retournera lentement contre la qualité de l’ensemble du produit.

Le problème pour de nombreuses équipes est le suivant : Concentrez-vous simplement sur le premier et pensez « ne perdez pas d’images » ; ou simplement se concentrer sur les indicateurs de l’outil, en oubliant que l’utilisateur ne se soucie pas d’un certain nombre lui-même, mais se soucie de savoir s’il finira par se bloquer, générer de la chaleur et consommer de l’énergie.

3. De nombreuses « optimisations de performances » sont essentiellement des problèmes de limites d’ingénierie.

C’est le point le plus sous-estimé.

De nombreux problèmes de performances ont finalement été étudiés, et le véritable problème résidait dans la perte de contrôle au niveau de l’ingénierie :

• La page demande trop de travail qui devrait être coulé
• Trop de logique inutile est insérée dans la phase d’initialisation
• Le chargement, la mise en cache et le décodage des images ne sont pas superposés
• Les frontières entre réutilisation des listes et mise à jour des données sont floues
• Les mêmes données sont traitées plusieurs fois

Cela signifie que l’optimisation des performances relève souvent du « remboursement structurel de la dette ».

Par conséquent, si les limites des responsabilités d’un projet sont au départ très confuses, les problèmes de performance ultérieurs ne seront souvent pas des problèmes isolés, mais l’une des manifestations de problèmes structurels.

4. L’erreur d’appréciation la plus courante en matière d’optimisation des performances : attribuer toute lenteur au “rendu” ou au “périphérique”

Une situation courante est que lorsque vous voyez une carte, vous pensez d’abord à :

• Le matériel est-il trop vieux ?
• Y a-t-il trop d’animations ?
• Est-ce parce que SwiftUI lui-même n’est pas bon ?

Bien sûr, cela est possible, mais les situations les plus courantes dans les projets réels sont :

• Trop de traitement de données est effectué sur le thread principal
• Décodage d’image lors du défilement de la liste
• Trop de mises à jour invalides déclenchées par un changement d’état
• De nombreuses initialisations non critiques sont effectuées à l’ouverture du premier écran

En d’autres termes, le problème ne réside souvent pas dans le « cadre de rendu », mais dans le fait de « laisser le thread principal assumer trop de travail disproportionné par rapport aux actions actuelles de l’utilisateur ».

L’optimisation des performances consiste donc à répondre en premier :

-Sur quelle couche se situe le goulot d’étranglement actuel ?

• Ce travail aura lieu à ce moment-là
• Ce n’était pas censé arriver ici ?

5. L’optimisation des performances est un ensemble de « capacités de classification des problèmes »

Une situation courante est que lorsque vous pensez à l’optimisation des performances, vous recherchez :

• Conseils d’optimisation de démarrage
• Conseils d’optimisation de liste
• Conseils pour la mise en cache des images

Les techniques sont certes utiles, mais elles peuvent facilement se transformer en saisie aveugle si le problème n’est pas catégorisé au préalable.

Un point de départ plus pratique est généralement :

1. Le problème vient du démarrage, du retard, de la mémoire ou de la consommation d’énergie.
2. Ce problème est-il un type de perception de l’utilisateur ou un type d’indicateur ?
3. Est-ce concentré sur une certaine page ou dans toute l’application ?
4. Récidive-t-il de manière constante ou n’apparaît-il que sporadiquement dans certaines voies ?

Cette étape ne semble pas être une « démonstration de compétences », mais elle détermine si l’enquête ultérieure aura une direction.

6. L’optimisation des performances revient souvent à « la responsabilité et les limites »

Parce que les problèmes de performances indiquent essentiellement : À un moment donné, le système demande trop de travail qu’il ne devrait pas.

Par exemple :

• Une initialisation excessive a été effectuée lors de l’ouverture de la page.
• Les calculs de décodage et de mise en page sont effectués simultanément lors du défilement de la liste
• Une certaine stratégie de mise en cache entraîne une occupation de la mémoire pendant une longue période
• Un certain changement d’état entraîne la reconstruction répétée des vues multicouches

Ces questions ont finalement forcé une nouvelle réponse :

• Qui devrait faire ce travail ?
• Quand faut-il le faire ?
• Est-ce qu’il faut le faire à chaque fois ?
• Peut-il être différé, fractionné ou mis en cache ?

Par conséquent, l’optimisation des performances implique souvent de « réorganiser la répartition du travail du système ».

7. Conclusion : Ce qui doit vraiment être optimisé dans l’optimisation des performances, c’est le déséquilibre entre l’expérience utilisateur et les ressources système.

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

Ce que l’optimisation des performances iOS doit vraiment optimiser, c’est l’inadéquation entre la charge de travail du système et la perception de l’utilisateur derrière des problèmes spécifiques tels que le démarrage, le retard, la mémoire et la consommation d’énergie.

La première étape consiste donc toujours à distinguer le type de problème :

• Où est la lenteur ?
• Qu’est-ce qui est important ?
• Où est-il dépensé ?
• Cela arrivera à ce moment-là

Ce n’est que si ces questions sont d’abord clarifiées que les optimisations ultérieures ne se transformeront pas en une accumulation d’expériences sans but.