iOS本地缓存方案之YYCache源码解析

iOS持久化方案有哪些？

简单列举一下，iOS的本地缓存方案有挺多，各有各的适用场景：

• NSUserDefault :

  系统提供的最简便的key-value本地存储方案，适合比较轻量的数据存储，比如一些业务flag。主要原因还是其底层是用plist文件存储的，在数据量逐步变大后，可能会发生性能问题。

• 存文件，归档：

  无论是自己转换业务数据为二进制再writeFile，还是直接利用系统的NSKeyedArchiver接口归档成文件，都属于文件存储的方案。优势是开发简单，业务可以自行控制单文件的存储内容以避免可能发生的性能问题。

• sqlite、FMDB：

  底层利用到数据的存储方案，比较适用数据量大，有查询，排序等需求的存储场景，缺点就是开发略复杂一些。

• CoreData、其他ORM方案：

  CoreData感觉好像应用并不是很广泛？

• Key-Value接口的缓存方案：

  这里特指提供Key-Value形式接口的缓存库，底层缓存可能使用文件或者sqlite都有。本文讨论的YYCache底层是混合使用文件+sqlite的存储方式。基于接口简便，性能优于NSUserDefault的特性，应该适用于大多数的业务场景，但是无法适用上面数据库类似的使用场景。

聊聊YYCache的优秀设计

这里其实yy大神本人在博文《YYCache 设计思路》中对其设计思路有比较详尽的介绍，建议大家可以先去读一读，本文就其相对于其他缓存库的一些优势点聊一聊。

高性能的线程安全方案

首先高性能是YYCache比较核心的一个设计目标，挺多代码逻辑都是围绕性能这个点来做的。

作为对比，yy提出了TMMemoryCache方案的性能缺陷。TMMemoryCache的线程安全采用的是比较常见的通过dispatch_barrier来保障并行读，串行写的方案。该方案我在上一篇《AFNetworking源码解析与面试考点思考》中有介绍。那么TMMemoryCache存在性能问题的原因会是因为其dispatch_barrier的线程安全方案吗？

答案应该在其同步接口的设计上：

- (id)obj