最近使用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的時候也可以先使用舊的資料展示列表，然後伺機更新。當然詳情也和過期下架的產品還是要即時的排除掉的。