【treeview开发笔记(2)】高兴,又发现了一个加速treeview的方法

今天研究焦点节点切换时的速度问题

梅花雪老师的树在展开近1000节点后,切换焦点节点(修改CSS样式时依然十分迅速)

而我的,几乎如蜗牛般了

让我百思不得其解

晚上吃了饭回来

有打开两棵树,对比了一下效果,再次叹息.还是慢不少

光看代码,也看不出什么啊?

都是接收单击或者焦点事件然后切换css样式,为什么我的就慢这么多呢?

唯一的解释就是我的树所形成的DOM结构比梅花老师的树复杂

加重了浏览器维护view的负担

dom结构,dom结构,dom结构

对阿,我看看两棵树最后形成的dom结构怎么样?

呵呵,前几天刚刚给firefox和IE配备了两个高级调试工具

用于firefox的firebug

用于IE的IE Developer Toolbar

先打开firefox,按F12查看梅花雪的DOM结构

结果无法显示,晕了

换IE试试

结果用IE Developer Toolbar可以显示dom结构
查看了他生成的dom结构,突然发现他的树枝和线索表示都是用的字符,而非图像

于是一下子明白了两个问题
1.梅花雪的代码中有一段关于字符兑换的,一直以为是为了照顾不支持图像的浏览器而设计的,呵呵,(当时还想:梅花老师想的可太周到了,远古时代的浏览器都可以看到他的treeview,不过哪种浏览器支持js不支持图像呢?用户禁止图像显示???)原来是为了效率.
      其实这个问题的答案我早该想到了,前几天为了解决浏览器随网页元素增多而执行效率下降的问题,在论坛上发贴,后来 gzdiablo发上来一段代码,我根据这段代码修改测试了一下,结果发现每个节点加两张图片,1000节点展开的速度由500ms陡增到5000ms,很是令我震惊,直到结贴,这个结论我觉得是最有价值的.当时想到减少节点中包含的图片,树的执行速度就快上去了,不过没有想到可以在这里(线索,树枝)下手,

2.也是前一阵子,在网上到处找有关treeview的话题的时候,从一个blog中看到一大侠自己写一个treeview的过程
,在构造树的基本表示的时候,他对另一颗有图片堆叠来表示线索的方式表示不屑.我当时想,我的树也是这样表示的啊,用图片表示怎么了?
现在将这些问题联系起来,就很明了了,图片占用资源大,如果用图片表示线索,随着树层次的加深,每个节点前面的图片序列也月来越多,,所造成的性能下降也就逐渐明显了

仔细的看了看IE Devloper 显示出来的dom树
呵呵,明白了,接下来就是改进原先的线索表示方式了

继续努力