0

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

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

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

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

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

谢谢

4

2 回答 2

3

使用仪器。总是。永远。

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

一切都是纯粹的推测，没有硬的、冷的、数字……你可以从 Instruments 轻松获得。

编辑

单元格绘图可能会减慢您的速度。但是，这对于较少数量的对象也是可以观察到的。如果您的数据与其他单元格有显着差异，您通常只会看到由于绘图而导致性能下降。

现在，当然，假设您正在使用单元重用。如果你不重复使用你的细胞，那么所有的赌注都没有了。但是，使用单元重用时，您通常不会看到与对象数量相关的性能。

再次，运行仪器。这是了解您的问题所在的唯一方法。其他一切都是浪费时间。

于 2012-08-25T19:47:11.817 回答
1

NSFetchedResultsController绝对强烈推荐。它不仅可以潜在地解决您的性能问题，还可以带来各种便利的设施（例如委托协议）和幕后优化。

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

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

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

如果性能仍然是一个问题，您将不得不通过覆盖子类来自己绘制drawRect内容UITableViewCell。

于 2012-08-25T19:48:23.340 回答