visual studio microsoft guia español descargar community ios view rendering layer

ios - studio - ¿Cuándo una vista(o capa) requiere representación fuera de la pantalla?



microsoft visual studio descargar (3)

No creo que haya una regla escrita en ningún lado, pero espero que esto ayude:

Primero, aclaremos algunas definiciones. Creo que la representación fuera de pantalla o en pantalla no es la principal preocupación la mayor parte del tiempo, porque la representación fuera de pantalla puede ser tan rápida como en la pantalla. El problema principal es si la representación se realiza en hardware o software.

También hay muy poca diferencia práctica entre el uso de capas y vistas. Las vistas son solo una capa delgada alrededor de CALayer y no introducen una penalización de rendimiento significativa la mayor parte del tiempo. Puede anular el tipo de capa utilizada por una vista utilizando el método + layerClass si desea tener una vista respaldada por un CAShapeLayer o CATileLayer, etc.

En general, en iOS, los efectos de píxeles y el dibujo de Quartz / Core Graphics no están acelerados por hardware, y la mayoría de las cosas sí lo están.

Las siguientes cosas no están aceleradas por hardware, lo que significa que deben realizarse en el software (fuera de pantalla):

  1. Cualquier cosa hecha en un drawRect. Si su vista tiene un drawRect, incluso uno vacío, el dibujo no está hecho en hardware, y hay una penalización de rendimiento.

  2. Cualquier capa con la propiedad shouldRasterize establecida en SÍ.

  3. Cualquier capa con una máscara o sombra paralela.

  4. Texto (de cualquier tipo, incluidos UILabels, CATextLayers, Core Text, etc.).

  5. Cualquier dibujo que haga usted mismo (ya sea en pantalla o fuera de la pantalla) utilizando un CGContext.

La mayoría de las otras cosas son aceleradas por hardware, por lo que son mucho más rápidas. Sin embargo, esto puede no significar lo que crees que hace.

Cualquiera de los tipos anteriores de dibujo es lento en comparación con el dibujo acelerado por hardware, sin embargo, no necesariamente ralentiza la aplicación porque no es necesario que ocurra cada cuadro. Por ejemplo, dibujar una sombra paralela en una vista es lento la primera vez, pero después de dibujarse se almacena en caché, y solo se vuelve a dibujar si la vista cambia de tamaño o forma.

Lo mismo ocurre con vistas rasterizadas o vistas con un drawRect personalizado: la vista normalmente no se vuelve a dibujar en cada cuadro, se dibuja una vez y luego se almacena en caché, por lo que el rendimiento después de la vista no es peor, a menos que los límites cambien o llama a setNeedsDisplay en él.

Para un buen rendimiento, el truco es evitar el uso de dibujo de software para las vistas que cambian cada fotograma. Por ejemplo, si necesita una forma de vector animado obtendrá un mejor rendimiento con CAShapeLayer u OpenGL que drawRect y Core Graphics. Pero si dibujas una forma una vez y luego no necesitas cambiarla, no habrá mucha diferencia.

Del mismo modo, no coloque una sombra paralela en una vista animada porque ralentizará su velocidad de fotogramas. Pero una sombra en una vista que no cambia de cuadro a cuadro no tendrá mucho impacto negativo.

Otra cosa a tener en cuenta es ralentizar el tiempo de configuración de la vista. Por ejemplo, supongamos que tiene una página de texto con sombras paralelas en todo el texto; esto tomará un tiempo muy largo para dibujar inicialmente, ya que tanto el texto como las sombras deben renderizarse en el software, pero una vez dibujado, será rápido. Por lo tanto, querrá configurar esta vista de antemano cuando se cargue su aplicación, y mantener una copia en la memoria para que el usuario no tenga que esperar años para que la vista se muestre cuando aparezca por primera vez en la pantalla.

Esta es probablemente la razón de la aparente contradicción en los videos de WWDC. Para vistas grandes y complejas que no cambian cada fotograma, dibujarlas una vez en el software (después de lo cual se almacenan en la memoria caché y no es necesario volver a dibujarlas) ofrecerá un mejor rendimiento que hacer que el hardware las vuelva a componer en cada fotograma, aunque será más lento dibujar la primera vez.

Pero para vistas que deben volver a dibujarse constantemente, como celdas de tabla (las celdas se reciclan para que se vuelvan a dibujar cada vez que una celda se desplaza fuera de pantalla y se reutiliza mientras se desplaza hacia atrás en el otro lado como una fila diferente), el diseño de software puede ralentiza mucho las cosas.

Hola
este fin de semana empecé a ver los videos WWDC 2011. He encontrado temas realmente interesantes sobre iOS. Mis favoritos eran sobre rendimiento y gráficos, pero he encontrado dos de ellos aparentemente en contradicción. Por supuesto que hay algo que no entendí. Las sesiones de las que estoy hablando son Comprensión de UIKit Rendering -121 y Pulido de su aplicación -105.
Lamentablemente, el código de muestra de 2011 todavía no se puede descargar, por lo que es bastante difícil tener una vista general. En una sesión explican que la mayoría de las veces la representación fuera de la pantalla debe evitarse durante la visualización en scrollview, etc. Arreglan los problemas de rendimiento en el código de ejemplo casi dibujando todo dentro del método -drawRect. En la otra sesión, el problema de rendimiento (en una vista de tabla) parece deberse a demasiado código en el método -drawRect de las celdas de la tabla.
Lo primero no está claro para mí cuando el sistema requiere una representación de OffScreen. He visto en el video que algunas funciones de cuarzo, como: cornerRadious, shadowOffset, shadowColor lo requieren, pero ¿existe una regla general?
En segundo lugar, no sé si entendí bien, pero parece que cuando no hay representación fuera de la pantalla, agregar capas o vistas es el camino a seguir. Espero que alguien pueda aclarar eso ...
Gracias,
Andrea


Representación fuera de pantalla / Representación en la CPU

Los principales cuellos de botella del rendimiento de los gráficos son la representación y fusión fuera de la pantalla: pueden suceder para cada fotograma de la animación y pueden causar un desplazamiento entrecortado.

La representación fuera de pantalla (representación del software) ocurre cuando es necesario hacer el dibujo en el software (fuera de pantalla) antes de que pueda entregarse a la GPU. El hardware no maneja la representación de texto y las composiciones avanzadas con máscaras y sombras.

Lo siguiente activará la representación fuera de la pantalla:

  • Cualquier capa con una máscara ( layer.mask )

  • Cualquier capa con layer.masksToBounds / view.clipsToBounds es verdadera

  • Cualquier capa con layer.allowsGroupOpacity establecido en YES y layer.opacity es menor que 1.0
    ¿Cuándo una vista (o capa) requiere representación fuera de la pantalla?

  • Cualquier capa con una sombra layer.shadow* ( layer.shadow* ).
    Consejos sobre cómo solucionarlo: https://markpospesel.wordpress.com/tag/performance/

  • Cualquier capa con layer.shouldRasterize siendo verdadera

  • Cualquier capa con layer.cornerRadius , layer.edgeAntialiasingMask , layer.allowsEdgeAntialiasing

  • ¿Alguna capa con layer.borderWith y layer.borderColor ?
    Falta referencia / prueba

  • Texto (de cualquier tipo, incluidos UILabel , CATextLayer , Core Text , etc.).

  • La mayoría del dibujo que haces con CGContext en drawRect: Incluso una implementación vacía se representará fuera de pantalla.

Esta publicación cubre la fusión y otras cosas que afectan el rendimiento: ¿Qué desencadena la representación, fusión y distribución de presentaciones fuera de la pantalla en iOS?


La representación fuera de pantalla es uno de los temas peor definidos en la representación de iOS hoy en día. Cuando los ingenieros de UIKit de Apple se refieren a la representación fuera de pantalla, tiene un significado muy específico, y muchos blogs de desarrolladores de iOS de terceros se están equivocando.

Cuando anula "drawRect:", está dibujando a través de la CPU y escupiendo un mapa de bits. El mapa de bits se empaqueta y se envía a un proceso separado que vive en iOS, el servidor de renderizado. Idealmente, el servidor de renderizado solo muestra los datos en la pantalla.

Si juega con propiedades en CALayer, como activar sombras paralelas, la GPU realizará un dibujo adicional. Este trabajo adicional es lo que los ingenieros de UIKit quieren decir cuando dicen "representación fuera de la pantalla". Esto siempre se realiza con hardware.

El problema con el dibujo fuera de la pantalla no es necesariamente el dibujo. El pase fuera de la pantalla requiere un cambio de contexto, ya que la GPU cambia su destino de dibujo. Durante este cambio, la GPU está inactiva.

Si bien no conozco una lista completa de las propiedades que desencadenan un pase fuera de la pantalla, puede diagnosticar esto con la opción "Color de la capa reproducida sin pantalla" del Instrumento de animación de Core. Supongo que cualquier propiedad que no sea alfa se realiza a través de un pase fuera de pantalla.

Con el hardware iOS anterior, era razonable decir "hacer todo en drawRect". Hoy en día las GPU son mejores, y UIKit tiene características como shouldRasterize. Hoy en día, es un acto de equilibrio entre el tiempo pasado en drawRect, el número de pases fuera de la pantalla y la cantidad de mezcla. Para conocer todos los detalles, mire la sesión WWDC 2014 419, "Gráficos avanzados y animación para aplicaciones de iOS".

Dicho todo esto, es bueno entender lo que sucede detrás de las escenas, y mantenerlo en la parte posterior de la cabeza para que no hagas nada loco, pero debes comenzar desde la solución más simple. Luego, pruébelo en el hardware más lento que admita. Si no está alcanzando 60FPS, use los instrumentos para medir cosas y resolverlo. Hay algunos posibles cuellos de botella, y si no está usando datos para diagnosticar cosas, simplemente está adivinando.