iPhone操作系统: Strategies for high density image work

Question

今年夏天我有一个项目即将完成，该项目可能会涉及大量的图像数据用于显示。我们讨论的是给定应用程序 session 中的数百个 640x480 左右的图像(显示时缩放到较小的分辨率)，以及一次大量的非常大(1280x1024 或更高)的图像。

我已经做了一些初步工作，我发现典型的 640x480ish 图像在放入 UIImageView 并显示时在内存中仅占 1MB 以下的阴影......但是非常大的图像可能高达 5+在某些情况下为 MB。

这个项目实际上是针对 iPad 的，在我的 Instruments 测试中，iPad 的可寻址物理内存似乎上限约为 80-100MB。

除了细节之外，我需要开始考虑如何在虚拟内存和物理内存之间移动大量图像数据，同时保持应用程序的流动性和响应能力，这将是高可见性。

我可能处于 Objective-C 中级的较高水平......所以我正在寻找一些关于以下内容的可靠文章和建议:

1) 以节省物理 RAM 的名义负责管理 UIImage 和 UIImageView2)使用 CGImage 相对于 UIImage 的优点，特别是对于巨大的图像，以及是否会有任何性能提升3)任何涉及内存分页的事情，特别是与图像相关的事情

最后我会说，我上面的数字可能会减少大约 10 或 15%。图像最终可能会也可能不会捆绑到实际应用程序本身中，而不是从外部服务器加载。

Answer 1

CATiledLayer 可能是最佳选择。为每个图像创建 UIImageView 的唯一原因是您需要为您管理交互性。 CATiledLayer 将允许您根据需要从后台线程异步加载和绘制图像。只需使用 CGImage，因为无论如何您都会将其绘制到图层中。

您可能希望实现自己的线程图像缓存，以便可以对内存中保存的图像数量施加上限，并在您预测很快需要它们时开始加载图像。如果在绘制请求到来时加载尚未完成，您可以阻塞绘制线程。