早上收到比较重要的用户反馈说某个重要的系统的页面在 IE 浏览器中卡死,无法继续。

问题很严重。
系统比较特殊复杂,不是一般人能登录进去的。找到对应同学在小概率重现的情况下终于拿到了第一手的问题源码。
修改配置和采样率之后在本地跑起来,发现在 IE6 里非常有问题。
性能这么大的问题,首先想到的是页面中大面积扫描 HTML 代码的部分,但是注释掉这部分仍然没有改善。
再次把整个回调处理函数注释掉,仍然没有改善。
直接把加载后置脚本的 seajs.use 注释掉之后,终于没问题了。(坑爹的缓存问题就不说了,好久之后才发现,都是泪~)
这么看来有两种可能:
模块本身有性能问题。
seajs 性能有问题(这个问题页面目前使用的 1.3.1)
首先考虑自身的问题。return 整个 factory,性能无问题,因此不是模块过多导致 seajs 性能问题。
逐步修改 return 位置(其实可以打断点),终于发现问题出在 初始化事件绑定函数部分。
此时 \nevents = undefined。访问 undefined.length 或其他属性会导致浏览器挂起? IE6 还有这样的坑?
新建一个最小代码的新页面,直接 script[src] 引入这个脚本没有问题,IE 会正常的抛出异常,不会挂起。
动态创建 script 插入脚本,仍然不会挂起,正常抛出异常。
奇怪。各种尝试,最终加入前置脚本后在这个最小重现代码中重现了异常。
然后发现是在 window.onerror 中出现问题。
继续发现的模拟调用栈信息的算法出现问题。
cmd 模块在 define 的 factory 中本身抛出异常,会被前置脚本的 window.onerror 捕获,捕获过程中尝试 还原函数调用栈。模拟还原调用栈信息是通过 arguments.callee.caller 向上递归,直到找到函数调用的发起者。但是悲剧的是发现 seajs 这个调用栈是无穷无尽的:
这也就是为什么用户的浏览器会挂起的原因。
\n\n\n\n
用户浏览器被挂起,最终发现:
\n 不是扫描整个文档的性能问题。 \n 不是 seajs 加载多个模块的性能问题。 \n 主要不是 cmd define 中报错的问题。 \n 不是 window.onerror 捕获异常的问题。 \n 而是获取异常函数调用栈出现无限循环链的问题, \n 这其实是 IE 的问题。 \n 好吧,最终还是我的问题。
monitor 2.2.0 新增了 事件机制,支持监控任意的自定义数据。
其中在前置脚本中新增了 monitor.on() 方法,将自定义事件处理函数临时存储在 monitor.\nEVENTS 属性中 参考代码 。后置脚本加载完成后,会复写 monitor.on() 方法,并将之前用户自定义事件处理函数绑定到对应事件,以使事件机制生效。
这些理论上都是非常不错的设计思路。
但是现实太残酷,全站公共区域被实际部署的情况有太复杂:
后置脚本对于后面的这个场景没有考虑到,因此这段保险栓未能正确执行导致后续脚本报错。
都是我的错,没有考虑周全。没有考虑到这种特殊的系统部署环境,而且我也从来不能进去实际体验、验证。
这是 seajs 1.3.1 的 BUG,更准确的说,可能是 IE6,7,8闭包的问题。参考: https://github.com/seajs/seajs/issues/911