iOS数据持久化设计

数据持久化的目的

1、快速展示,提升体验

已经加载过的数据,用户下次查看时,不需要再次从网络(磁盘)加载,直接展示给用户

2、节省用户流量(节省服务器资源)

对于较大的资源数据进行缓存,下次展示无需下载消耗流量
同时降低了服务器的访问次数,节约服务器资源。(图片)

3、离线使用。

用户浏览过的数据无需联网,可以再次查看。
部分功能使用解除对网络的依赖。(百度离线地图、图书阅读器)
无网络时,允许用户进行操作,等到下次联网时同步到服务端。

4、记录用户操作

草稿:对于用户需要花费较大成本进行的操作,对用户的每个步骤进行缓存,用户中断操作后,下次用户操作时直接继续上次的操作。
已读内容标记缓存,帮助用户识别哪些已读。
搜索记录缓存

数据持久化方式分类

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

1、内存缓存

  • 定义
    对于使用频率比较高的数据,从网络或者磁盘加载数据到内存以后,使用后并不马上销毁,下次使用时直接从内存加载。
  • 案例
    iOS系统图片加载——[UIImage imageNamed:@"imageName"]
    网络图片加载三方库:SDWebImage

2、磁盘缓存

  • 定义
    将从网络加载的、用户操作产生的数据写入到磁盘,用户下次查看、继续操作时,直接从磁盘加载使用。
  • 案例
    用户输入内容草稿缓存(如:评论、文本编辑)
    网络图片加载三方库:SDWebImage
    搜索历史缓存

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

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

1、FIFO(First in First out)

实现原理:

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

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

2、LFU(Least Frequently Used)

实现原理:

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

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

3、 LRU (LeastRecentlyUsed)
4、 LRU-K (LeastRecentlyUsed)
5、2Q(Two queues)
6、MQ(Multi Queue)

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)移动数据库。

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

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,233评论 4 360
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,013评论 1 291
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,030评论 0 241
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,827评论 0 204
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,221评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,542评论 1 216
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,814评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,513评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,225评论 1 241
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,497评论 2 244
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,998评论 1 258
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,342评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,986评论 3 235
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,055评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,812评论 0 194
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,560评论 2 271
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,461评论 2 266

推荐阅读更多精彩内容