网络缓存

查询一下网络请求,你会发现这种,是不是真的这么简单?可以参考一下
http://www.cocoachina.com/ios/20161107/17981.html?utm_source=tuicool&utm_medium=referral

我理解的正如评论所说的,post无法。
这个每个公司是不一样,不过感觉都喜欢post,毕竟稍微安全点。

so,自带缓存可能不一定合适。最流行的流行afn和yycache组合,yycache内存和硬盘缓存会比较快。

现在剩下思路:
什么需要缓存?(这部分只说网络缓存,用户数据缓存的话,可以是归档、数据库等)
何时更新?
最最重要的是要根据现有项目情况来做出相应的修改。

什么需要缓存。
一般请求分成二种,一种是展示(不一定缓存,按需求),一种是修改,修改结果的接口我们不需要缓存(修改都是post),我们需要缓存的是展示的网络请求。这部分当然还需要区分,区分的依据是更新机制,如果你每次请求都更新的话,缓存就是为了用户体验(防止用户网卡)。如果你是根据后台某个通知机制去更新,那就是一些不太常改变的数据缓存。我们可以封装相应的api请求接口,根据需求情况相应改变。

那么现有问题又是如何去更新?
1.每次api接口请求时更新;
2.根据某个消息通知更新。(app存在多端操作,以及上级可以修改下级状态)

github上会有几个afn和yycache封装的缓存库
我选择了PPNetworkHelper。
大致思路,可以看下方法回调,如果需要缓存的话,去内存缓存(优先内存缓存,没有硬盘缓存)查找,有就先返回缓存,没有的话,返回nil,当网络请求有返回时,根据返回,返回成功或者失败数据。如成功,缓存请求成功的数据。

项目情况(原网络框架,afn封了一成)
项目暂无一个很好的更新机制,且一个用户相应身份权限都基础数据需要大致5-8个接口(这部分缓存是希望体验好点,app内信息查询根据令另外的数据缓存),同时由于无法判断身份(后期app端不判断,接口判断能否正常调用)以前版本需要实时判断,体检较差。
展示页面,根据返回显示
列表页面,根据返回显示,同时支持返回,搜索(网络请求)

修改方案:(在ppnetworkhelper上封装一层,ydnetworkhelper,然后原网络框架套在ydneiworkhelper上)
修改思路:需要缓存的数据,每次接口请求,优先加载缓存(如有),再返回网络数据。
单纯的无列表展示页面就这样。
然后当碰到列表页面的时候,就有问题了。
列表翻页时是要模型加到数据,如果返回二次的话,数据就不对了。所以我们自己的ydnetworkhelper上最好把缓存和成功(正常),以及缓存和失败(这部分依照自己意愿,失败情况,网络慢,身份等等)的写在二个block上,而不是分开的三个block。

在相应的控制器或者presenter上去修改。
1.有缓存,无网络请求
2.无缓存,有网络请求
3.有缓存,有网络请求
4.无缓存,无网络请求(忽略)

无缓存时,执行:--->2 2执行加到数组,刷新列表
有缓存时,执行:1--->3 2执行加到数组,刷新列表 3执行删除缓存加到数据的个数,同时把网络请求数据的模型加到数组刷新。

本来考虑了线程,如果网络比较好的话,可以把1这步取消,后来发现删除是按数据个数的,如果加了线程可取消的话,还需要其他判断,同时无法定义网络好坏,因为暴露给了p或者c,代码量就比较多,同时,一般一页只设置了10到20个数据,暂放弃。

以上仅测试阶段,工作量较大,慢慢修改。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容