Performance NSFetchedResultsController插入锁定UI

我正在使用web套接字和核心数据构建聊天应用程序

基本上，只要在web套接字上接收到消息，就会发生以下情况：

通过使用索引的id执行核心数据提取，检查消息是否存在 如果1。返回是，更新消息并执行核心数据保存。如果1。返回否，创建消息并执行核心数据保存。 通过更新或插入新行来更新表视图。 以下是我的设置：

我有两个默认的托管对象上下文。主NSMainQueueConcurrencyType和写入程序NSPrivateQueueConcurrencyType。WRITER有一个对persisten存储协调器的引用，MAIN没有，但WRITER被设置为MAIN的父级

TableView连接到一个NSResultsFetchController，该控制器连接到MAIN

获取都是使用临时上下文performBlock:执行的，该上下文以MAIN作为其父级。写操作如下所示：保存临时上下文，然后保存MAIN，然后保存WRITER

问题:

因为更新是通过web套接字进行的，所以在繁忙的聊天室中，许多更新都是在短时间内完成的。同步获取旧消息可能意味着许多消息会快速传入。这会锁定用户界面

我使用fetched results controller的委托跟踪对ui的更改，如下所示：

// called on main thread
- (void)controllerWillChangeContent:(NSFetchedResultsController *)controller
{
  NSLog(@"WILL CHANGE CONTENT");
  [_tableView beginUpdates];
}

// called on main thread
- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller
{
  NSLog(@"DID CHANGE CONTENT");
  [_tableView endUpdates];
}

下面是我在日志文件中看到的示例：

2014-07-14 18:46:20.630 AppName[4938:60b] DID CHANGE CONTENT
2014-07-14 18:46:22.334 AppName[4938:60b] WILL CHANGE CONTENT

这几乎是每次插入2秒

这仅仅是我在TableView中遇到的一个限制吗？在某些情况下，我说的是1000多行，但我无法想象情况会是这样。UITableView针对这种操作进行了超级优化

我可能犯的任何明显的新手错误？

这不符合逻辑：

写操作如下所示：保存临时上下文，然后保存MAIN，然后保存WRITER

如果writer是main的子上下文，则在下次保存之前不会保留更改。

好的，我已经解决了

问题是tableView:heightForRowAtIndexPath:。计算行高度的获取需要时间，每次调用tableView.endUpdates时，UITableView都需要所有行的高度

---

tableView:EstimatedHeightForrowatineXpath:是一种可能的方法，可以使用iOS7+，或者我可以选择自己缓存高度，因为行不会更改，或者只显示较少的行。altog

日志中显示的时差是两次更新之间的时差，不是一次更新的持续时间。@Mundi yes显示每个周期有多慢。。不，writer是main的父级。