iphone - 为什么我更愿意为每个新线程或 NSOperation 创建一个 NSManagedObjectContext 而不是在主线程上调用核心数据？

Question

一些开发人员已经告诉我，我可以为每个新线程创建一个新的 NSManagedObjectContext 实例，以使 Core Data 线程安全。然后我只需要处理之后的合并。

对我来说，这听起来像是很多额外的代码和开销。

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

我不会为每个新线程或每个 NSOperation 创建一个新的 MOC，而是在主线程上执行 MOC 更改，就像我们从 UIKit 中了解到的那样。我会调用 -performSelectorOnMainThread:...waitUntilDone:YES 并摆脱所有核心数据并发问题。

优点:- 不必为每个线程/NSOperation 创建一个新的 MOC。- 不必将 MOC 合并在一起。- 确保没有并发问题，因为核心数据保留在安全的主线程上。

缺点:- 像 -performSelectorOnMainThread:...waitUntilDone:YES 这样的调用看起来很难看，难以阅读。- 线程/NSOperation 被阻塞。但实际上，系统无论如何都不能同时做多件事。就我而言，核心数据部分不是性能瓶颈。这是在后台线程或 NSOperation 中进行的大量计算。

你怎么看？这值得进一步探索吗？为什么您仍然更愿意为每个新线程/NSOperation 创建一个 MOC，然后处理合并？与在主线程上执行相比，这样做有什么优势？

Answer 1

在后台线程/操作上执行密集操作的主要原因是 UI 在前台/主线程上运行。如果你有一个密集的核心数据操作在主线程上运行，UI 将没有响应并且可能让用户认为应用程序已经挂起或崩溃。由于各地的大多数应用程序在高强度工作时至少会显示一些 Action ，因此用户已经习惯于预期无响应或静态的 UI 表示崩溃或挂起。

移动用户对等待时间也更加敏感。如果您坐在办公 table 前喝着咖啡，那么 45 秒的停顿似乎并不长。如果你穿过机场，它确实如此。

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

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

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