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