最近使用 RN 做 APP, 时间长了总是觉得接口请求是在太频繁遂想到, 不如给接口做个缓存吧
这里申明一下, 我是从前端开始接触 RN, 然后到 APP 的对于 APP 原本是使用什么样的缓存策略还真的没有去深入了解这里本着将前端的思想带入 APP 的原则来探讨一下使用 RN 来做接口部分的缓存策略
服务器接口缓存
最开始的时候只是希望减轻服务器压力, 减少不必要的计算过程比如用户数据没变化的时候就不需要去计算用户的各种数据, 直接使用缓存就好了
这里将服务器的接口返回数据根据策略缓存在 redis 中, 然后根据上次更新之后的时间戳来判断是否需要重新计算缓存中的数据
有人可能开始质疑这个数据本来就是放在缓存中的, 尤其是用户数据, 根本不可能实时去计算这里稍微说一下这个方案的背景
后端计算和更新的数据其实已经存在在 redis 中了, 但是在业务比较复杂的情况下, 有些数据其实还是需要去获取的这里的缓存其实类似于一个 http 的缓存它的本意只是为了缓存最终接口需要返回的数据这里使用 redis 去存储本来只是一个过度方案打算使用这个方案的同学可以去关注一下 varnish, 这个才是真正的 http 缓存
使用 APP 缓存
这个阶段其实才开始算真正的缓存
APP 端会把第一次从接口获取到的数据缓存在本地, 并且返回接口的时间戳当下一次请求的时候直接带上这个时间戳去请求
服务器根据这个时间戳去判断接口是否有更新, 或者也可以定一个固定的时间在这个时间段内默认缓存不过期服务器返回 304 这样的 http codeAPP 根据这个 code 判断缓存未过期, 直接使用本地缓存的接口信息
这样有很多好处:
减少不必要的计算
关键时刻可以立马更新接口数据, 甚至可以灰度更新某些地区的 ip 的用户缓存
不返回大块的数据, 加速了请求速度
如果遇到网络错误, 可以直接使用缓存的信息相当于离线 APP
使用接口 hash
将接口返回的数据看过一段固定的字符串, 每次都计算字符串的 hash 值这样可以更加方便的判断接口返回数据是否需要更新
在上一步的策略中, 接口返回的数据根据时间戳其实是根据接口更新的时间来定的加入接口更新了, 但是数据并没有变化, 这个时候就会产生一次额外的请求用户多的时候也是一个非常流量的操作
如果使用 hash 来判断接口是否需要更新, 这样就可以直接免去了这种无用的更新操作相比上一个版本更加的高效不过服务端计算 hash 让整个项目的复杂度又高了不少这个就要考虑这样做是否值得了
如果原有的更新策略已经完成了比如刷新 redis 的策略已经做完了其实这个时候将 redis 中的数据做一次 hash 也不费事, 这样也可以非常简单的将缓存策略升级
使用 APP 过期策略
这里再提出一个更加激进的策略假如某些接口的更新速度非常慢, 我叫这些接口静态接口那么每次的 304 请求是不是非常多余?
这里就将这种接口设置一个固定的过期时间在这个过期时间内, 每次请求接口都会使用本地缓存, 直到过期之后采取请求远程接口
有人提出说, 这种策略在后端有更新的时候不能即时的更新数据别着急, 更新数据也可以非常及时
在所有接口之后, 在新增一个本地缓存策略接口将上述几个接口的状态放在这里每次都请求后端接口, 让后端来判断这个接口是否需要更新比如: 请求 hash, 如果需要更新就返回最新状态, 不需要更新就不返回数据
其他的静态接口在请求之前都会使用这个状态比较一次如果需要更新就发请求, 不需要更新就使用本地缓存这样就完美的解决了接口缓存的问题从一个每次都要请求接口变成了部分接口快速返回 304, 部分接口不请求
RN 开发的 APP 可以非常快的发布版本 (热更新), 同时开发的时候由于 js 的原因也会非常的灵活这个时候使用上面的缓存策略会更加简单方便
通过上述几个策略就可以减少非常多的无用请求比如后端的热配置信息, 很多时候其实没有改动, 完全可以使用静态接口的策略
进入 APP 的时候也可以先使用旧的数据展示列表, 然后伺机更新当然详情也和过期下架的产品还是要即时的排除掉的
链接地址
来源: https://juejin.im/post/5abb7d38f265da237b2225b2