如何使用Swift在iOS开发中处理“缓存”问题

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.

 ]

关键在于我只想在应用程序启动时或过了一定的时间后，或者当应用程序用户将其位置明显移动以至于会改变附近的位置时，才发送/重新发送此查询。为了保持服务器负载低，我计划在应用程序内部对返回的位置进行搜索查询，而不是针对每个单独的请求查询服务器，这将非常低效和昂贵。

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

我相信还有其他解决方案可能更适合我的目的。毕竟，我对iOS中的这个主题相当新，因此我非常感谢一些指导。

提前致谢。

- arauter

---

已经有几个相关的Pod，例如https://github.com/Haneke/HanekeSwift、https://github.com/aschuch/AwesomeCache和https://github.com/hyperoslo/Cache。 - Josh Homann

Answer 1

你考虑使用CoreData和NSCache是正确的选择。

但需要权衡一些方面。为了减少网络活动，您将利用设备内存和/或文件系统。在认真考虑这些资源的使用情况后，以下所有选项都是可行的，可以通过仪器测量每种方法的影响。

根据您的要求，以下是我如何权衡它们。

NSCache

优点

• 简单的API，实施成本低
• 易于理解

缺点

• 如果您需要的数据不再缓存，则必须发出另一个网络请求。不过，您可以实现NSCacheDelegate，并在“对象即将从缓存中逐出或删除”时做出响应。请参见NSCacheDelegate

Core Data

优点

• 可以用作内存存储（不仅仅是持久化数据到磁盘）
• 可以扩展以适应更复杂的数据建模、查询和存储需求
• 具有Xcode工具支持

缺点

• 最初需要比其他选项更多的实现工作
• 如Duncan C所述，有一个学习曲线
• 添加另一个抽象层可能需要比NSCache或plist更多的思考

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

优点

• 实施成本低
• 易于理解

缺点

• 引入了文件系统I/O操作。从性能角度来看，如果有其他选择，则这是不可取的。
• 难以扩展（如果您的需求发生变化）

- Ryan H.

---

不错的全面回答。 - Duncan C

这意味着当应用程序终止时，NSCache会丢失数据...另一方面，Plist和CoreData会保留数据。 - Wahab Khan Jadon

只是为了帮助未来的读者，需要注意的一点是，如果直接实现NSCache，当应用程序简单地进入后台时，缓存将被清空。仍在努力寻找一个合适的方法来解决这个问题。 - undefined

Answer 2

您展示的是一个字典数组。

如果您要缓存的数据不会经常更改，且整个数据集更改时均会发生更改，则实际上不需要 SQL 数据库。

您可以使用 NSArray 方法 func write（toFile：atomically :) 将数组保存到 plist 文件中。

如果将数组写入文档目录，则它不会消失。如果将其写入缓存目录，则可能在稍后被清除。

它的优点是非常简单。它的缺点是不适合更新某些内容而不是其他内容。您保存整个内容，然后加载整个内容。对于 10,000 条纯文本记录，将整个内容加载到内存中并不是什么大问题。如果每个记录只有 250 字节，那就不到 2.5 MB，相当合理。

Core Data 非常强大，但也非常复杂，并且具有陡峭的学习曲线。需要一段时间才能理解如何使用它。

- Duncan C