app缓存策略探索

最近使用RN作APP，时间长了老是以为接口请求是在太频繁。遂想到，不如给接口作个缓存吧。

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

服务器接口缓存

最开始的时候只是但愿减轻服务器压力，减小没必要要的计算过程。好比用户数据没变化的时候就不须要去计算用户的各类数据，直接使用缓存就行了。

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

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

后端计算和更新的数据其实已经存在在redis中了，可是在业务比较复杂的状况下，有些数据其实仍是须要去获取的。这里的缓存其实相似于一个http的缓存。它的本意只是为了缓存最终接口须要返回的数据。这里使用redis去存储原本只是一个过分方案。打算使用这个方案的同窗能够去关注一下varnish，这个才是真正的http缓存。

使用APP缓存

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

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

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

这样有不少好处：

1. 减小没必要要的计算
2. 关键时刻能够立马更新接口数据，甚至能够灰度更新某些地区的、ip的用户缓存
3. 不返回大块的数据，加速了请求速度
4. 若是遇到网络错误，能够直接使用缓存的信息。至关于离线APP

使用接口hash

将接口返回的数据看过一段固定的字符串，每次都计算字符串的hash值。这样能够更加方便的判断接口返回数据是否须要更新。

在上一步的策略中，接口返回的数据根据时间戳实际上是根据接口更新的时间来定的。加入接口更新了，可是数据并无变化，这个时候就会产生一次额外的请求。用户多的时候也是一个很是流量的操做。

若是使用hash来判断接口是否须要更新，这样就能够直接免去了这种无用的更新操做。相比上一个版本更加的高效。不过服务端计算hash让整个项目的复杂度又高了很多。这个就要考虑这样作是否值得了。

若是原有的更新策略已经完成了。好比刷新redis的策略已经作完了。其实这个时候将redis中的数据作一次hash也不费事，这样也能够很是简单的将缓存策略升级。

使用APP过时策略

这里再提出一个更加激进的策略。假如某些接口的更新速度很是慢，我叫这些接口静态接口。那么每次的304请求是否是很是多余？

这里就将这种接口设置一个固定的过时时间。在这个过时时间内，每次请求接口都会使用本地缓存，直到过时以后采起请求远程接口。

有人提出说，这种策略在后端有更新的时候不能即时的更新数据。别着急，更新数据也能够很是及时。

在全部接口以后，在新增一个本地缓存策略接口。将上述几个接口的状态放在这里。每次都请求后端接口，让后端来判断这个接口是否须要更新。好比：请求hash，若是须要更新就返回最新状态，不须要更新就不返回数据。

其余的静态接口在请求以前都会使用这个状态比较一次。若是须要更新就发请求，不须要更新就使用本地缓存。这样就完美的解决了接口缓存的问题。从一个每次都要请求接口变成了部分接口快速返回304，部分接口不请求。

---

RN开发的APP能够很是快的发布版本（热更新），同时开发的时候因为js的缘由也会很是的灵活。这个时候使用上面的缓存策略会更加简单方便。

经过上述几个策略就能够减小很是多的无用请求。好比后端的热配置信息，不少时候其实没有改动，彻底可使用静态接口的策略。

进入APP的时候也能够先使用旧的数据展现列表，而后乘机更新。固然详情也和过时下架的产品仍是要即时的排除掉的。

连接地址