最近使用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的时候也可以先使用旧的数据展示列表，然后伺机更新。当然详情也和过期下架的产品还是要即时的排除掉的。

链接地址