Performances de UICollectionView - _updateVisibleCellsNow

Question

Je travaille sur un projet personnalisé UICollectionViewLayout qui affiche les cellules organisées par jour/semaine/mois.

Le défilement n'est pas fluide, et il semble que le décalage soit causé par [UICollectionView _updateVisibleCellsNow] qui est appelé sur chaque boucle de rendu.

Les performances sont correctes pour < 30 éléments, mais à partir de 100 éléments, elles sont terriblement lentes. S'agit-il d'une limitation de UICollectionView et des mises en page personnalisées, ou est-ce que je ne donne pas assez d'informations à la vue pour qu'elle fonctionne correctement ?

Source ici : https://github.com/oskarhagberg/calendarcollection

Mise en page : https://github.com/oskarhagberg/calendarcollection/blob/master/CalendarHeatMap/OHCalendarWeekLayout.m

Source de données et délégué : https://github.com/oskarhagberg/calendarcollection/blob/master/CalendarHeatMap/OHCalendarView.m

Profil de temps :

Mise à jour

Peut-être est-ce futile ? Quelques tests avec un simple UICollectionViewController avec un UICollectionViewFlowLayout qui reçoit approximativement la même quantité de cellules/écran donne un profil temporel similaire.

Je pense qu'il debe être capable de gérer ~100 cellules opaques simples à la fois sans la gigue. Est-ce que je me trompe ?

Answer 1

N'oubliez pas non plus d'essayer de rastériser la couche de la cellule :

cell.layer.shouldRasterize = YES;
cell.layer.rasterizationScale = [UIScreen mainScreen].scale;

J'avais 10 fps sans ça, et boom 55fps avec ! Je ne suis pas vraiment familier avec le GPU et le modèle de composition, donc ce qu'il fait exactement n'est pas tout à fait clair pour moi, mais en gros il aplatit le rendu de toutes les sous-vues en un seul bitmap (au lieu d'un bitmap par sous-vue ?). Quoi qu'il en soit, je ne sais pas s'il y a des inconvénients, mais il est nettement plus rapide !

Answer 2

J'ai mené une enquête approfondie sur les performances de UICollectionView. La conclusion est simple. Les performances sont médiocres pour un grand nombre de cellules.

---

---

EDIT : Mes excuses, je viens de relire votre message, le nombre de cellules que vous avez devrait être correct (voir le reste de mon commentaire), donc la complexité des cellules peut aussi être un problème.

Si votre conception le permet, vérifiez :

1. Chaque cellule est opaque.

2. Le contenu des cellules s'accroche aux limites.

3. Les coordonnées des cellules ne contiennent pas de valeurs fractionnaires (par exemple, elles sont toujours calculées comme des pixels entiers).

4. Essayez d'éviter les chevauchements de cellules.

5. Essayez d'éviter les ombres portées.

---

---

La raison en est en fait très simple. Beaucoup de gens ne la comprennent pas, mais elle vaut la peine d'être comprise : Les UIScrollViews n'utilisent pas de Core Animation pour défiler. Ma croyance naïve était qu'elles impliquaient une "sauce" secrète d'animation de défilement et qu'elles demandaient simplement des mises à jour occasionnelles aux délégués de temps en temps pour vérifier le statut. Mais en fait, les vues de défilement sont des objets qui n'appliquent directement aucun comportement de dessin. Tout ce qu'ils sont vraiment, c'est une classe qui applique une fonction mathématique abstraite du placement des coordonnées des UIViews qu'ils contiennent, de sorte que les coordonnées des vues sont traitées comme relatives à un plan abstrait de ContentView plutôt que relatives à l'origine de la vue qui les contient. Une vue défilante mettra à jour la position du plan de défilement abstrait en fonction de l'entrée de l'utilisateur (par exemple, le balayage) et, bien sûr, il y a aussi un algorithme physique qui donne un "momentum" aux positions des coordonnées traduites.

Maintenant, si vous deviez produire votre propre objet de mise en page de vue de collection, en théorie, vous pourriez en produire un qui inverse à 100% la translation mathématique appliquée par la vue de défilement sous-jacente. Ce serait intéressant mais inutile, car il semblerait alors que les cellules ne bougent pas du tout lorsque vous les faites glisser. Mais je soulève cette possibilité parce qu'elle illustre le fait que l'objet de mise en page de la vue de collection travaillant avec l'objet de vue de collection lui-même effectue une opération très similaire à celle du scrollview sous-jacent. Par exemple, il offre simplement la possibilité d'appliquer une traduction mathématique supplémentaire, image par image, des attributs des vues à afficher, et dans la plupart des cas, il s'agira d'une simple traduction des attributs de position.

Ce n'est que lorsque de nouvelles cellules sont insérées, supprimées, déplacées ou rechargées que CoreAnimation intervient, le plus souvent en appelant :

- (void)performBatchUpdates:(void (^)(void))updates
                 completion:(void (^)(BOOL finished))completion

UICollectionView demande les attributs de mise en page des cellules pour chaque image de défilement et chaque vue visible est mise en page pour chaque image. Les UIView sont des objets riches optimisés pour la flexibilité plus que pour les performances. Chaque fois qu'une vue est disposée, le système effectue un certain nombre de tests pour vérifier son alpha, son zIndex, ses sous-vues, ses attributs d'écrêtage, etc. La liste est longue. Ces vérifications et les modifications de la vue qui en résultent sont effectuées pour chaque élément de vue de la collection pour chaque image.

Pour garantir de bonnes performances, toutes les opérations image par image doivent être effectuées dans un délai de 17 ms. [J'ai mis cette clause entre crochets car j'ai relu votre message et je me suis rendu compte que je l'avais mal lu. Avec le nombre de cellules que vous avez, il ne devrait pas y avoir de problème de performance. J'ai personnellement constaté qu'avec un test simplifié avec des cellules vanille, contenant une seule image en cache, la limite testée sur un iPad 3 est d'environ 784 cellules à l'écran avant que les performances ne commencent à chuter en dessous de 50 images par seconde.

Dans la pratique, vous devrez rester en deçà de cette valeur.

Personnellement, j'utilise mon propre objet de mise en page personnalisé et j'ai besoin de performances plus élevées que celles fournies par UICollectionView. Malheureusement, je n'ai exécuté le test simple ci-dessus qu'à un certain stade du développement et j'ai réalisé qu'il y avait des problèmes de performances. Je vais donc retravailler le back-port open source de UICollectionView, PSTCollectionView. Je pense qu'il existe une solution de contournement qui peut être mise en œuvre de sorte que, juste pour le défilement général, la couche de chaque élément de cellule est écrite en utilisant une opération qui contourne la mise en page de chaque cellule UIView. Cela fonctionnera pour moi puisque j'ai mon propre objet de mise en page, et je sais quand la mise en page est nécessaire et j'ai une astuce qui permettra au PSTCollectionView de revenir à son mode de fonctionnement normal à ce moment-là. J'ai vérifié la séquence d'appels et elle ne semble pas être trop complexe, ni du tout irréalisable. Mais il est certain que ce n'est pas trivial et que d'autres tests doivent être effectués avant que je puisse confirmer que cela fonctionnera.

Answer 3

Quelques observations supplémentaires qui pourraient être utiles :

Je suis en mesure de reproduire le problème, en utilisant une mise en page de flux avec environ 175 éléments visibles à la fois : le défilement est fluide dans le simulateur, mais il est très lent sur l'iPhone 5. Je me suis assuré qu'ils sont opaques, etc.

Ce qui prend le plus de temps semble être le travail avec un NSDictionary mutable à l'intérieur. _updateVisibleCellsNow . Il s'agit à la fois de copier le dictionnaire et de rechercher des éléments par clé. Les clés semblent être UICollectionViewItemKey et la balise [UICollectionViewItemKey isEqual:] est la méthode la plus longue de toutes. UICollectionViewItemKey contient au moins type , identifier y indexPath et la comparaison de la propriété contenue indexPath [NSIndexPath isEqual:] prend le plus de temps.

D'après cela, je suppose que la fonction de hachage de UICollectionViewItemKey n'est pas suffisante car isEqual: est appelé si souvent pendant la recherche de dictionnaire. De nombreux éléments peuvent se retrouver avec le même hachage (ou dans le même seau de hachage, je ne sais pas comment fonctionne le NSDictionary).

Pour une raison quelconque, il est plus rapide avec tous les éléments dans une seule section, par rapport à plusieurs sections avec 7 éléments dans chacune. Probablement parce qu'il passe beaucoup de temps dans NSIndexPath isEqual et que c'est plus rapide si la ligne diffère en premier, ou peut-être parce que UICollectionViewItemKey obtient un meilleur hachage.

Honnêtement, cela semble vraiment bizarre que UICollectionView fasse ce lourd travail de dictionnaire à chaque frame de défilement, comme mentionné précédemment, chaque mise à jour de frame doit être <16ms pour éviter le lag. Je me demande si ce nombre de recherches dans le dictionnaire est suffisant :

• Vraiment nécessaire pour le fonctionnement général de UICollectionView
• Il s'agit de prendre en charge certains cas limites rarement utilisés et qui peuvent être désactivés pour la plupart des mises en page.
• Du code interne non optimisé qui n'a pas encore été corrigé.
• Une erreur de notre part

Espérons que nous verrons une amélioration cet été pendant la WWDC, ou si quelqu'un d'autre ici peut trouver un moyen de le corriger.

Answer 4

Le problème n'est pas le nombre de cellules que vous affichez dans le total de la vue de la collection, mais le nombre de cellules qui sont à l'écran en même temps. Comme la taille des cellules est très petite (22x22), vous avez 154 cellules visibles à l'écran en même temps. Le rendu de chacune d'entre elles est ce qui ralentit votre interface. Vous pouvez le prouver en augmentant la taille des cellules dans votre Storyboard et en relançant l'application.

Malheureusement, il n'y a pas grand-chose que vous puissiez faire. Je vous recommanderais d'atténuer le problème en évitant de couper les limites et en essayant de ne pas mettre en œuvre l'option drawRect: puisque c'est lent.

Answer 5

Un grand coup de chapeau aux deux réponses ci-dessus ! Voici une autre chose que vous pouvez essayer : J'ai eu de grandes améliorations dans UICollectionView les performances en désactivant la mise en page automatique. Bien que vous deviez ajouter du code supplémentaire pour agencer l'intérieur des cellules, le code personnalisé semble être beaucoup plus rapide que la mise en page automatique.