发送请求的传送机制优化--浏览器细节深究（2）

背景

首先介绍一下我们项目的架构：

可以看到我们的平台分为四个部分：1. 监控中台 2. npm 包 3. 产生错误 & 性能信息的页面 4. 后端

首先我们需要知道，我们想要使用 npm 包，其实就是把 npm 包植入 "产生错误 & 性能信息的页面"，那么我们传递信息的过程本身，就会给"产生错误 & 性能信息的页面"带来相当大的负担，那么我们需要去做一个优化，怎么去做呢？

最开始我们使用的是轮询策略，那么这种行为必然带来问题------"持续不断的请求拖垮页面性能。"

然后我们就开始了优化的思路，第一个方面是优化轮询，轮询本身的逻辑在于产生一个请求就往后端发送，而我们优化的思路在于合并这些发送的请求。

这里使用的东西主要有两个------------localStorage + 队列。

我们这里有两个核心的判断逻辑，第一个核心逻辑：当队列的长度 >= 20 的时候，我们就把队列清空，也就是把我们的值传递到后端去；第二个核心逻辑：每过一秒钟，如果队列不为空，我们进行一次倾倒，也就是把队列中的值发送到后端去。

那么这里还有一些考量：

首先是 indexDB 的写法过于复杂了，而它带来的好处是什么呢？主要是容量很大很大。但是我们需要这么大的容量吗？显然不需要，因为我们队列在超过 20 个之后会进行清空操作，所以没有必要花时间精力去写 indexDB。
另一方面 localStorage 的 5MB 已经够用了。
cookie 4kb 的容量就更不用说了。

但是这里仍然存在一个问题，那就是 1s 中间也可能无法传递信息。

举个例子，用户在某个一秒的中间关闭了浏览器，导致存在队列里的信息无法发送给后端，我们这时候该怎么处理？

那么我们这个时候就要拿出之前用的一个 API------Navigator.sendBeacon，它可以在浏览器卸载的时候发送请求给后端，从而把没来得及发出去的数据传给后端。

下篇文章会仔细的介绍一下这个"浏览器卸载"到底是啥时候～

那么这就是本篇文章的所有内容啦，可以留个赞再走莫～