海淘科技編者為大家整理了手機WAP網站知識——《移動web之滾動知識篇》
在移動端，使用滾動來處理業(yè)務邏輯的情況有很多，例如列表的滾動加載數據，下拉刷新等等都需要利用滾動的相關知識，但是滾動事件在不同的移動端機型卻又有不同的表現，下面就來一一總結一下。
滾動事件：即onscroll事件，形成原因通俗解釋是當子元素的高度超過父元素的高度時且父元素的高度時定值window除外，就會形成滾動條，滾動分為兩種：局部滾動和body滾動。
onscroll方法： 一般情況下當我們需要監(jiān)聽一個滾動事件時通常會用到onscroll方法來監(jiān)聽滾動事件的觸發(fā)。 如果在瀏覽器上調試這個方法在瀏覽器上很好用，但是如果跑在手機端就沒有想象中的效果了。
body滾動：在移動端如果使用body滾動，意思就是頁面的高度由內容自動撐大，body自然形成滾動條，這時我們監(jiān)聽window.onscroll，發(fā)現onscroll并沒有實時觸發(fā)，只在手指觸摸的屏幕上一直滑動時和滾動停止的那一刻才觸發(fā),采用了wk內核的webview除外。
body滾動
局部滾動
局部滾動：在移動端如果使用局部滾動，意思就是我們的滾動在一個固定寬高的div內觸發(fā)，將該div設置成overflow:scroll/auto;來形成div內部的滾動，這時我們監(jiān)聽div的onscroll發(fā)現觸發(fā)的時機區(qū)分android和ios兩種情況，具體可以看下面表格：
不同機型onscroll事件觸發(fā)情況：
| body滾動 | 局部滾動 | |
| ios | 不能實時觸發(fā) | 不能實時觸發(fā) |
| android | 實時觸發(fā) | 實時觸發(fā) |
| ios wkwebview內核 | 實時觸發(fā) | 實時觸發(fā) |
wkwebview內核:這里說明一下關于ios的wkwebview內核是ios從ios8開始提供的新型webview內核，和之前的uiwebview相比，性能要好，具體大家可以自行查看關于wkwebview的相關概念。
body滾動和局部滾動demo：這里我需要指出的是在采用wkwebview內核的頁面中scroll是可以實時觸發(fā)的，如果使用的是原本的uiwebview則不能夠實時觸發(fā)，手q目前使用的是uiwebview而新版微信使用的是wkwebview，大家可以分別使用來嘗試一下下面的demo：
局部滾動
body滾動
分別用ios手q和微信和android手q體驗會有不同的結果。
正常的滾動：我們平時使用的scroll，包括上面講的滾動都屬于正常滾動，利用瀏覽器自身提供的滾動條來實現滾動，底層是由瀏覽器內核控制。
模擬滾動：最典型的例子就是iscroll(AlloyTouch)了，原理一般有兩種：
1). 監(jiān)聽滾動元素的touchmove事件，當事件觸發(fā)時修改元素的transform屬性來實現元素的位移，讓手指離開時觸發(fā)touchend事件，然后采用requestanimationframe來在一個線型函數下不斷的修改元素的transform來實現手指離開時的一段慣性滾動距離。
2).監(jiān)聽滾動元素的touchmove事件，當事件觸發(fā)時修改元素的transform屬性來實現元素的位移，讓手指離開時觸發(fā)touchend事件，然后給元素一個css的animation，并設置好duration和function來實現手指離開時的一段慣性距離。
方案區(qū)別：這兩種方案對比起來各有好處，第一種方案由于慣性滾動的時機時由js自己控制所以可以拿到滾動觸發(fā)階段的scrolltop值，并且滾動的回調函數onscroll在滾動的階段都會觸發(fā)。
第二種方案相比第一種要劣勢一些，區(qū)別在于手指離開時，采用的時css的animation來實現慣性滾動，所以無法直接觸發(fā)慣性滾動過程中的onscroll事件，只有在animation結束時才可以借助animationend來獲取到事件，當然也有一種方法可以實時獲取滾動事件，也是借助于requestanimationframe來不斷的去讀取滾動元素的transform來拿到scrolltop同時觸發(fā)onscroll回調。
demo體驗：關于模擬滾動和正常滾動，兩者在性能上差別還是比較明顯的，下面時兩個demo，可以掃描體驗一下：
正常滾動模擬滾動
衡量指標：衡量滾動是否流暢的指標fps，我這邊也統(tǒng)計了一下正常滾動和模擬滾動的fps數據：
正常滾動
模擬滾動
結論： 模擬滾動的fps值波動較大，這樣滾動起來會有明顯的卡頓感覺，各位體驗的時候如果滾動超過10屏之后就可以明顯感覺到兩著的區(qū)別。
在使用模擬滾動時，瀏覽器在js層面會消耗更多的性能去改變dom元素的位置，在dom復雜層級深的頁面更為高，所以在長列表滾動時還要使用正常滾動更好。
下拉刷新的元素在頁面頂部，正常瀏覽時不可見的。
當在頁面頂部往下滾動時出現下拉刷新元素，當手指離開時收起。
以上兩點時實現一個下拉刷新組件的基本步驟，結合我們上述關于滾動的描述，我們可以這樣實現下拉刷新：
方案1：借助iscroll的原理，整個頁面使用模擬滾動，將下拉刷新元素放在頂部，當頁面滾動到頂部下拉時，下拉刷新元素隨著頁面的滾動出現，當手指離開時收回，此方案實現起來較為簡單直接借助iscoll即可，但是使用了模擬滾動之后在正常的列表滾動時性能上不如正常滾動。
方案2：頁面使用正常滾動，將下拉刷新元素放置在頂部top值為負值(正常情況下不可見)，當頁面處于頂部時下拉，這時監(jiān)聽touchmove事件，修改scrollcontent的tranlateY值，同時修改下拉刷新元素的tranlateY值，將兩者同時位移來將下拉刷新元素顯示出來，手指離開時(touchend)收回，這種方案滿足了在正常列表滾動時使用原生的滾動節(jié)省性能，只在下拉刷新時使用模擬滾動來實現效果。
方案3：方案2的改良版，唯一不同是將下拉刷新元素和scrollcontent放在一個div里，將下拉刷新元素的margintop設為負值，在下拉刷新時，只需要修改scrollcontent一個元素的tranlateY值即可實現下拉，在性能上要比方案2好。
性能問題：在采用了上述方案之后，還會有一個性能上的問題就是：當頁面的列表過長，dom元素過多時，在模擬滾動，下拉刷新這段時間內，頁面也會有卡頓現象，這里采取了一個
優(yōu)化策略：
1) 列表較長時dom數量較多時，在觸發(fā)下拉刷新的時機時將頁面視窗之外的dom元素隱藏或者存放在fragment里面。
2) 在刷新完成之后手指離開(touchend)時將隱藏的元素顯示出來。
3) 需要注意的是，隱藏和顯示視窗外的元素這個操作在下拉刷新時只會執(zhí)行一次，并且只有在下拉刷新時才會執(zhí)行。
以上就是上海APP開發(fā)公司——海淘科技為你整理《移動web之滾動知識篇》的全部內容。想看更多的手機建站知識，可點擊：手機建站知識。
