最近使用RN做APP，時(shí)間長(zhǎng)了總是覺(jué)得接口請(qǐng)求是在太頻繁。遂想到，不如給接口做個(gè)緩存吧。

這里申明一下，我是從前端開(kāi)始接觸RN，然后到APP的。對(duì)于APP原本是使用什么樣的緩存策略還真的沒(méi)有去深入了解。這里本著將前端的思想帶入APP的原則來(lái)探討一下使用RN來(lái)做接口部分的緩存策略。

服務(wù)器接口緩存

最開(kāi)始的時(shí)候只是希望減輕服務(wù)器壓力，減少不必要的計(jì)算過(guò)程。比如用戶數(shù)據(jù)沒(méi)變化的時(shí)候就不需要去計(jì)算用戶的各種數(shù)據(jù)，直接使用緩存就好了。

這里將服務(wù)器的接口返回?cái)?shù)據(jù)根據(jù)策略緩存在redis中，然后根據(jù)上次更新之后的時(shí)間戳來(lái)判斷是否需要重新計(jì)算緩存中的數(shù)據(jù)。

有人可能開(kāi)始質(zhì)疑。這個(gè)數(shù)據(jù)本來(lái)就是放在緩存中的，尤其是用戶數(shù)據(jù)，根本不可能實(shí)時(shí)去計(jì)算。這里稍微說(shuō)一下這個(gè)方案的背景。

后端計(jì)算和更新的數(shù)據(jù)其實(shí)已經(jīng)存在在redis中了，但是在業(yè)務(wù)比較復(fù)雜的情況下，有些數(shù)據(jù)其實(shí)還是需要去獲取的。這里的緩存其實(shí)類(lèi)似于一個(gè)http的緩存。它的本意只是為了緩存最終接口需要返回的數(shù)據(jù)。這里使用redis去存儲(chǔ)本來(lái)只是一個(gè)過(guò)度方案。打算使用這個(gè)方案的同學(xué)可以去關(guān)注一下varnish，這個(gè)才是真正的http緩存。

使用APP緩存

這個(gè)階段其實(shí)才開(kāi)始算真正的緩存。

APP端會(huì)把第一次從接口獲取到的數(shù)據(jù)緩存在本地，并且返回接口的時(shí)間戳。當(dāng)下一次請(qǐng)求的時(shí)候直接帶上這個(gè)時(shí)間戳去請(qǐng)求。

服務(wù)器根據(jù)這個(gè)時(shí)間戳去判斷接口是否有更新，或者也可以定一個(gè)固定的時(shí)間。在這個(gè)時(shí)間段內(nèi)默認(rèn)緩存不過(guò)期。服務(wù)器返回304這樣的http code。APP根據(jù)這個(gè)code判斷緩存未過(guò)期，直接使用本地緩存的接口信息。

這樣有很多好處：

減少不必要的計(jì)算

關(guān)鍵時(shí)刻可以立馬更新接口數(shù)據(jù)，甚至可以灰度更新某些地區(qū)的、ip的用戶緩存

不返回大塊的數(shù)據(jù)，加速了請(qǐng)求速度

如果遇到網(wǎng)絡(luò)錯(cuò)誤，可以直接使用緩存的信息。相當(dāng)于離線APP

使用接口hash

將接口返回的數(shù)據(jù)看過(guò)一段固定的字符串，每次都計(jì)算字符串的hash值。這樣可以更加方便的判斷接口返回?cái)?shù)據(jù)是否需要更新。

在上一步的策略中，接口返回的數(shù)據(jù)根據(jù)時(shí)間戳其實(shí)是根據(jù)接口更新的時(shí)間來(lái)定的。加入接口更新了，但是數(shù)據(jù)并沒(méi)有變化，這個(gè)時(shí)候就會(huì)產(chǎn)生一次額外的請(qǐng)求。用戶多的時(shí)候也是一個(gè)非常流量的操作。

如果使用hash來(lái)判斷接口是否需要更新，這樣就可以直接免去了這種無(wú)用的更新操作。相比上一個(gè)版本更加的高效。不過(guò)服務(wù)端計(jì)算hash讓整個(gè)項(xiàng)目的復(fù)雜度又高了不少。這個(gè)就要考慮這樣做是否值得了。

如果原有的更新策略已經(jīng)完成了。比如刷新redis的策略已經(jīng)做完了。其實(shí)這個(gè)時(shí)候?qū)edis中的數(shù)據(jù)做一次hash也不費(fèi)事，這樣也可以非常簡(jiǎn)單的將緩存策略升級(jí)。

使用APP過(guò)期策略

這里再提出一個(gè)更加激進(jìn)的策略。假如某些接口的更新速度非常慢，我叫這些接口靜態(tài)接口。那么每次的304請(qǐng)求是不是非常多余？

這里就將這種接口設(shè)置一個(gè)固定的過(guò)期時(shí)間。在這個(gè)過(guò)期時(shí)間內(nèi)，每次請(qǐng)求接口都會(huì)使用本地緩存，直到過(guò)期之后采取請(qǐng)求遠(yuǎn)程接口。

有人提出說(shuō)，這種策略在后端有更新的時(shí)候不能即時(shí)的更新數(shù)據(jù)。別著急，更新數(shù)據(jù)也可以非常及時(shí)。

在所有接口之后，在新增一個(gè)本地緩存策略接口。將上述幾個(gè)接口的狀態(tài)放在這里。每次都請(qǐng)求后端接口，讓后端來(lái)判斷這個(gè)接口是否需要更新。比如：請(qǐng)求hash，如果需要更新就返回最新?tīng)顟B(tài)，不需要更新就不返回?cái)?shù)據(jù)。

其他的靜態(tài)接口在請(qǐng)求之前都會(huì)使用這個(gè)狀態(tài)比較一次。如果需要更新就發(fā)請(qǐng)求，不需要更新就使用本地緩存。這樣就完美的解決了接口緩存的問(wèn)題。從一個(gè)每次都要請(qǐng)求接口變成了部分接口快速返回304，部分接口不請(qǐng)求。

---

RN開(kāi)發(fā)的APP可以非常快的發(fā)布版本（熱更新），同時(shí)開(kāi)發(fā)的時(shí)候由于js的原因也會(huì)非常的靈活。這個(gè)時(shí)候使用上面的緩存策略會(huì)更加簡(jiǎn)單方便。

通過(guò)上述幾個(gè)策略就可以減少非常多的無(wú)用請(qǐng)求。比如后端的熱配置信息，很多時(shí)候其實(shí)沒(méi)有改動(dòng)，完全可以使用靜態(tài)接口的策略。

進(jìn)入APP的時(shí)候也可以先使用舊的數(shù)據(jù)展示列表，然后伺機(jī)更新。當(dāng)然詳情也和過(guò)期下架的產(chǎn)品還是要即時(shí)的排除掉的。

鏈接地址

總結(jié)

以上是生活随笔為你收集整理的app缓存策略探索的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。