等宽瀑布流布局的开发实践

Pinterest 当时的成功,在国内掀起了一股瀑布流的潮流,但很多国内的网站仅仅只学会了使用瀑布流的布局方式,却没有看到 Pinterest 成功背后的模式。页面的布局方式仅仅是一个壳,瀑布流的布局方式也最多算是一个漂亮的壳。如果没有实质性的内容,光有壳就只能让用户图个新鲜。就好比帅哥美女仅仅是外表漂亮,而没有内涵和气质一样。

瀑布流展现的内容通常是扁平化、琐碎的东西,首先吸引人的应该是图片,如果瀑布流中文字过多,只会给人很杂乱的感觉,所以瀑布流更适合单纯的图片浏览。

最近公司的项目–360图片的美女秀场,就用到了瀑布流的布局方式,这种纯粹的看美女图片的页面用瀑布流还是挺合适的。

以前并未开发过瀑布流布局的网站,第一个想到的实现方式就是多列浮动,从表面上看这种方式要简单。

传统的定位布局方式

但是,目前主流的瀑布流布局都是采用定位的方式,对每个单元格计算定位值,如下图:

定位方式实现的瀑布流布局

定位的方式实现起来其实也简单,在窗口 resize 时,也可以方便的对单元格进行重新计算排序。但是计算的频率比较高,如果要做无限的加载数据,以及 resize 时的自适应排列,那么性能就是一个必须要重视的问题。

如果没有任何优化手段,成百上千个单元格本身就很耗资源,resize 时再全部重新计算一遍,可以想象浏览器在这个时候一定很吃力,必然会有浏览器假死的情况。

多列浮动的布局方式

再来看看多列浮动布局的实现方式,多个单元格组成一列,无需对单个的单元格进行定位的计算,然后对整列进行浮动,如下图:

多列浮动方式实现的瀑布流布局

当然,这种布局方式在无限加载和 resize 时的自适应面前,面对着同样的问题。

自适应窗口

先说 resize 时的布局自适应,虽然浮动布局的计算没有定位那么方便,但要实现自适应的布局还是可以的。比如原来有 4 列,resize 时页面宽度变小了,只能放 3 列了,单元格的总数是不变的,数据的顺序也是固定的,那么只有把原来 4 列里面的单元格全部清空,按照数据的顺序重新计算排序,依次添加到 3 列中。需要注意的是清空的时候并不是把单元格的 DOM 元素给删除掉,而是从 DOM 树提取出来存放在一个文档碎片中,这样就避免了每次都要去创建单元格的 DOM 元素,节省了创建时的性能开销,说得通俗点就是离线操作。

无限加载的挑战

浏览器中运行的 WEB 程序并不能像桌面软件那样会有足够多的 CPU 和内存去使用。当网页中的 DOM 元素的数量呈指数倍的增长,那么其占用的内存也势必会成正比的增长,每个 DOM 元素都会有性能开销,只是通常情况下 DOM 的数量并没有达到需要注意型性能的那个阙值。

无限加载的瀑布流就必须要注意这种由于 DOM 数量庞大而引发出来的性能问题。不能抱着侥幸的心理去认为用户可能滚动不了多长就会跳出。此次做的瀑布流布局的项目压根就没有内页,都是浮层直接展示大图,虽说在一定程度上方便了用户,但同时也给浏览器端很大的性能压力。用户如果不需要跳转一直停留在瀑布流的列表页,只要不关闭这个页面,内存就会一直没有释放的机会。

虽然页面可以无限长,但是用户的显示器的可视区域是有限的,就好比一个再富有的人,他晚上睡觉时占的面积还是那么大,床的面积也是有限的。由于可视区域是有限的,通常会利用这一点对没加载的 DOM 元素作延迟加载,那么反过来,能否对已加载的但不在可视区域的 DOM 元素做文章呢?答案是肯定的,人有多大胆,地有多大产嘛。

当页面向下滚动的时候,瀑布流会创建新的单元格,老的单元格就会随着页面的向下滚动而处于非可视范围,既然都不可见了,那么为了节省性能完全可以把这些老单元格删除掉。当然,也要有技巧性的去删除。如果页面往上滚,滚回去的时候你总不能给用户看白板,不能这样坑人。那么原来删除的还得保持原位置加回去。不悠着点的话,光是这样一删一加的两个动作就够浏览器受的了。作为 WEB 开发者,要时刻都有浏览器是很脆弱的如芒在背的心理。

分组操作

上面说到的有技巧性的删除就是将那些处于非可视区域的 DOM 元素从 DOM 树中提取出来,存储在一个文档碎片的容器中。DOM 元素脱离了 DOM 树也会大大节省性能的开销,这样就达到了节省性能的目的。当然如果仅仅只做到这一步还不太好意思说是技巧。正是因为这个,我将 HTML 结构再包裹一层,在 ul 外面添加了一个
div ,称之为一组,其真实结构如下图所示。

多列浮动方式实现的瀑布流布局的HTML结构

在这里,组是比列更大的单位,一组可以是可视区域大小的尺寸( 目前组还没精确到针对不同的分辨率 ),一组里面就是浮动的自适应屏幕分辨率的几列,每列里面就是一个个的单元格。如上图,这样几列就可以组成一组。有了组就可以比较方便的将频繁出入于 DOM 树中的 DOM 元素的性能开销平衡的分配到每一组。可以在页面滚动向下到指定的位置,只删除某一组,继续向下滚再继续删除。每次都删除处于最顶端的那一组,因为是在非可视区域内,用户也不会知道你的删除操作。

页面的高度是由一个个单元格给撑起来的,删除了单元格后,其高度就会出现变化,由此就会导致页面的高度也跟着变化。在删除前计算出组元素的高度,然后设置其 visibility 为 hidden,让其在删除后还保留组元素原有的位置和高度,这样就不会有高度的变化了。

通过的删除非可视区域的 DOM 元素的优化方法,可以让页面始终保持1-2组单元格,只要你组内的单元格的数量能把握好。这样就在一定程度上大大的缓解了了页面中由于 DOM 数量过多而出现的性能开销的问题。

当窗口 resize 达到重新排序的宽度条件时,还是要将页面中所有单元格重新计算排序。由于非可视区域的单元格已经不在 DOM 树中,那么其计算也没什么压力了。那些存储在文档碎片容器中的单元格也还是需要计算的,因为如果此时页面往上滚动时那些离线的单元格还要重新和用户见面嘛,只是这个计算并不是在 DOM 树中而已。

多列浮动方式实现的瀑布流布局的HTML结构

好了,篇幅又有点超出预期了,今天就写这么多了。由于当时项目工期比较紧,就没有更深入和细致的做性能方面的调优了。以后再做优化还是会有优化空间的。

组件已开源,github 地址:https://github.com/chenmnkken/ecope/tree/master/waterfall

原载于:雨夜带刀’s Blog
本文链接:http://stylechen.com/waterfall.html
如需转载请以链接形式注明原载或原文地址。

“等宽瀑布流布局的开发实践”目前已有 16 条评论

  • *
  • *

评论列表

  • GY说道:

    带刀兄一直很给力

  • 小人说道:

    楼主高手

    一流的代码,二流的设计,三流的项目….

  • 雨夜带刀说道:

    @小人
    哈哈,设计我也感觉是糙了点,不过,这些都不是重点,重点是美女。

  • jQuery说道:

    前辈:如何用jQuery实现瀑布流布局中的图片放大。换句话说,就是将图片放大用在瀑布流布局上,当鼠标悬停图片上时,图片放大

  • 雨夜带刀说道:

    @jQuery
    图片放大的效果用在瀑布流上的体验感觉很不好,最好的体验还是点击小图跳转到新页面看大图的体验会更好。

  • 子龙说道:

    每次读带刀的文章,都觉得神清气爽。。。

  • G.Shawn说道:

    不错的瀑布流,貌似跟我开发的会有不同,希望有代码的开源哦。谢谢。

  • yoven说道:

    很受启发,但是想问个问题,这样滚动下去的话,之前删除的dom元素的内存是不是一直占用呢?

  • 雨夜带刀说道:

    @yoven
    都是存放在一个文档碎片容器中,只是不在DOM树中而已。

  • […] 图片搜索中,今年经常接触最多的就是各种布局方式的图片列表,各种形式的瀑布流,等宽和等高的瀑布流。其中等宽瀑布流的实现和优化花了不少的时间,采用了组、列结合的布局方式,在滚动时可以动态的删除/恢复组,也算是解决了这种等宽瀑布流常见的性能瓶颈的问题。 […]

  • Amin说道:

    文档碎片容器还是会占用内存,是不是可以把离用户很远的元素直接删掉,如果用户再回头看的时候,再动态拉取,这样实现的可行性怎么样?

  • 雨夜带刀说道:

    @Amin
    文档碎片容器是会占内存,但这个已经很不错了,图片元素在和不在DOM树中其占用内存的区别是相当明显的。后面的这种方案我就不考虑了,拉取数据和重新创建图片元素这个代价比较高。

  • 微个日光日说道:

    又发现一个前端大牛!

  • 煜楠说道:

    我在 git 上看了一下这个组件的 demo 的那个 index.html ,然后发现在 类选择器 wf_group 上添加了font-size: 12px; line-height: 1.5; 后,在 li 元素中的 img 元素的下方多出了一个类似相框的空白。这个是怎么出现的?又是什么原理呢?也搜索了一下,完全不明所以。。。

    • 雨夜带刀说道:

      如果使用 h5 的 doctype 头,那么 img 标签的底部默认就会有一个空白的间距,可以修改其 vertical-align: bottom; 来移除。