Quand utiliser PNG ou JPG dans le développement de l'iPhone?

Apple optimise les images PNG incluses dans votre pack d'applications iPhone. En fait, l'iPhone utilise un codage spécial dans lequel les octets de couleur sont optimisés pour le matériel. XCode gère cet encodage spécial pour vous lorsque vous construisez votre projet. Donc, vous voyez des avantages supplémentaires à l'utilisation de PNG sur un iPhone autre que leur prise en compte de la taille. Pour cette raison, il est certainement recommandé d'utiliser des PNG pour toutes les images qui apparaissent dans le cadre de l'interface (dans une vue de table, des étiquettes, etc.).

En ce qui concerne l'affichage d'une image en plein écran comme une photographie, vous pouvez toujours récolter des avantages avec les PNG car ils ne sont pas avec perte et la qualité visuelle devrait être meilleure qu'un JPG sans parler de l'utilisation des ressources avec décodage de l'image. Vous devrez peut-être diminuer la qualité de vos JPG afin de voir un avantage réel dans la taille du fichier, mais vous affichez des images non optimales.

La Taille du fichier est certainement un facteur, mais il y a d'autres considérations en jeu aussi bien lors du choix d'un format de l'image.

Il y a une chose importante à penser avec les png. Si un PNG est inclus dans votre build Xcode, il sera optimisé pour iOS. Ceci est appelé écrasement PNG. Si votre PNG est téléchargé au moment de l'exécution, il ne sera pas écrasé. Les png écrasés fonctionnent à peu près de la même manière que les jpg 100%. Les JPG de qualité inférieure fonctionnent mieux que les JPG de qualité supérieure. Donc, du point de vue des performances, du plus rapide au plus lent, il irait au JPG de faible qualité, au JPG de haute qualité, au PNG écrasé, au PNG.

Si vous avez besoin de télécharger des PNG, vous devriez pensez à écraser les fichiers PNG sur le serveur avant le téléchargement.

Http://www.cocoanetics.com/2011/10/avoiding-image-decompression-sickness/

Le blog Cocoanetics a publié un bon benchmark de performance iOS de JPG à différents niveaux de qualité, et PNG, avec et sans écrasement.

De sa conclusion:

Si vous avez absolument besoin d'un canal alpha ou que vous devez utiliser des png, alors il est conseillé d'installer l'outil pngcrush sur votre serveur web et avoir tous vos Png. Dans presque tous les autres cas de haute qualité JPEGs combinent des tailles de fichiers plus petites (c'est-à-dire une transmission plus rapide) avec plus rapide compression et rendu.

Il s'avère que les png sont parfaits pour les petites images que vous utiliseriez pour les éléments de L'interface utilisateur, mais ils ne sont pas raisonnables à utiliser pour tout applications d'écran comme des catalogues ou des magazines. Là, vous voulez choisir une qualité de compression comprise entre 60 et 80% en fonction de votre le matériel source.

En termes de tout afficher, vous voudrez vous accrocher UIImage instances à partir de laquelle vous avez dessiné une fois parce que ceux-ci ont un cache version non compressée du fichier à eux. Et où vous ne le faites pas la pause visuelle pour qu'une grande image apparaisse à l'écran, vous aurez pour forcer la décompression pour quelques images à l'avance. Mais gardez à l' rappelez-vous que ceux-ci prendront de grandes quantités de RAM et si vous êtes exagérer cela pourrait entraîner la fin de votre application. NSCache est un excellent endroit pour placer des images fréquemment utilisées car cela automatiquement prend soin d'expulser les images lorsque la RAM devient rare.

Il est regrettable que nous n'ayons aucun moyen de savoir si oui ou non un l'image a encore besoin de décompresser ou non. Aussi une image pourrait avoir expulsé la version non compressée sans nous en informer effet. Cela pourrait être un bon Radar à soulever au rapport de bogue D'Apple site. Mais heureusement l'accès à l'image comme indiqué ci dessus ne prend pas de temps si l'image est déjà décompressé. Donc tu pourrais juste faire ça pas seulement "juste à temps", mais aussi "au cas où".

Je pensais juste partager un peu de données de performance de décompression...

Je fais du prototypage d'une visionneuse à 360 degrés - un carrousel où l'utilisateur peut tourner à travers une série de photos prises sous différents angles, pour donner l'impression de pouvoir faire pivoter un objet en douceur.

J'ai chargé les données d'image dans un tableau de NSData pour sortir les e / s de fichier de l'équation, mais créer NSImage à la volée. Test à près de Max frame rate (~25 fps) et regarder dans Instruments je vois que l'application est clairement liée au processeur et il y a une augmentation d'environ 10% de la charge du processeur montrant ~275 kb png vs ~ 75 kb jpg.

Je ne peux pas dire avec certitude, mais je suppose que la limite du processeur provient simplement de l'exécution générale du programme et du déplacement de toutes les données en mémoire, mais la décompression de l'image est effectuée sur le GPU. De toute façon et L'argument de performance JPG vs. PNG semble favoriser JPG, en particulier lorsque les petites tailles de fichiers (et donc les plus petites tailles d'objets en mémoire à moins dans certaines parties de la chaîne) est pris en considération.

Bien sûr, chaque situation est différente, il n'y a pas de substitut pour les tests...

J'ai trouvé des différences massives dans les performances d'animation lors de l'utilisation de jpegs vs png. Par exemple, placer trois JPEG de taille d'écran côte à côte dans un UIScrollView et faire défiler horizontalement sur un iPhone4 entraîne un décalage et une animation saccadée complètement désagréable. Avec des png non transparents de mêmes dimensions, le défilement est lisse. Je n'utilise jamais de JPEG, même si l'image est grande.

Je pense que si vous voulez utiliser transparent, vous n'avez pas D'autre choix que PNG. Mais, si votre arrière-plan est déjà opaque, alors vous pouvez utiliser JPG. C'est la seule différence que je peux voir

'utiliser JPEG pour les photos' comme mentionné dans Lignes directrices de L'Interface humaine sous section produire des illustrations dans le format approprié.