问UIManagedDocument与NSManagedObject:性能

EN

UIManagedDocument是为基于文档的应用程序设计/设计的。每个文档一个UIManagedDocument实例。如果您没有构建基于文档的应用程序，那么您应该使用而不是正在使用UIManagedDocument。

人们喜欢UIManagedDocument的所有东西都可以通过直接使用核心数据栈来完成。UIManagedDocument将您从持久化层中抽象出来。你真的不想要的东西。

如果您想要一个高性能的核心数据应用程序，您不希望使用UIManagedDocument。你会遇到问题的。它会在随机的时间做一些事情，并导致性能问题。

你最好好好地学习这个框架。

就Vesper而言，这些不是文件；它们太小了。将文档视为Word文件或Excel文件。大的、复杂的数据结构，它们之间是100%隔离的。

此外，无论您是否使用UIManagedDocument，您都将使用NSManagedObject实例。NSManagedObject、NSManagedObjectContext、NSPersistentStoreCoordinator都是核心数据的基础对象。UIManagedDocument只是顶层的一个抽象层。

最后，Core数据不是数据库。这样想会让你陷入困境。核心数据是一个可以持久化到磁盘的对象模型，而持久化格式之一恰好是SQLite。

更新(遇到问题)

UIManagedDocument是核心数据之上的一个抽象。要使用UIManagedDocument，您实际上需要学习有关核心数据的更多，而不是仅仅使用主核心数据堆栈。

UIManagedDocument在内部使用父/子上下文。还不明白吗？请看上面的要点。这也意味着你对它保存的请求是“经过深思熟虑的”，而不是当时和那里被拯救的。这可能会导致意想不到的结果，如果你不理解它的意义，或不希望它保存当它感觉它。

UIManagedDocument使用异步保存，最多可以请求保存。这并不意味着它现在要保存，也不意味着您可以轻松地停止并等待保存完成。你需要相信它会完成它。此外，它可能会在不合时宜的时候决定储蓄。

当您开始使用Core数据寻找性能提升时，您倾向于希望以一种非常特定的方式构建堆栈，以最大限度地提高您的应用程序的效益。这是依赖于应用程序的，使用UIManagedDocument中的抽象，您很快就会受到限制。

即使在我构建基于文档的应用程序的情况下，我仍然会，，而不是使用UIManagedDocument。就在窗帘后面。

性能很可能取决于您的其余代码是如何实现的，而不一定是UIManagedDocument或NSManagedObject之间的区别。

将UIManagedDocument看作是CoreData的一个特定的小众实现，它已经将CoreData的部分放入到它的结构中，以节省您(开发人员)编写代码的时间。它是为处理UIDocuments和多线程而构建的。在幕后，UIManagedDocument很可能和你一样使用CoreData (假设你知道你在做什么)，但理论上你可以通过知道你的实现的确切和不合理的细节而省吃俭用。

如果您是CoreData或GCD和NSOperationQueue的新手，那么通过利用UIManagedDocument而不是滚动您自己的UIManagedDocument，您可能会节省大量的开发人员时间。

一个非常贴切的类比是使用NSFetchedResultsController来运行UITableView，而不是滚动自己的CoreData和UITableView实现。

如果你是目标C的新手，我建议你一开始就用UIManagedDocument做些有用的东西。稍后，您会在dispatch_asynch()和NSFetchRequest的杂草丛生中迷失方向，并在这里和那里获得几毫秒的性能。

干杯!

只需为每个便笺在磁盘上存储一个纯文本文件即可。

保持一个单独的数据库(使用sqlite或者仅仅使用-[NSDictionary writeToFile:atomically])来存储元数据，例如每个注释的最后一个用户修改日期和最后一个服务器同步日期。

定期与服务器对话，要求它提供自上次同步以来更改的内容列表，并在您的终端发送在同一时间内发生变化的任何数据。

这应该是完美的速度，只要你有少于一百万的笔记文件。在NSOperationQueue上执行所有网络和文件系统操作。