用户侧性能指标收集方案

Love The Way You Lie 2022-08-31 01:57 172阅读 0赞

#  #

**有效性能测量的第一条规则是确保性能测量技术本身不会导致性能问题**，因此还是尽可能利用浏览器支持的性能收集指标的api，但常规 `performance` 定义好的一些api基本是适用于首屏性能优化的，因此需要利用自定义指标api统计结合业务统计收集数据

## 前提 ##

*  需要通过 `PerformanceObserver.supportedEntryTypes` 判断是否浏览器支持对应的 `entryType`
 *  所有时间数据都表示从性能测量时刻开始经过的毫秒数

## 1、http请求数据 ##

*  [Resource Timing][]
 *  [PerformanceResourceTiming][]

[Exposed=(Window,Worker)]
    interface PerformanceEntry {
      readonly    attribute DOMString           name;
      readonly    attribute DOMString           entryType;
      readonly    attribute DOMHighResTimeStamp startTime;
      readonly    attribute DOMHighResTimeStamp duration;
      [Default] object toJSON();
    };

[Exposed=(Window,Worker)]
    interface PerformanceResourceTiming : PerformanceEntry {
        readonly attribute DOMString initiatorType;
        readonly attribute ByteString nextHopProtocol;
        readonly attribute DOMHighResTimeStamp workerStart;
        readonly attribute DOMHighResTimeStamp redirectStart;
        readonly attribute DOMHighResTimeStamp redirectEnd;
        readonly attribute DOMHighResTimeStamp fetchStart;
        readonly attribute DOMHighResTimeStamp domainLookupStart;
        readonly attribute DOMHighResTimeStamp domainLookupEnd;
        readonly attribute DOMHighResTimeStamp connectStart;
        readonly attribute DOMHighResTimeStamp connectEnd;
        readonly attribute DOMHighResTimeStamp secureConnectionStart;
        readonly attribute DOMHighResTimeStamp requestStart;
        readonly attribute DOMHighResTimeStamp responseStart;
        readonly attribute DOMHighResTimeStamp responseEnd;
        readonly attribute unsigned long long  transferSize;
        readonly attribute unsigned long long  encodedBodySize;
        readonly attribute unsigned long long  decodedBodySize;
        [Default] object toJSON();
    };

可以通过 `name` 字段区分资源地址, `duration` 字段获取整个 `http` 请求耗时。

ngOnInit() {
            const po = new PerformanceObserver((list) => {
                console.table(list.getEntries())
            });
            po.observe({entryTypes: ['resource'], buffered: true});
        }

![在这里插入图片描述][e35fb8fa1dac0b1cd011eeaf5bef962b.png]

可以同步收集一下用户的带宽，粗略估计用户当前网络情况结合分析

var speed = navigator.connection.downlink * 1024 / 8;

## 2、内存数据 ##

*  [performance.memory][] ：Chrome 添加的一个非标准扩展，这个属性提供了一个可以获取到基本内存使用情况的对象。

{
      jsHeapSizeLimit，
      totalJSHeapSize，
      usedJSHeapSize
    }

*  jsHeapSizeLimit: 内存大小限制
 *  totalJSHeapSize: 可使用的内存
 *  usedJSHeapSize: JS对象(包括V8引擎内部对象)占用的内存，不能大于totalJSHeapSize，如果大于，有可能出现了内存泄漏

![在这里插入图片描述][04d10cd31d14f3d84fe21241b700a2f8.png]

## 3、长任务数据 ##

*  [Long Task Timing][] ：统计执行时间超过50s的长任务,可以自行过滤出指定指标的任务比如：1000s

ngOnInit() {
            const po = new PerformanceObserver((list) => {
                console.table(list.getEntries())
            });
            po.observe({entryTypes: ['longtask'], buffered: true});
        }

这个api不会给出具体任务调用栈，但可以获取任务调用时机，所以如果有充分的的日志信息可以根据时间线来获取对应时机任务信息。

![在这里插入图片描述][57122e00b6e52eaf2c52da2df1d3f7f6.png]

## 4、事件触发数据 ##

*  [Event Timing][]

当用户执行某些操作时，例如单击按钮，主线程可能处于其他操作的中间。动作是排队的，只有当主线程空闲时，它才能处理事件。此 API 提供了事件处理程序的持续时间和自用户交互开始以来的持续时间。

#### demo1 ####

html:

<button onclick="myfunc()" id="mybutton">Click me</button>

js:

假设按钮的事件处理程序myfunc运行了 150 毫秒，输出将是这样的：

PerformanceEventTiming
    	duration: 168
    	entryType: "event"
    	name: "click"
    	processingEnd: 1731.0949999955483
    	processingStart: 1580.664999986766
    	startTime: 1577.709999983199
    	target: button#mybutton
     
    duration: 168 handlersDuration: 150.43000000878237 Target Id: mybutton

#### demo2 ####

ngOnInit() {
            const po = new PerformanceObserver((list) => {
                console.table(list.getEntries())
            });
            po.observe({entryTypes: ['event'], buffered: true});
        }

![在这里插入图片描述][626d8953be69cc1ccd06501914e598ed.png]

除了可以获取事件相关数据之外，还可以结合 `longtask` 分析一些用户行为，可以知道长任务的触发时间，可以知道事件触发的时间，两者相结合的话，也就有了上文提到的所谓’时间线’，大概能够分析出触发长任务的事件行为进而可以分析出消耗性能的代码位置。

## 5、自定义统计数据 ##

*  [User Timing][]

dictionary PerformanceMarkOptions {
        any detail;
        DOMHighResTimeStamp startTime;
    };
    
    dictionary PerformanceMeasureOptions {
        any detail;
        (DOMString or DOMHighResTimeStamp) start;
        DOMHighResTimeStamp duration;
        (DOMString or DOMHighResTimeStamp) end;
    };
    
    partial interface Performance {
        PerformanceMark mark(DOMString markName, optional PerformanceMarkOptions markOptions = {});
        undefined clearMarks(optional DOMString markName);
        PerformanceMeasure measure(DOMString measureName, optional (DOMString or PerformanceMeasureOptions) startOrMeasureOptions = {}, optional DOMString endMark);
        undefined clearMeasures(optional DOMString measureName);
    };

利用 `performance.mark()` 打标记，`performance.measure()` 可以分析两个标记之间的时间差，用来测量某些时间消耗指标,用完的 `mark` 和 `measure` 可以通过 `performance.clearMarks()` 、`performance.clearMeasures()` clear 掉。

function run() {
        performance.mark("startTask1");
        console.log(1); // Some developer code
        performance.mark("endTask1");
    
        performance.measure('task1', "startTask1", "endTask1")
      
        // Log them out
        const entries = performance.getEntriesByType("measure");
        const result = entries.filter(entry => entry.name === 'task1')
        console.table(result);
    
        performance.clearMarks();
        performance.clearMeasures();
    }
      run();

![图片: /uploader/f/XZpN6kZ3s0Wt3rSP.png][_uploader_f_XZpN6kZ3s0Wt3rSP.png]

## 6、performance profile ##

从某种意义上说，可以查看某种时间线视图，显示所有被调用的调用堆栈及其持续时间。类似于 `Chrome DevTools` 中的性能视图(不过多介绍了）  
[https://github.com/WICG/js-self-profiling][https_github.com_WICG_js-self-profiling]

**当然，这个还属于一个提案，现有浏览器不支持**

## last ##

结合以上前五点数据指标可基本定位到造成卡顿的代码所在，在具体定位的话可以在研发侧结合`devtool performance`来准确定位

## 参考 ##

*  [User-centric performance metrics][]
 *  [Custom metrics][]
 *  [New browser APIs to detect JavaScript performance problems in production][]
 *  [前端性能优化指南\[6\]–Web 性能标准][6_Web]

[Resource Timing]: https://w3c.github.io/resource-timing/#introduction
[PerformanceResourceTiming]: https://w3c.github.io/resource-timing/#dom-performanceresourcetiming
[e35fb8fa1dac0b1cd011eeaf5bef962b.png]: /images/20220829/94216404666a46e481c01fc75d8dc6bb.png
[performance.memory]: https://developer.mozilla.org/zh-CN/docs/Web/API/Performance/memory
[04d10cd31d14f3d84fe21241b700a2f8.png]: /images/20220829/895233bffe384a46a8d91078fddc4397.png
[Long Task Timing]: https://w3c.github.io/longtasks/#report-long-tasks
[57122e00b6e52eaf2c52da2df1d3f7f6.png]: /images/20220829/ef44ad15c60045cf96f0f7e1f741c56b.png
[Event Timing]: https://wicg.github.io/event-timing/
[626d8953be69cc1ccd06501914e598ed.png]: /images/20220829/d834aa1491414e35a54a1a3cc83904ed.png
[User Timing]: https://w3c.github.io/user-timing/#introduction
[_uploader_f_XZpN6kZ3s0Wt3rSP.png]: /images/20220829/39b811ddaafa469b896d7258bd918608.png
[https_github.com_WICG_js-self-profiling]: https://github.com/WICG/js-self-profiling
[User-centric performance metrics]: https://web.dev/user-centric-performance-metrics/
[Custom metrics]: https://web.dev/custom-metrics/
[New browser APIs to detect JavaScript performance problems in production]: https://michaelscodingspot.com/javascript-performance-apis/
[6_Web]: https://juejin.cn/post/6844904152317820935