Question

我在面向iOS应用程序实现的缓存机制方面遇到了一些问题。首先，让我们解释一下我的情况。

我想使用 Alamofire 通过我的服务器上的RESTful API请求数千个附近位置记录（10000或更多），其中每个记录由一串字符串组成。 JSON响应格式与此类似：

[
   {
     "id": 1,
     "name": "Name x",
     "lat": 59.5025878,
     "lng": -0.1509515,
     "address": "Address x"
   },
   {
     "id": 2,
     "name": "Name y",
     "lat": 61.5025878,
     "lng": -0.1508515,
     "address": "Address y"
   },

   etc.

 ]

关键是我只想在应用程序启动时或经过一段时间后或者app用户大幅移动他/她的位置时发送/重新发送此查询，这也会改变附近的位置。为了保持较低的服务器负载，我计划对应用程序内部的返回位置进行搜索查询，而不是为每个请求查询服务器，这样做效率非常低且成本高。

因此，我想在手机上缓存我的回复数据，但我不知道应该选择哪种方式。我对 CoreData 和 NSCache 进行了一些背景阅读。 CoreData允许我将位置结果存储在数据库中。这样做的好处是存储的记录在内部保持活跃，因为它毕竟是永久存储解决方案。另一方面，使用CoreData可能是一个完全的过度杀伤，因为它带来了开销，使用 NSCache 将位置记录保存在缓存中可能不会占用太多内存（请记住我只存储字符串）。但话说回来，为什么当用户甚至不经常访问它们时，将位置数据保留在缓存中。此外，有可能释放缓存中的位置条目以节省更多内存。

我相信还有其他解决方案可能更适合我的目的。毕竟，我对iOS中的这个主题很新，所以我真的很感激一些指导。

提前谢谢。

Answer 1

考虑到CoreData和NSCache，你走在正确的轨道上。

会有权衡。在减少网络活动时，您将寻求利用设备内存和/或文件系统。应仔细考虑使用这些资源。以下所有选项都是可行的，用仪器进行一些测量可能是值得的，以了解每种方法的影响。

在纸面上，我可以根据您的要求权衡它们。

NSCache

<强>赞成

简单的API，实施工作量小
易于推理

<强>缺点

如果您需要的数据不再缓存，则必须触发另一个网络请求。也就是说，您可以实现NSCacheDelegate并在“对象即将被逐出或从缓存中删除时”进行响应。请参阅NSCacheDelegate

核心数据

<强>赞成

可以用作内存存储（不仅仅是用于将数据保存到磁盘）
可以扩展以适应更复杂的数据建模，查询和存储要求
拥有Xcode工具支持

<强>缺点

最初，它需要比其他选项更多的努力才能实现
如Duncan C所述，有一个学习曲线
添加另一个抽象，可能需要更多的思考，而不是NSCache或plist

文件系统（plist或其他格式）

<强>赞成

努力实施
易于推理

<强>缺点

介绍文件系统I / O操作。从性能的角度来看，如果还有其他选择，这是不可取的。
不容易扩展（如果您的需求发生变化）

Answer 2

你所展示的是一系列词典。

如果您正在缓存的数据没有那么大的变化，并且当它发生变化时，整个过程发生了变化，那么您实际上并不需要SQL数据库。

您可以使用NSArray方法func write(toFile:atomically:)

将数组保存到plist文件中

如果将数组写入文档目录，那么它就不会消失。如果将其写入caches目录，则可以在以后刷新它。

它具有污垢简单的优点。它的缺点是它不能更新某些内容而不能更新其他内容。你保存整个东西，然后加载整个东西。将整个内容加载到内存中对于10,000个纯文本记录来说并不是什么大问题。如果每个250字节，那就小于2.5 MB - 非常合理。

核心数据非常强大，但也非常复杂，并且具有陡峭的学习曲线。我们需要一段时间来探讨如何使用它。

如何处理＆＃39;缓存＆＃39;在使用Swift

2 个答案:

NSCache

核心数据

文件系统（plist或其他格式）