Série d'optimisation des performances iOS 04｜Problèmes de performances haute fréquence lors du chargement et de la mise en cache des images

Les images sont presque l’endroit le plus probable pour des problèmes de performances récurrents dans les projets iOS.

Vous le rencontrez souvent dans divers scénarios :

• La page d’accueil se bloque
• Liste des images déroulantes
• Augmentation de la mémoire
• Le premier écran se charge lentement
• Les images clignotent lors du défilement
• Pour une même page de contenu, s’il y a plus d’images, la vitesse sera évidemment plus lente.

Lorsqu’on traite initialement de ce type de problème, le problème de l’image sera simplifié en une phrase :

Ajoutez ensuite du cache.

La mise en cache est bien sûr importante, mais si vous comprenez l’optimisation d’image uniquement comme “l’existence ou non d’un cache”, c’est généralement loin du véritable problème. Car la vraie complexité du lien image est qu’il cumule de nombreux coûts :

• Télécharger
• Décoder
• Zoomer
• Rendu
• maintien de la mémoire
• Gestion du cycle de vie

Un problème d’image est donc presque toujours un problème de système.

1. Les images sont plus susceptibles d’amplifier les problèmes que les données ordinaires.

Car les images présentent par nature plusieurs caractéristiques qui rendent leur performance fragile :

• La taille des ressources est généralement plus grande
• Souvent, un décodage est requis avant l’affichage
• Des appareils et des scènes de différentes tailles déclencheront la mise à l’échelle
• Apparaîtra fréquemment dans la liste
• Facilement mis en cache et occupant la mémoire pendant longtemps

En d’autres termes, les images sont un type de ressource qui exerce à la fois une pression sur le processeur, la mémoire, la bande passante et le rendu.

Cela montre également qu’une fois que l’image n’est pas correctement traitée, elle n’apparaît souvent pas comme un seul problème, mais plusieurs problèmes apparaissent ensemble :

• Cartes à rouler
• mémoire élevée
• Premier écran lent

2. Le téléchargement n’est pas le seul coût. Ce que beaucoup d’équipes sous-estiment réellement, c’est le timing de décodage.

Lorsque ce sujet est abordé, le chargement des images est au centre de l’attention : téléchargement :

-L’image est-elle grande ou pas ?

• Le réseau est-il lent ?
• le cache n’a pas été atteint

Mais dans les projets réels, le téléchargement n’est souvent pas le seul coût, et ce n’est souvent même pas le coût principal du défilement. Ce qui a vraiment tendance à ralentir l’expérience aux moments critiques, c’est souvent :

• Décodage d’images
• Traitement de la taille de pré-affichage
• Préparation de l’image qui se produit sur le fil principal lors du défilement

En d’autres termes, « téléchargement terminé » d’une image ne signifie pas « prête à être affichée ». Si une grande partie du travail de traitement de l’image est appliquée au moment de l’affichage, la page perdra facilement des images au moment le plus sensible.

3. Plus il y a de caches, mieux c’est. La stratégie de cache elle-même peut créer de nouveaux problèmes.

La mise en cache est nécessaire, mais elle n’est jamais gratuite.

Si la stratégie de mise en cache n’est pas claire, les conséquences courantes incluent :

• Le cache est évidemment touché, mais la mémoire devient de plus en plus élevée.
• La mise en cache disque est trop agressive et la stratégie de nettoyage est déraisonnable
• La même image est mise en cache à plusieurs reprises dans plusieurs tailles
• L’accès au cache semble bon lors du changement rapide de liste, mais la page est toujours bloquée

Cela montre que ce que la mise en cache veut vraiment résoudre n’est pas seulement « moins la prochaine fois », mais inclut également :

• Quelle taille mettre en cache
• Combien de temps conserver
• Quand éliminer
• Quelles ressources conviennent à la mise en cache mémoire et lesquelles conviennent uniquement à la mise en cache disque

Par conséquent, la mise en cache des images ne peut jamais être expliquée clairement par un simple « ajout de cache ». Il s’agit essentiellement d’un ensemble de stratégies de cycle de vie des ressources.

4. Les images de la liste sont particulièrement susceptibles de devenir une source de décalage.

Car le scénario de liste répond naturellement à plusieurs conditions à haut risque :

• Grand nombre d’images sur le même écran
• Fréquence de défilement élevée
• La réutilisation et le recyclage sont fréquents
• Les utilisateurs sont très sensibles aux pertes d’images

Si vous faites également ces choses en même temps dans ce scénario :

• Décodage d’images
• Calcul de la taille
• Recadrage des coins arrondis
• Superposition de texte enrichi

Ensuite, le fil de discussion principal peut facilement être submergé lors du défilement.

Par conséquent, l’aspect le plus critique de l’optimisation des images de liste est :

Ce travail s’effectue-t-il sur le chemin critique glissant ?

Si cela se produit sur le chemin critique, quel que soit le coût supplémentaire, il sera amplifié par le roulement à haute fréquence.

5. Un malentendu très courant : tous les problèmes d’image sont attribués à des problèmes de réseau

Dans les projets réels, les gens disent souvent :

• Il y a beaucoup de photos, donc c’est lent
• L’image est lente, c’est donc un problème de réseau

Ce raisonnement est souvent incomplet.

Parce que de nombreux problèmes d’image subsistent même dans des conditions de réseau difficiles et des accès au cache. Les raisons sont :

• L’image a été obtenue, mais n’a pas été décodée au préalable
• La taille de l’image est inappropriée et un traitement supplémentaire a été effectué avant l’affichage.
• L’état change trop lorsque la liste défile, provoquant un grand nombre de redessinages

Ainsi, dans la question imagée, « l’acquisition de ressources » n’est qu’une partie du lien. La vraie difficulté est de savoir si chaque étape du lien se déroule au bon moment.

6. Lors de l’optimisation des liens d’images, certaines des questions que je pose le plus souvent

Si je devais résoudre une question de performances liée à l’image aujourd’hui, je commencerais généralement par demander :

1. Le problème est que le premier écran est lent, que la liste est bloquée ou que la mémoire est saturée.
2. L’image commence-t-elle à supporter des coûts de traitement élevés au moment où elle est affichée ?
3. L’image actuellement chargée est-elle de taille appropriée et n’est-elle pas une réduction brutale de l’image originale ?
4. Qu’est-ce qui arrive dans le cache ? L’image originale, l’image traitée ou la taille de la clé ne correspondent-elles pas du tout ?
5. Le lien vers l’image demande-t-il trop de travail au fil de discussion principal ?

Ces questions sont plus utiles que « essayez une autre bibliothèque » car elles se rapprochent directement du coût réel.

7. Conclusion : les problèmes d’image surviennent fréquemment. En apparence, le tableau semble spécial, mais en réalité il s’en rapproche davantage et s’étend naturellement sur plusieurs dimensions de ressources.

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

La raison pour laquelle le chargement et la mise en cache des images est toujours un domaine avec une incidence élevée de problèmes de performances est qu’en apparence, cela semble “les images sont difficiles”, mais en fait, cela ressemble plus au fait que cela implique également la bande passante, le processeur, la mémoire, le timing de rendu et la gestion du cycle de vie. Une fois qu’un lien est conçu de manière déraisonnable, le problème sera rapidement amplifié.

Ainsi, ce que l’optimisation d’image doit vraiment faire, ce n’est pas seulement le cache, mais aussi :

• Télécharger
• Décoder
• Zoomer
• cache
• Afficher le timing

Prenez tout ce lien ensemble.