做网络层缓存的思路和总结(基于XTFMDB)
- 前言:
我们知道. 微信微博都是大量使用缓存的app.在没有网络的情况下. 用户依然可以浏览历史记录 .这种体验很好, 而且能节省用户的手机流量.
我自己仿照写了一个缓存机制.结合在网络层.
这篇文章谈谈我实现的想法. 在应用里去做大量的缓存的时候 . 到底怎么做比较合适 ? 以及我为什么这么做 .
这篇文章谈谈思路.
层次关系
NSCache & NSURLCache
这是一种思路. 优点是有内存的缓存. 也能做磁盘的缓存 . 键值对的存储形式. 访问速度更快. SDWebImage里用了内存的缓存提高图片读写速度. 说一下缺陷, 是看不到整个保存的数据结构什么样. 追踪复杂的数据结构的时候不太方便. 如果是运算量大.但结构单一的数据类型.我会用NSCache. 结合现在需求的场景. 我们要做对整个app数据的缓存. 这种肯定不适合了.
用数据库
表结构一目了然,出问题了追起来也容易的多,数据不会丢失,性能也不慢(有差距,但已经可以忽略不计). 综上,很适合我的需求. 所以决定了, 用数据库. 那么问题来了. 怎么去设计这个数据库的表结构呢 ?
方案一.
沿袭服务端的表结构.照抄一个和后台一模一样的数据库建模.
优点是,结构很清晰.但工作量太大.而且有一些数据你只需要保存你当前用户的,和后台一模一样设计并没有什么意义.
当然不排除有的时候对一些数据要深度处理.这种方案还是有优势.
方案二.
只对请求返回的response做缓存 .表结构以键值为主去保存 .
在原有的网络架构中在加一层做缓存处理. 每个请求拼上参数作为一个唯一性的字段做主键. 就能保证不重复保存了.
最大的优点在于.不需要考虑复杂的数据结构.只针对每个请求的response.
当然,还需要不同的缓存策略. 各种请求的需求不同. 有的不需要缓存只需要在无网状态下返回上一次的数据就行了(实时/频繁更新). 有的只请求一次后面每次都返回缓存的(千年不变). 有的按时间判断超时与否再做操作(判断超时).
缓存逻辑
如何建模
上一篇博客XTFMDB. 缓存表XTResponseDBModel在XTFMDB这个项目基础上开发. 把每个请求拼成一个URL当成UNIQUE的KEY. response当成VALUE去存储. 当然还有一些常规字段.
