在 iPhone 上的滚动视图中处理许多图像文件，类似于照片应用程序
所以我以前见过这个问题，事实上我昨晚问过这个问题，但我想我会再试一次，看看我是否能对这个问题有任何其他独特的看法。
问题 - 我有一个应用程序，在滚动视图中包含大量 uiimageview（图像下载到磁盘），这当然面临两个大问题：内存使用和性能。在我的应用程序中，内存使用并不是什么大问题，因为我正在采用诸如出列和重用图像视图等技术。但性能完全是另一回事。现在，作为一个节省内存的过程，我只将图像文件路径存储在内存中，因为将图像存储在内存中是荒谬的。但这样做的问题是，从磁盘读取比从内存读取需要更多时间，并且会极大地减慢滚动视图的滚动速度。
那么，对于这样的事情，你们有什么建议呢？我见过 Three20，但不想使用它，因为在我看来，我需要高度可定制性，但这是行不通的。图像文件不大，只是缩略图大小，因此不会缩放或尺寸过大。必须有一种直观的方法来处理这个问题。内置的照片应用程序可以完美处理多达数千张照片，内存占用低，滚动性能流畅。
So I've seen this question asked before and in fact I asked it last night but I thought I'd give it another go just to see if I could get any other unique views on the problem.
The Problem — I have an app with a large number of uiimageviews (with image downloaded to disk) in a scrollview which of course has two large problems facing it: Memory use, and performance. In my app memory use isn't so much a problem because I am employing techniques such as dequeuing and reusing imageviews and such. But performance is another thing entirely. Right now, as a memory saving procedure, I only store image filepaths in memory because it would be ridiculous to store images in memory. But the problem with this is that reading from the disk takes more time than from memory and slows down scrolling on the scrollview immensely.
So, what kind of techniques do any of you suggest for something like this? I've seen three20 but don't want to use it because I need high customizability in my view and that just won't do. Image files are not large, but just thumbnail size so there is no scaling or excess size. There's got to be an intuitive way to handle this. The built in photos app handles up to thousands of photos perfectly with low memory and slick and smooth scrolling performance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从根本上来说，问题在于您可能在 UI 线程上执行大量磁盘 I/O，这基本上肯定会导致性能问题。
您应该考虑在后台线程上加载图像，并在加载图像时更新主线程上的图像视图。根据您的用例，您可以或多或少地了解提前预加载的程度等，以便您可以准备好图像。 （可能有一些可用的源代码，甚至 Apple 示例代码可以执行类似的操作，但我不知道它是如何实现的。）
您可能会注意到某些应用程序（不确定照片应用程序 ） ）有一个中间阶段，他们为所有图像加载非常拇指大小的图像，并将其放大到渲染大小，这充当占位符，直到加载完整尺寸版本 - 如果用户在加载完整尺寸之前滚动经过该图像，可见效果几乎与图像一直存在一样。
Fundamentally, the problem is that you're probably doing a bunch of disk I/O on your UI thread, which is basically guaranteed to cause performance problems.
You should consider loading your images on a background thread and updating the image views on the main thread when the images are loaded. Depending on your use case you can get more or less clever about how far you preload in advance, etc, so you can have images ready. (There might be some usable source code or even Apple sample code out there that does something like this, but I don't know of it off the top of my head.)
You may notice that some applications (not sure about the Photos app) have an intermediate stage where they load a very small thumb size image for all images, and scale it up to the render size, which acts as a placeholder until the full size version is loaded-- if the user scrolls past that image before the full size is loaded, the visible effect is nearly the same as if the image was there all along.