1、客戶端做緩存的目的：
解決弱網條件下的加載速度問題。
2、緩存的原理：
緩存接口數據，在一些數據新舊敏感性不高的場景下很有用，在非首次加載數據時候優先使用上次請求來的緩存數據，可以讓頁面更加快速地渲染出來，而不用等待一個新的HTTP請求結束之后再渲染。
3、資源離線：
- 再快的網絡交互，畢竟也是跨越了數個網絡節點，因此一張圖片、一個js，優化到了極致，也照樣可能需要幾百毫秒的時間來獲得。因此想要打破這個極限，就要使用資源離線的策略。
- 在釘釘的微應用中，就使用了這樣的一個“離線包”策略。一些固定的圖片、js庫等，被打包放入app中（或根據需要，在app啟動的時候進行下載更新）。
- 微應用中，網頁代碼里面加載網絡資源的需求，就變成了直接加載本地文件，速度自然得到再一次巨大的提升。
4、數據緩存，頁面渲染流程圖：
首次進入頁面，流程如下：
而非首次進入界面，流程如下：
可以看出，在非首次進入界面的時候，頁面不需要等待網絡數據返回，就可以進行界面渲染，渲染的初始數據來自於本地的緩存，頁面可以“秒開”。而當服務端的數據返回之后，本地的渲染會再次更新，緩存也被更新。
采用這樣的方案有利有弊，好處顯而易見，首屏加載的速度簡直太快了——靜態資源來自本地，數據接口來自本地，這在2G、3G或者其他網絡速度較慢的時候，也可以讓用戶在極短的時間內就看到內容。但是這種方案也並非萬能。
首次加載不可避免，還是會請求網絡。
服務端有更新的時候，客戶端不能夠快速感知，頁面可能還停留在一個“舊的版本”上，尤其是網絡速度較慢時，可能還是需要經過好幾秒，頁面才會更新至最新版本。因此如果應用對數據的新舊很敏感的話，這種方案就不適合
數據更新后，需要重新渲染界面，界面刷新的性能消耗比正常情況更多，而且增加了程序的復雜度，容易出錯。
5、可緩存的情況示例如下：
（1）靜態類加載數據一般會做緩存，示例：列表數據等
（2）不適合做緩存的功能，示例：表單，因數據一直在變動，不適合
本地緩存分為：緩存數據到內存 和 CPU，重要的需要及時查看的數據一般會放在CPU中，不及時查看的數據且大部分數據會存放在內存中。
測試方案：
- 弱網絡下loading提示，是否有超時機制
- 無網狀態的測試（斷網功能測試、本地數據存儲），再次開啟網絡，進入頁面，查看是否緩存了無數據的頁面。
- 網絡切換測試（無網到多網狀態的切換）
- 接口數據異常提示
緩存的相關知識介紹：
緩存的優缺點總結：https://www.cnblogs.com/syw20170419/p/9846215.html
緩存的本質、優化手段等：https://www.cnblogs.com/syw20170419/p/11641763.html