打造丝般顺滑的 H5 翻页库 _小知识

背景随着近几年移动营销页的火爆，催生了一个中国式的名词「H5」。而 H5 最常见的形态就是类似幻灯片翻页效果。
我们需要制作 H5 的时候，最快的办法就是使用一些滑动插件库，如 iDangero.us 出品的 Swiper，百度 BE-FE 出品的 iSlider 。通过这些翻页库提供的强大的配置功能，我们就能实现很酷炫的翻页效果。当然，这些库还支持自动播放，点击切换和当前页面指示等配置，所以还能用在网页上，实现一些 web carousel 的效果。
百度 H5 也先后使用了 Swiper 和 iSlider 作为 H5 运行时的翻页框架，随着用户越来越多，也遇到了一些问题：

H5 平台和这些库不能很好贴合，有些配置项用不上，而有些必要的功能需要「Hack」的方式实现。
一些 H5 的元素多、动画多，在低端机型上翻页时，翻页时会有「卡顿感」和「粘滞感」，用户体验不好。

而我们希望的 H5 翻页库能和平台本身的功能完美贴合，在保持体积小的同时，在翻页的时候能做到「丝般顺滑」。于是我们就开始了研(zao)究(lun)之(zi)旅。
开始H5 滑屏框架的开发，第一个问题就是：页面是否跟随手指滑动？这也是腾讯 ISUX 团队的《滑屏 H5 开发实践九问》的第一问（这篇文章原文出处现在是 404 ，大家可以在其他的转载网站看到），这里用这篇文章的图片说明一下这个问题。

文章插图

文章插图

上图：不跟随手指滑动，下图：跟随手指滑动。
左边的是不跟随手指滑动，只需要关注手指触碰开始和离开两个时间点，中间过程不用考虑。所以实现起来比较简单。但是用户的操作没有实时的反馈，体验不够好。因此，尽管实现起来更复杂，我们仍然决定实现前一种「跟随手指滑动」的效果。
起步下图是跟随手指滑动的 H5 最直观的版本，所有的「页面」依次从上到下，首尾相接。需要说明一下，这里的「页面」打引号，是因为实际上他们都是 div，后文说的页面都指这些 div 。同时，我们这里以最常见的竖直方向滑动为例，水平方向同理。

文章插图

基本原理图
这些 div 的宽度和高度都是 100% 的容器高度，可视区域是中间的部分，我们监听 touchstart, touchmove, touchend 事件，跟鼠标拖拽的原理类似：

touchstart 时，记下起点位置；
touchmove 实时计算滑动的距离，让所有页面一起沿着 Y 轴 translate 这段距离。
touchend 时，能得到最终的滑动距离，跟设定的阈值比较。进入到页面自动控制阶段：大于阈值则让页面滑动到下一页，小于阈值则恢复到起始位置。

深入探究
简单的版本在上一部分很容易就实现了，如果其他需求不多，页面上元素和动画比较少，基本上就够用了。但是本文要探究的是如何能做到「丝般顺滑」，其实就是两个字：性能。

性能的瓶颈是什么呢？

我们的目标是：在「三多一低」（页面多、元素多、动画多，配置低）的情况下，滑动翻页时，尽可能不产生卡顿。
我们分成两部分来看这问题：手指离开屏幕前和手指离开屏幕后。
手指离开屏幕前
此时比较耗费性能的操作是：当 touchmove 触发时，计算出了要移动的距离，所有的页面都需要沿着 Y 轴移动相同的距离。此时必然免不了进行 DOM 操作，而 DOM 操作是非常「昂贵」的，再加上 touchmove 事件的频繁触发，性能处理不够好的话，很容易出现卡顿。
为了优化性能，我们很自然的想到一个策略：减少 DOM 操作。
这里面包含两部分：减少 DOM 操作的元素和减少 DOM 操作的属性。前者比如，看不到的页面不参与动画。后者比如，只改变元素的 css 属性的一个或几个。
减少 DOM 操作的元素
最开始简易的版本的例子中，touchmove 触发时，所有的页面都沿着 Y 轴移动。其实没有必要，因为相当一部分页面是看不见的。那一般情况下，我们最少需要操作几个页面呢？答案是两个。可以回想一下，我们滑动的时候，最多能同时看到两个页面。这个方法相对于所有的页面一起移动，成倍地提升性能。
减少 DOM 操作的属性
这个方法的主要意思是，只需要操作一次 DOM 能达到的效果，绝不用两次。实际上，对于 slide 动画，我们只需要改变页面的 transform的值，其他的 DOM 操作（增加 class，修改元素的 innerhtml）等能不做就不做。