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

Bertha 。 2023-08-17 17:30 99阅读 0赞

1、客户端做缓存的目的：

解决弱网条件下的加载速度问题。

2、缓存的原理：

缓存接口数据，在一些数据新旧敏感性不高的场景下很有用，在非首次加载数据时候优先使用上次请求来的缓存数据，可以让页面更加快速地渲染出来，而不用等待一个新的HTTP请求结束之后再渲染。

3、资源离线：

*  　　再快的网络交互，毕竟也是跨越了数个网络节点，因此一张图片、一个js，优化到了极致，也照样可能需要几百毫秒的时间来获得。因此想要打破这个极限，就要使用资源离线的策略。
 *  　　在钉钉的微应用中，就使用了这样的一个“离线包”策略。一些固定的图片、js库等，被打包放入app中（或根据需要，在app启动的时候进行下载更新）。
 *  　　微应用中，网页代码里面加载网络资源的需求，就变成了直接加载本地文件，速度自然得到再一次巨大的提升。

4、数据缓存，页面渲染流程图：

首次进入页面，流程如下：

![1150129-20190912153707392-1997885938.png][]

而非首次进入界面，流程如下：

![1150129-20190912153833091-1666312652.png][]

可以看出，在非首次进入界面的时候，页面不需要等待网络数据返回，就可以进行界面渲染，渲染的初始数据来自于本地的缓存，页面可以“秒开”。而当服务端的数据返回之后，本地的渲染会再次更新，缓存也被更新。

采用这样的方案有利有弊，好处显而易见，首屏加载的速度简直太快了——静态资源来自本地，数据接口来自本地，这在2G、3G或者其他网络速度较慢的时候，也可以让用户在极短的时间内就看到内容。但是这种方案也并非万能。

首次加载不可避免，还是会请求网络。

服务端有更新的时候，客户端不能够快速感知，页面可能还停留在一个“旧的版本”上，尤其是网络速度较慢时，可能还是需要经过好几秒，页面才会更新至最新版本。因此如果应用对数据的新旧很敏感的话，这种方案就不适合

数据更新后，需要重新渲染界面，界面刷新的性能消耗比正常情况更多，而且增加了程序的复杂度，容易出错。

5、可缓存的情况示例如下：

（1）静态类加载数据一般会做缓存，示例：列表数据等

（2）不适合做缓存的功能，示例：表单，因数据一直在变动，不适合

本地缓存分为：缓存数据到内存 和 CPU，重要的需要及时查看的数据一般会放在CPU中，不及时查看的数据且大部分数据会存放在内存中。

测试方案：

*  弱网络下loading提示，是否有超时机制
 *  无网状态的测试（断网功能测试、本地数据存储），再次开启网络，进入页面，查看是否缓存了无数据的页面。
 *  网络切换测试（无网到多网状态的切换）
 *  接口数据异常提示

转载于:https://www.cnblogs.com/syw20170419/p/11498048.html

[1150129-20190912153707392-1997885938.png]: /images/20230808/27ba3224db884c79bee8820d46355db3.png
[1150129-20190912153833091-1666312652.png]: /images/20230808/f18df7cfaafe4fa08695a0188a243435.png