半永久性图像和视频持久性的缓存或核心数据？

Question

（注意如果这是很多文本，底部有一个TLDR）

我正致力于从服务器中提取和显示图像和视频。基本上可以想到不同的文件夹，背后有可以查看的图片和视频。

每个文件夹都可以相当一致地更新新图片和视频，因此我希望能够一次存储尽可能多的图片和视频，以便通过预加载和节省一些来最小化加载/请求数据库时间。

让我先说这一切，说我在这一行之后写的任何事情都完全错了。这就是我要问的原因。我不是100％清楚每种方法的能力

我将尽力在这里尽可能有条理：

REQS /用法：

• 保存大文件（图像和视频数据）以便快速访问（从服务器填充）
• 保存数据的快速轮换;不断更新
• 文件肯定是短暂的，我不想显示过期的信息，但我不想在每次需要时都重新加载类似的东西。
• 需要能够完全存储多个文件夹的数据，比如说中高端的每个文件夹的文件大小为8-12MB（如果只有一个文件可以立即访问并且仍然需要从数据库加载，则不是很有用在查看时）
• 高效的网络使用（避免每次完全重新填充表的冗余调用）
• 坚持应用背景/无限期存储新数据，直到足够的互联网上传
• 文件夹与该文件夹中的文件之间存在显着的一对多关系...我需要能够轻松访问文件夹中的所有文件
• （更容易编码/维护......没必要，但会很好）

我对核心数据的理性：

优点：

• 支持默认情况下我想做的大部分工作
• 以易于查询的方式轻松保存不是大型媒体文件的模型对象的所有其他方面（例如文件夹名称等）
• 许多很棒的工具，例如Magical Record和RestKit，可以与服务器互动/轻松实现
• 通过保存到文件系统，可以一次存储更多数据
• 易于坚持

CONS：

• 这不是典型的核心数据设置，因为我并不特别关注永久存储，我只想尽可能多的文件夹立即可用;根据需要清除内存。
• SPEED ：小修改仍需要重新保存整个上下文。这意味着加载，同步和刷新比缓存更慢（参见this的实际速度指标......它绝对不是非常重要的）。大量持续写入磁盘似乎在性能方面存在问题。

缓存的理性：

优点：

• QUICKER ：更符合半永久性方面（保存数据的快速轮换等）
• 更简单的内存管理（不必持续和手动清除已保存到我不再需要/想要的Core Data的旧数据）
• 更少的样板/代码数量

CONS：

• 默认情况下不会保留，在背景上清除
• 使用的内存较少;真正关心的是必须不断删除数据并将数据重新加载到内存中的性能问题。
• 没有查询支持和（我认为）没有办法选择性地清除对象的某些属性，同时保留其他属性（我认为你必须解码整个对象，手动清除一些信息，并重新编码？）
• 默认情况下在应用程序背景时清除（即控制何时转储信息以释放可能需要的内存）

的 TLDR

我是否应该使用缓存或核心数据来保存将要经常从服务器更新的大文件？要考虑的因素是效率（最小化服务器请求;存储数据直到被新数据覆盖），速度（写入/加载），数量数据存储/可用内存（内存涉及使用缓存移动大量数据，是否会影响性能..在我开始看到不良性能之前，我可以在内存中有多少文件？），可定制性（在我看来，我需要两者之间的东西，所以更容易适应我的用途）

并且重要的是....还有其他我完全错过的东西吗？像某种文件系统管理器或独特的缓存ma-jiggy？）

Answer 1

如果你所做的只是缓存文件，那么对CoreData的需求就不多了，因为文件系统本身就是一个非常快速的文件密钥/值存储。

如果您想为文件提供大量关联数据，可以在文件上设置扩展属性（尽管您无法在搜索中有效地使用这些属性）。

如果您仍想使用CoreData，您当然可以这样做。你有几个选择。最常见的两个选项是：

1. 将文件的URL存储为CoreData实体中的属性，并自行管理将文件直接存储到磁盘。

2. 将数据存储为CoreData属性，然后选择＆＃34;允许外部存储＆＃34;属性的选项。这将导致CoreData进行自己的计算，如果数据足够小＆＃34;它将存储在数据库中。如果它太大＆＃34;然后它将被存储为外部文件。

Apple没有记录截止值，但实验表明它是1MB。

使用选项2会更容易，因为Core Data会为您管理所有内容。这是一个非常可行的选项，我在一个非常大的应用程序中使用它，它存储了一堆非常大的文件（没有一个足够小，可以选择存放在数据库中）。

迁移速度存在问题，因为Core Data希望迁移整个商店。因此，您需要在决定之前考虑这一点。

你可能想要构建一个测试应用程序，添加一堆东西，并在决定之前经历各种场景，但这些是你可以使用的两个最常见的选项。