iOS数据持久化设计探讨（NSCache，PINCache，YYCache，CoreData，FMDB，WCDB，Realm）

一、目标

了解移动端的数据持久化方式和对应的使用场景，提供相关技术选型做技术储备。

二、数据持久化的目的

1. 快速展示，提升体验
   • 已经加载过的数据，用户下次查看时，不需要再次从网络（磁盘）加载，直接展示给用户
2. 节省用户流量（节省服务器资源）
   • 对于较大的资源数据进行缓存，下次展示无需下载消耗流量
   • 同时降低了服务器的访问次数，节约服务器资源。（图片）
3. 离线使用。
   • 用户浏览过的数据无需联网，可以再次查看。
   • 部分功能使用解除对网络的依赖。（百度离线地图、图书阅读器）
   • 无网络时，允许用户进行操作，等到下次联网时同步到服务端。
4. 记录用户操作
   • 草稿：对于用户需要花费较大成本进行的操作，对用户的每个步骤进行缓存，用户中断操作后，下次用户操作时直接继续上次的操作。
   • 已读内容标记缓存，帮助用户识别哪些已读。
   • 搜索记录缓存
     …

三、数据持久化方式分类

在移动端的数据持久化方式总体可以分为以下两类：

1、内存缓存

• 定义

  对于使用频率比较高的数据，从网络或者磁盘加载数据到内存以后，使用后并不马上销毁，下次使用时直接从内存加载。

• 案例

  • iOS系统图片加载——[UIImage imageNamed:@“imageName”]
  • 网络图片加载三方库：SDWebImage

2、磁盘缓存

• 定义

  将从网络加载的、用户操作产生的数据写入到磁盘，用户下次查看、继续操作时，直接从磁盘加载使用。

• 案例

  • 用户输入内容草稿缓存（如：评论、文本编辑）
  • 网络图片加载三方库：SDWebImage
  • 搜索历史缓存

四、缓存策略(常见缓存算法)

在缓存设计中，由于硬件设备的存储空间不是无限的，我们期望存储空间不要占用过多，仅能缓存有限的数据，但是我们希望获得更高的命中率。想达到这一目的。通常需要借助缓存算法来实现。

1、FIFO（First in First out）

实现原理：

FIFO 先进先出的核心思想如果一个数据最先进入缓存中，则应该最早淘汰掉。类似实现一个按照时间先后顺序的队列来管理缓存，将淘汰最早访问的数据缓存。

示意图：

问题：

没有考虑时间最近和访问频率对缓存命中率的影响。对于用户较高概率访问最近访问数据的情况，命中率会比较低。

2、LFU（Least Frequently Used）

实现原理:

LFU 最近最少使用算法是基于“如果一个数据在最近一段时间内使用次数很少，那么在将来一段时间内被使用的可能性也很小”的思路。记录用户对数据的访问次数，将访问次数多的数据降序排列在一个容器中，淘汰访问次数最少的数据。

问题:

LFU仅维护各项的被访问频率信息,对于某缓存项,如果该项在过去有着极高的访问频率而最近访问频率较低,当缓存空间已满时该项很难被从缓存中替换出来,进而导致命中率下降。

3、 LRU (LeastRecentlyUsed)

实现原理：

LRU 是一种应用广泛的缓存算法。该算法维护一个缓存项队列,队列中的缓存项按每项的最后被访问时间排序。当缓存空间已满时,将处于队尾,即删除最后一次被访问时间距现在最久的项,将新的区段放入队列首部。

示意图：

问题：

LRU算法仅维护了缓存块的访问时间信息，没有考虑被访问频率等因素，当存在热点数据时，LRU的效率很好，但偶发性的、周期性的批量操作会导致LRU命中率急剧下降。例如对于VoD（视频点播）系统，用户已经访问过的数据不会重复访问等场景。

4、 LRU-K (LeastRecentlyUsed)

实现原理：

相比LRU，其核心思想是将“最近使用过1次”的判断标准扩展为“最近使用过K次”。具体来说它多维护一个队列，记录所有缓存数据被访问的历史。仅当数据的访问次数达到K次的时候，才将数据放入缓存。当需要淘汰数据时，LRU-K会淘汰第K次访问时间距当前时间最大的数据。

示意图：

问题：

需要额外的空间来存储访问历史，维护两个队列增加了算法的复杂度，提升了CPU等消耗。

5、2Q（Two queues）

实现原理：

2Q算法类似于LRU-2，不同点在于2Q将LRU-2算法中的访问历史队列（注意这不是缓存数据的）改为一个FIFO缓存队列，即：2Q算法有两个缓存队列，一个是FIFO队列，一个是LRU队列。

示意图：

问题：

需要两个队列，但两个队列本身都比较简单，2Q算法和LRU-2算法命中率、内存消耗都比较接近，但对于最后缓存的数据来说，2Q会减少一次从原始存储读取数据或者计算数据的操作。

6、MQ（Multi Queue）

实现原理：

MQ算法根据优先级（访问频率）将数据划分为多个LRU队列，其核心思想是：优先缓存访问次数多的数据。

示意图：

问题：

多个队列需要额外的空间来存储缓存，维护多个队列增加了算法的复杂度，提升了CPU等消耗。

五、iOS端可供选择的数据持久化方案

1. 内存缓存

实现内存缓存的技术手段包括苹果官方提供的NSURLCache，NSCache，还有性能和API上比较有优势的开源缓存库YYCache、PINCache等。

2. 磁盘缓存

• NSUserDefault

  适合小规模数据，弱业务相关数据的缓存。

• keychain

  Keychain是苹果提供的带有可逆加密的存储机制，普遍用在各种存用户名、密码的需求上。另外，Keychain是系统级存储，还可以被iCloud同步，即使App被删除，Keychain数据依然保留，用户下次安装App，可以直接读取，通常会用来存储用户唯一标识串。所以需要加密、同步iCloud的敏感小数据，一般使用Keychain存取。

• 文件存储

  • Plist：一般结构化的数据可以Plist的方式去持久化
  • archive：Archive方式可以存取遵循协议的数据，比较方便的是存取使用的都是对象，不过中间的序列化和反序列化需要花费一定的性能，可以在想要使用对象直接进行磁盘存取时使用。
  • Stream：指文件存储，一般用来存图片、视频文件等数据

• 数据库存储

  数据库适合存取一些关系型的数据；可以在有大量的条件查询排序类需求时使用。

  • Core Data：苹果官方封装的ORM(Object Relational Mapping)
  • FMDB：github最受欢迎的iOS sqlite 封装开源库之一
  • WCDB：微信团队在自己使用的sqlite封装基础上的开源实现，具有ORM(Object Relational Mapping)的特性，支持iOS、Android。
  • Realm：由Y Combinator孵化的创业团队开源出来的一款跨平台（iOS、Android）移动数据库。

3. 应该用哪种缓存方案

根据需求选择：

• 简单数据存储直接写文件、key-value存取即可。
• 需要按照一些条件查找、排序等需求的，可以使用sqlite等关系型存储方式。
• 敏感性高的数据，加密存储。
• 不希望App删除后清除的小容量数据（用户名、密码、token）存keychain。

六、内存、磁盘数据持久化方案对比

1、可选方案详解

1.1、NSCache

苹果提供的一个简单的内存缓存，它有着和 NSDictionary 类似的 API，不同点是它是线程安全的，并且不会 retain key，内部实现了内存警告处理（仅应用在后台时，会移除一部分缓存）。

1.1.1、特性

• 属性
  • 名称
  • delegate：obj从cache移除时，通知代理
  • countLimit：存储数限制
  • costLimit：存储空间开销值限制（不精确）
  • evictsObjectsWithDiscardedContent(自动回收废弃内容，没看到这个属性的使用场景)
• 方法
  • 使用key同步存、取、删
  • 删除所有内容

1.1.2、实现

• NSCacheEntry：内部类，将key-value转换成改实体，用来实现双向链表存储结构
  • key：键
  • value：值
  • cost：开销
  • prevByCost：上个节点
  • nextByCost：下个节点
• NSCacheKey：对存取使用的key的封装，用于实现存取使用不支持NSCopy协议的object
  • value：存取使用的key的值
• _entries：NSDictionary，使用它以键值对形式存取NSCacheEntry实例
• _head：双向链表头节点，链表按cost升序排序；setObject触发costLimit/countLimit trim时，从根节点开始删除
• NSLock：实现读写线程安全

1.2、TMCache

TMCache 最初由 Tumblr 开发，但现在已经不再维护了。TMMemoryCache 实现了很多 NSCache 并没有提供的功能，比如数量限制、总容量限制、存活时间限制、内存警告或应用退到后台时清空缓存等。TMMemoryCache 在设计时，主要目标是线程安全，它把所有读写操作都放到了同一个 concurrent queue 中，然后用 dispatch_barrier_async 来保证任务能顺序执行。它错误的用了大量异步 block 回调来实现存取功能，以至于产生了很大的性能和死锁问题。
由于该库很久不再维护，不做详细对比。

1.3、PINCache

Tumblr 宣布不在维护 TMCache 后，由 Pinterest 维护和改进的一个缓存SDK。它的功能和接口基本和 TMCache 一样，但修复了性能和死锁的问题。它同样也用 dispatch_semaphore 来保证线程安全，但去掉了dispatch_barrier_async，避免了线程切换带来的巨大开销，也避免了可能的死锁。

1.3.1、特性：

• PINCaching（protocal）

  • 属性
    • 名称
  • 方法
    • 同步/异步使用key存、取、删、判断存在、设置ttl时长、存储空间消耗值
    • 同步/异步删除指定日期之前的数据（磁盘缓存指创建日期）
    • 同步/异步删除过期数据
    • 同步/异步删除所有数据

• PINMemoryCache

  • 属性
    • totalCost：已经使用的总开销
    • costLimit：开销（内存）使用限制（每次赋值时，触发trim)
    • ageLimit：统一生命周期限制（每次赋值时，触发trim；GCD timer循环触发)
    • ttlCache：是否ttl，配置此项，获取数据只会返回生命周期存活状态的数据
    • removeAllObjectsOnMemoryWarning
    • removeAllObjectsOnEnteringBackground
    • 将要/已经添加、移除缓存对象block监听
    • 将要/已经移除缓存所有对象block监听
    • 已经接收内存警告、已经进入后台block监听
  • 方法
    • 同步/异步删除数据到指定的cost以下
    • 同步/异步删除在指定日期之前的数据，继续删除数据到指定的cost以下（trimToCostLimitByDate）
    • 同步/异步遍历所有缓存数据
  • 内部实现
    • 通过NSMutableDictionary保存需要缓存的数据，通过额外的NSMutableDictionary来保存createdDates（创建时间）、accessDates（最近访问时间）、costLimit、ageLimit等信息
    • 使用互斥锁保证多线程安全
    • 使用PINOperationQueue实现异步操作
    • setObject触发c