1

创建单元格时，我正在做一些繁重的计算。我试图找出保持 UITableView 流畅的最佳方法，但在同一类型的背景下进行计算（保持 UI 线程没有太多处理）。

仅出于测试目的，我将其用作我的繁重计算方法：

+(NSString*)bigCalculation
{
    int finalValue=0;
    int j=0;
    int i=0;

    for (i=0; i<1000; i++) {
        for (j=0; j<10000000; j++) {
            j++;
        }
        finalValue+=j/100*i;
    }

    return [NSString stringWithFormat:@"%d",finalValue];
}

在 cellForRowAtIndexPath 中，我只执行以下操作：

- (UITableViewCell *)tableView:(UITableView *)aTableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    NSString *identifier=@"identifier";

    UITableViewCell *cell=nil;
    cell=[aTableView dequeueReusableCellWithIdentifier:identifier];
    if(!cell)
    {
        cell=[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleSubtitle reuseIdentifier:identifier];
    }

    NSString *text=[dataSource objectForKey:[[dataSource allKeys] objectAtIndex:indexPath.row]];


    dispatch_queue_t a_queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0);
;
    dispatch_async(a_queue, ^{

        NSString *subtitle=[CalculationEngine bigCalculation];
        dispatch_async(dispatch_get_main_queue(), ^{
            [[cell detailTextLabel] setText:subtitle];
            dispatch_release(a_queue); 
        });
    });


    [[cell textLabel] setText:text];
    return cell;
}

目前我有 UITableView 流体，而在后台一切正常。所以我的问题是：

1）这是实现我想要的最佳方式吗，KVO 也可以是答案吗？

2）在这样做之前：

dispatch_queue_t a_queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0);

我在做：

dispatch_queue_create("com.mydomain.app.newimagesinbackground", DISPATCH_QUEUE_SERIAL)

而且表现很差。你能解释一下为什么吗？

4

2 回答 2

6

首先

您的实施存在根本缺陷。您将对单元格的引用放入在后台执行的块中。当您滚动并从屏幕上取下单元格时，它们将被放入重用池中。当新的细胞出现在屏幕上时，它们就会从这个池中被拉出来。当您的块完成时，单元格可能不再位于同一行中。为了说明这一点，我将这个语句放在工作块的开头：

NSLog(@"my Row is: %d myCell is: %x", indexPath.row, (unsigned int)cell);

这导致：

我的行是：0 myCell 是：16fd20
我的行是：13 myCell 是：16fd20
我的行是：24 myCell 是：16fd20
我的行是：35 myCell 是：16fd20
我的行是：44 myCell 是：16fd20
我的行是：56 myCell 是：16fd20
我的行是：66 myCell 是：16fd20

所以在这里你可以看到 7 个块，它们都在计算不同的行，但都指向同一个单元格。
如果用户在块完成时滚动，则会更新错误的单元格。

您还希望dispatch_sync(dispatch_get_main_queue(),0)在更新单元格时使用以确保立即对其进行处理。

KVO 是解决此问题的一种方法，导致..

你的第一个问题：

KVO 将是一个很好的方法来做到这一点。正如 Rob Napier 提到的，您应该为列表中的每个项目都有一个单独的模型对象。为了管理 tableView 中单元格的更新，您希望继承 UITableViewCell。然后单元格订阅模型对象以获取通知，并且可以在收到通知时自行更新。如果单元格模型对象发生更改，您只需退出旧模型对象的通知并订阅新模型对象。

这应该保证您永远不会像当前代码那样在单元格中显示不准确的信息。

需要注意的一点：KVO 在设置新值的同一线程上发送通知。这意味着您需要确保在主线程上设置新值或在observeValueForKeyPath:方法中的主线程上分派一个块。

你的第二个问题：

以这种方式排队的原因：

dispatch_queue_create("com.mydomain.app.newimagesinbackground", DISPATCH_QUEUE_SERIAL);

太慢了，以至于您为每个计划的块生成一个串行队列。这些队列将同时执行。由于您只有少量内核，队列有越来越小的时间片来执行自己。主队列（运行 UI）只是另一个队列，它必须执行的时间也越来越少，并且更小。

在我的测试中，我发现每个队列都有一个线程。与单元格一样多的线程。

使用全局并发队列：

dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_LOW, 0);

允许系统管理一次执行的块数。这样做的最终结果是，你有一个队列，而不是数百个队列和数百个线程，而在我的 iPhone 4s 上，有两个线程。每个核心一个线程。这使得调度更简单，并为线程分配更准确的优先级。最终结果是主线程有足够的时间执行。

于 2012-04-14T13:18:37.450 回答
3

这不是一个好方法。您通过将计算工作推入视图控制器来破坏 MVC。您应该将数据保存在模型对象中并在那里管理计算。然后，表格视图应该只显示模型中的当前值，reloadRowsAtIndexPaths:withRowAnimation:在数据更改时使用。KVO 是确定数据何时更改的一种合理方法。

如果你想在计算中偷懒，那么你可以调用模型recalculateIfNeeded，让模型知道有人（在这种情况下是表视图）想要一个新的值。但是，如果输入数据实际上没有更改，则不应重新计算。模型是跟踪数据是否发生变化的地方。

于 2012-04-11T17:42:29.553 回答