8

我现在被一个令人讨厌的核心数据问题困住了大约两个星期。我阅读了很多博文、文章和 SO 问题/答案，但我仍然无法解决我的问题。

我进行了很多测试，并且能够将较大的问题减少到较小的问题。这将是一个很大的解释，所以请继续关注我！

问题 - 数据模型

我必须得到以下数据模型：

对象 A 与对象 B 具有一对多关系，而对象 B 与对象 C 具有另一个一对多关系。由于 Core Data 的建议，我必须创建反向关系，因此 B 的每个实例都指向其父 A 并且对于C 指向它的父 B。

A <->> B <->> C

问题 - MOC 设置

为了保持响应顺畅，我创建了一个三级 managedObjectContext 结构。

  1. Parent MOC - 在它自己的私有线程上运行，使用NSPrivateQueueConcurrencyType紧persistentStoreCoordinator
  2. MainQueue MOC - 使用NSMainQueueConcurrencyType并具有父 MOC 1在 mainThread 上运行
  3. 对于每个解析操作，我创建了第三个 MOC，它也有它的私有队列和父 mainQueue MOC

我的主数据控制器作为观察者添加到 MOC 2 的NSManagedObjectContextDidSave通知中，因此每次 MOC 2performBlock:在 MOC1 上保存时都会触发执行保存操作（因为异步performBlock:）。

问题 - 解析

为了将大型 JSON 文件解析为我的核心数据结构，我编写了一个循环解析器。这个解析器首先创建一个新的 MOC (3)。然后它获取对象 A 的数据并解析其属性。然后解析器读取 B 的 JSON 关系并创建相应的填充数据的对象。这些新对象通过调用 A 添加到addBObject:A。因为解析器是循环的，解析 B 意味着解析 C，并且这里也创建了新对象并将其附加到 B。这一切都发生在performBlock:MOC 3 中。

  • 解析（创建“A”对象并开始解析 B）
    • 解析 A（创建“B”对象，将它们附加到 A 并开始解析 C）
      • 解析 B（创建“C”对象，将它们附加到 B）
        • 解析 C（仅将数据存储在 C 对象中）

在每次解析操作之后，我保存 MOC 3 并在 mainThread 上调度主 MOC (2) 的保存操作。由于NSManagedObjectContextDidSave通知 MOC 1 将异步自动保存。

        if (parsed){
            NSError *error = nil;
            if (![managedObjectContext save:&error])
                NSLog(@"Error while saving parsed data: %@", error);
        }else{
            // something went wrong, discard changes
            [managedObjectContext reset];
        }

        dispatch_async(dispatch_get_main_queue(), ^{                
            // save mainQueueManagedObjectContext
            [[HWOverallDataController sharedOverallDataController] saveMainThreadManagedObjectContext];
        });

为了释放我的内存占用，并且因为我现在不需要解析数据，我正在执行：

[a.managedObjectContext refreshObject:a mergeChanges:NO];

对于刚刚解析的每个 AI。

因为我需要解析大约 10 个 A，它们都有大约 10 个 B，它们大约有 10 个 C，所以会生成很多 managedObject。

问题 - 仪器

一切正常。唯一的事情是：当我打开分配工具时，我看到未发布的 A、B 和 C。我没有从他们的 retainCounts 或任何其他信息中获得任何有用的信息。而且由于我的实际问题涉及更复杂的数据模型，因此活动对象成为严重的内存问题。有人能弄清楚我做错了什么吗？使用正确的 managedObject 在其他 managedObjectContexts 上调用 refreshObjects 也不起作用。似乎只有一个困难reset的工作，但后来我失去了指向 UI 使用的活对象的指针。

我尝试过的其他解决方案

  • 我尝试创建单向关系而不是双向关系。这会产生许多其他问题，导致 Core Data 不一致和奇怪的行为（例如悬空对象和 Core Data 生成 1-n 关系而不是 nn 关系（因为反向关系未知）。

  • 当我检索NSManagedObjectContextDidSave任何对象的通知时，我尝试刷新每个更改或插入的对象

这两种“解决方案”（顺便说一句都行不通）似乎也有点老套。这不应该是要走的路。但是，应该有一种方法可以在不增加内存占用并保持 UI 流畅的情况下使其工作？

- 代码演示

http://cl.ly/133p073h2I0j

- 进一步的调查

在 mainContext 中（在 mainSave 之后）刷新每个曾经使用过的对象（这是一项繁琐的工作）后，对象的大小会减少到 48 个字节。这表明对象全部出错，但内存中仍有一个指针。当我们有大约 40.000 个对象都出现故障时，内存中仍然有 1.920 MB 的内存在persistentManagedObjectContext 重置之前永远不会释放。这是我们不想做的事情，因为我们失去了对任何 managedObject 的每个引用。

4

3 回答 3

5

罗宾，

我有一个类似的问题，我解决的方式与你不同。在您的情况下，您有第三个，IMO，冗余 MOC，父 MOC。在我的例子中，我让两个 MOC 以老式的方式通过 DidSave 通知通过持久存储协调器进行通信。新的面向块的 API 使这更加简单和健壮。这让我可以重置子 MOC。虽然您从第三个 MOC 获得了性能优势，但与我利用的 SQLite 行缓存相比，它的优势并不大。您的路径会消耗更多内存。最后，通过跟踪 DidSave 通知，我可以在创建项目时对其进行修剪。

顺便说一句，您也可能会遭受您MALLOC_TINY和MALLOC_SMALLVM 区域大小的大幅增加。我的尾随修剪算法让分配器更快地重用空间，从而延缓这些问题区域的增长。根据我的经验，这些区域由于它们的大量驻留内存占用，是我的应用程序 Retweever 被杀死的主要原因。我怀疑您的应用程序也遭受了同样的命运。

当内存警告出现时，我调用以下代码段：

[self.backgroundMOC performBlock: ^{ [self.backgroundMOC reset]; }];

[self.moc save];

[self.moc.registeredObjects trimObjects];

-[NSArray(DDGArray) trimObjects]只是通过一个数组并刷新对象，从而修剪它们。

总之，Core Data 似乎为许多 MOC 中出现的项目实现了写入时复制算法。因此，您以意想不到的方式保留了一些东西。我专注于在导入后断开这些连接以最小化我的内存占用。由于 SQLite 行缓存，我的系统似乎表现得可以接受。

安德鲁

于 2012-10-31T13:10:44.690 回答
1

对于NSManagedObjectContext您为特定目的而保留的每一个，您都将积累NSManagedObject

ANSManagedObjectContext只是一张便条纸，您可以随意实例化并保存，如果您希望保留更改，NSPersistentStore然后再丢弃。

对于解析操作（第 3 层），尝试为 op 创建一个 MOC，进行解析，保存 MOC，然后将其丢弃。

感觉就像你至少有一层 MOC 被太多的强引用所持有。

基本上问每个 MOC 的问题。“为什么要保持这个对象及其相关的孩子活着”。

于 2012-10-30T08:41:11.513 回答
0

我有一个非常相似的导入助手。

看看下面的代码，看看它是否对你有帮助

__block NSUInteger i = 0;
NSArray *jsonArray = ...
for (NSDictionary *dataStucture in jsonArray)
{
    [managedObjectContext performBlock:^{
        @autoreleasepool {
            i++;
            A *a = (A*)[self newManagedObjectOfType:@"A" inManagedObjectContext:managedObjectContext];
            [self parseData:[dataStucture objectForKey:@"a"]
                 intoObject:a
     inManagedObjectContext:managedObjectContext];

            [managedObjectContext refreshObject:a
                                   mergeChanges:YES];
            if (i > 20) // Arbitrary number here
            {
                NSError *error = nil;
                [managedObjectContext save:&error];
                [managedObjectContext reset];
            }

            [managedObjectContext refreshObject:a
                                   mergeChanges:YES];

        }
        dispatch_async(dispatch_get_main_queue(), ^{
            [self saveMainThreadManagedObjectContext];

            NSLog(@"DONE");
            // parsing is done, now you see that there are still
            // A's, B's and C's left in memory.
            // Every managedObjectContext is saved and no references are kept
            // to any A, B and C so they should be released. This is not true,
            // so a managedObjectContext is keeping a strong reference to these
            // objects.
        });
    }];
}
于 2012-10-30T10:31:27.150 回答