Bonjour
ce week-end j'ai commencé à regarder le 2011 WWDC vidéos. Je l'ai trouvé vraiment intéressant sujets sur iOS. Mes favoris étaient au sujet de la performance et des graphiques, mais j'ai trouvé deux d'entre eux, apparemment en contradiction. Bien sûr, il y a quelque chose que je n'ai pas.
Les séances que je parle de la Compréhension UIKit Rendu -121 et de Polissage votre application -105.
Malheureusement, des exemples de code à partir de 2011 n'est pas encore téléchargeable, donc c'est assez difficile d'avoir une vue d'ensemble.
Dans une session, ils expliquent que la plupart de fois à l'écran le rendu doit être évitée lors de la visualisation dans le scrollview etc. Ils résoudre les problèmes de performances dans l'exemple de code près de dessin tout à l'intérieur de la méthode drawRect.
Dans l'autre session le problème de performances (sur un tableau) semble être due à trop de code dans la méthode drawRect de la table de cellules.
La première n'est pas clair pour moi lors de l'une à l'Écran, le rendu est requis par le système, j'ai vu dans la vidéo que certains quartz fonctions telles que: cornerRadious, shadowOffset, shadowColor l'exige, mais il existe une règle générale?
La deuxième je ne sais pas si j'ai bien compris, mais il semble que lorsqu'il n'existe pas à l'écran le rendu de l'ajout de couches ou de points de vue est le chemin à parcourir.
J'espère que quelqu'un pourrait apporter de la lumière à ce sujet..
Merci,
Andrea
Réponse
Trop de publicités?
Je ne pense pas qu'il y est une règle écrit nulle part, mais j'espère que cela vous aidera à:
Tout d'abord, nous allons préciser certaines définitions. Je pense que les limites de l'écran vs à l'écran le rendu n'est pas le souci principal la plupart du temps, parce que les limites de l'écran le rendu peut être aussi rapide qu'à l'écran. La question principale est de savoir si le rendu est fait en matériel ou en logiciel.
Il y a aussi très peu de différence pratique entre l'utilisation des calques et des vues. Les vues sont juste une mince wrapper autour de CALayer et qu'ils n'introduisent pas de façon significative les performances de pénalité, la plupart du temps. Vous pouvez remplacer le type de couche utilisé par un affichage à l'aide de +layerClass méthode si vous voulez avoir un point de vue soutenu par une CAShapeLayer ou CATileLayer, etc.
Généralement, sur iOS, les effets des pixels et de Quartz / Graphiques de Base de dessin ne sont pas l'accélération matérielle, et la plupart des autres choses.
Les éléments suivants ne sont pas d'accélération matérielle, ce qui signifie qu'ils doivent être fait dans le logiciel (à l'écran):
Tout ce qui est fait dans un drawRect. Si votre vue a un drawRect, même vide, le dessin n'est pas fait en hardware, et il y a une perte de performance.
De toute couche avec le shouldRasterize propriété est définie sur OUI.
Un calque avec un masque ou une ombre portée.
Texte (n'importe quel type, y compris UILabels, CATextLayers, Base de Texte, etc).
N'importe quel dessin vous faire vous-même (que ce soit à l'écran ou à l'écran) à l'aide d'un CGContext.
La plupart des autres choses sont l'accélération matérielle, de sorte qu'ils sont beaucoup plus rapides. Cependant, on ne pourra pas dire ce que vous pensez que cela fonctionne.
Un des types ci-dessus de dessin sont lentes par rapport à l'accélération matérielle du dessin, cependant ils n'ont pas nécessairement ralentir votre application, car ils n'ont pas besoin de se produire à chaque image. Par exemple, le dessin d'une ombre portée sur un point de vue est lent la première fois, mais après il est tiré, il est mis en cache, et n'est redessiné si le point de vue des changements de taille ou de forme.
Il en va de même pour les raster opinions ou de points de vue avec une coutume drawRect: le point de vue est généralement pas redessiné chaque image, il est établi une fois puis mis en cache, de sorte que la performance après le point de vue de la configuration initiale n'est pas pire, à moins que les limites de changer ou de vous appeler setNeedsDisplay sur elle.
Pour une bonne performance, l'astuce consiste à éviter d'utiliser des logiciels de dessin pour les vues qui changent à chaque image. Par exemple, si vous avez besoin d'une animation vecteur de la forme, vous obtiendrez de meilleures performances à l'aide de CAShapeLayer ou OpenGL que drawRect et Graphiques de Base. Mais si vous dessinez une forme une fois et puis ne pas le modifier, il ne fera pas beaucoup de différence.
De même, ne pas mettre une ombre portée sur une vue animée car il va ralentir votre cadence. Mais une ombre sur une vue qui ne change pas d'une image à ne pas avoir beaucoup d'impact négatif.
Une autre chose à regarder dehors pour est de ralentir l'affichage de temps d'installation. Par exemple, supposons que vous avez une page de texte avec des ombres portées sur l'ensemble du texte; cela va prendre un temps très long à dessiner d'abord car à la fois le texte et les ombres, toutes doivent être rendus dans le logiciel, mais une fois établi, il sera rapide. Par conséquent, vous souhaitez configurer ce point de vue à l'avance lors de votre demande de charges, et de garder une copie dans la mémoire de sorte que l'utilisateur n'a pas à attendre les âges pour l'affichage lors de la première apparaît à l'écran.
C'est probablement la raison de l'apparente contradiction dans la WWDC vidéos. Pour les grands, des vues complexes qui ne changent pas à chaque image, un dessin, une fois dans le logiciel (à la suite duquel ils sont mis en cache et n'ont pas besoin d'être redessinée) permet d'obtenir de meilleures performances que d'avoir le matériel re-composition de chaque image, même si elle sera plus lente à se dessiner la première fois.
Mais pour les vues qui doivent être redessinés constamment, comme un tableau de cellules (les cellules sont recyclés, de sorte qu'ils doivent être redessiné à chaque fois qu'une cellule défile à l'écran et est réutilisé comme il défile en arrière sur l'autre côté comme une ligne différente), un logiciel de dessin peut ralentir les choses beaucoup.
