链接：fex.baidu.com/blog/2017/10/build-a-silky-smooth-slide-library/
背景
随着近年来联通营销页面的火爆，一个中国式的术语“H5”诞生了。 H5最常见的形式就是类似于幻影kt板翻页效果。
当我们需要制作H5时，最快的方式就是使用一些滑动插件库，比如iDangero.us出品的Swiper、百度BE-FE出品的iSlider。 通过这个翻页库提供的强大的配置功能，我们可以实现非常炫酷的翻页效果。 其实这个库还支持手动播放、点击切换、当前页面指示等配置，因此可以用在网页上实现一些webcarousel的效果。
百度H5也先后使用了Swiper和iSlider作为H5运行时的翻页框架。 随着用户越来越多，也遇到了一些问题：
1、H5平台与那些库不太契合，有些配置项无法使用，有些必要的功能需要以“Hack”的形式实现。
2、有的H5元素多，动画多。 在高端机型上翻页时，翻页时会有“卡住感”、“粘滞感”，用户体验不好。
而我们希望H5翻页库能够完美契合平台本身的功能，在保持体积较小的同时，翻页时能够“丝滑”。 于是我们开始了研究（zao）研究（lun）的（zi）之旅。
开始
在H5滑屏框架开发中，第一个问题是：页面是否跟随中指滑动？ 这也是腾讯ISUX团队的《滑屏H5开发实践十问》第一题（本文原始出处现为404，可以在其他转载网站看到），这里是本文图片来说明这个问题。
左：不跟随中指滑动，下：用中指滑动。
左边的不跟随中指滑动，只需要关注右手触摸开始和离开的两个时间点，中间的过程不需要考虑。 所以实现起来还是比较简单的。 并且没有对用户的操作进行实时反馈，体验不够好。 为此，虽然实现上比较复杂，但我们还是决定实现前面的“跟随脚趾滑动”的效果。
开始
右图是H5最直观的中指滑动版本。 所有的“页面”都是从上到下依次连接的。 需要说明的是，这里的“页面”有一个冒号，因为它们实际上是div，后面提到的页面就是指那些div。 同时，这里以最常见的垂直滑动为例，水平方向也是一样。
基本原理图
这种div的长度和高度都是容器高度的100%，可见区域是中间部分。 我们点击touchstart、touchmove、touchend，这和键盘拖拽的原理类似：
1. touchstart时，记下起始位置；
2. touchmove实时估计滑动距离，并允许所有页面一起沿Y轴平移这个距离。
3、touchend时，可以获得最终的滑动距离，并与设定的阈值进行比较。 进入页面手动控制阶段：小于阈值则页面滑动到下一页，大于阈值则返回原来位置。
深入探索
简单版本很容易在前面的部分中实现。 如果没有太多其他需求，并且页面上的元素和动画较少css3 图片水平翻转，基本就够用了。 而本文想要探讨的是如何实现“如丝般顺滑”，虽然只是两个字：性能。
绩效困境是什么？
我们的目标是：在“三多一低”（页面多、元素多、动画多、配置低）的情况下，滑动翻页时，滞后尽可能小。
我们分两部分来看这个问题：右手离开屏幕之前和手臂离开屏幕之后。
在手掌离开屏幕之前
此时比较昂贵的操作是：触发touchmove时，估计要连接的距离，所有页面需要沿Y轴以相同的距离连接。 这时候就不可避免的要进行DOM操作，而DOM操作是非常“昂贵”的。 再加上频繁触发touchmove干扰css3 图片水平翻转，如果性能处理不够好，很容易卡顿。
为了优化性能，我们很自然地想到一个策略：减少DOM操作。
这里有两部分：减少 DOM 操作的元素和减少 DOM 操作的属性。 后者，例如看不到的页面不参与动画。 例如，前者仅更改元素的一个或几个 css 属性。
减少 DOM 操作的元素
在第一个简单版本的情况下，当触发touchmove时，所有页面都沿着Y轴连接。 似乎没有必要，因为相当多的页面是不可见的。 一般情况下，我们至少需要操作多少个页面呢？ 答案是两个。 您还记得，当我们滑动时，我们最多可以同时听到两个页面。 与所有页面连接在一起相比，这种方法使性能提高了一倍。
减少 DOM 操作的属性
这个方法的主要意义在于，你只需要操作DOM一次就可以达到疗效，而不是两次。 其实对于幻灯片动画，我们只需要改变页面的transform值即可，其他的DOM操作（降低class、改变元素的innerHTML）等都可以省略。
我们得到了初步的解决方案：初始化时，将所有页面一次性放入容器中，不仅仅是我们使用的两个页面，而且将display属性设置为none。 touchmove时，只有这两个页面的transform属性发生变化。
touchmove的过程可以写成物理表达式：
表示右手的滑动距离，表示页面的滑动距离，即当前滑动边的宽度，如果是沿y轴滑动，则为页面高度。 说起来，这和现在流行的“数据驱动”的概念很相似。 我们要实现的只是一个渲染函数，输入是用户的交互数据，输出是页面表现。
右手离开屏幕后
当中指离开屏幕时，我们已经知道了滑动的结果（向下还是向上？翻页还是反弹？），而我们想要实现的只是动画的效果。 我们有两个选择：
方案一：复用touchmove的渲染逻辑，使用requestAnimationFrame根据右手滑动的速率来控制动画；
方案二：使用css3过渡动画；
方案一的优点在于，右手滑动和动画过程可以使用相同的渲染函数，最大化代码复用和统一逻辑； 同时，可以精确控制动画的每一帧，动画曲线会更加平滑。 缺点是可能出现性能问题。 方案2正好和方案1相反，虽然最终还是js动画vscss动画的问题。
动画表演实验
为了对比两种方案在H5翻页动画上的表现，我们举一个稍微复杂一点的例子：
H5：百度无人驾驶汽车急聘H5
动漫：从第 1 页翻到第 2 页
CPU：6*减速
浏览器：Chrome61.0.3163.100（64位）
js动画程序：点击这里
css动画方案：点击这里
js翻页动画方案，Profile结果
CSS翻页动画方案，Profile结果
通过实验我们可以看到，js动画过程中，分辨率大多维持在30fps左右。 css动画基本上在60fps左右。 而且在动画过程中，明显感觉到js动画卡住了。 这些情况在一些 CPU 和主板配置相对较低的 Android 机型上尤其明显。 对这个问题感兴趣的朋友可以看一下swiper库的raf分支，也就是本次对比测试使用的js。
因此，js动画方案虽然看起来比较“优雅”，但却可以利用“数据驱动”的理念，统一解决滑动过程和动画过程的问题。 其实是性能有问题。 我们只能使用CSS动画方案来保证右手离开屏幕后的性能。 正好应了那句话“用css能解决的事，千万别用js解决”。
实施计划
右图展示了我们实现的基本思路，只有两页：
当前页：当前页
