打造丝般顺滑的H5翻页库

2017年架构师最重要的48个小时 | 8折倒计时

背景

打造丝般顺滑的H5翻页库

百度 H5 也先后应用了 Swiper 和 iSlider 作为 H5 运行时的翻页框架，跟着用户越来越多，也碰到了一些问题：

而我们欲望的 H5 翻页库能和平台本身的功能完美贴合，在保持体积小的同时，在翻页的时刻能做到「丝般顺滑」。于是我们就开端了研(zao)究(lun)之(zi)旅。

此时比较消费机能的操作是：当 touchmove 触发时，计算出了要移动的距离，所有的页面都须要沿着 Y 轴移动雷同的距离。此时必定免不了进行 DOM 操作，而 DOM 操作是异常「昂贵」的，再加上 touchmove 事宜的频繁触发，机能处理不敷好的话，很轻易出现卡顿。

开端

H5 滑屏框架的开辟，第一个问题就是：页面是否追顺手指滑动?这也是腾讯 ISUX 团队的《滑屏 H5 开辟实践九问》的第一问(这篇文┞仿原文出处如今是 404 ，大年夜家可以在其他的转载网站看到)，这里用这篇文┞仿的图片解释一下这个问题。

基来源基本理图

左边的是不追顺手指滑动，只须要存眷手指触碰开端和分开两个时光点，中心过程不消推敲。所以实现起来比较简单。然则用户的操作没有及时的反馈，体验不敷好。是以，尽管实现起来更复杂，我们仍然决定实现前一种「追顺手指滑动」的效不雅。

起步

下图是追顺手指滑动的 H5 最直不雅的版本，所有的「页面」依次大年夜上到下，首尾相接。须要解释一下，这里的「页面」打引号，是因为实际上他们都是 div ，后文说的页面都指这些 div 。同时，我们这里以最常见的竖直偏向滑动为例，程度偏向同理。

打造丝般顺滑的H5翻页库

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

深刻商量

简单的版本在上一部分很轻易就实现了，如不雅其他需求不多，页面上元素和动画比较少，根本上就够用了。然则本文要商量的是若何能做到「丝般顺滑」，其实就是两钢髦己机能。

机能的瓶颈是什么呢?

我们分成两部分来看这问题：手指分开屏幕前和手指分开屏幕后。

手指分开屏幕前

这琅绫擎包含两部分：削减 DOM 操作的元素和削减 DOM 操作的属性。前者比如，看不到的页面不介入动画。后者比如，只改变元素的 css 属性的一个或几个。

削减 DOM 操作的元素

最开端简略单纯的版本的例子中， touchmove 触发时，所有的页面都沿着 Y 轴移动。其实没有须要，因为相当一部分页面是看不见的。那一般情况下，我们起码须要操作几个页面呢?谜底是两个。可以回想一下，我们滑动的时刻，最多能同时看到两个页面。这个办法相对于所有的页面一路移动，成倍地晋升机能。

削减 DOM 操作的属性

这个办法的重要意思是，只须要操作一次 DOM 能达到的效不雅，毫不消两次。实际上，对于 slide 动画，我们只须要改变页面的 transform 的值，其他的 DOM 操作(增长 class，修改元素的 innerHTML)等能不做就不做。

我们的目标是：在「三多一低」(页面多、元素多、动画多，设备低)的情况下，滑动翻页时，尽可能不产生卡顿。

我们获得了一个初步的筹划：初始化时，所有的页面一次性全部置入 container，除了我们用到的两页， display 属性都设置为 none 。 touchmove 的时刻，只有这两页的 transform 属性有变更。

touchmove 的过程，我们可以写成数学表达式：

是当前滑动边的长度，如不雅是沿 y 轴滑动，则是页面高度。写到这里，就跟时下很风行的「数据驱动」的概念很类似了。我们要实现的就只有一个 render 函数，输入是用户的交互数据，输出是页面表示。

手指分开屏幕后

当手指分开屏幕时，我们就已经知道了此次滑动的结不雅(向上照样向下?翻页照样回弹?)，要实现的只是动画效不雅，我们有两个选择：

计整洁：复竽暌姑 touchmove 的 render 逻辑，按照手指滑动的速度，应用 requestAnimationFrame 控制动画;
筹划二：应用 css3 transition 动画;
计整洁的长处在于：可以在手指滑动和动画过程应用同样的 render 函数，最大年夜限度复竽暌姑了代码，逻辑同一;同时可以精确控制动画的每一帧，动画曲线会比较流畅。缺点就是可能存在的机能问题。筹划二跟计整洁刚好相反。其实说到底照样 js 动画 vs css 动画的问题。

动画机能实验

为了比较两个筹划在 H5 翻页动画上的机能好坏，我们取一个稍微复杂点的例子：