ios 什么时候在 iPhone 开发中使用 PNG 或 JPG?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/3929281/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
When to use PNG or JPG in iPhone development?
提问by Maverick
I have an app that will display a bunch of images in a slideshow. Those images will be part of the bundle, thus distributed with the app.
我有一个应用程序可以在幻灯片中显示一堆图像。这些图像将成为捆绑包的一部分,因此与应用程序一起分发。
All the images are photographs or photographic, etc.
所有图像均为照片或摄影等。
I've read that it's preferred to use PNG as the image format, but seeing that the JPG version will be much smaller, I'd rather be using that.
我读过最好使用 PNG 作为图像格式,但看到 JPG 版本会小得多,我宁愿使用它。
Are there any guidelines which format to use and in which case?
是否有任何指南使用哪种格式以及在哪种情况下使用?
回答by hotpaw2
PNG's are pixel perfect (non-lossy), and require very little extra CPU energy to display. However, large PNGs may take longer to read from storage than more compressed image formats, and thus be slower to display.
PNG 是像素完美的(非有损的),并且只需要很少的额外 CPU 能量来显示。然而,大的PNG可能需要更长的时间从存储超过压缩图像格式的读取,因此是更慢的显示。
JPG's are smaller to store, but lossy (amount depends on compression level), and to display them requires a much more complicated decoding algorithm. But the typical compression and image quality is usually quite sufficient for photos.
JPG 的存储较小,但有损(数量取决于压缩级别),并且显示它们需要更复杂的解码算法。但是典型的压缩和图像质量对于照片来说通常已经足够了。
Use JPG's for photos and for anything large, and PNG's for anything small and/or designed to be displayed "pixel perfect" (e.g. small icons) or as a part of a composited transparent overlay, etc.
将 JPG 用于照片和任何大的东西,将 PNG 用于任何小和/或设计为“像素完美”(例如小图标)或作为合成透明叠加层的一部分等。
回答by shanezilla
Apple optimizes PNG images that are included in your iPhone app bundle. In fact, the iPhone uses a special encoding in which the color bytes are optimized for the hardware. XCode handles this special encoding for you when you build your project. So, you do see additional benefits to using PNG's on an iPhone other than their size consideration. For this reason it is definitely recommended to use PNG's for any images that appear as part of the interface (in a table view, labels, etc).
Apple 优化了 iPhone 应用程序包中包含的 PNG 图像。事实上,iPhone 使用一种特殊的编码,其中颜色字节针对硬件进行了优化。当您构建项目时,XCode 会为您处理这种特殊编码。因此,您确实看到了在 iPhone 上使用 PNG 的额外好处,而不是考虑它们的大小。出于这个原因,绝对建议对作为界面一部分(在表格视图、标签等中)出现的任何图像使用 PNG。
As for displaying a full screen image such as a photograph you may still reap benefits with PNG's since they are non-lossy and the visual quality should be better than a JPG not to mention resource usage with decoding the image. You may need to decrease the quality of your JPG's in order to see a real benefit in file size but then you are displaying non-optimal images.
至于显示全屏图像(例如照片),您仍然可以从 PNG 中受益,因为它们是无损的,视觉质量应该比 JPG 更好,更不用说解码图像时的资源使用情况了。您可能需要降低 JPG 的质量才能看到文件大小的真正好处,但随后您会显示非最佳图像。
File size is certainly a factor but there are other considerations at play as well when choosing an image format.
文件大小当然是一个因素,但在选择图像格式时还有其他考虑因素。
回答by respectTheCode
There is one important thing to think about with PNGs. If a PNG is included in your Xcode build it will be optimized for iOS. This is called PNG crush. If your PNG is downloaded at run time it will not be crushed. Crushed PNGs run about the same as 100% JPGs. Lower quality JPGs run better than higher quality JPGs. So from a performance standpoint from fastest to slowest it would go low quality JPG, high quality JPG, PNG Crushed, PNG.
使用 PNG 需要考虑一件重要的事情。如果 PNG 包含在您的 Xcode 构建中,它将针对 iOS 进行优化。这称为 PNG 粉碎。如果您的 PNG 是在运行时下载的,则它不会被粉碎。破碎的 PNG 与 100% JPG 的运行方式大致相同。较低质量的 JPG 比较高质量的 JPG 运行得更好。因此,从性能的角度来看,从最快到最慢,它将变为低质量 JPG、高质量 JPG、PNG 粉碎、PNG。
If you need to download PNGs you should consider crushing the PNGs on the server before the download.
如果您需要下载 PNG,您应该考虑在下载前粉碎服务器上的 PNG。
http://www.cocoanetics.com/2011/10/avoiding-image-decompression-sickness/
http://www.cocoanetics.com/2011/10/avoiding-image-decompression-sickness/
回答by Nate
The Cocoanetics blog published a nice iOS performance benchmarkof JPGs at various quality levels, and PNGs, with and without crushing.
该Cocoanetics博客上发表了一个很好的iOS业绩比较基准在不同的质量水平,和PNG格式JPG格式的,有和没有破碎。
From his conclusion:
从他的结论来看:
If you absolutely need an alpha channel or have to go with PNGs then it is advisable to install the pngcrush tool on your web server and have it process all your PNGs. In almost all other cases high quality JPEGs combine smaller file sizes (i.e. faster transmission) with faster compression and rendering.
It turns out that PNGs are great for small images that you would use for UI elements, but they are not reasonable to use for any full screen applications like catalogues or magazines. There you would want to choose a compression quality between 60 and 80% depending on your source material.
In terms of getting it all to display you will want to hang onto UIImage instances from which you have drawn once because those have a cached uncompressed version of the file in them. And where you don't the visual pause for a large image to appear on screen you will have to force decompression for a couple of images in advance. But bear in mind that these will take large amounts of RAM and if you are overdoing it that might cause your app to be terminated. NSCache is a great place to place frequently used images because this automatically takes care of evicting the images when RAM becomes scarce.
It is unfortunate that we don't have any way to know whether or not an image still needs decompressing or not. Also an image might have evicted the uncompressed version without informing us as to this effect. That might be a good Radar to raise at Apple's bug reporting site. But fortunately accessing the image as shown above takes no time if the image is already decompressed. So you could just do that not only “just in time” but also “just in case”.
如果您绝对需要 alpha 通道或必须使用 PNG,那么建议在您的 Web 服务器上安装 pngcrush 工具并让它处理您所有的 PNG。在几乎所有其他情况下,高质量 JPEG 将较小的文件大小(即更快的传输)与更快的压缩和渲染相结合。
事实证明,PNG 非常适合用于 UI 元素的小图像,但它们不适用于任何全屏应用程序,如目录或杂志。在那里,您可能希望根据源材料选择 60% 到 80% 之间的压缩质量。
就让所有内容都显示出来而言,您将希望挂在您绘制过一次的 UIImage 实例上,因为这些实例中有一个缓存的未压缩文件版本。如果您没有在屏幕上出现大图像的视觉暂停,您将不得不提前对几张图像进行强制解压缩。但请记住,这些将占用大量 RAM,如果您过度使用,可能会导致您的应用程序被终止。NSCache 是放置常用图像的好地方,因为它会在 RAM 变得稀缺时自动清除图像。
不幸的是,我们没有任何方法知道图像是否还需要解压缩。此外,图像可能在没有通知我们这种效果的情况下驱逐了未压缩的版本。这可能是在 Apple 的错误报告站点上提出的一个很好的雷达。但幸运的是,如果图像已经解压缩,则访问如上所示的图像不会花费任何时间。因此,您不仅可以“及时”这样做,还可以“以防万一”。
回答by Nigel Flack
Just thought I'd share a bit of decompression performance data...
只是想我会分享一些减压性能数据......
I'm doing some prototyping of a 360 degree viewer - a carousel where the user can spin through a series of photos taken from different angles, to give the impression of being able to smoothly rotate an object.
我正在做一些 360 度查看器的原型设计 - 一个旋转木马,用户可以在其中旋转从不同角度拍摄的一系列照片,给人一种能够平滑旋转对象的印象。
I have loaded the image data into an array of NSData's to take file i/o out of the equation, but create NSImage's on the fly. Testing at near max frame rate (~25 fps) and watching in Instruments I see the app is clearly CPU-bound and there's an approximately 10% increase in CPU load showing ~275 kb png's vs. ~75 kb jpg's.
我已将图像数据加载到 NSData 的数组中以将文件 i/o 排除在等式之外,但会即时创建 NSImage。以接近最大帧率 (~25 fps) 进行测试并在 Instruments 中观看我看到该应用程序显然受 CPU 限制,并且 CPU 负载增加了大约 10%,显示 ~275 kb png 与 ~75 kb jpg。
I can't say for sure but my guess is the CPU limit is just from general program execution and moving all the data around in memory, but that image decompression is done on the GPU. Either way and the JPG vs. PNG performance argument looks to favour JPG, especially when the smaller file sizes (and therefore smaller sizes of objects in memory at least in some parts of the chain) is taken into consideration.
我不能肯定,但我的猜测是 CPU 限制仅来自一般程序执行和在内存中移动所有数据,但图像解压缩是在 GPU 上完成的。无论哪种方式,JPG 与 PNG 性能参数看起来都偏向于 JPG,尤其是当考虑到较小的文件大小(因此,至少在链的某些部分内存中的对象大小较小)时。
Of course every situation is different, there's no substitute for testing...
当然,每种情况都不同,没有什么可以替代测试......
回答by Undistraction
I have found massive differences in animation performance when using jpegs vs png. For example placing three screen-sized jpegs side by side in a UIScrollView and scrolling horizontally on an iPhone4 results in lag and a thoroughly unpleasant jerky animation. With non-transparent pngs of the same dimensions the scrolling is smooth. I never use jpegs, even if the image is large.
我发现使用 jpeg 与 png 时动画性能存在巨大差异。例如,将三个屏幕大小的 jpeg 并排放置在 UIScrollView 中并在 iPhone4 上水平滚动会导致延迟和完全令人不快的生涩动画。对于相同尺寸的非透明 png,滚动是平滑的。我从不使用 jpeg,即使图像很大。
回答by vodkhang
I think if you want to use transparent, you have no choice except PNG. But, if your background is opaque already, then you may use JPG. That is the only difference I can see
我想如果你想使用透明的,除了PNG你别无选择。但是,如果您的背景已经不透明,那么您可以使用 JPG。这是我能看到的唯一区别
回答by Tanya Berezovsky
'Use JPEG for photos' as mentioned in Human Interface Guidelinesunder section Produce artwork in the appropriate format.
如人机界面指南中以适当格式制作艺术品部分中所述的“对照片使用 JPEG” 。