Storing Images in file system vs. Core Data

五迷三道 提交于 2019-12-03 14:16:37

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.

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.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!