存储 NSManagedObjectID 与 NSManagedObject
我有一个应用程序，用户可以在其中选择要显示的位置的特定主题。我将选定的主题 objectID 存储在 NSUserDefaults 中，以便当应用程序重新启动时，选定的主题仍然完好无损。
在整个应用程序中，我都会引用这个选定的主题。我目前有一个类变量来保存 objectID，但是有时我需要检索对象本身的属性（即名称属性）。为此，我从核心数据中检索对象，然后访问我的值。
我担心执行此操作所需的处理时间，所以我的问题 - 什么是更好的选择......？
1）将objectID存储在内存中，并在每次需要访问属性时查询核心数据以检索对象。我认为这更便宜，因为我的内存使用量更少，但处理成本更高。
2）将actaul对象存储在内存中，然后在我需要的时候简单地访问该对象。我认为这在处理意义上更便宜，但在内存使用方面可能更昂贵。
I have an app where users can select a specific theme for locations to display. I store the selected theme objectID in NSUserDefaults so that when the app restarts, the selected theme will still be intact.
Throughout the app I reference back to this selected theme. I currently have a class variable to hold the objectID, however I sometimes need to retrieve properties of the object itself (i.e. the name property). To do this I retrive the object from core data and then access my value.
I'm worried about the processing time required to do this, so my question - What is the better option ... ?
1) Store the objectID in memory and query core data to retrieve the object each time I need to access a property. I think this is cheaper in the sense that I have less memory usage, but more expensive in processing.
2) Store the actaul ojbect in memory and then simply access the object whenever I want. I think this is cheaper in the sense of processing, but may be more costly in memory usage.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
无论如何，这都不重要。 Core Data 通过 ID 检索单个对象所需的时间实际上为 0。单个托管对象使用的内存量（假设该对象不包含一堆图像数据元素）正在减少可以忽略不计。
根据最容易实施和最容易维护的方式做出决定。性能不会成为一个因素。我目前正在开发一个在 Core Data 中存储数百个 HTML 页面的应用程序，并且我不断地读取/写入/修改这些对象，没有任何明显的滞后时间。
It's not going to matter either way. The amount of time it takes Core Data to retrieve a single object by its ID is going to be effectively 0. The amount of memory used by a single managed object (assuming the object doesn't contain a bunch of image data elements) is going to be negligible.
Base your decision on whatever is easiest to implement and easiest to maintain. Performance is not going to be a factor. I'm currently working on an app that stores hundreds of HTML pages in Core Data and I am constantly reading/writing/modifying these objects with no perceptible lag time whatsoever.