与IE兼容性纠缠的这几个月(续)

前段时间写了篇博客,简单描述了之前参与的系统中解决IE兼容性问题的一点过程。对于我个人而言,是非常厌恶微软IE789浏览器的,经常和同事开玩笑说,“IE789简直就是阻止人类进步的绊脚石”。我们这个系统从今年3月份正式上线,一直到现在,还在处于天天救火严重bug的状态,这其中包含了所有你能想出来的原因,当然之一就是IE兼容性问题。

当然,不可否认,在解决IE兼容性问题的过程中,确实变相找到一些乐趣。至少比重复写着controller,service,dao,onclick,$().val()来的有意思。加上,这周中,用我上一篇文章中提到的一点,帮助了同事解决了迫在眉睫的问题,觉得还是有意义的。

今天,要得瑟的内容,层面上,要比上一篇更高一个层次,就是性能问题。性能问题,可以说和ie无关,也可以说有关。比如你无端跑了极大量的循环,无论哪个浏览器里,都是不应该的。当然,在chrome里,可能是一瞬间,在ie里,却需要N秒。所以,又是和IE有关。


以下是三个Case:

1. 对HandsonTable单元格赋值

handsonTable是一个国外的开源工具,用来提供仿excel的js表格控件,包括合并单元格等特性,是非常优秀的工具。

我们的系统,打开某个页面的时候,非常慢,在chrome下也需要2秒+的样子,在IE9下需要10秒,IE8下需要14秒+,基本就是不可忍了。于是,我尝试着去解决这个性能问题。首先,当然是使用工具检测一下,在哪些代码上可能存在瓶颈[color=blue]。我选择的是chrome的profiles工具。有些人可能会觉得在chrome下测比较难,因为chrome跑js性能太好。但是,问题代码和正常代码的耗时比例,其实差别不会太大。[/color]我使用IE9的profiles测试过,心里是有底的。而且我在mac的虚拟机里跑一个ie9,加上win7在高分屏下的体验,总之就是不愿意。。

通过profiles对js方法运行时间的统计,通过tree结构的结果列表分析,最终定位于handsontable的一个对单元格赋值的API。

[color=blue]这里要插一句,定位到问题所在的过程,并非一帆风顺。不像自己写的代码,出了异常,能直接定位到某一行的某个变量。前端js里大多数都是第三方库,自己写的出问题的几率很少,很大程度上,是自己没用好第三方库的api,导致问题爆发在第三方库的逻辑中,而这些逻辑往往比较抽象。总之,依靠缩小范围,推理,猜测,动用一切经验和智慧,找出关键点。[/color]

handsontable的这个api,setDataAtCell,很明显是给一个单元格赋值,再看我们使用的逻辑,是个使用了两层for循环给一个表格赋上初始值。当时就明白了,很明显,开发的过程中没想到实际使用时会出现上百列的场景,完全没想到这么多列下,一个一个赋值会慢的这么明显。

解决的办法,我第一反应就是,批量赋值。尽管当时我完全不了解handsontable的api,但是我心里想,肯定有批量赋值的api,不然它就是shit!而且批量赋值的操作在底层一定不会像我们这样循环去做,不然还是shit!打开官网,粗粗扫了一遍api文档,操,没找到…… 然后开始细细地看,忽然发现setDataAtCell方法居然还可以传数组!由于官网文档写的实在太简陋,足足体会了好一会,才认定,一定就是它了。

于是,我把双层for循环改成单层for循环。其实就是,一行一行赋值,而不是一个一个单元格赋值。耗时瞬减!IE下足足快了5秒。

解决完这个问题,感觉还是很良好的,而且解决思路简单,没有副作用。但是下面这个case,就有点麻烦了。

2. jQuery UI的sortable组件

紧跟着上一个case,从原来10s+减少到5s+,已经提升了一倍性能,但是还不够,没有人愿意等5秒钟才打开页面。

我本想说,用ie89的人活该,但是想想他们也是无辜的,因为有些老系统只支持老浏览器,总不能让用户一天到晚切换浏览器吧。这就是个恶心循环!

接着说,依然使用profiles检测,可以看见前面setData部分的代码运行耗时比例已经降低很多,原来可是达到了70%+。此时另一个堆栈挑起了性能慢的大梁。通过tree结构分析,似乎涉及到jQuery UI的代码,但那时不了解代码逻辑,也就不知道为什么慢在jQuery UI上了。主要是我不知道 sortable和dragglable是属于 jQuery UI的,囧。。

忽然想到,console.time()方法,可以测量代码执行时间,于是我在出问题的方法里,切了好几段,分别统计执行时间。运行,很明显,在创建sortable对像的方法上,消耗了大量的时间!问题点找到了,开始读逻辑,才发现原来给上文表格中的每一个单元格,都绑定了一个sortable组件。因为交互逻辑是,可以拖拽一些东西到表格内。

google了一下,全世界都在抱怨sortable组件创建时的消耗大。当时一想,坏了,要是设计就必须放这个组件,就不能随意砍掉,而且几乎没有优化余地啊。

此时,走了一个弯路,由于是失败的弯路,准备放在最后讲。

读通原有设计思路是不可避免得了,耐下心读吧。同时还去官网学习了我不熟悉的sortable,dragglable,droppable组件的使用。然后,惊!天!大!发!现!

[color=blue]先科普一下,sortable的作用是,某个区域内的元素,可拖动交换位置,比如一个列表中的每一行。draggable定义了可拖动元素,而droppable是指该区域可被放置拖动的元素。因此sortable就好比,draggable和droppable的结合。
[/color]

页面逻辑是,用户从其他地方拖动一个元素到表格的一个单元格内,再拖动一个新元素进来时,会覆盖。然后顿时震惊了,现在将单元格本身作为一个sortable区域,而内部却永远只需要存在一个元素,就完全没有必要成为sortable区域啊,又不需要排序!于是将sortable组件改为droppable组件的想法自然产生。

由于我也不知道droppable的性能会被sortable好多少,所以怀着惴惴不安的心情做了尝试,中间省略很长时间调节代码逻辑的过程,这也不是容易的过程。。。

确实快了很多!之前IE9下降到5秒+的过程,如今只需要2秒了!换句话说,两个优化以后,ie9从10秒降到2秒,同时,ie8也从14秒降到4秒。

至此,这部分就不准备再调节了,虽然理论上还存在优化的余地。

3. jquery选择器 :not

这个Case准备简单掠过,因为直接砍掉了一部分逻辑,不算真正改好,(其实我觉得原逻辑也不好,所以砍掉就砍掉了。。。。嘿嘿偷偷的)

通过profiles和 console.time 定位到了一个jquery选择器居然执行了好几秒,这里含有多个选择器的并列,还涉及到not语法,通过调试,发现单个使用not时没有性能问题,但与其他并列选择器的同时使用,就出奇的慢。关于这个我就没有深究,心想这not这种东西就和sql里not,like之流有异曲同工之妙,总有慢的理由。。。。遂,砍之。。


到这里,经历过的三次调优就结束了,之后由于参与其他任务,没时间调优,所以就放置一边了。总之,和前一篇博客一样,记一件有意义的事情。


——————————————————————————————————

前面讲过一个弯路,虽是弯路,但是挺有意思的尝试。

由于sortable慢,一开始又不知道可以怎么优化。于是想着能不能将这种卡顿感弱化。js是一个单线程的语言,放在浏览器里就是,如果一直在忙于执行一段任务,其他事情就会被卡住,包括用户页面操作,页面无响应,弹出IE是否结束脚本警告框,等等。

那么如果我自己模拟一个时分复用,将5秒钟的任务分割成N分,每5/N秒中断一次,因为有了中断,js线程就不会永远卡在当前任务上,有机会让其他任务插一脚执行,比如页面点个按钮啥的。在stackoverflow上拷了段js代码,用promise辅以setTimeout,模拟出一个时分复用的样子。

当然结果还是不理想啦,感觉卡顿感更严重了啊,页面点击时好时坏的,想着不能从根本上解决,还是不行啊,于是只能开始啃上下文代码。。。
——————————————————————————————————
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值