3

我目前正在开发一个应用程序，它一个接一个地显示许多图像。不幸的是，我没有为此使用视频的奢侈，但是，我可以选择使用的图像编解码器。数据从服务器发送到应用程序，已经编码。

例如，如果我使用 PNG 或 JPEG，我可以使用[[UIImage alloc] initWithData:some_data]. 当我使用原始字节数组或另一个必须首先解码为原始字节数组的自定义编解码器时，我必须创建一个位图上下文，然后使用CGBitmapContextCreateImage(bitmapContext)它提供一个 CGImageRef，然后将其馈入[[UIImage alloc] initWithImage:cg_image]. 这要慢得多。

图像转换时间

上图（时间以秒为单位）是执行从 NSData 到 UIImage 的转换所需的时间。PNG、JPEG、BMP 和 GIF 都大致相同。Null 根本不打扰转换并返回 nil 。Raw 是使用位图上下文方法转换的原始 RGBA 字节数组。自定义的解压缩为原始格式，然后执行相同的操作。LZ4 是原始数据，使用 LZ4 算法压缩，因此它也通过位图上下文方法运行。

例如，PNG 图像只是经过压缩的位图图像。这种解压缩然后渲染比我渲染原始图像所花费的时间更少。iOS 必须在幕后做一些事情来加快速度。

如果我们查看转换每种类型需要多长时间以及绘制（到图形上下文）需要多长时间的图表，我们会得到以下信息：

绘图和转换时间

我们可以看到大多数图像的转换时间非常不同，但绘制时间却非常相似。这排除了 UIImage 懒惰并仅在需要时转换的任何性能提升。

我的问题本质上是：我可以利用众所周知的编解码器的更快速度吗？或者，如果没有，是否有另一种方法可以更快地呈现我的原始数据？

编辑：为了记录，每当我得到一个新的 UIImage 时，我都会在另一个 UIImage 上绘制这些图像。可能有一种我愿意研究的更快的替代方案。但是，不幸的是，OpenGL 不是一种选择。

进一步编辑：这个问题相当重要，我想要最好的答案。在确保给出最佳答案的时间到期之前，不会颁发赏金。

最终编辑：我的问题是为什么解压缩和绘制原始 RGBA 数组比绘制 PNG 更快，例如，因为 PNG 必须解压缩为 RGBA 数组然后绘制。结果是它实际上更快。但是，这似乎只在发布版本中出现。调试版本没有为此优化，但在幕后运行的 UIImage 代码显然是优化的。通过编译为发布版本，RGBA 阵列图像比其他编解码器快得多。

4

3 回答 3

1

在测量性能时，测量整个管道以找到瓶颈非常重要。

在您的情况下，这意味着您无法隔离UIImage创作。你必须包括图像显示——否则你会陷入只测量你感兴趣的部分的陷阱。

UIImage不是位图数据的薄包装器，而是一个相当复杂和优化的系统。例如，底层CGImage可以只是对磁盘上某些压缩数据的引用。这就是初始化UIImageusing initWithContentsOfFile:or的原因initWithData:。iOS 中的 ImageIO 和 Quartz 框架中有更多隐藏的性能优化，所有这些都将添加到您的测量中。

获得可靠测量的唯一可靠方法是做你真正想做的事情（从网络或磁盘获取数据，以某种方式创建 UIImage，并在屏幕上显示至少一帧）。

以下是您应该注意的一些注意事项：

  • Apple 的图形框架不遗余力地执行必要的最少工作。如果未显示图像，则可能永远不会解压缩。

  • 如果图像以低于其原始像素的分辨率显示，则可能只是部分解压缩（尤其是 JPEG）。这对于帮助优化可能是一件好事，但当然不能在从CGBitmapContext全图像分辨率创建图像时使用。所以除非必要，否则不要这样做。

  • 使用 Instruments 进行测量时，您可能看不到所有相关的 CPU 周期。图像的解压可能发生在backboardd（iOS 中使用的那种窗口服务器）。

  • 使用未压缩的图像似乎是最快的想法。但这确实忽略了这样一个事实，即内存可能是瓶颈，更少的数据（压缩图像）可以帮助解决这个问题。

结论：

你的目标应该是为你的真实场景找到瓶颈。所以不要使用虚构的测试数据和人为的代码进行测试。您最终可能会优化应用程序中未采用的代码路径的性能。

当您更改测试代码以测量整个管道时，如果您可以使用结果更新您的问题，那就太好了。

于 2014-08-11T09:43:42.043 回答
0

[UIImage initWithData:]不会复制任何内存。它只是将内存留在原处，然后当你绘制它时，它会将内存转储到 GPU 上以完成它的工作 - 无需 CPU 或 RAM 大量参与解码图像。这一切都在 GPU 的专用硬件中完成。

请记住，Apple 通过授权其他制造商的技术并根据他们的需求进行定制来设计自己的 CPU/GPU。他们有 1000 多名 CPU 硬件工程师在一个芯片组上工作，高效处理图像是当务之急。

您的较低级别的代码可能正在执行大量的内存复制和数学运算，这就是它慢得多的原因。

UIImage并且NSData是非常智能的高性能 API，由真正了解（甚至构建）硬件和内核的人开发了数十年。除非您准备编写数千行代码并花费数月甚至数年的时间进行测试和调整以获得更好的性能，否则它们比您使用较低级别的 API 可以实现的效率要高得多。

NSData例如，即使只有几 GB 的 RAM 可用，也可以毫不费力地以良好的性能处理 TB 的数据 - 如果使用得当，它将经常无缝结合 RAM 和 SSD/HDD 存储，其性能类似于您实际拥有的性能TB 的 RAM，并且UIImage可以检测内存不足的情况并释放几乎所有的 RAM，而无需代表您的任何代码——如果它知道最初加载图像的 URL（对于 file:// URL 比 http:// URL 更有效） .

UIImage如果你可以用and做你想做的事NSData，那么你应该这样做。如果您有无法以其他方式实现的功能，请仅使用较低级别的 API。

于 2014-08-11T11:33:29.810 回答
0

UIImage使用和抽象内部表示最适合实际源，因此具有良好的性能。PNG 图像不会转换为位图，然后通过UIImage更高性能的绘图显示。

另一方面，位图是处理图像的最大且效率较低且繁重的方式，因此除了将它们转换为另一种格式之外，您无能为力。

于 2014-08-11T09:04:01.070 回答