Iphone 为什么我更喜欢为每个新线程或NSOperation创建NSManagedObjectContext，而不是在主线程上调用核心数据？

一些开发人员已经告诉我，我可以为每个新线程创建一个新的NSManagedObjectContext实例，以使核心数据线程安全。然后，我就必须处理合并后的问题

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

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

我不会为每个新线程或每个NSO操作创建新的MOC，而是在主线程上执行MOC更改，就像我们从UIKit中知道的那样。我只需调用

-performselectornmainthread:…waitUntilDone:YES

，就可以解决所有核心数据并发问题

优点： -不必为每个线程/NSO操作创建新的MOC。 -不必将主运行中心合并在一起。 -确保没有并发性问题，因为核心数据留在主线程上是安全的

缺点： -像

-performselectornmainthread:…waitUntilDone:YES

这样的调用看起来很难看，很难阅读。 -线程/NSO操作被阻止。但在现实中，该系统无论如何都不能同时完成多项任务。在我的例子中，核心数据部分不是性能瓶颈。在后台线程或操作中进行的是大量的计算

---

你觉得怎么样？这值得进一步探索吗？为什么您仍然希望为每个新线程/NSO操作创建一个MOC，然后处理合并？与在主线程上执行此操作相比，它有什么优势？

在后台线程/操作上执行密集操作的主要原因是UI在前/主线程上运行。如果在主线程上运行密集的核心数据操作，UI将无响应，可能会让用户认为应用程序已挂断或崩溃。由于各地的大多数应用程序在密集工作时至少会显示一些运动，用户已经接受过训练，认为无响应或静态UI表示崩溃或挂起

移动用户对等待时间也更加敏感。如果你坐在办公桌前喝一杯咖啡，45秒的停顿似乎不会太长。如果你要穿过一个机场，它会

从主线程中删除密集操作可以使UI继续工作。在某些情况下，这意味着用户可以继续工作，在另一些情况下，这意味着您可以动态更新UI，以告知应用程序正在进行密集操作，这就是用户必须等待的原因

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

话虽如此，在您测试应用程序并发现核心数据无法在主线程上处理之前，我不会使用后台线程/操作。在绝大多数情况下，它可以。服务器下载速度慢可能是需要后台操作的主要原因。如果你没有这些，你的应用程序就不需要任何严肃的背景了

“磁盘访问很昂贵”-我们被告知

如果获取或保存大量数据，则在NSThread/NSO操作上使用单独的MOC有一个优点。再加上视图转换，这可以很好地提高应用程序中“速度”的感知，因为主线程只剩下执行UI转换

我认为你可以通过测量访问商店的实际时间与用户界面响应时间（IIRC：尝试CoreData和CoreAnimation工具）来找到答案，并比较两种情况：每个线程使用不同的MOC与调用

-performSelectorOnMainThread:…waitUntilDone:YES

---

也许我不清楚这一点：在我的情况下，核心数据不是瓶颈。我执行超重型计算，并将结果保存在核心数据中。这就像计算需要99%的时间，核心数据只需要1%。但无论如何，你是完全正确的！好的，如果我在后台线程上保存，并且应用程序被终止，那么核心数据数据库文件已经损坏，对吗？这听起来不是一个解决办法。是的，但有办法避免。一种方法是编写代码来监视是否正在进行任何后台保存。在应用程序退出之前，让主线程等待这些操作完成。然而，如果这需要太长时间，你无论如何都会被烤熟。另一种避免后台保存问题的方法是更频繁地保存少量数据，以最大限度地降低损坏数据库的可能性。总之，这是一件棘手的事情。。。