前端监控｜埋点
为什么有前端监控？
用户体验直接决定用户留存，然而总多的体验问题如页面加载慢、白屏、请求交互速度等，单靠用户反馈并不现实
统计这些数据是有意义的，比如我们知道了用户来源的渠道，可以促进产品的推广，知道用户在每一个页面停留的时间，可以针对停留较长的页面，增加广告推送等等，可以根据用户浏览量重点去关注哪些页面或者功能的实现，之后的开发流程可以分配相应的人力去对这方面的功能和代码进行优化，节省公司的人力物力，一些很少访问的功能，一年也用不到几次的就没必要耗费精力。产出并不是看你写了几千行代码，要看的是产出，要拿出数据，可以根据监控得到这部分的功能做优化后的用户增长量、用户停留时间、给公司带来的收益，拿出这些数据比写几千行代码来的实际，把时间花在刀刃上，在公司需求太多，而很多是一些没必要的需求，一年也用不到几次那种，可以根据监控统计数据来和产品运营battle。
什么是前端监控
前端监控一般也分为三大类：
用户行为监控
- PV/UV: PV(page view)：即页面访问次数；UV：页面访问人数(即不同ip地址)
- 用户在每一个页面的停留时间
- 用户通过什么入口来访问该网页
- 用户在相应的页面中的点击操作，等...
统计这些数据是有意义的，比如我们知道了用户来源的渠道，可以促进产品的推广，知道用户在每一个页面停留的时间，可以针对停留较长的页面，增加广告推送等等，可以根据用户浏览量重点去关注哪些页面或者功能的实现，之后的开发流程可以分配相应的人力去对这方面的功能和代码进行优化，节省公司的人力物力，一些很少访问的功能，一年也用不到几次的就没必要耗费精力。产出并不是看你写了几千行代码，要看的是产出，要拿出数据，可以根据监控得到这部分的功能做优化后的用户增长量、用户停留时间、给公司带来的收益，拿出这些数据比写几千行代码来的实际，把时间花在刀刃上，在公司需求太多，而很多是一些没必要的需求，一年也用不到几次那种，可以根据监控统计数据来和产品运营battle。
页面性能监控
- 不同机型和不同系统下的首屏加载时间
- 白屏时长
- http 等请求的响应时间
- 静态资源整体下载时间
- 页面渲染时间
可以展示前端性能的好坏，根据性能监测的结果可以进一步的去优化前端性能，尽可能的提高用户体验。
异常监控
- Javascript 的异常监控
- 资源加载的异常监控
- http异常：axios请求异常
- promise异常
前端埋点方案
前端埋点方法分为三种：手动埋点、可视化埋点和无痕埋点
(1) 手动埋点
以嵌入代码的形式进行埋点，比如需要监控用户的点击事件，会选择在用户点击时，插入一段代码，将监听行为以某一种数据格式直接传递给server端。
(2)可视化埋点
将业务代码和埋点代码分离，提供一个可视化交互的页面，输入为业务代码，通过这个可视化系统，可以在业务代码中自定义的增加埋点事件等等，最后输出的代码耦合了业务代码和埋点代码。
可视化埋点听起来比较高大上，实际上跟代码埋点还是区别不大。也就是用一个系统来实现手动插入代码埋点的过程。这种埋点方式由于自带技术壁垒，所以开发人员基本基本不用考虑，花钱即可。
(3)无埋点
无埋点并不是不需要埋点，而是前端自动采集全部事件，上报埋点数据，由后端来过滤和计算出有用的数据。优点是前端只要一次加载埋点脚本，缺点是流量和采集的数据过于庞大，服务器性能压力山大。
数据发送（上报错误信息）
当SDK拿到错误的所有信息时需要上报到服务端，有几种方式
1、通过xhr上报
通过xhr上报，如果设置成异步的时候，当用户跳转新页面或者关闭页面时就会丢失当前这个请求，如果设置成同步，又会让页面造成卡顿的现象
2、Image的形式来发送请求
通常请求的这个url会是一张1X1px的GIF图片，使用gif有以下原因：
- 防止跨域问题
- 发 GET 请求之后不需要获取和处理数据
- 不会阻塞页面加载，影响用户的体验，因为new Image对象就能发起请求，不会插入dom，不会阻塞页面的渲染
- GIF相比于 BMP/PNG 体积最小
3、Navigator.sendBeacon （更优雅，elegant）
这种打点标记的方式被称web beacon（网络信标）
特点：（相比较于图片img）
- 不会和主要业务代码抢占资源，而是在浏览器空闲时去做发送；
- 并且在页面卸载时也能保证请求成功发送，不阻塞页面刷新和跳转；
- 兼容性不是很友好，可用gif兜底
用户唯一标识
为了方便统计用户量，在每次上报的时候会带一个唯一标识符trackerId，生成这个trackerId的途径有两种：
如果你是用ajax上报的话，发现cookie中没有带trackerId这个字段，服务端生成并setCookie设置到用户端的cookie
直接用SDK生成，在每次上报之前都判断localstorage是否存在trackerId，有则随着错误信息一起发送，没有的话生成一个并设置到localstorage
下面我们采用的是手动埋点方案：
SDK的设计
性能相关的公式：
DNS 解析耗时: domainLookupEnd - domainLookupStart
TCP 连接耗时: connectEnd - connectStart
SSL 安全连接耗时: connectEnd - secureConnectionStart
网络请求耗时 (TTFB): responseStart - requestStart
数据传输耗时: responseEnd - responseStart
DOM 解析耗时: domInteractive - responseEnd
资源加载耗时: loadEventStart - domContentLoadedEventEnd
First Byte时间: responseStart - domainLookupStart
白屏时间: responseEnd - fetchStart
首次可交互时间: domInteractive - fetchStart
DOM Ready 时间: domContentLoadEventEnd - fetchStart
页面完全加载时间: loadEventStart - fetchStart
http 头部大小： transferSize - encodedBodySize
重定向次数：performance.navigation.redirectCount
重定向耗时: redirectEnd - redirectStart
周会：
3个流程 ： 1、说一下这周自己的工作内容吧 2、项目如何开展，即每个人可以提出一些建议。
我这周干嘛了：
首先前端监控这一部分，我的理论知识是欠缺的，了解的也不多，大家应该跟我也差不多，所以这周我就整体的学习和整理了下这方面的知识，然后我把关于前端监控的学习资料补充到文档里面，你们后续找到一些干货可以补充进来。 我整理的资料在后面会详细讲一下，
代码写，http的监控怎么实现：思路是劫持xmlhttprequest这个东西，然后改写方法，先通过window.xmlhttprequest获取到这个对象，然后对xml上的原型对象上的 xml.open,send方法进行改写，在open方法中改写判断请求是上报到后台系统还是正常的请求，如果是上报的请求就过滤不处理，防止陷入死循环。 劫持是怎么实现的？ 通过this.addeventlistener监听xml实例的load、error事件，在事件监听 的回调中对数据处理（比如发送的延时、持续时间、状态码、请求的类型、相应内容）并发送到到后台系统。后面可以看代码，我写的注释还是比较详细的