iOS 架构之数据持久化设计方案

前言：

之前看了Casa大神的架构设计文章，醍醐灌顶，一直想开个系列文章记录一下（这次就做个小小搬运工，别打脸），公司项目实在太忙，最近稍好些，就开始着手做这件事，这个系列共以下几篇：
１. 搭建优质的App框架
２. view层的组织和调用方案（常用架构模式-ＭＶＣ、ＭＶＣＳ、ＭＶＶＭ）
３. 网络层设计方案
４. 数据持久化设计方案及动态部署
５. 组件化方案

在项目架构时，做数据持久化方案的设计是很重要的核心工作之一。数据持久化无论在服务器端和移动客户端都是非常重要的技术工作。但是客户端和服务器端持久化的侧重点不同，在服务端，持久化方案的优劣往往都会在一定程度上影响到产品的性能。然而在客户端，只有为数不多的业务需求会涉及持久化方案，而且在大多数情况下，持久化方案对性能的要求并不是特别苛刻。我在移动端这边做持久化方案设计的时候，我更考虑的是以下几点：

****用户第一，做持久化希望解决用户的问题****

1.在正常网络下，快速提供给用户必要的展示数据，提高APP的用户体验。
2.在网络异常，甚至无网络情况下，能让应用提供基本功能。
3.在必要时无网络情况下，用户可进行必要操作，在有网情况下，同步数据。
4.减少对同一URL的请求次数，甚至只从服务器下载更新过或更改过的资源。节约用户流量，并且也可以减少服务器请求压力。
5.还有确保用户敏感数据的安全。

****作为架构师做持久化还需关注的问题****

1.方案的长期可维护性和拓展性
2.持久化方案对APP的性能影响优化
3.方案对业务开发工程师是否友好
4.不同需求的缓存目录的选择
5.数据库的读写隔离
6.数据库的多线程实现和线程安全
7.数据库的版本升级和迁移

****作为架构师做持久化需要了解APP的个别需求****

1.根据APP的特点采取不同的持久化方案
2.是否需要支持多用户切换，以及多用户切换带来的数据库迁移操作变化
3.是否有重要的敏感信息需要加密

****可供缓存方案的技术手段****
每个APP的功能需求不同，导致需要持久化的功能也有差异，面对不同的持久化需求，我们应该胸有成竹，手中有货。作为架构师必须要知道的几种持久化手段：
1.内存缓存
内存缓存主要为了节约用户流量，避免相同URL请求多次相同的数据。内存缓存需要根据业务的更新的频率和用户请求数据的频率来觉得内存缓存数据的有效期。实现内存缓存的技术手段有苹果官方提供了NSURLCache，还有优秀的开源缓存库YYCache（国内牛人开发）、PinCache（Pinster公司维护）。
2.磁盘缓存

• NSUserDefault
  一般来说，小规模数据，弱业务相关数据，都可以放到NSUserDefault里面，内容比较多的数据，强业务相关的数据就不太适合NSUserDefault了。
• keychain
  Keychain是苹果提供的带有可逆加密的存储机制，普遍用在各种存密码的需求上。另外，由于App卸载只要系统不重装，Keychain中的数据依旧能够得到保留，以及可被iCloud同步的特性，大家都会在这里存储用户唯一标识串。所以有需要加密、需要存iCloud的敏感小数据，一般都会放在Keychain。
• 文件存储
  文件存储包括了Plist、archive、Stream等方式，一般结构化的数据或者需要方便查询的数据，都会以Plist的方式去持久化。Archive方式适合存储平时不太经常使用但很大量的数据，或者读取之后希望直接对象化的数据，因为Archive会将对象及其对象关系序列化，以至于读取数据的时候需要Decode很花时间，Decode的过程可以是解压，也可以是对象化，这个可以根据具体中的实现来决定。Stream就是一般的文件存储了，一般用来存存图片啊啥的，适用于比较经常使用，然而数据量又不算非常大的那种。
• 数据库存储
  数据库存储的话，花样就比较多了。苹果自带了一个Core Data，当然业界也有无数替代方案可选，不过真正用在iOS领域的除了Core Data外，就是FMDB比较多了。数据库方案主要是为了便于增删改查，当数据有状态和类别的时候最好还是采用数据库方案比较好，而且尤其是当这些状态和类别都是强业务相关的时候，就更加要采用数据库方案了。因为你不可能通过文件系统遍历文件去甄别你需要获取的属于某个状态或类别的数据，这么做成本就太大了。当然，特别大量的数据也不适合直接存储数据库，比如图片或者文章这样的数据，一般来说，都是数据库存一个文件名，然后这个文件名指向的是某个图片或者文章的文件。如果真的要做全文索引这种需求，建议最好还是挂个API丢到服务端去做。

3.应该用哪种缓存技术
在众多可以本地保存数据的技术中，有三种脱颖而出：URL缓存、数据模型缓存（利用NSKeyedArchiver）和 SQLLite。假设你正在开发一个应用，需要缓存数据以改善应用表现出的性能，你应该实现按需缓存（使用数据模型缓存或URL缓存）。另一方面，如果需要数据能够离线访问，而且具有合理的存储方式以便离线编辑，那么就用高级序列化技术（如Core Data,SQLLite）。

****缓存需求的种类****

• 按需缓存
  获取数据的速度比数据本身重要。 按需缓存是指把从服务器获取的内容以某种格式存放在本地文件系统，之后对于每次请求，检查缓存中是否存在这块数据，只有当数据不存在（或者过期）的情况下才从服务器获取。这样的话，缓存层就和处理器的高速缓存差不多。
• 预缓存
  预缓存是把内容放在本地以备将来访问。数据对用户离线情况下也非常有意义。对预缓存来说，数据丢失或者缓存出现问题是不可接受的，会给用户带来非常差的感官。实现预缓存可能需要一个后台线程访问数据并以有意义的格式保存，以便本地缓存无需重新连接服务器即可被编辑。编辑可能是“标记记录为已读”或“加入收藏”，或其他类似的操作。这里有意义的格式是指可以用这种方式保存内容，不用和服务器通信就可以在本地作出上面提到的修改，并且一旦再次连上网就可以把变更发送回服务器。
• 区分APP持久化需求的分类方法
  选择使用按需缓存还是预缓存的一个简便方法是判断是否需要在下载数据之后处理数据。后期处理数据可能是以用户产生编辑的形式，也可能是更新下载的数据。如果一个应用需要做上面提到的任何后期处理，就必须实现预缓存。

****持久化设计方案****

• 按需缓存
  对于按需缓存，因为这部分数据并不需要精确的管理，我们有很多的第三方框架解决，现在比较著名的有YYCache（国产精品）,PinCache,TMCache（已经不再维护）。他们的共同点就是轻量级、内存和磁盘缓存支持、多线程和线程安全支持，也支持过期时间设置。
• 预缓存
  预缓存的数据我们希望为用户精确存储，以方便增删改查操作。因此我们可以使用CoreData、FMDB、Realm等解决方案。我个人觉得CoreData过度封装和设计，导致灵活性不足，而且使用起来也是很麻烦的。相对而言我更喜欢FMDB，它给了我们更大的设计自由度，但为了达到更好的面向对象直接操作数据库（目标要超越CoreData的方便,并且提供后期扩展到灵活性），我推荐大家可以使用第三方开源FSModel、LKDBHelper、JSONModel等框架。
• 解决方案

/****第三方库****/
pod 'FMDB/SQLCipher', '~> 2.5'//自动导入FMDB和SQLCipher 实现数据库操作和加密
pod 'LKDBHelper', '~> 2.1.9'//对FMDB的封装，实现ORM面向对象操作数据库
pod 'YYCache', '~> 1.0.2'//支持内存和磁盘缓存