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的時候也能夠先使用舊的數據展現列表，而後乘機更新。固然詳情也和過時下架的產品仍是要即時的排除掉的。

連接地址