[译]无尽滚动的复杂度--来自Google大神的拆解

傷城~ 2022-07-10 10:58 145阅读 0赞

转载自：http://www.jianshu.com/p/4e16b4211d84

原文地址：[https://developers.google.com/web/updates/2016/07/infinite-scroller][https_developers.google.com_web_updates_2016_07_infinite-scroller]  
原文作者：Surma  
译者：王芃

--------------------

摘要: 重用你的DOM元素以及删除那些远离可视范围的元素。为延迟显示的元素使用占位符。这里是一个无尽滚动的[演示][Link 1]和[代码][Link 2]。

无尽滚动在互联网上到处都有应用。Google Music的艺术家列表是一个，Facebook的时间线是一个，Tweeter的话题列表也是一个。当你向下滚动，新的内容就神奇的“无中生有”了。这是一个得到广泛赞扬的、非常好的用户体验。

在这个无尽滚动背后的技术挑战其实比它看上去要难。当你想做正确的事时，你遇到的问题是巨大的。开始时是一些比较简单的事情，比如在页面尾部的链接是无法点击的，因为内容不断的把它们“挤”走。但是问题逐渐开始变得越来越难：当用户将手机从竖屏改为横屏时你该如何处理 `resize` 事件？或者当列表过长时你如何避免手机的卡顿？

## 正确的事 ##

我们认为有充分的理由来实现一个参考设计：在保证性能的基础上，以一个可复用的方式来解决这些问题。

我们将会使用3种技术来达成目标：DOM回收、墓碑和滚动锚定。

我们的demo会是一个类似聊天的窗口，我们可以滚动这些消息列表。首先需要的是一个无尽的消息数据源。从技术角度看，没有任何一个无尽列表是真正无尽的，但当有足够的数据量填充进去时，它们看上去感觉是无尽的。为简化问题，我们这里硬编码了一套消息数据，随机的抽取消息、联系人和图片。为了更像网络的真实情况，我们人为加入了一些延迟。

![6a00e9c6a6f8ab0a27c660a2d2fd1f78.png][]

image\_1b8s8bm77scgbh31ill1qn41h199.png-786kB

## DOM 回收 ##

DOM回收是一个未被广泛使用的技术，它的用途是让DOM的节点数保持在较低的数值。概括来说，它的机制是利用那些离开视图区域的、已经创建的DOM元素，而不是新建DOM元素。需要承认的一点是DOM节点本身并非耗能大户，但是也不是一点都不消耗性能，每一个节点都会增加一些额外的内存、布局、样式和绘制。如果一个站点的DOM节点过多，在低端设备上会发现明显的变慢，如果没有彻底卡死的话。同样需要注意的一点是，在一个较大的DOM中每一次重新布局或重新应用样式（在节点上增加或删除样式所触发的过程）的系统开销都会比较昂贵。所以进行DOM回收意味着我们会保持DOM节点在一个比较低的数量上，进而加快上面提到的这些处理过程。

第一个障碍是滚动本身。由于我们在任何时刻DOM中只有全部列表项目的一个微小子集，我们需要找到一种方式可以让浏览器正确的反映出理论上应该在“那里”的全部列表项目数量。我们这里用一个 `1px * 1px` 的”前哨“元素（`sentinel`），并且应用一个变换使得包含“逃兵”列表项目的元素（下图中的 `runway`）保持一个理想的高度。我们会把`runaway`中的每一个元素提升到它们自己的层，保持 `runaway` 本身是完全空的，没有背景色，神马都木有。如果 `runaway`层不是空的话，是不利于浏览器优化的。因为我们将不得不在显卡上存储一个由成千上万的像素组成的纹理。这样做显然在移动设备上是不可行的。

当我们进行滚动时，我们会检查是否viewport是否已经足够接近 `runaway` 的尾部。如果是的话，我们会通过把 `sentinel`和viewport中的剩余元素移向 `runaway`的底部来扩展 `runaway`，然后用新内容渲染这些元素。

![4009c34c1851bf5c4c9a.gif][]

向反方向滚动时也类似，但我们无论如何也不会缩小 `runaway`，原因是我们需要滚动栏的位置保持连续性。

## 墓碑（Tombstones） ##

如之前我们所说，我们会尽量让数据源表现的像现实世界遇到的情况：有网络延迟及其它情况。这就意味着如果我们的用户飞快地滚动，他们会很容易就把我们渲染的有数据的项目都甩在身后。如果这种情况发生时，我们就需要放置一个墓碑条目（占位）在对应位置，等到数据取到后墓碑条目会被实际内容替代。墓碑也会被回收，对于墓碑元素会有一个独立的可复用DOM元素的池。这样设计的原因是，我们希望墓碑元素在被实际数据替代时可以有一个漂亮的过渡，而不是出现那种生硬的或者让人迷失的效果。

![69a305fc54ab9be8921fd339023f2854.png][]

墓碑元素

这里有一个有趣的挑战，那就是真实的条目的高度可能会超过墓碑的高度，因为不同的文本量或者图片的大小决定了这点。为了解决这个问题，每次当取到数据后我们会调整当前的滚动位置，而且在viewport之上的一个墓碑条目也会被替换。将滚动位置锚定到某一条目而非某一具体的像素位置，这个概念叫做滚动锚定。

## 滚动锚定 ##

滚动锚定的触发时机有两个：一个是墓碑被替换时，另一个是窗口大小发生改变时（在设备发生翻转时也会发生）。我们必须要知道在viewport中的最顶部可见元素是什么。由于这个元素可能只是部分可见的，所以我们也需要存储从顶部元素到viewport顶部的偏移量。

![4d00a80e242a16d48735c9af0b4152fd.png][]

滚动锚定

这样的话，当viewport改变大小时、`runaway` 改变时，我们是可以把场景恢复到一个看起来和原来几乎一致的样子。爽就一个字！但是改变大小的视窗意味着每个条目都可能改变了高度，那么我们如何能知道该把锚定的内容移动多少偏移量呢？我们并不知道！为了搞清楚这点，我们可能不得不把锚定条目之上的元素布局起来，把它们的高度累加在一起。但显然这样做会造成改变大小时会有明显的停顿，我们并不想要这样的结果。相反，我们借助于一个假设：在viewport之上的每个元素都是和墓碑等高的。根据这个假设来调整对应的滚动位置。当元素滚动进入 `runaway` 时，我们调整滚动位置，这样就有效的把布局工作延迟到真正需要的时候了。

## 布局 ##

我刚才跳过了一个重要的细节：布局。每次DOM元素的回收通常情况下都会引发整个 `runaway` 的重新布局，这会直接影响我们的性能：无法达成每秒60帧的目标。为避免这一点，我们自己承担了布局的重任，使用了绝对定位的元素。这样我们可以让所有 `runaway` 中的元素感觉上还在占用空间，但其实那里毛都没有。由于我们自己在操控布局，我们便可以缓存每个元素消失前的位置，在用户往回滚动时，我们能立刻从缓存中加载正确的元素。

理想情况下，条目应该只被重绘一次，那就是当它们被加到DOM时。而且应该对于 `runaway` 中其它条目的增加或删除完全不受影响。这个是可能的，但是只限于现代浏览器。

## 极致优化 ##

最近，[Chrome增加了CSS Containment的支持][Chrome_CSS Containment]，这个特性允许开发者告诉浏览器某个元素是布局和绘制的边界。由于我们这里采用的是自己来布局，这是一个很好的可以应用 `containment` 的机会。当我们增加一个元素到 `runaway`时，我们知道其它条目不应该被这个重新布局影响。所以每个条目应该设置一个 `contain: layout`。我们同样也不希望影响站点的其它部分，所以 `runaway` 本身也需要这样设置。

另一个优化点，我们考虑的是利用[IntersectionObservers][]去检测用户是否已经滚动了足够距离，以便于我们决定是否开始回收DOM和加载新数据。但是 `IntersectionObservers`是为高延迟设计的，所以我们实际上会“感觉”用了 `IntersectionObservers` 反而比不用时“响应更慢”。在我们当前的实现中滚动事件的处理其实也存在这个问题。也许这个问题的可信度较高的解决方案会是 [Houdini’s Compositor Worklet][Houdini_s Compositor Worklet]

## 仍不完美 ##

目前的DOM回收实现方式仍不是完美的，因为我们把所有“滚过”viewport的元素都添加到DOM了，而不是仅仅关心那些在屏幕上可见的元素。这就意味着，如果你滚动的真的非常非常快的话，快到你堆积了大量的布局和绘制工作，浏览器已经无法跟上的地步时，这时我们可能除了背景什么都看不到了。这当然不是世界末日但是确实是一个可以优化的地方。

我们希望你可以看到这个过程：当你想提供一个高性能的有良好用户体验的功能时，一个简单的问题是演变成复杂问题的。随着“Progressive Web Apps ”逐渐成为移动设备的一等公民，高性能的良好体验会变得越来越重要，开发者也必须持续的研究使用一些模式来应对性能约束。

所有的代码可以到[这里][Link 2]查看，我们已经尽力让代码有可复用性了，但不会发布一个npm类库或其它单独的项目。这个代码的主要目的是教学。

学习前端的过程中，我整理了很多资料，也希望能共享出来帮助到更多刚接触或者接触前端不久的同学。不过也为了把控微信群的质量，入群的一定要是前端的小伙伴才可以。入群我就会把资料发给每个人，每天也会挑选前沿的前端高质量文章发到群里给大家学习。想加入的同学可以加 **笑笑微信：iamaixiaoxiao**，拉你入群。再次强调，保证群高质量，群非前端不加，请谅解哦。扫描微信二维码也可以。

![Center][]

[https_developers.google.com_web_updates_2016_07_infinite-scroller]: https://developers.google.com/web/updates/2016/07/infinite-scroller
[Link 1]: http://googlechrome.github.io/ui-element-samples/infinite-scroller/
[Link 2]: https://github.com/GoogleChrome/ui-element-samples/tree/gh-pages/infinite-scroller
[6a00e9c6a6f8ab0a27c660a2d2fd1f78.png]: https://user-gold-cdn.xitu.io/2017/2/15/6a00e9c6a6f8ab0a27c660a2d2fd1f78.png
[4009c34c1851bf5c4c9a.gif]: https://dn-mhke0kuv.qbox.me/4009c34c1851bf5c4c9a.gif
[69a305fc54ab9be8921fd339023f2854.png]: https://user-gold-cdn.xitu.io/2017/2/15/69a305fc54ab9be8921fd339023f2854.png
[4d00a80e242a16d48735c9af0b4152fd.png]: https://user-gold-cdn.xitu.io/2017/2/15/4d00a80e242a16d48735c9af0b4152fd.png
[Chrome_CSS Containment]: https://developers.google.com/web/updates/2016/06/css-containment
[IntersectionObservers]: https://developers.google.com/web/updates/2016/04/intersectionobserver
[Houdini_s Compositor Worklet]: https://developers.google.com/web/updates/2016/05/houdini
[Center]: /images/20220709/198dffb27aec4ac3be8149b18a8c1892.png