0

这是我在 cellForRowAtIndexPath 中调用的内容：

   NSManagedObjectContext *context = [[AppDelegate sharedAppDelegate] managedObjectContext];
    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
    NSEntityDescription *entity = [NSEntityDescription
                                   entityForName:@"Favorites" inManagedObjectContext:context];
    [fetchRequest setEntity:entity];

    NSPredicate *requestPredicate = [NSPredicate predicateWithFormat:[NSString stringWithFormat:@"(link like '%@')",articleLink]];
    [fetchRequest setPredicate:requestPredicate];

    [fetchRequest setFetchBatchSize:1];
    NSError *error = nil;
    NSUInteger count = [context countForFetchRequest:fetchRequest error:&error];
    NSLog(@"Count - %d", count);
    if (count == 0)
        return NO;
    else
        return YES;

基本上它会检查我的模型中是否存在某个项目。非常有用，但我认为在这么短的时间内发出如此多的获取请求有什么问题吗？

电池管理有任何问题，每次调用时都会从磁盘读取吗？

有更好的吗？

谢谢！

4

2 回答 2

2

您不想在滚动时进行提取。它会破坏你的滚动性能。

从您提到的代码中，您正在尝试根据是否已存储链接对单元格执行某些操作。

我可能会在加载视图控制器并将其存储在内存中时预先执行该操作，然后在滚动时检查该值。

于 2012-11-11T14:27:32.657 回答
1

你正在做的事情有几个问题。首先，获取非常慢，因为它确实会从磁盘上的持久存储中读取。您的获取只会变得越慢，您的数据库越大，您的查询（您的 NSPredicate）就越复杂。

其次，您无法控制 cellForRowAtIndexPath 被调用的次数，您只能假设它在每个单元格可见时被调用一次，但它也可能在其他情况下被调用。您也无法控制用户如何使用您的 ScrollView，他可能会疯狂地滚动。该方法中的所有内容都必须尽可能高效并且不能减慢您的主线程，否则您的 ScrollView 将不断冻结，这对用户来说看起来很糟糕。

第三，您不断地分配和初始化新对象，在本例中是 NSFetchRequests，这很昂贵。缓存将极大地提高您的性能，如果可能，您应该始终尽量避免分配新对象。尽管这已经是一个不好的例子，但 fetchRequest 可以很容易地存储为全局变量，并在每次获取之前更改其谓词。

从代码中我可以看出，您似乎有一个名为 Favorite 的实体，其中包含一个链接、一个显示链接的 TableView，并且您希望根据该链接是否为收藏来更改有关您的单元格的某些内容。

您应该做的是在首次加载 ViewController 时获取所有收藏夹，将它们的所有链接存储在一个数组中，然后在 cellForRowAtIndexPath 中检查 articleLink 是否存在于该数组中。这样，您只有在用户滚动浏览您的 ScrollView 时才从内存中读取，并且您的性能将是最佳的。

于 2012-11-12T09:15:44.967 回答