客户端的缓存策略与测试方案

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