NSFetchedResultsController和executeFetchRequest之间是否存在UITableView性能差异？

Question

我有一个由Core Date支持的iPad应用程序，并在UITableView中显示数据。我也在使用自定义单元格来显示每个单元格的多个ULabel。

它工作正常但是当很多项目被添加到tableView时它会陷入困境并感觉有些迟钝。我目前没有使用NSFetchedResultsController。每当对数据进行更改时，都会刷新ivar数组的数据：

items = [self.managedObjectContext executeFetchRequest:allItems error:&error];

Items是tableView从中提取所有数据的数组，所有内容都更新并运行。但它不是超级快！我的方法有问题吗？ NSFetchedResultsController是唯一的出路吗？委托/数据源方法中正在进行的处理并不那么重。基本上从数组中提取值并将它们设置为UILabels。

一切都按照我现在需要的方式运作，我只需要它更具响应性。

由于

Answer 1

使用仪器。总是。永远。

最有可能的是，你需要至少模仿FRC所做的一些批处理和前瞻性思考。但是，您可能会发现您始终在访问关系，预取它们可能会解决您的问题。

一切都是纯粹的猜测，没有硬，冷，数字......你很容易从乐器中获得。

修改

细胞绘制可能会减慢你的速度。但是，使用较少数量的对象也可以观察到这种情况。如果您的数据与其他单元格显着不同，您通常只会看到由于绘图导致性能下降。

现在，当然，假设您正在使用单元重用。如果你没有重复使用你的单元格，那么所有的赌注都会被取消。但是，对于单元重用，通常不应该看到与对象数相关的性能。

再次，运行乐器。这是唯一方式来了解问题所在。其他一切都是浪费时间。

Answer 2

绝对强烈推荐

NSFetchedResultsController。它不仅可以解决您的性能问题，还可以提供各种便利设施（例如委托协议）和幕后优化。

这些优化中最重要的可能是内存管理。您的解决方案（包含数组中的所有项目）似乎是一个糟糕的设计选择，不会扩展到大量的记录/行。

话虽如此，在绘制单元格时使用通常的优化策略：

• 尽量减少标签和其他子视图的使用;
• 不要使用透明背景;
• 不要使用1.0以外的alpha;
• 在单元格重叠等方面没有子视图。

如果性能仍然存在问题，则必须通过覆盖drawRect UITableViewCell子类的{{1}}来自行绘制内容。