iPhone 开发中何时使用 PNG 或 JPG？答案

【问题标题】：When to use PNG or JPG in iPhone development?iPhone 开发中何时使用 PNG 或 JPG？
【发布时间】：2011-04-25 03:55:41
【问题描述】：

我有一个应用程序可以在幻灯片中显示一堆图像。这些图像将成为捆绑包的一部分，因此与应用程序一起分发。

所有图片均为照片或照片等

我听说最好使用 PNG 作为图像格式，但看到 JPG 版本会小得多，我宁愿使用它。

在什么情况下使用哪种格式有什么指导方针吗？

【问题讨论】：

我想补充一点，如果这有什么不同的话，原始图像都已经是 JPG 格式了。

标签： iphone ios png jpeg

【解决方案1】：

PNG 像素完美（无损），显示所需的额外 CPU 能量非常少。但是，与压缩程度更高的图像格式相比，从存储中读取大的 PNG 可能需要更长的时间，因此显示速度会更慢。

JPG 的存储更小，但有损（数量取决于压缩级别），并且显示它们需要更复杂的解码算法。但是对于照片来说，典型的压缩和图像质量通常已经足够了。

将 JPG 用于照片和任何大的东西，将 PNG 用于任何小的和/或设计为显示“像素完美”（例如小图标）或作为合成透明叠加层的一部分等。

【讨论】：

我还没有看到任何关于 JPEG、PNG 和 iPNG 解码性能的数据。有时，由于所需的 I/O 减少，压缩程度更高的格式会更好；我不确定 iPhone 的闪存驱动器有多快。而且我绝对不会说PNG解压缩需要“非常少”的能量； Other.artwork 文件看起来是原始位图数据，大概是因为 PNG 解压的 CPU/内存开销对于常用的 UI 组件来说太大了。
在我当前的项目中，由于透明度要求，我们有非常大的 png 文件。磁盘 IO 大大超过了解码 jpeg 所花费的时间。请记住，PNG 也会被压缩，只是使用了不同的算法。
我想为那些试图最大化图像性能的人添加一个补充提示。如果您有良好压缩的 JPG，您可以提前将原始 JPG 数据加载到 NSData 对象中（可能在数组或字典中），并在您想要显示时使用 UIImage:imageFromData 构建 JPG。 JPG 数据可以比位图图像数据小 10-100 倍，但它可以让您尽早摆脱（相对较慢的）IO 部分。显然要小心以这种方式缓存/预加载多少数据。
我发现了一些关于压缩时间的数据：cocoanetics.com/2012/09/… 看来，使用 png 并不比 jpg 快 ;)

【解决方案2】：

Apple 会优化 iPhone 应用程序包中包含的 PNG 图像。事实上，iPhone 使用一种特殊的编码，其中颜色字节针对硬件进行了优化。当您构建项目时，XCode 会为您处理这种特殊编码。因此，除了尺寸考虑之外，您确实看到了在 iPhone 上使用 PNG 的其他好处。出于这个原因，绝对建议对作为界面一部分出现的任何图像（在表格视图、标签等中）使用 PNG。

至于显示全屏图像（例如照片），您仍然可以使用 PNG 获得好处，因为它们是无损的，并且视觉质量应该比 JPG 更好，更不用说解码图像时的资源使用了。您可能需要降低 JPG 的质量才能看到文件大小的真正好处，但您会显示非最佳图像。

文件大小当然是一个因素，但在选择图像格式时还有其他考虑因素。

【讨论】：

In my benchmark Xcode 优化实际上使文件变慢，可能是因为磁盘 I/O，而不是 CPU 是瓶颈。
“Apple 优化了 iPhone 应用程序包中包含的 PNG 图像” - 这是否意味着动态下载的 PNG 未优化？
不，动态下载的 PNG 没有经过优化。优化基本上只是将字节顺序从 RGBA 交换到 BGRA，这是 iPhone 图形芯片内部使用的。更多信息在这里：graphicsoptimization.com/blog/?p=259

【解决方案3】：

使用 PNG 需要考虑一件重要的事情。如果您的 Xcode 构建中包含 PNG，它将针对 iOS 进行优化。这称为PNG粉碎。如果您的 PNG 在运行时下载，它不会被压碎。粉碎的 PNG 与 100% JPG 的运行方式大致相同。较低质量的 JPG 比较高质量的 JPG 运行得更好。因此，从性能的角度来看，从最快到最慢的顺序是低质量 JPG、高质量 JPG、PNG Crushed、PNG。

如果您需要下载 PNG，您应该考虑在下载之前在服务器上粉碎 PNG。

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

【讨论】：

【解决方案4】：

Cocoanetics blog published a nice iOS performance benchmark 各种质量级别的 JPG 和 PNG，无论是否经过压缩。

从他的结论：

如果您绝对需要 Alpha 通道或必须使用 PNG，那么建议在您的 Web 服务器上安装 pngcrush 工具，并且让它处理你所有的PNG。在几乎所有其他情况下，高质量 JPEG 将较小的文件大小（即更快的传输）与更快的压缩和渲染。

事实证明，PNG 非常适合您将使用的小图像用于 UI 元素，但它们不适用于任何完整的屏幕应用程序，如目录或杂志。你想要的选择 60% 到 80% 之间的压缩质量，具体取决于您的源材料。

要让所有内容都显示出来，你会想要坚持下去您从中绘制过一次的 UIImage 实例，因为它们具有在其中缓存文件的未压缩版本。在你不知道的地方大图像出现在屏幕上的视觉暂停提前对几个图像强制解压缩。但忍耐请注意，这些将占用大量 RAM，如果您是过度使用可能会导致您的应用程序被终止。 NSCache 是一个放置常用图像的好地方，因为它会自动当 RAM 变得稀缺时，负责逐出图像。

不幸的是，我们没有任何办法知道图像是否仍然需要解压缩。图像也可能有在没有通知我们的情况下驱逐了未压缩的版本影响。这可能是在 Apple 的错误报告中提出的一个很好的雷达地点。但幸运的是访问如上所示的图像不需要时间如果图像已经解压缩。所以你可以不这样做不仅“及时”，而且“以防万一”。

【讨论】：

没错，JPEGMini 和 ImageOptim 让 jpeg 变得非常小！

【解决方案5】：

只是想我会分享一些减压性能数据...

我正在做一些 360 度查看器的原型设计 - 一个轮播，用户可以在其中旋转浏览从不同角度拍摄的一系列照片，给人一种能够平滑旋转对象的印象。

我已将图像数据加载到一个 NSData 数组中，以便将文件 i/o 排除在外，但动态创建 NSImage。以接近最大帧速率 (~25 fps) 进行测试并在 Instruments 中观看我发现该应用显然受 CPU 限制，并且 CPU 负载增加了约 10%，显示 ~275 kb png 与 ~75 kb jpg 相比。

我不能肯定地说，但我的猜测是 CPU 限制只是来自一般程序执行和在内存中移动所有数据，但图像解压缩是在 GPU 上完成的。无论哪种方式，JPG 与 PNG 的性能参数看起来都偏向于 JPG，尤其是考虑到较小的文件大小（因此至少在链的某些部分内存中的对象大小较小）时。

当然，每种情况都不同，没有什么可以替代测试...

【讨论】：

GPU 无法解压缩 PNG。它使用的 deflate 格式不适合 GPU 启用的那种并行化。我猜 JPG 解码可以部分由 GPU 加速，因为其中涉及色彩空间转换。

【解决方案6】：

我发现使用 jpeg 与 png 时动画性能存在巨大差异。例如，将三个屏幕大小的 jpeg 并排放置在 UIScrollView 中并在 iPhone4 上水平滚动会导致延迟和完全不愉快的生涩动画。使用相同尺寸的非透明png，滚动是平滑的。我从不使用 jpeg，即使图像很大。

【讨论】：

【解决方案7】：

我想如果你想使用透明，除了PNG你别无选择。但是，如果您的背景已经不透明，那么您可以使用 JPG。这是我能看到的唯一区别

【讨论】：

这并没有解决 JPG 与 PNG 的任何性能考虑。

【解决方案8】：

Human Interface Guidelines 中提到的“将 JPEG 用于照片”，在 以适当的格式制作图稿。

【讨论】：