Rendimiento: una gran cantidad de pequeños PNG o un gran PNG?

Question

Desarrollando un juego simple para el iPhone, ¿qué le da un mejor rendimiento?

1. El uso de una gran cantidad de pequeños (10x10 a 30x30 píxeles) PNG para los fondos mis UIViews'.
2. Usando un PNG grande y un recorte a los límites de mi UIViews.

Mi pensamiento es que la primera técnica requiere menos memoria por UIView individual, pero complica la forma en que el iPhone se encarga de la gran cantidad de imágenes, ya que trata de combinar las imágenes en una textura más grande o intenta cambiar entre todos las pequeñas texturas mucho.

La segunda técnica, por otro lado, le da al iPhone la oportunidad de manejar solo un PNG grande, pero aumenta el peso de la imagen cada UIView de forma no necesariamente elemental.

• ¿Tengo razón sobre los intentos del iPhone, manejando las imágenes de la manera que lo describí?
• Entonces, ¿cuál es el camino a seguir?

Al ver las respuestas hasta ahora, todavía hay dudas. Parece haber una compensación con dos parámetros: complejidad y codificación intensiva de la CPU. ¿Cuál sería mi punto de inflexión para decidir qué técnica usar?

Answer 1

Si termina refiriéndose al mismo CGImageRef (por ejemplo, al compartir un UIImage *), las diferentes vistas no cargarán la imagen varias veces. Esta es la técnica utilizada por el videowall Core Animation demo at the WWDC 07 keynote. Es código OSX, pero UIViews es muy similar a CALayers.

La manera en que Core Graphics maneja las imágenes (desde mi punto de vista) está muy ajustada para una carga "justo a tiempo" y una liberación agresiva cuando la memoria es escasa.

Al utilizar una imagen grande, podría terminar cargando la imagen en el momento del dibujo si la memoria de la imagen decodificada a la que apunta CGImageRef ha sido recuperada por el sistema.

Lo que hace la diferencia no es la cantidad de imágenes que tiene, sino la frecuencia con la que el UIKit atraviesa su código.

Tanto UIViews como Core Animation CALayers solo volverán a pintar si se lo pides (-setNeedsDisplay), y el cuello de botella suele ser el código más la transferencia del contenido representado en una textura para el chip gráfico.

Así que mi consejo es pensar en su diseño UIView de una manera que permita que las partes que cambian juntas se actualicen todas al mismo tiempo, lo que se convierte en una sola carga de textura.

Answer 2

Una grande le ofrece un mejor rendimiento. (De causa si debe renderizar todas las imágenes de todos modos).

Answer 3

Una imagen grande eliminará cualquier sobrecarga asociada con la apertura y la manipulación de muchas imágenes en la memoria.

Answer 4

Una imagen grande principalmente le da más trabajo y más dolores de cabeza. Es más difícil de mantener, pero es probable que sea menos intensivo en ram porque solo hay una estructura + datos en la memoria en lugar de muchas estructuras + datos. (aunque probablemente no lo suficiente como para darse cuenta).

Al observar los contenidos de los paquetes de .app en el sistema operativo Mac OS normal, parece que el método de almacenamiento generalmente aprobado es un archivo/recurso por imagen.

Por supuesto, esto supone que no está obteniendo los recursos de la imagen de la web, donde el cuello de botella estaría en http y su máximo especificado de dos solicitudes concurrentes.

Answer 5

Yo diría que no hay una respuesta autorizada a esta pregunta. Una sola imagen grande reduce el acceso (lento) al flash y hace que la decodificación se realice de una vez, pero muchas imágenes más pequeñas le dan un mejor control sobre qué proceso ocurre cuando ... pero tiene mucha memoria y usted tiene que cortar esa imagen o enmascararlo

Deberá implementar una solución y probarla. Si no es lo suficientemente rápido y no puede optimizar, implemente el otro. Sugiero implementar la versión que personalmente encuentre más fácil de imaginar implementar porque será más fácil de implementar.