Question

自从我决定通过类似的

获取背景中的所有数据后，我就遇到了这个问题

 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的来源，似乎它会自动为当前线程创建新的上下文

我的想法不多了，请帮忙

事先提前

Answer 1

解决此问题的一个好主意是省去具有不可预测和无法追踪的行为的第三方框架。您可以通过默认为标准托管对象API来规避这一点。

看来MR对表视图的效果不佳。数据太多，核心数据会使对象出错。相反，实现普通的NSFetchedResultsController并享受其可用的内存优化，包括根据需要自动出错和管理对象的故障。

Answer 2

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

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

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

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

所以你可以这样做......

dispatch_async(queue, ^{

    [self doSomeHeavyProcessingForSomeEntityThenSaveThreadContext];

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

    });
});

coredata + MagicRecords，如何在后台找到所有

2 个答案: