iPhone OS：高密度图像工作的策略答案

【问题标题】：iPhone OS: Strategies for high density image workiPhone OS：高密度图像工作的策略
【发布时间】：2010-04-20 14:24:51
【问题描述】：

我有一个项目即将在今年夏天进行，该项目可能会涉及大量用于显示的图像数据。我们在一个给定的应用程序会话中讨论数百个 640x480 的图像（显示时缩放到更小的分辨率），以及一次少数非常大（1280x1024 或更高）的图像。

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

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

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

我可能处于 Objective-C 中级的高端...所以我正在寻找一些关于以下方面的可靠文章和建议：

1) 以节约物理RAM的名义负责UIImage和UIImageView的管理 2）使用 CGImage 优于 UIImage 的优点，特别是对于巨大的图像，以及是否会有任何性能提升 3) 任何处理内存分页的东西，尤其是与图像有关的东西

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

【问题讨论】：

【解决方案1】：

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

您可能希望实现自己的线程图像缓存，这样您就可以对保存在内存中的图像数量施加上限，并在您预测很快就会需要它们时开始加载图像。如果有draw request进来时加载没有完成，可以阻塞draw线程。

【讨论】：

【解决方案2】：

图像通常有很多重复数据，是很好的压缩对象。这取决于您用于图像的格式以及它是否具有内置压缩功能。我的第一个想法是坚持使用 png 格式，因为它是 iPhone 的原生格式，并且以某种方式对大部分图像使用压缩存档。 .zip 或 .rar 之类的文件。

如果您可以确定用户可能遇到的图像批次，则可以将它们取消归档并将它们呈现给用户。使用子集“缩略图”存档也很有用。

我不确定所有这些压缩和解压缩会对您的响应时间产生什么影响，但它的一个想法是降低您的内存占用。

【讨论】：

你知道PNG作为一种原生格式是否会导致相对于磁盘大小的占用更少？由于建筑要求，所有有问题的图像目前都是 JPEG。他们的来源，但是我可以编写一个批处理作业来转换它们。假设 Apple 有一些复杂的 PNG 处理方法，我可以相信这样一种情况，即 JPEG 没有得到很好的支持，它可能比 PNG 消耗更多的内存。
我会坚持使用 JPG，对于大多数图像，它们在网络上的压缩性更高，并且没有证据表明它们的渲染效率更高。这里有一些值得深思的地方：stackoverflow.com/questions/800926/…
如果您已经在 JPG 中，那么我想您在那里很好。我同意上述观点。

【解决方案3】：

这是一个相当大的问题，所以我将向您介绍一个开源地图视图的项目。您可以通过将服务器添加为数据源（如果它基于 lng/lat 可能有意义）来批量重用此项目，或者您可以采用一些设计模式并直接实现您的要求。

您的图片为 1mb 或 5mb 的事实不是问题，因为您一次只能显示 1 或 4 张图片。然后是一个异步缓存加载器，它会根据用户接下来可能看到的内容来填充和老化您的图像缓存。然后当用户交互时，从缓存中获取图像（或缓存未命中的微调器）并将其添加到 CALayer 并在 CALayer 层次结构中弹出。

有很多关于性能/使用的问题。我会与上述项目中的某个人取得联系，或者只是跟随他们的领导。根据我对该项目的了解，这意味着一个 UIView 用于传递事件的父容器，并使用 CALayers 进行所有平铺。 CGImageRefs 在 CALayers 中使用，所以也要坚持使用。

希望这会有所帮助。

【讨论】：