RN的缓存策略探索

最近使用RN做APP，时间长了总是觉得接口请求是在太频繁。遂想到，不如给接口做个缓存吧。

这里申明一下，我是从前端开始接触RN，然后到APP的。对于APP原本是使用什么样的缓存策略还真的没有去深入了解。这里本着将前端的思想带入APP的原则来探讨一下使用RN来做接口部分的缓存策略。

服务器接口缓存

最开始的时候只是希望减轻服务器压力，减少不必要的计算过程。比如用户数据没变化的时候就不需要去计算用户的各种数据，直接使用缓存就好了。

这里将服务器的接口返回数据根据策略缓存在redis中，然后根据上次更新之后的时间戳来判断是否需要重新计算缓存中的数据。

有人可能开始质疑。这个数据本来就是放在缓存中的，尤其是用户数据，根本不可能实时去计算。这里稍微说一下这个方案的背景。

后端计算和更新的数据其实已经存在在redis中了，但是在业务比较复杂的情况下，有些数据其实还是需要去获取的。这里的缓存其实类似于一个http的缓存。它的本意只是为了缓存最终接口需要返回的数据。这里使用redis去存储本来只是一个过度方案。打算使用这个方案的同学可以去关注一下varnish，这个才是真正的http缓存。

使用APP缓存

这个阶段其实才开始算真正的缓存。

APP端会把第一次从接口获取到的数据缓存在本地，并且返回接口的时间戳。当下一次请求的时候直接带上这个时间戳去请求。

服务器根据这个时间戳去判断接口是否有更新，或者也可以定一个固定的时间。在这个时间段内默认缓存不过期。服务器返回304这样的http code。APP根据这个code判断缓存未过期，直