4

我的应用程序在后台线程中进行更新，然后保存上下文更改。在主要上下文中，有一个与NSFetchedResultsController. 一段时间内更新正常工作，但随后引发异常。要检查这一点，我已添加NSLog(@"%@", [self.controller fetchedObjects]);到-controllerDidChangeContent:. 这是我得到的：

"<PRBattle: 0x6d30530> (entity: PRBattle; id: 0x6d319d0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p2> ; data: {\n    battleId = \"-1\";\n    finishedAt = \"2012-11-06 11:37:36 +0000\";\n    opponent = \"0x6d2f730 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p1>\";\n    opponentScore = nil;\n    score = nil;\n    status = 4;\n})",
"<PRBattle: 0x6d306f0> (entity: PRBattle; id: 0x6d319f0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p1> ; data: {\n    battleId = \"-1\";\n    finishedAt = \"2012-11-06 11:37:36 +0000\";\n    opponent = \"0x6d2ddb0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p3>\";\n    opponentScore = nil;\n    score = nil;\n    status = 4;\n})",
"<PRBattle: 0x6d30830> (entity: PRBattle; id: 0x6d31650 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p11> ; data: <fault>)",
"<PRBattle: 0x6d306b0> (entity: PRBattle; id: 0x6d319e0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p5> ; data: {\n    battleId = 325;\n    finishedAt = nil;\n    opponent = \"0x6d2f730 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p1>\";\n    opponentScore = 91;\n    score = 59;\n    status = 3;\n})",
"<PRBattle: 0x6d30730> (entity: PRBattle; id: 0x6d31a00 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p6> ; data: {\n    battleId = 323;\n    finishedAt = nil;\n    opponent = \"0x6d2ddb0 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p3>\";\n    opponentScore = 0;\n    score = 0;\n    status = 3;\n})",
"<PRBattle: 0x6d307b0> (entity: PRBattle; id: 0x6d31630 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p9> ; data: {\n    battleId = 370;\n    finishedAt = \"2012-11-06 14:24:14 +0000\";\n    opponent = \"0x79a8e90 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p2>\";\n    opponentScore = 180;\n    score = 180;\n    status = 4;\n})",
"<PRBattle: 0x6d307f0> (entity: PRBattle; id: 0x6d31640 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p10> ; data: {\n    battleId = 309;\n    finishedAt = \"2012-11-02 01:19:27 +0000\";\n    opponent = \"0x79a8e90 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p2>\";\n    opponentScore = 120;\n    score = 240;\n    status = 4;\n})",
"<PRBattle: 0x6d30770> (entity: PRBattle; id: 0x6d31620 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p7> ; data: {\n    battleId = 315;\n    finishedAt = \"2012-11-02 02:26:24 +0000\";\n    opponent = \"0x79a8e90 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PROpponent/p2>\";\n    opponentScore = 119;\n    score = 179;\n    status = 4;\n})"

)

此处的故障对象 (0xe972610) 会导致崩溃。我在更新期间和保存之前记录了数据。此对象仅在updatedObjects。为什么这个方法可以返回“坏”对象？（此外，在更新期间，该对象几乎每次更新都会受到影响。并且只有在某些通过之后才会变成“坏”）。

PS：我使用 RestKit 来管理 CoreData。

更新2：

看起来问题出在[self.controller fetchedObjects]枚举中。即使在此方法调用期间，它也被调用- (void)controllerDidChangeContent:(NSFetchedResultsController *)controller并且似乎这些对象被修改（我的意思是CoreData 更新尚未完成）。是否可以？

更新：

当我做某事时，出现了例外。像这样：

for (PRBattle *battle in [self.controller fetchedObjects) {
    switch (battle.statusScalar) {
        case ...
        default:
            [battle willAccessValueForKey:nil];
            NSAssert1(NO, @"Unexpected battle status found: %@", battle);
    }
}

例外是在线-willAccessValueForKey:。战斗的标量状态是枚举，即绑定到整数值 1..4。我已经提到了 switch 案例中的所有可能值（上图default:）。最后一个有break;。所以这个只有在battle.statusScalar返回非枚举值时才有可能。

状态标量实现PRBattle：

- (PRBattleStatuses)statusScalar
{
    [self willAccessValueForKey:@"statusScalar"];
    PRBattleStatuses result = (PRBattleStatuses)[self.status integerValue];
    [self didAccessValueForKey:@"statusScalar"];
    return result;
}

并且battle.status有验证规则： - 最小值：1 - 最大值：4 - 默认值：无值

最后一件事 - 调试日志：

objc[4664]: EXCEPTIONS: throwing 0x7d33f80 (object 0xe67d2a0, a _NSCoreDataException)
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97b401 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: catch(id)
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x97b401 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: handling exception 0x7d33f60 at 0x97b79f
objc[4664]: EXCEPTIONS: rethrowing current exception
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97b911 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x9ac8b7 sp=0xbfffdc20] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97ee80 sp=0xbfffdc40] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x361d0 sp=0xbfffdc70] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0xa701d8 sp=0xbfffde10] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: catch(id)
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x97b911 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: finishing handler
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97b963 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x9ac8b7 sp=0xbfffdc20] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x97ee80 sp=0xbfffdc40] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0x361d0 sp=0xbfffdc70] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: searching through frame [ip=0xa701d8 sp=0xbfffde10] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: catch(id)
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x97b963 sp=0xbfffd9b0] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x9ac8b7 sp=0xbfffdc20] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x97ee80 sp=0xbfffdc40] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x361d0 sp=0xbfffdc70] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0x3656f sp=0xbfffdc70] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: unwinding through frame [ip=0xa701d8 sp=0xbfffde10] for exception 0x7d33f60
objc[4664]: EXCEPTIONS: handling exception 0x7d33f60 at 0xa701f5
2012-11-07 13:37:55.463 TestApp[4664:fb03] CoreData: error: Serious application error.  An exception was caught from the delegate of NSFetchedResultsController during a call to -controllerDidChangeContent:.  CoreData could not fulfill a fault for '0x6d31650 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p10>' with userInfo {
    NSAffectedObjectsErrorKey =     (
        "<PRBattle: 0x6d30830> (entity: PRBattle; id: 0x6d31650 <x-coredata://882BD521-90CD-4682-B19A-000A4976E471/PRBattle/p10> ; data: <fault>)"
    );
}
4

1 回答 1

0

崩溃主要原因：“在后台线程中保存容易出错”（http://developer.apple.com/library/ios/#documentation/cocoa/conceptual/CoreData/Articles/cdConcurrency.html//apple_ref/doc/ uid/TP40003385-SW7)。当然，我以前读过这个。但是，RestKit 的问题变得更大了。它适用于“contextForCurrentThread”。因此，您应该获得后台线程的唯一上下文（根据同一文档）。但是你不能从主线程中保存它，除非你直接传递它，因为在主线程中这个方法返回另一个上下文。当我看到这个时，我认为 RestKit 为我解决了这个问题（在“正常”保存期间，而不是来自主线程），但没有。

第二件事是NSFetchedResultsController。当你打电话[self.controller fetchedObjects]给你时，-controllerDidChangeContent:你应该准备好了，这个数组可以及时改变。我拿了这个数组并进行枚举，检索了必要的数据。并且在枚举期间它被改变了（我认为，这是一个NSMutableArray返回的机智类型转换NSArray- 所以这种行为成为可能）。您永远不会在“默认”行为中看到这一点（当您objectForIndexPath:为每个呈现的单元格获取对象时 - 如在 Apple 示例中），但在我的应用程序中，除了包含数据对象外，我还有其他单元格。所以我需要生成自己的存储，而不是直接使用控制器获取的结果。这样我会建议完全避免使用NSFetchedResultsController。我已经用简单的NSManagedObjectDidSaveNotification观察者替换了它，并且每次都加载数据。

于 2012-11-15T12:01:54.977 回答