客戶端的緩存策略與測試方案

一、客戶端作緩存的目的：

　　解決弱網條件下的加載速度問題。

 

二、緩存的原理：

　　緩存接口數據，在一些數據新舊敏感性不高的場景下頗有用，在非首次加載數據時候優先使用上次請求來的緩存數據，可讓頁面更加快速地渲染出來，而不用等待一個新的HTTP請求結束以後再渲染。 

 

三、資源離線：

• 　　再快的網絡交互，畢竟也是跨越了數個網絡節點，所以一張圖片、一個js，優化到了極致，也照樣可能須要幾百毫秒的時間來得到。所以想要打破這個極限，就要使用資源離線的策略。
• 　　在釘釘的微應用中，就使用了這樣的一個「離線包」策略。一些固定的圖片、js庫等，被打包放入app中（或根據須要，在app啓動的時候進行下載更新）。
• 　　微應用中，網頁代碼裏面加載網絡資源的需求，就變成了直接加載本地文件，速度天然獲得再一次巨大的提高。

 

四、數據緩存，頁面渲染流程圖：

　　首次進入頁面，流程以下：

           

 

 　　而非首次進入界面，流程以下：

　　　　

 

 

       能夠看出，在非首次進入界面的時候，頁面不須要等待網絡數據返回，就能夠進行界面渲染，渲染的初始數據來自於本地的緩存，頁面能夠「秒開」。而當服務端的數據返回以後，本地的渲染會再次更新，緩存也被更新。

       採用這樣的方案有利有弊，好處顯而易見，首屏加載的速度簡直太快了——靜態資源來自本地，數據接口來自本地，這在2G、3G或者其餘網絡速度較慢的時候，也可讓用戶在極短的時間內就看到內容。可是這種方案也並不是萬能。

       首次加載不可避免，仍是會請求網絡。

       服務端有更新的時候，客戶端不可以快速感知，頁面可能還停留在一個「舊的版本」上，尤爲是網絡速度較慢時，可能仍是須要通過好幾秒，頁面纔會更新至最新版本。所以若是應用對數據的新舊很敏感的話，這種方案就不適合

      數據更新後，須要從新渲染界面，界面刷新的性能消耗比正常狀況更多，並且增長了程序的複雜度，容易出錯。

 

五、可緩存的狀況示例以下：

　　（1）靜態類加載數據通常會作緩存，示例：列表數據等

　　（2）不適合作緩存的功能，示例：表單，因數據一直在變更，不適合

 

本地緩存分爲：緩存數據到內存 和 CPU，重要的須要及時查看的數據通常會放在CPU中，不及時查看的數據且大部分數據會存放在內存中。

 

測試方案：

• 弱網絡下loading提示，是否有超時機制
• 無網狀態的測試（斷網功能測試、本地數據存儲），再次開啓網絡，進入頁面，查看是否緩存了無數據的頁面。
• 網絡切換測試（無網到多網狀態的切換）
• 接口數據異常提示

 

緩存的相關知識介紹：

緩存的優缺點總結：http://www.javashuo.com/article/p-uscghfpi-co.html

緩存的本質、優化手段等：http://www.javashuo.com/article/p-tlcjrdqk-ca.html