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

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