0

我一直在使用 Core Data 开发一个 Cocoa 应用程序。最初一切似乎都很好，但是当我向应用程序添加数据时，我发现初始数据窗口需要很长时间才能加载。为了解决这个问题，我移到了另一个没有数据的启动窗口，所以启动很迅速。但是，无论我做什么，我的第一次获取和我第一次尝试加载数据窗口（带有表格视图）总是很慢。（也就是说，如果我缓慢地获取然后请求数据窗口，那么第一次两者都会很慢。）之后，性能是可以接受的。

我跟踪了我的应用程序，发现虽然我可以快速单步执行程序，但无论如何，检索持久存储协调器的步骤非常慢……旋转的沙滩球可能需要 15 到 20 秒。

我在其他地方读过我可能想要对数据进行非规范化。我认为这还不够。早期版本在实体之间的“互连”要少得多，而且它在启动时仍然是一个蛞蝓。现在我正在查看可能拥有多达 18,000 个托管对象的实体。某些关系对于使数据正常工作至关重要。

我还阅读了有关在后台使用单独的托管对象上下文的选项。这样做的问题是，即使是这个背景上下文也需要很长时间才能使用。如果用户尝试运行搜索，他或她仍将永远等待该上下文加载。当用户决定在搜索字段中输入什么内容时，我可能会为自己争取几秒钟，但我不能拖延 25 秒。

我注意到，一旦将数据导入到持久存储中，即使在与其他表无关（并且只有 1000 个对象）上搜索仍然需要很长时间才能加载。原因似乎是协调器检索本身很慢，而不是实际的获取或上下文。

谁能指出我如何解决这个问题的正确方向？谢谢！

4

2 回答 2

0

您可能会认为 PSC 是罪魁祸首。CoreData 在幕后发生的事情比显而易见的要多——PSC 非常灵活，必须得到指导。
对于您指定的数据大小（18K），一种现实的方法是专注于模块化获取请求模板的逻辑和特定大小情况的验证（想想小型、中型、大型 XtraLarge 等）。

对数据进行非规范化的建议并未考虑使数据进入完全非规范化状态的开销，而且非规范化的（有时）意想不到的副作用是稀疏性（除非您当然有非常具体的模型）。

由于您通常事先不知道将访问和修改哪些数据，因此在您的中心任务和任何子任务之间建立一对多的关系。这将释放对数据访问的一些限制。

您始终可以让最终用户选择他们希望如何处理更大的数据集。

于 2017-08-07T07:20:33.983 回答
0

创建数据模型之前：

如果您要存储大型对象，例如照片、音频或视频，则需要非常小心您的模型设计。

要记住的关键点是，当您将托管对象带入上下文时，您会将其所有数据带入内存。

如果大照片位于从驱动表视图的同一实体切割的托管对象中，则性能将受到影响。即使您使用的是获取结果控制器，您仍然可以同时加载十几个高分辨率图像，这不会是即时的。

为了解决这个问题，应该将包含大对象的属性拆分为相关实体。这样，大对象可以保留在持久存储中，并且可以由故障表示，直到真正需要它们为止。

如果您需要在表格视图中显示照片，则应使用自动生成的缩略图。

阅读整篇文章

于 2016-11-16T21:18:06.610 回答