iPhone OS：高密度图像工作策略
我有一个项目将于今年夏天即将完成，该项目可能会涉及大量的图像数据用于显示。我们讨论的是给定应用程序会话中的数百个 640x480 左右的图像（显示时缩放到较小的分辨率），以及一次大量的非常大（1280x1024 或更高）的图像。
我已经做了一些初步工作，我发现典型的 640x480ish 图像在放入 UIImageView 并显示时在内存中仅占 1MB 以下的阴影......但在某些情况下，非常大的图像可能高达 5+ MB案例。
这个项目实际上是针对 iPad 的，在我的 Instruments 测试中，iPad 的可寻址物理内存似乎上限约为 80-100MB。
抛开细节不谈，我需要开始考虑如何在虚拟内存和物理内存之间移动大量图像数据，同时保持应用程序的流动性和响应能力，这将是高可见性。
我可能处于 Objective-C 中级的高端......所以我正在寻找一些关于以下内容的可靠文章和建议：
1）以节省物理 RAM 的名义负责任地管理 UIImage 和 UIImageView 2）使用 CGImage 相对于 UIImage 的优点，特别是对于巨大的图像，以及是否会有任何性能提升 3) 任何涉及内存分页的事情，特别是与图像相关的事情，
我将在结尾说，我上面的数字可能会减少大约 10 或 15%。图像最终可能会也可能不会被捆绑到实际的应用程序本身中，而不是从外部服务器加载。
I have a project that is coming around the bend this summer that is going to involve, potentially, an extremely high volume of image data for display. We are talking hundreds of 640x480-ish images in a given application session (scaled to a smaller resolution when displayed), and handfuls of very large (1280x1024 or higher) images at a time.
I've already done some preliminary work and I've found that the typical 640x480ish image is just a shade under 1MB in memory when placed into a UIImageView and displayed... but the very large images can be a whopping 5+ MB's in some cases.
This project is actually be targeted at the iPad, which, in my Instruments tests seems to cap out at about 80-100MB's of addressable physical memory.
Details aside, I need to start thinking of how to move huge volumes of image data between virtual and physical memory while preserving the fluidity and responsiveness of the application, which will be high visibility.
I'm probably on the higher ends of intermediate at Objective-C... so I am looking for some solid articles and advice on the following:
1) Responsible management of UIImage and UIImageView in the name of conserving physical RAM
2) Merits of using CGImage over UIImage, particularly for the huge images, and if there will be any performance gain
3) Anything dealing with memory paging particularly as it pertains to images
I will epilogue by saying that the numbers I have above maybe off by about 10 or 15%. Images may or may not end up being bundled into the actual app itself as opposed to being loaded in from an external server.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
CATiledLayer 可能是最佳选择。为每个图像创建 UIImageView 的唯一原因是您需要为您管理交互性。 CATiledLayer 将允许您根据需要从后台线程异步加载和绘制图像。只需使用 CGImage 即可，因为无论如何您都会将其绘制到图层中。
您可能希望实现自己的线程图像缓存，以便可以对内存中保存的图像数量施加上限，并在您预测很快需要它们时启动图像加载。如果绘制请求传入时加载尚未完成，您可以阻塞绘制线程。
CATiledLayer is probably the way to go. The only reason to create a UIImageView for each image is if you need the interactivity managed for you. CATiledLayer will allow you to load and draw images asynchronously from background threads as needed. Just use CGImage since that is what you will draw into the layer anyway.
You will probably want to implement your own threaded image cache so you can impose a cap on the number of images kept in memory and start image loads when you predict they will be needed soon. If a load is not finished when a draw request comes in, you can block the draw thread.
图像通常具有大量重复数据，是很好的压缩对象。这取决于您使用的图像格式以及它是否具有内置压缩功能。我的第一个想法是坚持使用 png 格式，因为它是 iPhone 原生的格式，并且以某种方式对大部分图像使用压缩存档。类似于 .zip 或 .rar。
如果您可以确定用户可能遇到的图像批次，则可以将它们解档并将其呈现给用户。使用子集“缩略图”存档也可能有用。
我不确定所有这些压缩和解压缩会对您的响应时间产生什么影响，但这是一个减少内存占用的想法。
Images generally have a lot of repeating data and are good subjects for compression. this depends on what format you use for your images and if it has built in compression. My first thought is to stick to png format because its native to the iPhone and somehow use a compression archive for the bulk of your images. Something like .zip or .rar.
if you can determine batches of images that the user may encounter you could then unarchive them and present them to the user. The use of a subset "thumbnail" archive could be useful as well.
I'm not sure what all this compressing and decompressing will do to your response times but its an idea to keep your memory footprint lower.
这是一个相当大的问题，所以我将向您介绍一个开源地图视图项目。您可以通过添加服务器作为数据源（如果它基于 lng/lat 可能有意义）来批量重复使用此项目，或者您可以采用一些设计模式并直接实现您的要求。
http://code.google.com/ p/route-me/source/browse/trunk#trunk/MapView/Map
事实上，您的图像为 1mb 或 5mb，这不是问题，因为您应该一次只显示 1 或 4 个图像。然后，异步缓存加载器会根据用户接下来可能查看的内容来填充和老化图像缓存。然后，当用户交互时，从缓存（或缓存未命中的微调器）中获取图像并将其添加到 CALayer 并将其弹出到 CALayer 层次结构中。
有很多关于性能/使用的问题。我会与上述项目中的某人联系，或者只是跟随他们的领导。根据我对该项目的了解，这意味着一个 UIView 用于传递事件的父容器，并使用 CALayers 进行所有平铺。 CGImageRefs 在 CALayers 中使用，所以也坚持使用它们。
希望这有帮助。
This is a pretty big question, so I'll point you to a project that is an open source map view. You may be able to re-use this project wholesale by adding your server as a data source (if it's lng/lat based that may make sense), or you can take some of the design patterns and implement your requirements directly.
http://code.google.com/p/route-me/source/browse/trunk#trunk/MapView/Map
The fact that your images are 1mb or 5mb's isn't a problem, as you should only be displaying 1 or 4 images at once. Then an asynchronous cache loader that stuffs and ages your cache of images based on what the user may look at next. Then as the user interacts, take the image from the cache (or a spinner on a cache miss) and add it to a CALayer and pop it in the CALayer hierarchy.
There are a lot of performance / usage questions about. I would get in touch with someone in the project above or just follow their lead. Based on what I know of the project that means one UIView for the parent container that passes in events, and using CALayers for all of the tiling. CGImageRefs are used in CALayers so stick with those too.
Hope this helps.