与CGContextDrawImage相比,为什么UIImageView的内存密集程度如此之高

Question

开发iPad PDF-Reader我们决定准备渲染密集页面的高分辨率图像(其中包含许多路径),并使用这些图像而不是pdf页面来避免性能问题.我们认为这3*768 by 3*1024是可读性和渲染性能之间的良好折衷,这导致~1.5 MB的jpeg.

但是,我们测试了两个用于显示图像页面的实现.一个使用CATiledLayer子类,它也负责处理"普通"PDF页面(绘图CGContextDrawImage)和另一个使用UIImageView.后者的优点是显示和缩放非常快,但内存使用非常糟糕 - 内存大约需要30 MB(这与图像的位图大小一致).另一种方法(CATiledLayer)需要更多时间来首次显示页面,并且在缩放后需要另外两秒钟来重新渲染(类似于pdf页面,但速度要快得多)但是不会占用比显示更小图像所需的更多内存或PDF页面.

有谁知道幕后发生了什么,如果可以通过使用Quartz Framework 将低内存使用率CGContextDrawImage和高性能结合起来UIImageView.

Answer 1

不确定这个问题是否仍然相关，但如果是这样，也许这会有所帮助：

我也在平铺图像视图中进行了有效显示大视图的斗争。这个问题有很多潜在的部分：

• 正常的UIView，包括UIImageView，似乎总是完全由记忆支持其图像。即使您实现该drawRect:方法，它似乎总是传递视图的整个边界，而不仅仅是滚动视图中的可见区域。正如您所发现的，这很快就会占用大量内存，因为每个像素占用 4 个字节。
• 仅CATiledLayer 请求可见图块的内容。它还会丢弃不再可见的图块 - 这就是节省内存的来源。但是，它在后台线程上执行通知和绘图，同时从白色到内容进行动画处理。它似乎是通过私有 API 来做到这一点的，我还没有找到一种方法来重新实现CATiledLayer的功能作为我自己的 的子类CALayer，因为似乎没有我们可以作为凡人使用的通知机制。
• 如果滚动视图中有多个视图，它们会drawRect:在分页时适当地接收消息。不过，UIKit 似乎很难处理视图下面太多的子视图。

对于你来说，我可以看到几个可能的选择：

• 或许可以挽救CATiledLayer基于 - 的实现。默认fadeDuration值为 0.25 秒，如果加载时间很短，则该时间可能会太长。您可以将其直接降低到类似的值1.0/60.0，即一帧。从您的描述中不清楚的一件事是您的图像是覆盖整个页面大小还是仅覆盖每个 256x256 像素图块。对每个图块一遍又一遍地解码整个 JPEG 将比解码单个图块文件慢得多。
• 如果从CATiledLayer线程执行所有操作的延迟太高，您可以手动创建一堆图块作为UIImageView空白的子视图UIView，空白是滚动视图的主子视图。每个子视图都分配有自己的平铺图像。如果幸运的话，UIKit 将足够智能，删除这些视图的内容并根据需要重新加载相应的 JPEG。
• 如果 UIImageViews 不够智能，或者你有太多 UIKit 无法处理的视图，你可以构建自己的视图，将它们的 JPEG 加载到drawRect:. 如果它仍然太不稳定，请尝试使用您自己的 CALayers，它将成为单个视图空白图层的子图层，并再次根据需要加载其图像。这就是我最终选择的平铺图像视图。

这应该涵盖滚动，但如果您允许用户直接缩小（缩小），它仍然可能非常慢。在这种情况下，我建议您存储适当的较低分辨率版本并加载/显示最外层缩放级别的版本。