首先，我在下面粘贴的链接问题上找到了几个相关问题，但没有一个真正帮助我解决问题：
iPhone CoreData properties: changes to managedObjects are too slow
iOS CoreData: NSFetchedResultsController performances
我有一个包含大约5,000行的表视图，当前由获取的结果控制器管理。
每行显示Document实体的基本属性，还包括一个按钮，供用户将特定Document标记为收藏夹。不可否认，Document实体与几个不同的实体有关系，底层的SQLite数据库很大（~20mb）。
获取每一行的属性相对较快，并且表视图在许多项目中表现良好。保存更改也不是问题。
当我尝试更改Document实体的isFavourite（BOOL）属性时出现问题。使用以下内容在事件内部按钮上设置/更新此属性：
[document setIsFavourite:[NSNumber numberWithBool:![document isFavourite]]]
这里的问题是，在每次点按“收藏夹”按钮时，这段特殊的代码会阻止用户界面约1-2秒，这显然不太理想。
我已经尝试将isFavourite属性标记为索引，以及增加获取批量大小并最终为NSFetchedResultsController创建缓存，但似乎没有任何帮助提高性能。
我设法避免UI锁定的唯一方法是在后台线程上执行属性设置，但这涉及创建新上下文，在保存上下文时注册通知和合并更改。在这种情况下会出现另一个问题，因为当我通过合并更改响应保存通知时，我的提取结果控制器似乎感到困惑，并且更改的行自动从我的tableview中删除，并且获取它的唯一方法是做a [tableview reloadData]。
是否有其他人遇到过类似的问题，还有什么我可以尝试修复的吗？
非常感谢，
罗格
答案 0 :(得分：1)
该行不应该导致挂起，因为不需要提取任何内容。您已在内存中拥有文档对象，并且您只在内存中更改该对象的单个属性。
我只能想到为什么这样一条线会导致挂起的两个原因。
首先，您有一个setIsFavourite:的自定义访问器，可以触发驱动故障和提取的副作用。例如。您有自定义逻辑，当isFavourite属性更改触发获取的属性时触发该自定义逻辑。
我倾向于这个解释，因为你使用旧的参考形式而不是：
document.isFavourite=[NSNumber numberWithBool:![document isFavourite]];
如果您手动创建了document对象的类，请检查您是否使用@dynamic而不是@synthesize作为属性。后者不适用于NSManagedObject子类。
其次，您在触发类似级联的属性上设置了验证，例如验证必须检查另一个对象中的属性。
我很怀疑代码行实际上是问题的根源。