ChatGPT解决这个技术问题 Extra ChatGPT

iPhone 开发中何时使用 PNG 或 JPG?

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

所有图像都是照片或照片等。

我读过它更喜欢使用 PNG 作为图像格式,但看到 JPG 版本会小得多,我宁愿使用它。

是否有使用哪种格式以及在哪种情况下使用的指南?

我想补充一点,如果这有什么不同的话,原始图像已经全部采用 JPG 格式。

h
hotpaw2

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 快;)
s
shanezilla

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
r
respectTheCode

使用 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/


N
Nate

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 变得非常小!
N
Nigel Flack

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

我正在做一些 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 加速,因为其中涉及色彩空间转换。
U
Undistraction

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


f
ff10

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


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

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