首页 > Iscroll解析

Iscroll解析

做了一些移动端的产品,发现一些滚动效果很多会使用 iscroll 作为底层库(如阿里小蜜)。iscroll 的文档已经好久没更新了,而且比较简单,经常需要直接读源码。这里写一篇总结,作为对 iscroll API的整理。而 iscroll 的库 probe,lite,zoom,infinite 和标准库等多个版本,而 probe 是平时运用的比较多的一个库,除了 iscroll 的标准库之外,还有 snap(广义翻页) 功能。这里主要以 probe 做整理。去掉里面的 scrollbars/indicators 部分,因为这两部分内容一般视觉不会有太多要求。但这一部分的内容在 iscroll 库中和 iscroll 的主体内容同等地位,个人觉得没有必要。

Iscroll的核心

仔细想想,如果我们要实现类似功能的触控库,我们会怎么做?正常思路大概就是:

检测 ->  处理数据 -> 产生位移

思路大概就是这样,和现实生活中的控制很类似:通过传感器检测数据,而我们这里的检测设备就是注册的一系列事件。检测到的数据往往属于原始数据,没有办法直接使用,这里就需要进行相应的处理。处理完后,就需要滚动屏幕,对应到实现就是操作 dom 的位置属性。

仔细看了一下 iscroll 的源码,果然也是采用类似的思路,一下是 iscroll 核心处理逻辑:

首先,iscroll 检测是每次初始化的时候,通过 HandEvent 注册一系列的函数。为了同时兼容无线和 PC 等多个端,同一类型的事件需要注册多个。简单的分有以下几类:

除了以上三个,还有 transitionend,wheel,keydown,click 等一系列事件。

除此之外,还有 _transitionEnd(e),_wheel(e),_key(e) 等处理函数。

配置

var myScroll = new IScroll('#wrapper', {
    mouseWheel: true,
    scrollbars: true
});

初始化出入的第二个参数为配置,会挂载到 myScroll 的 options 属性上。

方法

监听事件

局限

iscroll 有很多优点,最主要的是相对稳定,还有一系列兼容性处理。但他有一些局限性,主要的局限性是它的可扩展性较差。一个栗子:当我们想对某一元素进行拖拽时,会发现很难用 iscroll。而产生这一问题的主要原因时:iscroll 的 scroll 等监听事件是在元素移动时才会触发。也就说 iscroll 没有暴露出触控 api 给用户使用。

【热门文章】
【热门文章】