9

问题：

我已经使用我自己的缓存系统一段时间了NSFileManager。通常我收到的数据是 JSON，我只是将字典直接保存到缓存中（在文档文件夹中）。当我需要它时，我会去拿它。有时当我觉得更好时，我还会NSDictionary在根文件夹上实现一个给定资源路径的键/值。例如：

关于日内瓦 17/02/2013 天气的资源，所以我会有一个名为 GE_17_02_2013 的键和NSDictionary带有信息的路径的值。

通常我不需要做任何复杂的查询。但是，不知何故，根据我一直在阅读的内容，当您拥有大量数据时，您应该坚持使用 Core Data。就我而言，我通常有很多数据，但我从来没有真正感觉到应用程序出现故障，或者在性能方面受到影响。所以我的问题是：

  1. 在这种情况下，有时（天气只是一个例子）我需要删除所有数据（例如 Twitter 提要）并用全新的数据流替换它，Core Data 值得吗？我认为删除所有数据并插入（填充）它比仅存储NSDictionary和替换旧数据要重。

  2. 有时它会包含图像、文本文件等，并且 NSFileManager做得很完美，那么 Core Data 在这种情况下可以带来什么优势呢？

PS：我刚刚看到这篇文章，提出了这种问题，并且数字证明了哪个实际上更快。不过，我也想要一个经验性的答案。

4

2 回答 2

4

Core Data 值得在您描述的每个场景中使用。事实上，如果一个应用程序存储的不仅仅是首选项，你可能应该使用 Core Data。以下是一些原因，其中，您会找到自己问题的答案：

  • 绝对比文件系统快，即使您清除所有内容并按照您的描述重新编写它（因此您不会从缓存中受益匪浅）。这基本上是因为您可以合并您的操作并仅在需要时访问商店。所以如果你读、写、读，你只能保存一次，其余的都在内存中完成，这不用说，非常快。
  • 一切都是版本化的，您可以轻松地从一个版本迁移到另一个版本（同时保留用户在设备上的内容）
  • 80% 的模型操作都是免费的。就像，当某些事情发生变化时，您可以覆盖willSave托管对象方法并通知您的控制器。
  • usingcascade使得删除甚至非常复杂的对象结构变得微不足道
  • 虽然将图像保留在数据库中是一个坏主意，但您仍然可以将它们保留在文件系统中，并在删除代表它们的托管对象时让核心数据自动删除它们
  • 是灵活的，实际上非常灵活，您可以通过编写自定义数据存储将您的项目从使用本地文件系统迁移到使用服务器而只需很少修改。
  • 核心数据设计器基本上为您创建模型对象。您不需要创建自己的模型类（如果使用文件系统，则必须这样做）
于 2013-04-14T20:01:11.073 回答
1

在这种情况下...... Core Data 值得吗？

是的，在某种程度上，您需要比尝试制定自己的文件系统架构更集中管理的东西。Core Data 及其低级表亲 SQL 仍然是我们目前拥有的持久性的最佳选择。此外，使用NSKeyed(Un)Archiver更大的数据集一次又一次地对字典进行序列化/反序列化的性能影响变得越来越明显。

我认为删除所有数据并插入（填充）它比仅存储 NSDictionary 并替换旧的要重。

绝对没错。但是，您不必像那样考虑缓存周转率。如果您将 Core Data 想象为一个静态模型，您可以使用缓存层将数据传输进出存储。需要有关天气的资源吗？检查缓存层。如果它不在那里，让缓存运行一个获取请求。需要翻转整个缓存？让缓存自己清空，然后运行一个请求，用某种标志标记每个实体，以表明它们是无效的。当您看到所有新数据都已安全地保存在缓存中时，您担心的代价高昂的删除可以通过后台进程完成。

有时它会包含图像、文本文件等，而 NSFileManager 可以完美地做到这一点，那么 Core Data 在这种情况下可以带来什么优势呢？

不幸的是，并不多。对于数据块（Core Data 在这些情况下本质上就是这样做的），存储和从 Core Data 读取数据很快就会变得昂贵。如果它们没有被压缩，它们也会在磁盘上占用明显更大的空间（这会进一步降低性能）。如果您需要更快的替代方案，请使用更适合任务的存储，例如Tokyo Cabinet或LevelDB，并使用 Core Data 存储中的实体作为一种替代品，例如，将资源的密钥包含在一个那些关系数据库。

于 2013-04-14T20:44:49.817 回答