言

在CSS3中新增了很多的新特性，其中使用頻率比較高的應(yīng)該是動(dòng)畫(huà)效果了，它可以幫助我們實(shí)現(xiàn)以前使用Javascript才能實(shí)現(xiàn)的效果，極大的提高網(wǎng)頁(yè)的性能。今天這篇文章我們就來(lái)一起看一個(gè)使用CSS3新特性完成的翻書(shū)效果吧。

本文的源碼已經(jīng)放在了Github上，感興趣的可以clone到本地試試，地址如下。

https://github.com/zhouxiongking/article-pages/blob/master/articles/rollPage/rollPage.html

CSS3

實(shí)現(xiàn)效果

首先我們來(lái)看看實(shí)際的運(yùn)行效果，動(dòng)態(tài)圖如下所示。

效果圖

頁(yè)面分析

在看到上述的效果圖后，我們來(lái)進(jìn)行分析，這個(gè)過(guò)程是如何實(shí)現(xiàn)的。

這個(gè)頁(yè)面我們通過(guò)一個(gè)ul包含三個(gè)li來(lái)實(shí)現(xiàn)，每個(gè)li都給一個(gè)固定的寬度和高度。

• 第一個(gè)li在頁(yè)面上靜止不動(dòng)。

• 第二個(gè)li添加動(dòng)畫(huà)效果，使其直接繞Y軸翻轉(zhuǎn)360度。

• 第三個(gè)li添加動(dòng)畫(huà)效果，但是翻轉(zhuǎn)周期是在25%的時(shí)候開(kāi)始，因此會(huì)有一種翻書(shū)的速度差異感。

上面的步驟分析完后就剩下最重要的一個(gè)過(guò)程，那就是給外層的ul元素添加perspective屬性，這個(gè)屬性是決定這個(gè)動(dòng)畫(huà)能不能實(shí)現(xiàn)的主要的因素。

perspective

perspective是CSS3中新增的屬性，表示的是設(shè)置某個(gè)元素被查看的視角，用于實(shí)現(xiàn)3D效果。

需要注意的是當(dāng)某個(gè)元素設(shè)置了perspective屬性時(shí)，其子元素會(huì)獲得透視效果，而不是這個(gè)元素本身。

我們來(lái)看一個(gè)簡(jiǎn)單的例子，有一個(gè)section父元素和一個(gè)div子元素，讓div元素旋轉(zhuǎn)45度，html元素如下。

html元素

其對(duì)應(yīng)的CSS屬性如下。

CSS屬性

在section元素上，如果不使用perspective的情況下，得到效果如下圖所示。

效果圖1

如果給section元素加上perspective屬性，并設(shè)定600px時(shí)，得到的效果圖如下。

效果圖

通過(guò)以上兩幅圖的對(duì)比我們發(fā)現(xiàn)，兩幅圖在Y軸的視角上發(fā)生了變化。

接下來(lái)，我們來(lái)具體看看這個(gè)翻書(shū)效果的代碼實(shí)現(xiàn)。

翻書(shū)效果HTML代碼

通過(guò)之前的分析，我們知道這個(gè)效果是通過(guò)ul與li來(lái)實(shí)現(xiàn)的，html部分代碼如下。

HTML代碼

翻書(shū)效果CSS代碼

首先看看ul與li的基本css屬性，記住這里需要給ul元素添加perspective屬性。

基本CSS屬性

然后是給第二個(gè)li添加動(dòng)畫(huà)。

第二個(gè)li的css屬性

最后是給第三個(gè)li添加動(dòng)畫(huà)。

第三個(gè)li的css屬性

注意到上面的代碼中有個(gè)25%和100%的設(shè)置，這個(gè)和第二個(gè)li不同，所以會(huì)有一種翻轉(zhuǎn)書(shū)頁(yè)快慢的差異感。

如果按照上述代碼來(lái)做，即可實(shí)現(xiàn)文章開(kāi)始的翻書(shū)動(dòng)畫(huà)效果。

結(jié)束語(yǔ)

今天這篇文章主要是通過(guò)CSS3新增的屬性實(shí)現(xiàn)了一個(gè)翻書(shū)動(dòng)畫(huà)效果，大家學(xué)會(huì)了嗎？

景

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

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

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

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

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

開(kāi)始

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

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

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

起步

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

基本原理圖

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

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

深入探究

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

性能的瓶頸是什么呢？

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

我們分成兩部分來(lái)看這問(wèn)題：手指離開(kāi)屏幕前和手指離開(kāi)屏幕后。

手指離開(kāi)屏幕前

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

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

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

減少 DOM 操作的元素

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

減少 DOM 操作的屬性

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

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

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

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

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

x

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

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

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

手指離開(kāi)屏幕后

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

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

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

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

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

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

H5：百度無(wú)人車(chē)招聘的 H5

動(dòng)畫(huà)：從第 1 頁(yè)翻到第 2 頁(yè)

CPU： 6 * slowdown

瀏覽器：Chrome 61.0.3163.100（64 位）

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

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

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

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

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

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

實(shí)施方案

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

currentPage ：當(dāng)前頁(yè)面

activePage：即將要翻到的下一頁(yè)

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

swiper 原理圖

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

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

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

擴(kuò)展

翻頁(yè)效果

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

s=f(x)，x

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

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

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

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

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

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

x 和 s

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

x

x 和 s

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

x，縱軸為 s

s）

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

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

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

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

總結(jié)和展望

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

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

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

希望本文能幫助到您！

點(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