我在公司整前端监控（二）

上一章主要讲了前端监控的三个方向，本章继续。上一章有个遗留问题，为什么用navigator.sendBeacon去发送数据？这就涉及到如何上报数据的问题，下面我具体讲下。

一、五种数据上报的形式

XMLHttpRequest：经典的 AJAX 请求方式，用于发送数据到服务器。可以配置为同步或异步请求，但在页面卸载时可能不可靠。
Fetch API ：现代浏览器中推荐的方式，用于发送网络请求。相比XMLHttpRequest，它提供了更简洁的语法，但在页面卸载时仍可能会被中断。
Navigator.sendBeacon ：专门用于在页面卸载时发送数据的 API。sendBeacon是非阻塞的，确保数据在页面关闭时也能可靠地发送。
Image Ping ：通过动态创建图像对象并设置其src属性来发送 GET 请求。这种方法常用于简单的数据上报，不会受到跨域限制，但只能发送少量数据。
WebSocket：用于建立持久连接，实现双向通信。适合需要实时数据传输的场景，但对于简单的数据上报来说可能过于复杂。

一共有5种形式上报，我来分析下各有什么优劣势：

其中可以XMLHttpRequest和Fetch没有什么太大本质的区别属于一类，他们都是比较常规的上报形式，但是他有个致命问题可能会被中断，导致数据丢失，特别在页面跳出的情况，还有就是在请求里面优先级高，在页面加载的前期当有大量的上报的时候会阻塞页面的请求看下图：

Image Ping图片上报，在跨域和调用方式上比较好，但是有个致命的缺点数据量带不多。
WebSocket我见过的很少，可能在某些场景用的多，但是我很少见到
Navigator.sendBeacon专为页面卸载设计，确保数据在页面关闭时发送。非阻塞：不会影响页面卸载速度。在上图里面的优先级属于低，使用简单，但是有个问题，兼容性有点问题，可以配合fetch使用。他不会应为页面切换丢数据，调用起来非常方便。

二、上报时机

数据上报的形式可以从不同的角度来分类和理解。一般来说，数据上报主要有以下几种形式：

实时上报：

- 数据在产生后立即发送到服务器。这种方式确保数据的实时性，适用于需要即时分析和处理的场景。

批量上报：

- 数据在客户端累积到一定数量或满足特定条件后，再一次性发送到服务器。这种方式可以减少网络请求次数，适用于对时效性要求不高的场景。

定时上报：

- 客户端在固定的时间间隔内发送数据到服务器。这种方式可以平衡实时性和网络资源的消耗。

页面卸载上报：

- 在页面关闭或卸载时发送数据，通常使用sendBeaconAPI。这种方式确保在用户离开页面时也能可靠地将数据发送到服务器。

事件驱动上报：

- 基于特定事件触发数据上报，例如用户点击按钮、表单提交等。这种方式适用于需要对特定用户行为进行监控的场景。

一共有5种形式时机，我来分析下各有什么优劣势：

实时上报：

- 优点：

- - 实时性：数据在产生后立即发送，适合需要即时分析的场景。
  - 准确性：可以立即捕捉用户行为，减少数据丢失的风险。

- 缺点：

- - 网络开销：频繁发送请求可能增加网络负担。
  - 服务器压力：需要服务器能够处理高频率的数据请求。

批量上报：

- 优点：

- - 减少请求次数：通过合并多条数据减少网络请求。
  - 提高效率：降低网络和服务器的负担。

- 缺点：

- - 时效性：数据不是实时发送，可能导致分析滞后。
  - 数据丢失风险：如果客户端崩溃或断网，未发送的数据可能丢失。

定时上报：

- 优点：

- - 平衡实时性和效率：通过定时发送，减少频繁请求。
  - 可控性：可以根据需求调整上报频率。

- 缺点：

- - 复杂性：需要实现定时器逻辑。
  - 数据可能不够实时：与实时上报相比，数据可能有延迟。

页面卸载上报：

- 优点：

- - 可靠性：利用sendBeacon确保数据在页面关闭时发送。
  - 简单性：不需要复杂的逻辑，只需在页面卸载时触发。

- 缺点：

- - 数据量限制：通常只能发送较小的数据量。
  - 依赖浏览器支持：如果浏览器不支持sendBeacon，需要备用方案。

事件驱动上报：

- 优点：

- - 精确性：针对特定用户行为进行上报，适合精准分析。
  - 灵活性：可以根据业务需求定制上报逻辑。

- 缺点：

- - 复杂性：需要为每个事件设置监听器和上报逻辑。
  - 潜在的性能问题：过多的事件监听可能影响页面性能。

看你业务需要那种形式，去评估那种形式上报。

我来总结下我在狗东遇到的几种情况：狗东H5目前用的最多的就是第一种，但是在客户端里面是批量，我理解客户端的形式是最好的，H5的页面如果在端里面可以借助端的能力去实现批量上报。我们也可以在h5里面页面卸载的时候去上报，我自己测试过好像有一些兼容问题，最后还是放弃了用的实时上报。

三、最后来个小问题，如何对你的页面程序方法运行时间进行监控？

页面程序方法的运行时间进行监控是性能优化的重要一环，可以帮助识别性能瓶颈和优化点。以下是一些常用的方法来监控方法的运行时间：

使用 console.time和 console.timeEnd：

- 这是最简单的方法之一，适用于开发和调试阶段。
- 使用console.time('label')开始计时，console.timeEnd('label')结束计时，并在控制台输出运行时间。

js 复制代码

console.time('myFunction');myFunction();console.timeEnd('myFunction');

使用 performance.now() ：

- performance.now()提供高精度的时间戳，可以用于精确测量函数的执行时间。

js 复制代码

const start = performance.now();myFunction();const end = performance.now();console.log(`myFunction took ${end - start} milliseconds`);

使用 PerformanceAPI：

- 浏览器的PerformanceAPI 提供了更全面的性能测量工具，可以记录和分析多个时间点。
- 可以使用performance.mark()和performance.measure()来标记和测量代码片段。

js 复制代码

performance.mark('start');myFunction();
performance.mark('end');
performance.measure('myFunction', 'start', 'end');const measures = performance.getEntriesByName('myFunction');console.log(measures[0].duration);

使用第三方库：

- 有一些第三方库可以帮助监控和分析性能，如stats.js或New Relic等。
- 这些工具通常提供更详细的性能分析和报告功能。

自定义监控工具：

- 如果需要更复杂的监控，可以编写自定义的监控工具，结合performance.now()和日志记录，将数据发送到服务器进行分析。

目前用的比较多的是performance.mark() 因为他是用的比new date 提供高精度的时间戳，具体的可以自己去查文档，我懒得讲performance.mark()是 Web Performance API 提供的一个方法，用于在浏览器的性能时间线上创建一个标记。这个标记可以帮助开发者测量特定代码段的执行时间，尤其是在需要精确测量性能的复杂应用中。

用法

创建标记 ：使用performance.mark(name)来创建一个标记，其中name是一个字符串，用于标识这个标记。例如：

js 复制代码

performance.mark('start');// 执行一些代码
performance.mark('end');

测量时间 ：使用performance.measure(name, startMark, endMark)方法来测量两个标记之间的时间间隔。name是测量的名称，startMark和endMark是之前创建的标记。例如：

js 复制代码

performance.measure('myMeasure', 'start', 'end');

获取测量结果 ：使用performance.getEntriesByName(name)来获取测量结果。这个方法返回一个数组，其中包含所有与指定名称匹配的测量结果。例如：

js 复制代码

const measures = performance.getEntriesByName('myMeasure');
measures.forEach((measure) => {
    console.log(`${measure.name}: ${measure.duration}ms`);
});

我以前用过一个蠢方法就是用mark形式对接口进行打点监控，其实前面见过用资源监控就能完成，后面我为了精准的监控页面真实的渲染时间，用过mack在页面渲染完成的时间点去打mark，后面发现有lcp后放弃，但是我认为在有些特殊场景还是能用上，特别在性能优化到后期实在找不到优化点的时候可以对具体的某些方法进行监控优化。

总结：

讲完了监控基础理论知识，具体怎么去写一套前端监控等哪天我有时间我再继续写