CSS样式表的背景渲染效率

所属分类: 网络编程 / CSS/HTML 阅读数: 1190
收藏 0 赞 0 分享
我的MzTreeView1.0树控件发布至今,得到了不少意见反馈,很多网友给了我很多的中肯的建议,也指出了这个控件里的诸多BUG和不足之处,所以我准备写一个新版本的树,将大家的建议都整合进来实现。这几天我就一直在写新版的树,树控件最重要的是效率,特别是大节点量的时候,效率稍微差点的模式就会拖垮浏览器,所以新版的树我首要的还是提高效率,比如增加异步数据加载的支持等,另外我还有一个设想,就是树的树型结构竖线用样式表(背景图)来实现,样式表背景图片只需要加载一次,而现在这个模式(用多个<img>)图片虽然有缓存机制,但还是有可以每张小图片都请求一次服务器的,所以我想用样式表来实现有多么的好呀,代码又精简,结构又清晰,效果又酷,但是结果我将近一个星期的测试,我这种设想彻底失败,原因就是样式表的渲染效率太差。新的构想没能实现,心情有些沮丧,但我想也应该让大家分享一下这个测试成果。

    这里我再解释一下树型里的竖线,树的左边都有 ┌ ├ └ │ 这些竖线图表示树层次,我的1.0版里是用一张张的小图片堆积起来的,而这种使用样式表的是用<div class="l2"></div> 这种代码来实现的,样式表负责填充背景图。

    #mtvroot div td{width:20px;height:20px;}
    #mtvroot .l0{background:url(line0.gif) no-repeat center}
    #mtvroot .l1{background:url(line1.gif) no-repeat center}
    #mtvroot .l2{background:url(line2.gif) no-repeat center}
    #mtvroot .l3{background:url(line3.gif) no-repeat center}
    #mtvroot .l4{background:url(line4.gif) no-repeat center}
    #mtvroot .ll{background:url(line5.gif) no-repeat center}
    #mtvroot .pm0{background:url(plus0.gif) no-repeat center}
    #mtvroot .pm1{background:url(plus1.gif) no-repeat center}
    #mtvroot .pm2{background:url(plus2.gif) no-repeat center}
    #mtvroot .pm3{background:url(plus3.gif) no-repeat center}
    #mtvroot .expand .pm0{background:url(minus0.gif) no-repeat center}
    #mtvroot .expand .pm1{background:url(minus1.gif) no-repeat center}
    #mtvroot .expand .pm2{background:url(minus2.gif) no-repeat center}
    #mtvroot .expand .pm3{background:url(minus3.gif) no-repeat center}

    上面这段CSS是我在脚本里动态生成的一段样式的片段,我把它贴上来,有助于后面的讲解。运用样式表之后,果真精简了许多,每个节点的生成也够快,但我发现,当我的树节点量达到,比如说300-500个节点之后,节点生成的效率没有影响什么,但每个节点的展开/收缩很慢很慢,需要几秒钟以上甚至10秒,且这个期间的CPU占用率是100%。说明一下,树型的展开/收缩是设置父节点的 style.display = none|block 来实现的。我的电脑配置是:AMD2800+ 1GDDR400内存,配置不太差的。

    我首先的反应是:是不是用了太多的<table>影响了效率?因为我每一个节点都用了一个<table>,但是我把<table>换成了<div>、<span>等,效率没有什么改善,说明这个CPU占用率100%的问题不是HTML标签的问题,那么剩下来的问题就是这里使用了样式表。

    以一个500节点的量来说吧,1.0里左边大概要堆积2000个左右的小图片。这种情况在浏览器端设置本地不缓存的时候会存在很大的问题,要加载这些多的小图片需要消耗不少的时间和服务器资源,所以我才会有这种新的用样式表来解决的想法,现在换成样式表法,也就是大概有2000个地方需要用样式表来渲染出背景图。我测试了各种情况,再对比1.0版的代码得出的结论是:CPU的点用率如此之高,唯一的原因也就只有这种渲染的耗时了。验证也非常简单,我把上面的样式表的左边 #mtvroot 这部分去掉,也就是去掉样式表的依托关系,测试的结果发现效率改善了很多,但耗时依然是可观的,有3-5秒之多。

    另外我换了不同的浏览器,测试的结果也不太一样,在IE里最为恶心,比如说我在某个节点有500子节点,我将它收起(CPU100%,等待3-5秒),也就是display="none",这时候若我去收起这个节点的父节点(这个节点没有其它的同级节点,即它的父节点只有它这么一个子节点),照理说只有一个节点,收起应该是即时的事,但结果不然,结果又是3-5秒的CPU100%,这个让我狂郁闷,也就是说即使HTML对象被display="none"隐藏掉了,但是对它的父级进行任何操作的时候,IE会对这些被隐藏的对象用样式表重新渲染一遍,真是搞不懂IE的开发者当初是怎么想的。

    我又到FIREFOX里测试了一下,在收起的时候(display=none)是瞬间的,可以肯定,FF对待被隐藏的对象不会再消耗精力。当然展开的时候所有的浏览器都一样:3-5秒的CPU100%,不过FF稍微要快些。

    通过上面的这些现象我得出这么一个结论:样式表在动态渲染的时候效率并不高;在父容器发现状态变化的时候会引起它的所以子孙对象的样式表重新渲染;FireFox 对待被display=none隐藏的对象不会重新渲染而IE会。

    那么这种样式表的渲染效率问题以前为什么一直没有被发现呢?嘿嘿,大家做网页的时候难得会做到这种极端的时候,一个页面里有几千个需要样式表渲染背景图。通常也就几个地方或者几十个地方了,所以感觉不出来渲染的效率,也感觉不出这方面在不同的浏览器之间的差别。但是在做树这些的控件的时候必定会碰到各种极端的问题,比如大数据量的数组,生成的HTML对象的多少等等,象这种渲染的效率差别也只是我在写JS脚本时碰到的问题之一而已。今天我把这个测试结果共享出来是希望对大家以后写程序的时候有所借荐,在做设计的时候有所考虑。

    最后多谢大家对我写的控件的肯定与支持,谢谢了!
更多精彩内容其他人还在看

简单明了带你了解CSS Modules

不要误会,CSS Modules可不是在说“css模块化”这个好像在某些地方见过的词,它其实是特指一种近期才出现的技术手段。什么技术手段呢?下面小编来和大家一起学习一下
收藏 0 赞 0 分享

新手学习css优先级

大部分人同样也会在写css的过程中产生很多困惑,比如为什么自己写的某段css没有生效,或者呈现出的样式和预计的不同,但又不知道要如何解决。下面小编来和大家一起学习CSS的优先级
收藏 0 赞 0 分享

css进阶学习 选择符

css这种没有程序逻辑的代码中,又能找出什么来说明谁做得更出色呢?下面小编给大家说明如何从css选择符的角度来提高css代码质量。
收藏 0 赞 0 分享

实现css文字垂直居中的8种方法

CSS可以轻易实现文字的水平居中,但有时我们需要文字垂直居中,除了表格可以实现这种CSS文字垂直居中以外,还有其它几种方法可以做到
收藏 0 赞 0 分享

完美实现CSS垂直居中的11种方法

在做前端项目时CSS的水平居中我们经常使用,但有时还会用到CSS垂直居中,对于小白来说这个就有些难度了,下面看一下我是如何实现的
收藏 0 赞 0 分享

webpack高级配置与优化详解

这篇文章主要介绍了webpack高级配置与优化,其中包括了webpack打包多页面,webpack跨域问题等相关内容
收藏 0 赞 0 分享

5个HTML5的常用本地存储方式详解与介绍

在HTML5规范之前,存储主要是用cookies,但cookies缺点有在请求头上带着数据,大小是4k之内,今天为大家介绍一下H5的5种存储方式
收藏 0 赞 0 分享

CSS代码检查工具stylelint的使用方法详解

stylelint是一个强大的现代CSS检测器,可以让开发者在样式表中遵循一致的约定和避免错误。本文将详细介绍CSS代码检查工具stylelint
收藏 0 赞 0 分享

Zen Coding css,html缩写替换大观 快速写出html,css

本文是在zen使用生产中遇到的问题做一些分享。
收藏 0 赞 0 分享

javascript代码规范小结

javascript代码规范,大家可以参考下,以便写出更利于阅读的代码。
收藏 0 赞 0 分享
查看更多