0

自从我决定通过类似这样的方式在后台获取所有数据后，我就遇到了这个问题

 dispatch_async(queue, ^{

    /* fetch my data here */
    self.data = [SomeEntity MR_findAll];

    dispatch_sync(dispatch_get_main_queue(), ^{
        [self.tableview reloadData];

    });
});

第一次启动时它工作正常，如果你进入另一个视图控制器并等待几分钟然后回来，所有找到的实体都变成了故障状态并且没有更多的属性可以访问

我首先将 GCD 用于后台队列，然后我尝试创建自己的队列

queue = dispatch_queue_create("com.myname.queue", DISPATCH_QUEUE_CONCURRENT);

它仍然有问题

我查看了 MagicRecords 的来源，它似乎自动为当前线程创建新上下文

我的想法不多了，请帮忙

提前谢谢

4

2 回答 2

0

解决这个问题的一个好主意是放弃具有不可预测和不可追踪行为的第 3 方框架。您可以通过默认使用标准托管对象 API 来规避这种情况。

看起来 MR 在表格视图中表现不佳。数据太多，核心数据使对象出错。相反，实现一个普通的香草NSFetchedResultsController并享受它的免费内存优化，包括根据需要对托管对象进行自动故障和无故障。

于 2014-01-14T07:48:51.743 回答
0

你不能。MR 正在按设计工作。

tableview UI 和所有 UIKit UI 元素一样在主线程中工作。

您不能使用 Core-Data 交叉线程，这意味着 NSManagedObjects 及其关联的上下文属于创建它们的线程。任何使用 Core Data 跨线程的尝试最终都会崩溃。

因此，您可以在 Core Data 中进行后台处理并合并到您的主线程上下文中，但是您需要在主线程中获取您在 UI 中呈现的数据。

所以你可以这样做……</p> 

dispatch_async(queue, ^{

    [self doSomeHeavyProcessingForSomeEntityThenSaveThreadContext];

    dispatch_sync(dispatch_get_main_queue(), ^{
        self.data = [SomeEntity MR_findAll];
        [self.tableview reloadData];

    });
});
于 2014-01-14T08:22:16.827 回答