打造絲般順滑的 H5 翻頁庫(kù)

景

隨著近幾年移動(dòng)營(yíng)銷頁的火爆，催生了一個(gè)中國(guó)式的名詞「H5」。而 H5 最常見的形態(tài)就是類似幻燈片翻頁效果。

我們需要制作 H5 的時(shí)候，最快的辦法就是使用一些滑動(dòng)插件庫(kù)，如 iDangero.us 出品的 Swiper，百度 BE-FE 出品的 iSlider。通過這些翻頁庫(kù)提供的強(qiáng)大的配置功能，我們就能實(shí)現(xiàn)很酷炫的翻頁效果。當(dāng)然，這些庫(kù)還支持自動(dòng)播放，點(diǎn)擊切換和當(dāng)前頁面指示等配置，所以還能用在網(wǎng)頁上，實(shí)現(xiàn)一些 web carousel 的效果。

百度 H5 也先后使用了 Swiper 和 iSlider 作為 H5 運(yùn)行時(shí)的翻頁框架，隨著用戶越來越多，也遇到了一些問題：

H5 平臺(tái)和這些庫(kù)不能很好貼合，有些配置項(xiàng)用不上，而有些必要的功能需要「Hack」的方式實(shí)現(xiàn)。
一些 H5 的元素多、動(dòng)畫多，在低端機(jī)型上翻頁時(shí)，翻頁時(shí)會(huì)有「卡頓感」和「粘滯感」，用戶體驗(yàn)不好。

而我們希望的 H5 翻頁庫(kù)能和平臺(tái)本身的功能完美貼合，在保持體積小的同時(shí)，在翻頁的時(shí)候能做到「絲般順滑」。于是我們就開始了研(zao)究(lun)之(zi)旅。

開始

H5 滑屏框架的開發(fā)，第一個(gè)問題就是：頁面是否跟隨手指滑動(dòng)？這也是騰訊 ISUX 團(tuán)隊(duì)的《滑屏 H5 開發(fā)實(shí)踐九問》的第一問（這篇文章原文出處現(xiàn)在是 404 ，大家可以在其他的轉(zhuǎn)載網(wǎng)站看到），這里用這篇文章的圖片說明一下這個(gè)問題。

上圖：不跟隨手指滑動(dòng)，下圖：跟隨手指滑動(dòng)。

左邊的是不跟隨手指滑動(dòng)，只需要關(guān)注手指觸碰開始和離開兩個(gè)時(shí)間點(diǎn)，中間過程不用考慮。所以實(shí)現(xiàn)起來比較簡(jiǎn)單。但是用戶的操作沒有實(shí)時(shí)的反饋，體驗(yàn)不夠好。因此，盡管實(shí)現(xiàn)起來更復(fù)雜，我們?nèi)匀粵Q定實(shí)現(xiàn)前一種「跟隨手指滑動(dòng)」的效果。

起步

下圖是跟隨手指滑動(dòng)的 H5 最直觀的版本，所有的「頁面」依次從上到下，首尾相接。需要說明一下，這里的「頁面」打引號(hào)，是因?yàn)閷?shí)際上他們都是 div，后文說的頁面都指這些 div。同時(shí)，我們這里以最常見的豎直方向滑動(dòng)為例，水平方向同理。

基本原理圖

這些 div 的寬度和高度都是 100% 的容器高度，可視區(qū)域是中間的部分，我們監(jiān)聽 touchstart, touchmove, touchend 事件，跟鼠標(biāo)拖拽的原理類似：

touchstart 時(shí)，記下起點(diǎn)位置；
touchmove 實(shí)時(shí)計(jì)算滑動(dòng)的距離，讓所有頁面一起沿著 Y 軸 translate 這段距離。
touchend 時(shí)，能得到最終的滑動(dòng)距離，跟設(shè)定的閾值比較。進(jìn)入到頁面自動(dòng)控制階段：大于閾值則讓頁面滑動(dòng)到下一頁，小于閾值則恢復(fù)到起始位置。

深入探究

簡(jiǎn)單的版本在上一部分很容易就實(shí)現(xiàn)了，如果其他需求不多，頁面上元素和動(dòng)畫比較少，基本上就夠用了。但是本文要探究的是如何能做到「絲般順滑」，其實(shí)就是兩個(gè)字：性能。

性能的瓶頸是什么呢？

我們的目標(biāo)是：在「三多一低」（頁面多、元素多、動(dòng)畫多，配置低）的情況下，滑動(dòng)翻頁時(shí)，盡可能不產(chǎn)生卡頓。

我們分成兩部分來看這問題：手指離開屏幕前和手指離開屏幕后。

手指離開屏幕前

此時(shí)比較耗費(fèi)性能的操作是：當(dāng) touchmove 觸發(fā)時(shí)，計(jì)算出了要移動(dòng)的距離，所有的頁面都需要沿著 Y 軸移動(dòng)相同的距離。此時(shí)必然免不了進(jìn)行 DOM 操作，而 DOM 操作是非常「昂貴」的，再加上 touchmove 事件的頻繁觸發(fā)，性能處理不夠好的話，很容易出現(xiàn)卡頓。

為了優(yōu)化性能，我們很自然的想到一個(gè)策略：減少 DOM 操作。

這里面包含兩部分：減少 DOM 操作的元素和減少 DOM 操作的屬性。前者比如，看不到的頁面不參與動(dòng)畫。后者比如，只改變?cè)氐?css 屬性的一個(gè)或幾個(gè)。

減少 DOM 操作的元素

最開始簡(jiǎn)易的版本的例子中，touchmove 觸發(fā)時(shí)，所有的頁面都沿著 Y 軸移動(dòng)。其實(shí)沒有必要，因?yàn)橄喈?dāng)一部分頁面是看不見的。那一般情況下，我們最少需要操作幾個(gè)頁面呢？答案是兩個(gè)。可以回想一下，我們滑動(dòng)的時(shí)候，最多能同時(shí)看到兩個(gè)頁面。這個(gè)方法相對(duì)于所有的頁面一起移動(dòng)，成倍地提升性能。

減少 DOM 操作的屬性

這個(gè)方法的主要意思是，只需要操作一次 DOM 能達(dá)到的效果，絕不用兩次。實(shí)際上，對(duì)于 slide 動(dòng)畫，我們只需要改變頁面的 transform的值，其他的 DOM 操作（增加 class，修改元素的 innerHTML）等能不做就不做。

我們得到了一個(gè)初步的方案：初始化時(shí)，所有的頁面一次性全部置入 container，除了我們用到的兩頁，display 屬性都設(shè)置為 none。touchmove 的時(shí)候，只有這兩頁的 transform 屬性有變化。

touchmove 的過程，我們可以寫成數(shù)學(xué)表達(dá)式：

s=f(x),x∈[0,sideLength]

x 表示手指滑動(dòng)的距離，s

s 表示頁面滑動(dòng)距離，sideLength

sideLength 是當(dāng)前滑動(dòng)邊的長(zhǎng)度，如果是沿 y 軸滑動(dòng)，則是頁面高度。寫到這里，就跟時(shí)下很流行的「數(shù)據(jù)驅(qū)動(dòng)」的概念很類似了。我們要實(shí)現(xiàn)的就只有一個(gè) render 函數(shù)，輸入是用戶的交互數(shù)據(jù)，輸出是頁面表現(xiàn)。

手指離開屏幕后

當(dāng)手指離開屏幕時(shí)，我們就已經(jīng)知道了這次滑動(dòng)的結(jié)果（向上還是向下？翻頁還是回彈？），要實(shí)現(xiàn)的只是動(dòng)畫效果，我們有兩個(gè)選擇：

方案一：復(fù)用 touchmove 的 render 邏輯，按照手指滑動(dòng)的速度，使用 requestAnimationFrame 控制動(dòng)畫；

方案二：使用 css3 transition 動(dòng)畫；

方案一的優(yōu)點(diǎn)在于：可以在手指滑動(dòng)和動(dòng)畫過程使用同樣的 render 函數(shù)，最大限度復(fù)用了代碼，邏輯統(tǒng)一；同時(shí)可以精確控制動(dòng)畫的每一幀，動(dòng)畫曲線會(huì)比較流暢。缺點(diǎn)就是可能存在的性能問題。方案二跟方案一剛好相反。其實(shí)說到底還是 js 動(dòng)畫 vs css 動(dòng)畫的問題。

動(dòng)畫性能實(shí)驗(yàn)

為了比較兩個(gè)方案在 H5 翻頁動(dòng)畫上的性能優(yōu)劣，我們?nèi)∫粋€(gè)稍微復(fù)雜點(diǎn)的例子：

H5：百度無人車招聘的 H5

動(dòng)畫：從第 1 頁翻到第 2 頁

CPU： 6 * slowdown

瀏覽器：Chrome 61.0.3163.100（64 位）

js 動(dòng)畫方案：點(diǎn)擊這里

css 動(dòng)畫方案：點(diǎn)擊這里

js 翻頁動(dòng)畫方案，Profile 結(jié)果

css 翻頁動(dòng)畫方案，Profile 結(jié)果

通過實(shí)驗(yàn)我們可以看到，js 的動(dòng)畫過程中，幀率大多維持在 30 fps 上下。而 css 動(dòng)畫，基本都在 60 fps 上下。而且在動(dòng)畫過程中，明顯感覺 js 動(dòng)畫有卡頓。這種情況在一些 CPU 和顯卡配置相對(duì)低的 Android 機(jī)型上尤為明顯。對(duì)于這個(gè)問題有興趣的同學(xué)，可以看一下 swiper 庫(kù)的 raf 分支，這是本次對(duì)比測(cè)試所用到的 js 。

所以，盡管 js 的動(dòng)畫方案看起來比較「優(yōu)雅」，能用「數(shù)據(jù)驅(qū)動(dòng)」的理念，統(tǒng)一解決滑動(dòng)過程和動(dòng)畫過程的問題。實(shí)際上性能有瓶頸，我們只能在手指離開屏幕后，采用 css 的動(dòng)畫方案以保證性能。正應(yīng)了一句話「能用 css 做的，絕對(duì)不要用 js 解決」。

實(shí)施方案

下圖形象地展示了我們實(shí)施的基本思路，只有兩頁：

currentPage ：當(dāng)前頁面

activePage：即將要翻到的下一頁

其余的頁面都是初始化的時(shí)候加載進(jìn) DOM 結(jié)構(gòu)，但是 display 為 none 并且 z-index 都是 0。這里展示「層疊」的狀態(tài)是為了更形象的展示。

swiper 原理圖

為了方便獲取頁面，我們采用雙向鏈表保存頁面結(jié)構(gòu)。每個(gè) page 具有 prev 和 next 分別指向上一個(gè)和下一個(gè) page。

我們重點(diǎn)要關(guān)注的是，怎么樣確定 activePage ？即下一個(gè)要去到的頁面。答案很簡(jiǎn)單，其實(shí)，當(dāng)用戶開始觸碰屏幕，并且滑動(dòng)的時(shí)候，就能確定了：

滑動(dòng)距離 x < 0，表示頁面向上滑動(dòng)，此時(shí) activepage = currentPage.next
滑動(dòng)距離 x > 0，表示頁面向下滑動(dòng)，此時(shí) activepage = currentPage.prev

擴(kuò)展

翻頁效果

我們舉的例子中的翻頁效果是最普通的滑動(dòng)效果。怎么樣擴(kuò)展支持立方體、翻轉(zhuǎn)等效果呢？可以回頭看看「手指離開屏幕前」部分，我們提出了 s=f(x)

s=f(x)，x

x 是用戶滑動(dòng)距離，s

s 是頁面滑動(dòng)距離。我們把 s

s 擴(kuò)展一下，變成「頁面翻轉(zhuǎn)角度」或「頁面縮放比率」，就可以支持其他的效果了。

事實(shí)上，我們?cè)诨瑒?dòng)的時(shí)候，本身就是使用 css3 的 transform 屬性，將其中的 translate, rotate, scale 適當(dāng)?shù)慕M合就能做出千變?nèi)f化的翻頁效果了。

更令人愉悅的動(dòng)畫

這里指的是 animation-timing-function，拿最簡(jiǎn)單的滑動(dòng)效果舉例。如果是線性的函數(shù)，用戶滑動(dòng)的速度始終等于頁面滑動(dòng)速度。而「感覺上」更流暢、更靈敏的應(yīng)該是：剛開始頁面滑動(dòng)速度大于用戶滑動(dòng)速度，隨著翻頁的進(jìn)行，兩者趨于相同，過了某個(gè)點(diǎn)后，單位時(shí)間內(nèi)，頁面滑動(dòng)速度開始逐漸小于用戶滑動(dòng)速度，將速度表示為距離，就可以得到 x

x 和 s

s 之間的關(guān)系如下圖：

x 和 s

s 的關(guān)系圖（橫軸為 x

x，縱軸為 s

s）

在這里，不得不再提起兩種動(dòng)畫方案： js 動(dòng)畫和 css 動(dòng)畫。

js 動(dòng)畫方案的一個(gè)優(yōu)點(diǎn)是，可以精確控制動(dòng)畫的進(jìn)程，而 css 無法做到。比如用戶在 x = 0.8 的時(shí)候手指離開屏幕，因?yàn)椴捎玫耐粋€(gè) render，js 可以知道手指離開屏幕的瞬間 x 處于 0.8 的位置，接下來的動(dòng)畫由 requestAnimationFrame 完成，整個(gè)過程流暢且完整。

而 css 動(dòng)畫則不同，css 動(dòng)畫只有在動(dòng)畫開始之前設(shè)定 animation-timing-function，當(dāng)用戶在 x = 0.8 手指離開屏幕時(shí)，原本的 js 控制滑動(dòng)過程中斷，由 css 來完成剩余的動(dòng)畫，css 無法根據(jù)手指離開屏幕的瞬間動(dòng)態(tài)計(jì)算 animation-timing-function ，所以在銜接的那個(gè)點(diǎn)，兩者速度不匹配，會(huì)影響整體動(dòng)畫效果。

但遺憾的是，js 的動(dòng)畫方案有性能問題，我們?cè)谟脩羰种鸽x開屏幕后的那一部分只能采取 css 動(dòng)畫方案。這個(gè)「更令人愉悅的動(dòng)畫」也只能用在手指滑動(dòng)期間。

總結(jié)和展望

本文講述了一個(gè)「絲般順滑」的 H5 翻頁庫(kù)的開發(fā)過程中遇到的一些問題和對(duì)應(yīng)的解決方法。基本的滑動(dòng)翻頁模型建立之后，重點(diǎn)關(guān)注了性能的問題，分為手指離開屏幕前和手指離開屏幕后兩個(gè)階段。前一階段主要聚焦于減少 DOM 操作。后一階段聚焦于動(dòng)畫的性能，并且對(duì)比了 js 動(dòng)畫和 css 動(dòng)畫的性能數(shù)據(jù)，最后得出了在手指離開屏幕后使用 css 動(dòng)畫的結(jié)論。此外，我們還基于「數(shù)據(jù)驅(qū)動(dòng)」的思想，在翻頁效果和動(dòng)畫函數(shù)兩部分進(jìn)行了擴(kuò)展，增強(qiáng)了翻頁庫(kù)的功能，也豐富了 H5 的展現(xiàn)效果。

本文中嘗試用「數(shù)據(jù)驅(qū)動(dòng)」的思想去解釋整個(gè)過程，但是因?yàn)樾阅軉栴}只能暫時(shí)放棄，希望在未來能找到更好的方案。由于水平所限，文中難免會(huì)出現(xiàn)紕漏，歡迎大家批評(píng)指正，共同學(xué)習(xí)進(jìn)步。感謝 Swiper 和 islider 翻頁庫(kù)的啟發(fā)，特別感謝和 @Ronny 的熱烈討論。

本文所述的 swiper 庫(kù)地址：https://github.com/fex-team/swiper。master 分支所用的代碼是目前百度 H5 線上使用的。raf 分支是文中提到的使用 js 動(dòng)畫方案。

希望本文能幫助到您！

點(diǎn)贊+轉(zhuǎn)發(fā)，讓更多的人也能看到這篇內(nèi)容（收藏不點(diǎn)贊，都是耍流氓-_-）

關(guān)注｛我｝，享受文章首發(fā)體驗(yàn)！

每周重點(diǎn)攻克一個(gè)前端技術(shù)難點(diǎn)。更多精彩前端內(nèi)容私信我回復(fù)“教程”

原文鏈接：http://fex.baidu.com/blog/2017/10/build-a-silky-smooth-slide-library/

作者：zhangbobell

篇給大家介紹了，控件測(cè)試、界面及易用性、可靠性測(cè)試，今天我們一起來看看翻頁控件、輸入框、搜索框、增刪改功能試。

通用測(cè)試點(diǎn)——翻頁控件

2、總頁數(shù)，當(dāng)前頁數(shù) 　　

3、指定跳轉(zhuǎn)頁　　

4、指定每頁顯示條數(shù) 　　

當(dāng)然，有一些是少于多少頁，全部以數(shù)字的形式顯示，多于多少頁后，才出現(xiàn)下一頁的控件。本文暫且用以上四點(diǎn)來作為通用的用例來設(shè)計(jì)吧。　　

對(duì)于1翻頁鏈接或按鈕的測(cè)試，主要要檢查的測(cè)試點(diǎn)有：　　

1、有無數(shù)據(jù)時(shí)控件的顯示情況　　

2、在首頁時(shí)，首頁和上一頁是否能點(diǎn)擊　　

3、在尾頁時(shí)，下一頁和尾頁是否能點(diǎn)擊　　

4、在非首頁和非尾頁時(shí)，四個(gè)按鈕的功能是否正確　　

5、翻頁后，列表中的記錄是否按照指定的排序列進(jìn)行了排序　　

對(duì)于2總頁數(shù)，當(dāng)前頁數(shù)，主要要檢查的測(cè)試點(diǎn)有：　　

1、總頁數(shù)是否等于總的記錄數(shù)/指定每頁條數(shù) 　　

2、當(dāng)前頁數(shù)是否正確　　

對(duì)于3指定跳轉(zhuǎn)頁，主要要檢查的測(cè)試點(diǎn)有：　　

1、是否能正常跳轉(zhuǎn)到指定的頁數(shù) 　　

2、輸入地跳轉(zhuǎn)頁數(shù)非法時(shí)的處理　　

對(duì)于4指定每頁顯示條數(shù)，主要要檢查的測(cè)試點(diǎn)有：　　

1、是否有默認(rèn)地指定每頁顯示條數(shù) 　　

2、指定每頁的條數(shù)后，列表顯示的記錄數(shù)，頁數(shù)是否正確　　

3、輸入的每頁條數(shù)非法時(shí)的處理　　

分析完上面的測(cè)試點(diǎn)，應(yīng)該可以進(jìn)行用例的設(shè)計(jì)了。　　

step 1: 列表無記錄　　

expect:

1、四個(gè)翻頁控件變灰不可點(diǎn)擊　　

2、列表有相應(yīng)的無數(shù)據(jù)信息提示　　

3、不可指定頁數(shù) 　　

4、不可指定跳轉(zhuǎn)頁　　

5、總頁數(shù)顯示為0 　　

6、當(dāng)前頁數(shù)顯示為0 　　

step 2: 列表的記錄數(shù)<=指定的每頁顯示條數(shù) 　　

expect:

1、四個(gè)翻頁控件變灰不可點(diǎn)擊　　

2、總頁數(shù)顯示為1 　　

3、當(dāng)前頁數(shù)顯示為1 　　

step 3: 列表的記錄數(shù)>指定的每頁顯示條數(shù) 　　

expect:

1、默認(rèn)在首頁，當(dāng)前頁數(shù)為1 　　

2、列表的數(shù)據(jù)按照指定的排序列正確排序　　

3、記錄數(shù)與數(shù)據(jù)庫(kù)相符　　

4、總頁數(shù)=記錄數(shù)/指定的每頁顯示條數(shù) 　　

step 4: 列表的記錄數(shù)>指定的每頁顯示條數(shù)，在首頁　　

expect: 1、首頁變灰不可點(diǎn)擊　　

2、上一頁變灰不可點(diǎn)擊　　

3、下一頁可點(diǎn)擊，從(每頁指定條數(shù)+1)條記錄開始顯示，當(dāng)前頁數(shù)+1 　　

4、尾頁可點(diǎn)擊，顯示最后頁的記錄　　

step 5: 列表的記錄數(shù)>指定的每頁顯示條數(shù)，在中間的某頁　　

expect: 1、首頁可點(diǎn)擊，顯示1到每頁指定條數(shù)的記錄　　

2、上一頁可點(diǎn)擊，顯示上一頁的記錄　　

3、下一頁可點(diǎn)擊，從后一頁的記錄　　

4、尾頁可點(diǎn)擊，顯示最后頁的記錄　　

5、列表的數(shù)據(jù)按照指定的排序列正確排序　　

6、當(dāng)前頁數(shù)為所在頁　　

step 6:列表的記錄數(shù)>指定的每頁顯示條數(shù)，在尾頁　　

expect: 1、首頁可點(diǎn)擊，顯示1到每頁指定條數(shù)的記錄　　

2、上一頁可點(diǎn)擊，顯示上一頁的記錄　　

3、下一頁變灰不可點(diǎn)擊　　

4、尾頁變灰不可點(diǎn)擊　　

5、列表的數(shù)據(jù)按照指定的排序列正確排序　　

6、當(dāng)前頁數(shù)為最后一頁的頁數(shù) 　　

step 7:輸入每頁顯示條數(shù)為正整數(shù) 　　

expect: 1、每頁顯示條數(shù)更新成指定的條數(shù) 　　

2、超過指定的條數(shù)的記錄分頁顯示　　

3、總頁數(shù)更新成列表的記錄數(shù)/每頁顯示條數(shù) 　　

step 8:輸入每頁顯示條數(shù)為0 　　

expect: 1、提示“每頁顯示條數(shù)必須為大于1的整數(shù)” 　　