主流移动滚动插件分析以及思路方案拓展(原生onscroll 事件实现的滚动加载不逊色)

11次阅读

共计 4023 个字符,预计需要花费 11 分钟才能阅读完成。

背景
现在流行的各种移动端滚动加载、上拉刷新组件,滑动越来越流畅,体验很好;例如 better-scroll、vue-infinite-scroll、iscroll、vue-scroll 等等比较好的方案去解决业务上的问题,可是笔者总会听到使用过程中也会产生一些奇怪的问题,或许会引起很多人的共鸣比如很多 better-scroll 小白会在一开始发现不能滚动,或者滚动加载异步数据 better-scroll 页面怎么不能滚动
滚动加载了重复的数据(分页)、明明下面有数据,却拉不动等等各种姿势不对。笔者曾经已入坑了 vue-infinite-scroll 和 vue-scrollvue-infinite-scroll 是利用原生 scroll 滚动,优点是原生滚动可以在列表加载了很多的时候不会卡顿,(黑科技)ios 在微信上点两下回到顶部,但是不能滑动加速,插件本身不支持下拉刷新,而且在 v -if 的组件下用到滚动比如一个侧边栏,会报错 $mount error,发现原因是我组件还是隐藏的时候,插件默认给我去跑 $mount 钩子 , 我是通过改源码解决的,好坑,不过官方还是很快地发现了这个 bug, 所以我觉得仍然是比较靠谱的 vue-scroller 坑比较多,现在好像已经好久没维护了,不知道大家有无遇到过, 在同一个页面用 vue-scroll 然后弹窗要 textarea 输入,超过行数产生滚动条,但坑爹的是 textarea 竟然不能滚动了,看源码发现是 touchMove 的事件里禁止了原生滚动,提了链接 issue,我只能手动改源码了, 有图有真相
对于滚动插件的实现原理以及优缺点
对 better-scroll、vue-scroll 这类滚动插件是要父元素 container 定位在 body, 禁止原生滚动,然后通过 touch 事件,改变 transform: translateY 去实现,然后 refresh 去更新模拟滚动条长度
对于 vue-infinite-scroll 这一类是通过原生 onscroll 事件,判断 scrollTop 到达底部触发 loadMore 加载异步数据, 当然原生的 scroll 的缺点是 滚动点透,比如说在 body 上有一个弹窗滚动,滚动到底部之后会发现 body 在滚了;第二个问题是,在 finger 触摸滚动而未结束滚动时,如果要做一些动作会有延时,不能像 touchMove、touchEnd 那么灵敏
我也是看了这篇文章得到了启发
知识点 1: 移动 web 滚动问题在移动端,使用滚动来处理业务逻辑的情况有很多,例如列表的滚动加载数据,下拉刷新等等都需要利用滚动的相关知识,但是滚动事件在不同的移动端机型却又有不同的表现,下面就来一一总结一下。滚动事件:即 onscroll 事件,形成原因通俗解释是当子元素的高度超过父元素的高度时且父元素的高度时定值 window 除外,就会形成滚动条,滚动分为两种:局部滚动和 body 滚动。onscroll 方法:一般情况下当我们需要监听一个滚动事件时通常会用到 onscroll 方法来监听滚动事件的触发。如果在浏览器上调试这个方法在浏览器上很好用,但是如果跑在手机端就没有想象中的效果了。body 滚动:在移动端如果使用 body 滚动,意思就是页面的高度由内容自动撑大,body 自然形成滚动条,这时我们监听 window.onscroll,发现 onscroll 并没有实时触发,只在手指触摸的屏幕上一直滑动时和滚动停止的那一刻才触发, 采用了 wk 内核的 webview 除外。
body 滚动局部滚动 局部滚动:在移动端如果使用局部滚动,意思就是我们的滚动在一个固定宽高的 div 内触发,将该 div 设置成 overflow:scroll/auto; 来形成 div 内部的滚动,这时我们监听 div 的 onscroll 发现触发的时机区分 android 和 ios 两种情况,具体可以看下面表格:不同机型 onscroll 事件触发情况:body 滚动 局部滚动 ios 不能实时触发 不能实时触发 android 实时触发 实时触发 ios wkwebview 内核 实时触发 实时触发 wkwebview 内核: 这里说明一下关于 ios 的 wkwebview 内核是 ios 从 ios8 开始提供的新型 webview 内核,和之前的 uiwebview 相比,性能要好,具体大家可以自行查看关于 wkwebview 的相关概念。body 滚动和局部滚动 demo:这里我需要指出的是在采用 wkwebview 内核的页面中 scroll 是可以实时触发的,如果使用的是原本的 uiwebview 则不能够实时触发,手 q 目前使用的是 uiwebview 而新版微信使用的是 wkwebview,大家可以分别使用来尝试一下下面的 demo:局部滚动 body 滚动
分别用 ios 手 q 和微信和 android 手 q 体验会有不同的结果。知识点 2: 关于模拟滚动

有了上面介绍的关于滚动的知识,理解的模拟滚动就不难了。
正常的滚动:我们平时使用的 scroll,包括上面讲的滚动都属于正常滚动,利用浏览器自身提供的滚动条来实现滚动,底层是由浏览器内核控制。
模拟滚动:最典型的例子就是 iscroll 了,原理一般有两种:

1). 监听滚动元素的 touchmove 事件,当事件触发时修改元素的 transform 属性来实现元素的位移,让手指离开时触发 touchend 事件,然后采用 requestanimationframe 来在一个线型函数下不断的修改元素的 transform 来实现手指离开时的一段惯性滚动距离。
2). 监听滚动元素的 touchmove 事件,当事件触发时修改元素的 transform 属性来实现元素的位移,让手指离开时触发 touchend 事件,然后给元素一个 css 的 animation,并设置好 duration 和 function 来实现手指离开时的一段惯性距离。

这两种方案对比起来各有好处,第一种方案由于惯性滚动的时机时由 js 自己控制所以可以拿到滚动触发阶段的 scrolltop 值,并且滚动的回调函数 onscroll 在滚动的阶段都会触发。
第二种方案相比第一种要劣势一些,区别在于手指离开时,采用的时 css 的 animation 来实现惯性滚动,所以无法直接触发惯性滚动过程中的 onscroll 事件,只有在 animation 结束时才可以借助 animationend 来获取到事件,当然也有一种方法可以实时获取滚动事件,也是借助于 requestanimationframe 来不断的去读取滚动元素的 transform 来拿到 scrolltop 同时触发 onscroll 回调。

模拟滚动的 fps 值波动较大,这样滚动起来会有明显的卡顿感觉,各位体验的时候如果滚动超过 10 屏之后就可以明显感觉到两着的区别。
在使用模拟滚动时,浏览器在 js 层面会消耗更多的性能去改变 dom 元素的位置,在 dom 复杂层级深的页面更为高,所以在长列表滚动时还要使用正常滚动更好。知识点 3: 滚动和下拉刷新

下拉刷新的元素在页面顶部,正常浏览时不可见的。
当在页面顶部往下滚动时出现下拉刷新元素,当手指离开时收起。
以上两点时实现一个下拉刷新组件的基本步骤,结合我们上述关于滚动的描述,我们可以这样实现下拉刷新:

方案 1:借助 iscroll 的原理,整个页面使用模拟滚动,将下拉刷新元素放在顶部,当页面滚动到顶部下拉时,下拉刷新元素随着页面的滚动出现,当手指离开时收回,此方案实现起来较为简单直接借助 iscoll 即可,但是使用了模拟滚动之后在正常的列表滚动时性能上不如正常滚动。方案 2:页面使用正常滚动,将下拉刷新元素放置在顶部 top 值为负值(正常情况下不可见),当页面处于顶部时下拉,这时监听 touchmove 事件,修改 scrollcontent 的 tranlateY 值,同时修改下拉刷新元素的 tranlateY 值,将两者同时位移来将下拉刷新元素显示出来,手指离开时(touchend)收回,这种方案满足了在正常列表滚动时使用原生的滚动节省性能,只在下拉刷新时使用模拟滚动来实现效果。方案 3:方案 2 的改良版,唯一不同是将下拉刷新元素和 scrollcontent 放在一个 div 里,将下拉刷新元素的 margintop 设为负值,在下拉刷新时,只需要修改 scrollcontent 一个元素的 tranlateY 值即可实现下拉,在性能上要比方案 2 好。
在采用了上述方案之后,还会有一个性能上的问题就是:当页面的列表过长,dom 元素过多时,在模拟滚动,下拉刷新这段时间内,页面也会有卡顿现象,这里采取了一个优化策略即:
1) 列表较长时 dom 数量较多时,在触发下拉刷新的时机时将页面视窗之外的 dom 元素隐藏或者存放在 fragment 里面。2) 在刷新完成之后手指离开(touchend)时将隐藏的元素显示出来。3) 需要注意的是,隐藏和显示视窗外的元素这个操作在下拉刷新时只会执行一次,并且只有在下拉刷新时才会执行。
看完这篇文章,会感觉 better-scroll 也没那么牛逼了
自己的看法
滚动加载、上拉刷新一直是个前端界内一直在解决的题目,最近越发感觉自己要有自己的滚动插件,一个是用别人的东西不顺手,有问题只能在百度碰运气,解决不了问题可能要换框架或者改源码,时间也是挺耗的
我还是喜欢 原生的 onscroll 滚动加载,自己现在也是用这个实现的滚动加载,屡试不爽 在大神面前惭愧地贴下代码

进入页面时 document.addEventListener(“scroll”, this.isToBottom); 离开页面时 document.removeEventListener(“scroll”, this.isToBottom);
敬请期待
现在笔者正开发一个用两百行代码就可以实现原生 onscroll 滚动加载、下拉刷新,能够两次点击回到顶部、尽力打造稳定、解决问题、兼容性好、入手快、维护简单、源码简易的一个插件,区别于 better-scroll 这种流畅感较好的插件,也算是一个 符合大众的一个解决方案,没有最好的只有最适合自己的

正文完
 0