为什么我更喜欢为每个新线程或NSOperation创建NSManagedObjectContext而不是在主线程上调用Core Data？

Question

一些开发人员已经告诉我,我可以为每个新线程创建一个新的NSManagedObjectContext实例,以使Core Data具有线程安全性.然后我只需要照顾合并.

对我来说,这听起来像很多额外的代码和开销.

这个解决方案有什么不好的原因吗？它来了:

相反,每一个新的线程或每的NSOperation创建一个新的MOC的,我会在主线程中执行MOC-变化,就像我们从UIKit的认识.我只是打电话-performSelectorOnMainThread:...waitUntilDone:YES并摆脱所有Core Data并发问题.

优点: - 不必为每个Thread/NSOperation创建一个新的MOC. - 不必将MOC合并在一起. - 确保没有并发问题,因为Core Data保留在安全的主线程上.

缺点: - -performSelectorOnMainThread:...waitUntilDone:YES看起来像丑陋,难以阅读. - 线程/ NSOperation被阻止.但实际上,系统无论如何都不能同时做多件事.就我而言,核心数据部分不是性能瓶颈.围绕它的繁重计算是在后台线程或NSOperation中进行的.

你怎么看？这值得进一步探索吗？为什么你仍然希望为每个新的Thread/NSOperation创建一个MOC然后处理合并？与在主线程上执行此操作相比,这有什么好处？

Answer 1

在后台线程/操作上执行密集操作的主要原因是UI在前端/主线程上运行.如果您在主线程上运行密集的Core Data操作,则UI将无响应并可能使用户认为应用程序已挂起或崩溃.由于大多数应用程序在工作密集时至少显示一些动作,因此用户已经接受过培训,期望无响应或静态UI指示崩溃或挂起.

移动用户对等待时间也更敏感.如果您在桌边摆放一杯咖啡,45秒的暂停时间似乎不长.如果你正在机场穿行,那就行了.

从主线程中删除密集操作允许UI继续运行.在某些情况下,这意味着用户可以继续工作,在其他情况下,这意味着您可以动态更新UI以通信应用程序正在进行密集操作,这就是用户必须等待的原因.

这会对用户如何看待应用的质量和可用性产生重大影响.

话虽如此,在您测试应用程序并发现Core Data无法处理主线程上的处理之前,我不打算使用后台线程/操作.在广大的情况下,它可以.从服务器下载缓慢可能是后台操作需求的主要驱动因素.如果你没有这些,很有可能你的应用程序不需要任何严肃的背景.