Cocoa Touch:什么时候需要 NSFetchedResultsController 来管理核心数据获取? [英] Cocoa Touch: When does an NSFetchedResultsController become necessary to manage a Core Data fetch?

查看:15
本文介绍了Cocoa Touch:什么时候需要 NSFetchedResultsController 来管理核心数据获取?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在开发一个大量使用 Core Data 的 iPhone 应用程序,主要是因为它的类似数据库的功能(例如设置排序顺序或获取请求的谓词的能力).我正在展示我在各种 UITableViewController 中获取的所有数据.

I'm developing an iPhone application that makes heavy use of Core Data, primarily for its database-like features (such as the ability to set a sort order or predicate on fetch requests). I'm presenting all the data I fetch in various UITableViewControllers.

我想知道的是,在使用 NSFetchedResultsController 处理请求成为一个好主意之前,我可以获取多少对象的粗略概念.在 Core Data 文档中,它说 SQLite 存储认为10,000 个对象是一个相当小的数据集",但在 NSFetchedResultsController 的文档中它提到一次在内存中保留数十个对象".

What I'd like to know is a rough idea of how many objects I can fetch before it becomes a good idea to use an NSFetchedResultsController to handle the request. In the Core Data docs, it says that SQLite stores consider "10,000 objects to be a fairly small data set," but in the documentation for NSFetchedResultsController it mentions keeping "tens of objects" in memory at a time.

我主要处理多达五十个对象的数据集,每个对象可能有十几个 NSNumber 和 NSString 实例,以及下一组对象的一对多关系(即有二十个实例对象 A,每个对象与对象 B 的一组 30 个(不同)实例有一对多的关系,每个实例......).

I'm dealing primarily with data sets of up to fifty objects that each have maybe a dozen instances of NSNumber and NSString, as well as a one-to-many relationship for the next set of objects (i.e. there are twenty instances of object A, each of which have a to-many relationship to a set of thirty (distinct) instances of object B, each of which...).

这种情况是否适合使用 NSFetchedResultsController,或者我可以使用简单的 NSArray 结果吗?我自己在管理控制器的细节方面没有问题(获取 UITableView 索引路径的对象的便捷方法,将新对象添加回上下文等),我只是想知道内存使用情况每种方法.

Is this scenario a good fit for using an NSFetchedResultsController, or can I get away with a simple NSArray of results? I don't have an issue with managing the niceties of the controller (convenience methods to get an object for a UITableView index path, adding new objects back to the context, etc.) myself, I'm just wondering about the memory usage of each approach.

我应该提到该应用程序将主要针对 iPhone 3G(而非 S)和第一代 iPod Touch 用户,因此请记住这些平台的内存有限.

I should mention the app will be targeted primarily at iPhone 3G (not S) and first-gen iPod Touch users, so please keep the limited memory of these platforms in mind.

推荐答案

NSFetchedResultsController 是一个非常方便的辅助类,用于将 Core Data 与 UITableViews 连接起来.我的建议是将它与具有核心数据支持的每个表视图一起使用.在我使用它的每种情况下,它都显着减少了我必须编写的代码量.

NSFetchedResultsController is an incredibly handy helper class for interfacing Core Data with your UITableViews. My recommendation would be to use it with every table view that has a Core Data backing. In every case I've used it for, it significantly reduced the amount of code I had to write.

在性能方面,它也可以带来巨大的改进.如果您将 -setFetchBatchSize: 与您提供给 NSFetchedResultsController 的 NSFetchRequest 一起使用,而不是在整个数据集中提取,您可以进行批量提取,其中仅提取表视图中显示的相关数据.不再显示的数据也可以自动从内存中删除(或者我的理解是这样).

Performance-wise, it can lead to a huge improvement as well. Rather than fetching in your entire data set, if you use -setFetchBatchSize: with the NSFetchRequest that you feed into the NSFetchedResultsController, you can do batched fetching where only the relevant data being displayed in your table view is fetched. Data no longer on display can also be removed from memory automatically (or so is my understanding).

对于具有中等到大型数据集的表,这可以显着提高性能.引用 Apple 工程师的话说,对于一个 10,000 项的数据库,这可以减少 80% 以上的启动时间和 50% 的内存使用.

For tables with moderate to large data sets, this can lead to a significant performance win. Apple engineers have been quoted as saying that for a 10,000 item database, this can reduce your startup time by over 80% and your memory usage by 50%.

这篇关于Cocoa Touch:什么时候需要 NSFetchedResultsController 来管理核心数据获取?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆