Question

我在使用Core Data时遇到了一些性能问题，我希望有人能给我一些如何改进它的技巧。在为save:调用NSManagedObjectContext时，我遇到的单个实体的保存时间超过1秒。我正在主线程上执行保存，因此它在此期间锁定了GUI，这是不可接受的。这是我正在执行保存的代码;在修改WTSRecord的字段后启动此代码：

- (void)saveRecord:(WTSRecord *)record
           success:(void (^)(WTSRecord *record))success
           failure:(void (^)(NSError *error))failure {
    DDLogVerbose(@"saveRecord: %@", record.objectID);

    if (record.recordId != nil) {
        //mark this record as a pending modify if it has a database id
        record.pendingModify = [NSNumber numberWithBool:YES];
    }
    NSError *error;
    NSManagedObjectContext *context = record.managedObjectContext;
    NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970];
    if (![context saveToPersistentStore:&error]) {
        failure(error);
    } else {
        NSLog(@"time to persist record: %f", ([[NSDate date] timeIntervalSince1970] - startTime));

        ...do other stuff here...

    }
}

我启用了SQL调试，Core Data只是更新了一条记录，似乎没有做任何不寻常的事情：

2014-08-13 11:25:32.528 Identify[5395:60b] CoreData: sql: BEGIN EXCLUSIVE
2014-08-13 11:25:32.530 Identify[5395:60b] CoreData: sql: UPDATE ZWTSRECORD SET ZDESC = ?, Z_OPT = ?  WHERE Z_PK = ? AND Z_OPT = ?
2014-08-13 11:25:32.531 Identify[5395:60b] CoreData: details: SQLite bind[0] = "ffffffffffffuuuuiiiiuu"
2014-08-13 11:25:32.532 Identify[5395:60b] CoreData: details: SQLite bind[1] = (int64)48
2014-08-13 11:25:32.533 Identify[5395:60b] CoreData: details: SQLite bind[2] = (int64)306
2014-08-13 11:25:32.534 Identify[5395:60b] CoreData: details: SQLite bind[3] = (int64)47
2014-08-13 11:25:32.535 Identify[5395:60b] CoreData: sql: COMMIT
2014-08-13 11:25:32.538 Identify[5395:60b] time to persist record: 1.376321

这似乎是一个非常简单的更新，真的不应该花那么长时间。在这种情况下，sqllite数据库中大约有40 WTSRecord个。如果我删除sqllite商店并且只修改一个WTSRecord，则持续时间不到1/20秒。

我在cocoanetics上看到有关异步保存的this post，但我只是想知道在我走这条路之前我是否做了一些根本性的错误。提前谢谢！

编辑1：

附件是Time Profiler的屏幕截图。看起来1.3秒专门用于在我的controllerDidChangeContent:中运行UITableViewController，这是绘制表格视图单元格。为什么要花这么长时间？

Time Profiler

编辑2

以下是我的NSFetchedResultsControllerDelegate方法。它们并没有真正改变样板Apple代码：

- (void)controllerWillChangeContent:(NSFetchedResultsController *)controller
{
    DDLogVerbose(@"FRC calling beginUpdates in controllerWillChangeContent");
    [self.tableView beginUpdates];
    DDLogVerbose(@"FRC done calling beginUpdates in controllerWillChangeContent");
}

- (void)controller:(NSFetchedResultsController *)controller didChangeSection:(id <NSFetchedResultsSectionInfo>)sectionInfo
           atIndex:(NSUInteger)sectionIndex forChangeType:(NSFetchedResultsChangeType)type
{
    switch(type) {
        case NSFetchedResultsChangeInsert:
            DDLogVerbose(@"FRC inserted section");
            [self.tableView insertSections:[NSIndexSet indexSetWithIndex:sectionIndex] withRowAnimation:UITableViewRowAnimationFade];
            break;

        case NSFetchedResultsChangeDelete:
            DDLogVerbose(@"FRC deleted section");
            [self.tableView deleteSections:[NSIndexSet indexSetWithIndex:sectionIndex] withRowAnimation:UITableViewRowAnimationFade];
            break;
    }
}

- (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject
       atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type
      newIndexPath:(NSIndexPath *)newIndexPath
{
    UITableView *tableView = self.tableView;

    switch(type) {
        case NSFetchedResultsChangeInsert:
            DDLogVerbose(@"FRC inserted object");
            [tableView insertRowsAtIndexPaths:@[newIndexPath] withRowAnimation:UITableViewRowAnimationFade];
            break;

        case NSFetchedResultsChangeDelete:
            DDLogVerbose(@"FRC deleted object");
            [tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UITableViewRowAnimationFade];
            break;

        case NSFetchedResultsChangeUpdate:
            DDLogVerbose(@"FRC updated object");
            [self configureCell:[tableView cellForRowAtIndexPath:indexPath] atIndexPath:indexPath];
            break;

        case NSFetchedResultsChangeMove:
            DDLogVerbose(@"FRC moved objects");
            [tableView deleteRowsAtIndexPaths:@[indexPath] withRowAnimation:UITableViewRowAnimationFade];
            [tableView insertRowsAtIndexPaths:@[newIndexPath] withRowAnimation:UITableViewRowAnimationFade];
            break;
    }
}

- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller
{
    DDLogVerbose(@"FRC calling endUpdates in controllerDidChangeContent");
    [self.tableView endUpdates];
    DDLogVerbose(@"FRC done calling endUpdates in controllerDidChangeContent");
}

我添加了一些打印输出，发现绝大部分时间花在[self.tableView endUpdates]上。这是我的日志的打印输出：

2014-08-14 10:44:39:663 Identify[5718:60b] Saving to context(<NSManagedObjectContext: 0x145b82c0>)
2014-08-14 10:44:39:666 Identify[5718:60b] FRC calling beginUpdates in controllerWillChangeContent
2014-08-14 10:44:39:666 Identify[5718:60b] FRC done calling beginUpdates in controllerWillChangeContent
2014-08-14 10:44:39:668 Identify[5718:60b] FRC updated object
**2014-08-14 10:44:39:671 Identify[5718:60b] FRC calling endUpdates in controllerDidChangeContent
**2014-08-14 10:44:40:889 Identify[5718:60b] FRC done calling endUpdates in controllerDidChangeContent
2014-08-14 10:44:41:018 Identify[5718:60b] Time to save in context(<NSManagedObjectContext: 0x145b82c0>): 1.355229

Answer 1

现在你已经确定你的问题不是你的保存，而是你的绘图代码有一些选择。

深入了解您的手机代码，看看花了多长时间。计算一些东西？画阿尔法？
将保存移出主队列。

选项2无法解决您的重绘问题，但会减少您的节省时间。您可以通过在主MOC和PSC之间放置一个私有MOC来实现此目的。然后保存离开主队列。但是你的绘图代码仍然会阻止。

我会钻进每个单元格，看看发生了什么。使用工具打开源代码并找出哪些代码是昂贵的，然后探究原因。 Alpha绘图是一个常见问题。图像加载等也可能很受欢迎。

Answer 2

好吧，我想我弄明白了。解决方案涉及两个部分：

stackoverflow上的

This post帮助了我很多。显然，自动布局和离线绘图存在性能问题。当FRC被解雇时，UITableViewController遇到[tableView endUpdates]性能问题的viewWillAppear屏幕外。我将以下代码添加到NSFetchedResultsControllerDelegate和- (void)viewWillAppear:(BOOL)animated { [super viewWillAppear:animated]; if (self.needsFetch) { self.needsFetch = NO; [self.fetchedResultsController performFetch:nil]; } if (self.needsReload) { self.needsReload = NO; [self.tableView reloadData]; } } - (void)controllerWillChangeContent:(NSFetchedResultsController *)controller { //don't update the table view if it isn't being displayed if (!self.tableView.window) { self.needsReload = YES; return; } DDLogVerbose(@"FRC calling beginUpdates in controllerWillChangeContent. results list controller type: %i", self.type); [self.tableView beginUpdates]; DDLogVerbose(@"FRC done calling beginUpdates in controllerWillChangeContent"); } - (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type newIndexPath:(NSIndexPath *)newIndexPath { //don't update the table view if it isn't being displayed if (!self.tableView.window) { if (type == NSFetchedResultsChangeDelete) { NSLog(@"setting needs fetch"); self.needsFetch = YES; } return; } UITableView *tableView = self.tableView; ...same as before... } OTHER FRC DELEGATE FUNCTIONS NEED WINDOW NULL CHECK ALSO方法中。当表视图需要刷新或者需要执行获取的结果控制器时（我发现需要在删除时发生），我使用BOOL属性来标记：

[NSManagedObjectContext saveToPersistentStore]

我也改进了我打电话NSManagedObjectContext的方式。该方法是RestKit的NSManagedObjectContext类别的一部分，在其中我看到他们在自己的块中执行保存操作并等待，无论NSPrivateQueueConcurrencyType是否在其自己的私有队列中运行（RestKit by default使用写入NSManagedObjectContext类型的持久性存储的内容设置父/子上下文。在仔细阅读this post之后，我在我自己的- (void)saveToPersistentStoreAsync:(void (^)(NSError *error))block { [self performBlock:^{ DDLogVerbose(@"Saving to context(%@)", self); NSTimeInterval startTime = [[NSDate date] timeIntervalSince1970]; NSError *error; if (![self save:&error]) { if (block) { dispatch_async(dispatch_get_main_queue(), ^{ block(error); }); } } else { DDLogVerbose(@"Time to save in context(%@): %f", self, ([[NSDate date] timeIntervalSince1970] - startTime)); if (self.parentContext) { [self.parentContext saveToPersistentStoreAsync:block]; } else { if (block) { dispatch_async(dispatch_get_main_queue(), ^{ block(nil); }); } } } }]; }类别中构造了此方法，该类将执行核心数据与块回调异步保存：

{{1}}

总而言之，在这两种变化之后，我的UI响应速度更快。我希望我不会做任何会在将来引起某种竞争状况的事情，但是希望这对我有用！

Core Data在保存时表现不佳：和[UITableView endUpdates]

2 个答案: