保存NSManagedObjectContext而不点击主线程

Question

我正在做的事情:

• 使用Web API执行后台同步而不冻结UI.我正在使用MagicalRecord,但它并不是特定的.
• 确保我正确使用上下文等

我的问题是什么:我的理解是否正确？最后还有几个问题.

因此,MagicalRecord提供的上下文是:

• PrivateQueueConcurrencyType的MR_rootSavingContext,用于将数据持久化到商店,这是一个缓慢的过程
• MainQueueConcurrencyType的MR_defaultContext
• 对于背景,您可能希望使用MR_context()生成的上下文,MR_context()是MR_defaultContext的子项,并且是PrivateQueueConcurrencyType

现在,为了以异步方式保存,我们有两个选择:

• MR_saveToPersistentStoreWithCompletion()将一直保存到MR_rootSavingContext并写入磁盘
• MR_saveOnlySelfWithCompletion()将仅保存到父上下文(即MR_defaultContext,用于使用MR_context创建的上下文)

从那里开始,我认为我可以在不冻结UI的情况下执行以下操作(让我们称之为尝试#1):

let context = NSManagedObjectContext.MR_context()
for i in 1...1_000 {
    let user = User.MR_createInContext(context) as User
    context.MR_saveOnlySelfWithCompletion(nil)
}
// I would normally call MR_saveOnlySelfWithCompletion here, but calling it inside the loop makes any UI block easier to spot

但是,我的假设是错误的.我查看了 MR_saveOnlySelfWithCompletion并发现它依赖于它

[self performBlock:saveBlock];

其根据苹果文档

异步执行接收器队列上的给定块.

所以我有点困惑,因为我希望它不会因此而阻止UI.

然后我尝试了(让我们称之为尝试#2)

let context = NSManagedObjectContext.MR_context()
for i in 1...1_000 {
    let user = User.MR_createInContext(context) as User
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0)) { () -> Void in
        context.MR_saveOnlySelfWithCompletion(nil)
    }
}

这样做了,但感觉不对.

然后我在iOS 5.0的发行说明中找到了一些东西

将消息发送到使用队列关联创建的上下文时,如果您的代码尚未在该队列上执行(对于主队列类型)或在performBlock ...调用范围内,则必须使用performBlock:或performBlockAndWait:方法. (对于私有队列类型).在传递给这些方法的块中,您可以自由使用NSManagedObjectContext的方法.

所以,我假设:

• 尝试#1会冻结UI,因为我实际上是从主队列调用它而不是在performBlock的范围内
• 尝试#2工作,但我正在创建另一个线程,而上下文已经有自己的后台线程

所以我当然应该使用saveWithBlock:

MagicalRecord.saveWithBlock { (localContext) -> Void in
    for i in 1...1_000 {
        User.MR_createInContext(context)
    }
}

这将对MR_rootSavingContext的直接子节点执行操作,该子节点为PrivateQueueConcurrencyType.由于rootContextChanged,MR_defaultContext可以使用MR_rootSavingContext的任何更改.

所以似乎:

• 在显示数据时,MR_defaultContext是完美的上下文
• 编辑最好在MR_context(MR_defaultContext的子代)中完成
• 诸如服务器同步之类的长时间运行的任务最好使用saveWithBlock来完成

它仍然没有得到的是如何使用MR_save [...] WithCompletion().我会在MR_context上使用它,但因为它在我的测试用例中阻止了主线程,所以我不知道它何时变得相关(或者我错过了什么......).

谢谢你的时间 :)

Answer 1

好吧,我很少使用魔法记录但是因为你说你的问题更普遍,我会尝试回答.

一些理论:在创建上下文时,您会传递一个指示符,指示您是希望将其绑定在主线程还是后台线程上

let context = NSManagedObjectContext(concurrencyType: NSManagedObjectContextConcurrencyType.PrivateQueueConcurrencyType)

"绑定"是指内部上下文引用一个线程.在上面的示例中,新的线程由上下文创建并拥有.此线程不会自动使用,但必须显式调用:

context.performBlock({ () -> Void in
   context.save(nil)
   return
});

因此,使用'dispatch_async'的代码是错误的,因为上下文绑定的线程只能从上下文本身引用(它是一个私有线程).

你必须从上面推断的是,如果上下文绑定到主线程,从主线程调用performBlock将不会做任何不同的调用上下文方法.

最后评论你的要点:

• 在显示数据时,MR_defaultContext是完美的上下文:必须从创建的上下文访问NSManagedObject,因此它实际上是您可以从中提供UI 的唯一上下文.

• 编辑最好在MR_context(MR_defaultContext的子代)中完成:编辑并不昂贵,您应该遵循上面的规则.如果要调用从主线程编辑NSManagedObject属性的函数(比如按下按钮),则应更新主上下文.另一方面,保存是昂贵的,这就是为什么您的主上下文不应该直接链接到持久性存储,而只是将其编辑推送到具有后台并发拥有持久存储的根上下文.

• 长时间运行的任务(例如服务器同步)最好使用saveWithBlock来完成.

现在,在尝试1

for i in 1...1_000 {
    let user = User.MR_createInContext(context) as User
}
context.MR_saveOnlySelfWithCompletion(nil)

无需为每个对象创建进行保存.即使UI没有被阻止,也是浪费.

关于MR_context.在魔法记录的文档中,我看不到'MR_context'所以我想知道它是否是访问主要上下文的快速方法.如果是这样,它将阻止.