前端性能与异常上报前端性能与异常上报
概述
对于后台开发来说,记录日志是一种非常常见的开发习惯,通常我们会使用 try...catch代码块来主动捕获错误、对于每次接口
调用,也会记录下每次接口调用的时间消耗,以便我们监控服务器接口性能,进行问题排查。
刚进公司时,在进行 Node.js的接口开发时,我不太习惯每次排查问题都要通过跳板机登上服务器看日志,后来慢慢习惯了这
种方式。
举个例子:
以下代码经常会出现在用 Node.js的接口中,在接口中会统计查询 DB所耗时间、亦或是统计 RPC服务调用所耗时间,以便监
测性能瓶颈,对性能做优化;又或是对异常使用 try ... catch主动捕获,以便随时对问题进行回溯、还原问题的场景,进行
bug的修复。
而对于前端来说呢?可以看以下的场景。
最近在进行一个需求开发时,偶尔发现 webgl渲染影像失败的情况,或者说影像会出现解析失败的情况,我们可能根本不知道
哪张影像会解析或渲染失败;又或如最近开发的另外一个需求,我们会做一个关于 webgl渲染时间的优化和影像预加载的需
求,如果缺乏性能监控,该如何统计所做的渲染优化和影像预加载优化的优化比例,如何证明自己所做的事情具有价值呢?可
能是通过测试同学的黑盒测试,对优化前后的时间进行录屏,分析从进入页面到影像渲染完成到底经过了多少帧图像。这样的
数据,可能既不准确、又较为片面,设想测试同学并不是真正的用户,也无法还原真实的用户他们所处的网络环境。回过头来
发现,我们的项目,虽然在服务端层面做好了日志和性能统计,但在前端对异常的监控和性能的统计。对于前端的性能与异常
上报的可行性探索是有必要的。
异常捕获
对于前端来说,我们需要的异常捕获无非为以下两种:
接口调用情况;
页面逻辑是否错误,例如,用户进入页面后页面显示白屏;
对于接口调用情况,在前端通常需要上报客户端相关参数,例如:用户OS与浏览器版本、请求参数(如页面ID);而对于页
面逻辑是否错误问题,通常除了用户OS与浏览器版本外,需要的是报错的堆栈信息及具体报错位置。
异常捕获方法
全局捕获
可以通过全局监听异常来捕获,通过 window.onerror或者 addEventListener,看以下例子:
通过 window.onerror事件,可以得到具体的异常信息、异常文件的URL、异常的行号与列号及异常的堆栈信息,再捕获异常
后,统一上报至我们的日志服务器。
亦或是,通过 window.addEventListener方法来进行异常上报,道理同理: