最近使用RN做APP，時間長了總是覺得接口請求是在太頻繁。遂想到，不如給接口做個緩存吧。

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

服務器接口緩存

最開始的時候只是希望減輕服務器壓力，減少不必要的計算過程。比如用戶數據沒變化的時候就不需要去計算用戶的各種數據，直接使用緩存就好了。

這里將服務器的接口返回數據根據策略緩存在redis中，然后根據上次更新之后的時間戳來判斷是否需要重新計算緩存中的數據。

有人可能開始質疑。這個數據本來就是放在緩存中的，尤其是用戶數據，根本不可能實時去計算。這里稍微說一下這個方案的背景。

后端計算和更新的數據其實已經存在在redis中了，但是在業務比較復雜的情況下，有些數據其實還是需要去獲取的。這里的緩存其實類似于一個http的緩存。它的本意只是為了緩存最終接口需要返回的數據。這里使用redis去存儲本來只是一個過度方案。打算使用這個方案的同學可以去關注一下varnish，這個才是真正的http緩存。

使用APP緩存

這個階段其實才開始算真正的緩存。

APP端會把第一次從接口獲取到的數據緩存在本地，并且返回接口的時間戳。當下一次請求的時候直接帶上這個時間戳去請求。

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

這樣有很多好處：

減少不必要的計算

關鍵時刻可以立馬更新接口數據，甚至可以灰度更新某些地區的、ip的用戶緩存

不返回大塊的數據，加速了請求速度

如果遇到網絡錯誤，可以直接使用緩存的信息。相當于離線APP

使用接口hash

將接口返回的數據看過一段固定的字符串，每次都計算字符串的hash值。這樣可以更加方便的判斷接口返回數據是否需要更新。

在上一步的策略中，接口返回的數據根據時間戳其實是根據接口更新的時間來定的。加入接口更新了，但是數據并沒有變化，這個時候就會產生一次額外的請求。用戶多的時候也是一個非常流量的操作。

如果使用hash來判斷接口是否需要更新，這樣就可以直接免去了這種無用的更新操作。相比上一個版本更加的高效。不過服務端計算hash讓整個項目的復雜度又高了不少。這個就要考慮這樣做是否值得了。

如果原有的更新策略已經完成了。比如刷新redis的策略已經做完了。其實這個時候將redis中的數據做一次hash也不費事，這樣也可以非常簡單的將緩存策略升級。

使用APP過期策略

這里再提出一個更加激進的策略。假如某些接口的更新速度非常慢，我叫這些接口靜態接口。那么每次的304請求是不是非常多余？

這里就將這種接口設置一個固定的過期時間。在這個過期時間內，每次請求接口都會使用本地緩存，直到過期之后采取請求遠程接口。

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

在所有接口之后，在新增一個本地緩存策略接口。將上述幾個接口的狀態放在這里。每次都請求后端接口，讓后端來判斷這個接口是否需要更新。比如：請求hash，如果需要更新就返回最新狀態，不需要更新就不返回數據。

其他的靜態接口在請求之前都會使用這個狀態比較一次。如果需要更新就發請求，不需要更新就使用本地緩存。這樣就完美的解決了接口緩存的問題。從一個每次都要請求接口變成了部分接口快速返回304，部分接口不請求。

---

RN開發的APP可以非常快的發布版本（熱更新），同時開發的時候由于js的原因也會非常的靈活。這個時候使用上面的緩存策略會更加簡單方便。

通過上述幾個策略就可以減少非常多的無用請求。比如后端的熱配置信息，很多時候其實沒有改動，完全可以使用靜態接口的策略。

進入APP的時候也可以先使用舊的數據展示列表，然后伺機更新。當然詳情也和過期下架的產品還是要即時的排除掉的。

鏈接地址

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。