ios - 为什么 CGBitmapContextCreateImage 比 [UIImage initWithData :]? 慢

Question

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

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

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

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

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

• 使用 Instruments 进行测量时，您可能看不到所有相关的 CPU 周期。图片的解压缩可以在 backboardd(iOS 中使用的那种窗口服务器)中进行。

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

结论:

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

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