iOS-具有上下刷新列表页的缓存方案

最近项目要对一个具有上下刷新列表页做缓存方案，和安卓，后台一起讨论了差不多一个上午，也没得出一个有效可行的方案。后来我就上网查了下微信朋友圈和新浪微博的做法，觉得可以借鉴一下。

微信朋友圈的缓存机制是怎样
SNS 背后的技术: 消息流的推拉模式选择
上面两篇文章对这两个应用的缓存方案解释得比较好
微信朋友圈

朋友圈机制.png

在文章里，这位网友回答足以让我们大概了解朋友圈的缓存方案，朋友圈的信息是通过SNS的推模式实现，有消息推送过来就缓存，消息时就从数据拿，这样既保证了良好的用户体验，也确保了消息的时效性。

当然，并不是所有的应用都使用这套方案，正如上面文章里所说，推模式下比较耗费资源，做这套方案首先要具备良好性能的服务器，当然，这对于做即时聊天起家的腾讯来说，这并不是什么难事。
新浪微博
既然朋友圈的推模式不太适用，那新浪微博的方案呢，如下：

新浪微博缓存.png

如上面所说，新浪微博肯定是不适用于推模式的，微博里有这么多大v，有些大v有着上千万的粉丝，如果大v每发一条微博都会向千万个粉丝推送消息，估计新浪的服务器也扛不住。所以新浪这里应该就是用了拉模式。

至于这个拉模式的方案具体怎么实现，我们看看新浪微博提供的api文档能够有大概的想法了，获取当前登录用户及其所关注（授权）用户的最新微博

微博接口参数.png

根据since_id和max_id来确认向上查找或向下查找，查找完再缓存本地，下次再查找就根据当前缓存的数据最顶端或者低端的id作为since_id或max_id。当然我们也可以改成用时间戳来做标记，只要确定到当条消息在服务器的位置就好，看个人喜好咯。

上述这套方案既能保证缓存顺序的正确性，又能保持良好的用户体验，不失为一个好办法。

但是，有个情况存在的问题，我还没想懂，如果我在一次刷新后已经获取了一定数量的缓存数据，然后我间隔好久都没拉新数据，这时我后台的服务器已经有了几百条或者更多的新数据时，这时又应该怎么解决？

1.一次性全部拉取几百条，肯定是不行；

2.只拉取我们本地缓存的数据最新一条以上的10条或者一定数量条，这样倒是可以，但是又不符合产品需求啊，按照大家的惯性思维逻辑，顶部刷新肯定要查看最新的数据的；

3.拉取服务器里最新的10条或者一定数量条，但是这样做的话，我拉取到的新数据就和我原来缓存的数据产生断层了，这时又应该怎么解决呢？？？

首先我觉得肯定要用第三种方案，先拉取最新的10条后缓存，底部刷新时，这时还是拉取服务器的数据，直到拉取我们已经缓存的旧数据，这时候再次底部刷新时就直接从我们本地数据库查找。

当然，以上只是我一些比较浅薄的看法，实际怎么操作或者有更好的做法，希望大家能在评论里多多提点。

学习之路，与君共勉。