在文件系统中存储图像与核心数据
我目前正在开发一个 iOS 应用程序，我允许用户将照片库中的图像添加到应用程序中。我将这些图像存储在设备文件系统上，并在需要时访问它们（当它们位于 UIScrollView 中时，我可以经常访问它们）
我只是想获得有关此方法的一些意见。我应该继续使用文件系统方法，还是将这些图像存储在 CoreData 中会有好处。
任何对此的建议将不胜感激。
谢谢。
I am currently working on an iOS application that I allow the user to add images from their photo library into the application. I store these images on the devices file system, and access them when I need them (when they are in a UIScrollView, I could access them quite often)
I just wanted to get some opinions on this approach. Should I stay with the file system method, or would it be beneficial to store these I images in CoreData instead.
Any suggestions on this would be greatly appreciated.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为 Core Data 并不是真正为存储此类数据而设计的。这样做在道德上相当于将图像数据存储到 SQL/关系数据库中，但这也并不理想。
我有一个类似的情况，我有一堆图像存储在硬目标位置（我的图像列表永远不会改变，所以我只是将它们全部包含在应用程序包中），核心数据存储包含大量有关图像的元数据。我在图像本身的核心数据中保留的只是文件名，然后在运行时当最终看到图像时将完整的文件路径混在一起。我没有任何延迟或延迟的问题。
即使我没有在 UIScrollView 中显示图像，我仍然认为从核心数据存储中获取图像信息数组并在生成单元格时动态生成完整文件路径不会有什么问题，因为这些只是字符串和生成 UIImage 的代码非常紧凑。或者生成相同的信息数组，然后在生成任何单元格之前编译图像路径数组，就像 UIScrollView 即将出现时一样。
I don't think Core Data was really designed for storing this type of data. Doing so would be the moral equivalent of storing the image data into a SQL/relational database which isn't ideal either.
I have a similar situation where I have a bunch of images stored in hard targetted location (my image list never changes, so I just include them all in the application bundle) with a Core Data store that contains a lot of metadata about the images. All I keep in the Core Data of the image itself is the file name and then mash together the full file path during runtime when it is finally time to see the image. I don't have any problems with lag time or delays.
Even though I'm not showing the images in a UIScrollView, I still think you'd have little problem fetching the array of image information from the Core Data store and generating the full file path on the fly as cells are generated since those are just strings and the code for generating the UIImage is very compact. That or generate the same array of information, and then compiling an array of image paths before any cells are generating, like when the UIScrollView is just about to appear.
对于大于缩略图的任何内容，您应该使用文件系统方法。
一方面，如果您存储在核心数据中，则必须存储它具有数据或可转换属性。无论哪种情况，您都需要执行额外的步骤来转换为图像。如果您存储文件，则可以使用 UIImage 直接加载它。
然而，主要问题是内存使用，有缺陷的图像不会像 UIImage 那样从内存中清除。
2012-9-20 更新：这个答案现在已经过时了。 Core Data 没有自己的系统来存储大块数据，例如外部文件中的图像。
You should use the file system method for anything bigger than a thumbnail.
For one thing, if you store in Core Data you have to store it has either data or a transformable attribute. In either case, you have an extra step to convert to image. If you store a file, you can just use the UIImage to load it straight in.
The main problem, however, is memory use, a faulted image will not be purged from memory like a UIImage will.
Update 2012-9-20: This answer is now obsolete. Core Data no has its own system for storing large chunks of data like images in external files.
我认为将它们放入核心数据会很慢。文件系统将会变得更快。
I think that putting them in core data will be slow. The file system is going to be much faster.