Série d'optimisation des performances iOS 03 ｜ Problèmes courants liés au bégaiement de la liste iOS

Le retard de liste est le problème de performances le plus courant et le plus facilement mal évalué dans les projets iOS.

Dès que je vois cette situation et que la liste ne se déroule pas bien, je dirai immédiatement :

• Le SwiftUI List est-il trop lent ?
• UICollectionView est-il mal configuré ?
• Ce contrôle est-il intrinsèquement bloqué ?

Ces jugements ne sont parfois pas entièrement erronés, mais ils sont souvent superficiels. La vraie question, la plus centrale, est généralement :

Lors du défilement, une action qui dépend fortement de la réponse rapide du fil principal, quelle quantité de travail supplémentaire le système effectue-t-il en même temps ?

Par conséquent, bien que UITableView, UICollectionView et SwiftUI List soient implémentés de différentes manières, ils se heurtent souvent à des problèmes très similaires.

1. Les listes sont plus susceptibles d’exposer des problèmes de performances que de nombreuses pages.

Parce que la liste est une scène continue à haute fréquence, sensible à chaque image.

Au fur et à mesure que l’utilisateur fait défiler, le système doit continuellement effectuer ces tâches :

• Calculer la mise en page
• Préparer les unités visibles
• Unités de réutilisation et de recyclage
• dessiner du contenu
• Répondre aux gestes

Si le fil principal est également invité à effectuer beaucoup de travail supplémentaire en même temps, tel que :

• Décodage d’images
• Assemblage de texte enrichi
• Analyse JSON
• Calculs de mise en page automatique à coût élevé
• Des changements de statut fréquents conduisent à une actualisation complète

Ce décalage est presque un résultat inévitable.

La raison pour laquelle la liste est si populaire est qu’elle semble mystérieuse en surface, mais en fait elle en est plus proche, ce qui amplifie très évidemment la pression sur le fil principal.

2. Le problème le plus courant est que vous faites quelque chose que vous ne devriez pas faire à ce moment-là pendant le défilement.

Une approche courante lors de l’optimisation consiste à se concentrer uniquement sur la longueur du code de cellule lors de l’optimisation des listes. Mais dans les projets réels, les raisons des cartes de liste ressemblent souvent davantage aux suivantes :

• L’image n’est pas décodée tant qu’elle n’est pas affichée
• La hauteur du texte est calculée à plusieurs reprises pendant le défilement
• la cellule est reformatée et les données converties à chaque fois qu’elle apparaît.
• Trop de mises à jour de l’état de la couche parent déclenchées lors du défilement de la liste
• Un petit changement entraîne un redessinage de la liste entière ou un diff trop cher

Les caractéristiques communes de ces problèmes sont les suivantes : Ils sont censés “ne devraient pas être effectués à ce moment du défilement”.

L’idée la plus importante pour l’optimisation de liste est donc :

• Quelles tâches peuvent être effectuées à l’avance ?
• Quelles tâches peuvent être mises en cache
• Quelles tâches peuvent être reportées
• Quelles mises à jour peuvent être localisées

3. Les images sont souvent responsables des décalages de liste. En apparence, ils ressemblent à des téléchargements, mais ils sont en réalité plus proches du décodage et du traitement de la taille.

De nombreuses équipes disent « trop d’images » lorsqu’elles rencontrent des cartes de liste. Parfois, le sens de cette phrase est bon, mais la raison est souvent fausse.

Ce qui ralentit vraiment le défilement, c’est souvent :

• Décodage d’images
• Zoom d’image
• Chargement de taille inappropriée
• Déclencher fréquemment le traitement d’image sur le thread principal

Cela dit, la chose la plus effrayante à propos du problème graphique est qu’il peut facilement insérer un travail coûteux sur le chemin critique d’un rouleau.

Par conséquent, le cœur de l’optimisation des images dans la liste n’est généralement pas seulement la mise en cache, mais :

• Préparez la taille appropriée à l’avance
• Réduire la pression de décodage au moment de l’affichage
• Évitez les traitements d’image lourds lors du défilement

4. Le traitement des données ralentit souvent l’expérience de défilement.

C’est plus courant qu’on pourrait le penser.

Par exemple, un élément de liste doit être affiché :

• Formatage de l’heure
• Formatage du montant
• Combinaison de texte riche
• Cartographie des balises
• Rédaction de statuts complexes

Si ces choses sont faites temporairement pendant la phase de configuration de la cellule, le thread principal continuera à absorber ce coût pendant le défilement.

La partie la plus gênante de ce type de problème est :

• Fonctionnellement tout à fait correct
• Le coût unique ne semble pas exagéré
• Mais en défilement haute fréquence, il sera agrandi de façon exponentielle

Par conséquent, un principe très important pour l’optimisation des performances des listes est le suivant : **Laissez la couche d’affichage essayer de consommer les données d’affichage préparées au lieu d’effectuer de nombreuses conversions lors du défilement. **

5. Si la méthode de mise à jour du statut est erronée, la liste restera bloquée et elle est souvent confondue avec un problème de mise en page.

Certains problèmes de liste ne sont pas du tout compliqués par la cellule, mais aussi par le fait que la granularité de la mise à jour de l’état est trop grossière.

Par exemple :

• Actualisez toute la liste dès que le mot-clé de recherche change
• Comme un élément et toute l’arborescence d’état de la page est reconstruite
• Un résultat paginé revient et la liste entière est recalculée

Ce type de problème est facilement diagnostiqué à tort comme :

• Les composants de l’interface utilisateur sont trop lents
• Le système de mise en page n’est pas efficace

En fait, le vrai problème est souvent :

**Un changement dans une petite entreprise a déclenché une mise à jour de l’interface utilisateur bien plus importante que nécessaire. **

Ainsi, lorsque la liste de dépannage est en retard, une chose que je demande souvent est :

Quels éléments doivent être concernés par ce changement de statut ? Pourquoi cela a-t-il finalement affecté une si grande zone ?

6. Quels sont les problèmes courants des UITableView, UICollectionView et SwiftUI List ?

Bien que les détails de mise en œuvre de ces trois systèmes soient très différents, les problèmes de performances haute fréquence sont en réalité très similaires :

• faire trop de travail sur le thread principal pendant le défilement
• L’élément de liste indique que les données sont préparées trop tard
• Les traitements d’images et de textes sont placés sur le chemin critique
• La granularité de rafraîchissement est trop grande
• Certaines mises en page ou hiérarchies de vues sont trop complexes

En d’autres termes, leurs problèmes communs ne sont pas :

**La forme interactive de la liste elle-même est particulièrement sensible au timing du thread principal et à l’allocation du travail. **

Par conséquent, la même mauvaise conception peut provoquer des blocages similaires dans trois contrôles de liste différents.

7. Une séquence de dépannage plus proche du combat réel

Si je veux vérifier le problème de décalage de liste aujourd’hui, je ne changerai généralement pas le code en premier, mais je jugerai d’abord dans cet ordre :

1. Un bégaiement se produit lorsque le premier écran apparaît, lors d’un défilement rapide ou lors d’une pagination.
2. Si l’élément de liste actuel contient des images, du texte riche ou une mise en page complexe.
3. Si de nombreuses conversions en temps réel sont effectuées avant l’affichage de la cellule.
4. Si un certain changement d’état local a déclenché un rafraîchissement à trop grande échelle.
5. S’il y a un décodage, une mise à l’échelle ou un recalcul synchronisé pendant le défilement.

La valeur de cette séquence est : Découvrez d’abord “quel travail occupe le fil principal avec le défilement” au lieu de deviner d’abord le problème du framework.

8. Conclusion : L’essence du décalage de liste est généralement que trop de travail est chargé sur le chemin critique alors qu’il ne devrait pas l’être.

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

La liste est bloquée et le noyau défile généralement. Dans ce scénario à haute fréquence, le thread principal entraîne simultanément trop de coûts de mise en page, de décodage, de conversion et de rafraîchissement excessifs.

Les éléments les plus importants pour l’optimisation de la liste sont donc :

• Mettre le travail à l’avance
• Cacher les résultats
• Réduire la granularité du rafraîchissement
• Supprimez le fardeau supplémentaire du chemin critique

Si vous faites correctement ces quatre choses, l’expérience de la liste sera généralement plus stable que le simple ajustement de quelques paramètres.