內容來源:2017年6月18日,手淘前端技術專家大漠在「2017 iWeb峯會·第六屆HTML5峯會 」進行《手淘互動動效的探索》演講分享。IT大咖說做爲獨家視頻合做方,經主辦方和講者審閱受權發佈。html
閱讀字數:3089 | 6分鐘閱讀
如今的營銷活動,用一張簡單的圖片去吸引消費者已經遠遠不夠,必需要有能給消費者帶來視覺衝擊的東西,或者在動畫過程當中提供更好的引導部分。手淘的前端團隊經歷了從Gif、視頻到CSS Animation的從0-1的過程,並致力於研究的數據化驅動的動效。大漠將爲咱們帶來在手淘互動動效上的探索分享。前端
咱們之前訪問Web頁面是沒有動畫和動效的,甚至點擊跳轉的功能都不多。那時是純粹的文字展現,圖片在網站上也不多能看見。編程
最初點擊一個連接跳到一個新的頁面,這是一種交互。隨着技術的變革,點擊一個按鈕會彈出一個窗口,這也是我之前認識的一種交互。如今咱們的交互行爲變得更加複雜。json
用戶無需進行任何操做,頁面只是告訴用戶去點擊某個按鈕能夠進入一個頁面或一個會場。這種交互行爲在內部咱們稱之爲引流。瀏覽器
交互在咱們團隊就是以上這些表現形式。網絡
最先咱們只能看到PC端的Web頁面,隨着移動端的快速發展,移動端的互動方式也會愈來愈豐富。架構
最先實現動畫的技術方案是Gif、視頻,還有早期PC端看到的Flash頁面,這些方案都是前端不用參與的。運維
可是Gif圖放到移動端,會產生一些很差的後果。以及iOS不支持Flash,視頻也有一些存在的風險。編程語言
在CSS3出現之後,你們作簡單動畫的時候會常常用到。還有一些SVG和Canvas動畫。但其實這些都還不能知足咱們各類業務場景。工具
咱們今天的重點會放在JS-Driven Animation動畫。
2015年,咱們團隊經歷了一個0-1的過程。在15年以前,各類大觸看到的氛圍和動效基本上是Gif圖或是視頻。15年年貨節,咱們嘗試了第一次的改變,經過前端CSS或JS的技術手段,把一個Gif圖轉換成動畫效果。完成這個效果的時候,不管是需求方仍是產品都很滿意,由於這種方案能夠隨時更改動畫中的元素。
通過市場調研綜合結果以後,咱們最終仍是選擇本身「造輪子」。由於咱們但願能夠是本身控制的,不用擔憂被別人起訴,也不擔憂新功能沒法在它的基礎上進行擴展。
後來咱們通過一年的時間作了一個用JS驅動動畫的工具Animation Flow Tool。
我我的喜歡把動畫的管理看成是導演一場舞臺劇,要指揮每一個演員什麼時候出場,出來作什麼,什麼時候退場。在咱們的動畫管理中有一個timeline,它很像導演的角色。
經過時間軸能夠很好地控制動畫的場景,包括它什麼時候播放、什麼時候中止、什麼時候退出。
CSS是經過持續時間來實現控制,若是全部時間點都已經肯定了,這樣作是沒有問題的。
好比動畫「火山升起」的時候發來1秒的時間,第二個動畫「火焰柱噴發」是在「火山升起」結束後開始播放。這時就可知它的延遲時間是1秒,「岩漿流動」同時播放也是1秒。到了「紅包噴發」的時候就須要進行計算,前面的動畫播放4秒後再播放「紅包噴發」,它的延遲是1.4秒。若是這時「火山升起」的持續時間有所變更,那麼後續的全部時間都要從新進行計算。這是CSS管理動畫最大的缺點之一。
後來咱們改變了一種模式,經過JS來監控第一段動畫,並告訴後面的動畫何時結束再能夠開始播放。這時不管第一段動畫如何改變,都不用擔憂後面的動畫。
CSS在手淘上實現的動效性質都是相同的,咱們把它定義爲精靈動畫和路徑動畫。通過一年咱們發現這兩種動畫是咱們業務中最多見的動畫效果,因而就對它們進行了封裝。
之前要把全部圖案拼成一張圖,而後經過Animation控制每一幀的播放。後來咱們經過API來控制。
好比一個圖案從底部出現到頂部隱藏一共經歷了80幀。按照之前CSS的動畫實現方案,須要拼80張圖片。在這80張小圖裏有40張多是相同的,CSS卻不能把相同的圖片利用起來。
而AFT的方案是能夠的,也就是說在這個基礎上最起碼節省了40張圖片。
在沒有AFT的狀況下,咱們作的是路徑動畫,經過translate來改變x和y軸的軌徑位置。
咱們當時作這個動畫效果描點描了好久,可是產品經理忽然提出不要Z形的路徑,要改爲S形,咱們又只好從新描S形的路徑出來。有一位同事描了七套路徑,需求方還不是很滿意,由於用translate來描點,無論怎麼描到沒法達到流暢的效果。
後來咱們改用SVG的路徑,不管需求方想要什麼路徑,只要找個SVG的製圖軟件導出路徑節點就能夠。這是咱們後來對路徑動畫作的改變。
若是之後CSS的路徑動畫屬性獲得瀏覽器的支持,能夠直接用原生的CSS路徑動畫,也支持SVG導出的路徑,實現路徑動畫,AFT就要退出歷史舞臺了。
骨骼動畫是藉助第三方平臺的工具把骨骼動畫作出來,導出它的json數據,拿到json數據再出動畫效果。
最先的時候咱們是利用IDE導出一份json數據,經過第三方JS庫來實現DOM的動畫效果。
咱們的第二種方案是經過An/AE導出一份json數據,再經過前端的DSL層面來實現動畫效果。
通過實驗,這兩種都不是咱們想要的實現方案,後來咱們對它進行了一些簡單的改造。
第一部分是元素,第二部分是動效器,第三部分是引擎,最關鍵的一點是動畫管理,也就是時間軸。
元素和動效是分離的,只要作動效,而後把動效賦予到元素上,再找引擎來渲染。
咱們專一於作管理動畫,怎樣把動畫描述出來,怎樣把動畫串起來構成咱們所需業務的動畫。這是AFT後面實現的底層架構,看上去沒有之前那麼複雜。
視覺設計提供一個Gif或視頻文件和一個PSD文件,交付到前端。前端根據Gif或視頻的動畫效果,把整個動畫繁衍出來。也就是AFT動畫繁衍的過程。這個模式的溝通成本很是高。
前端只負責業務層的邏輯代碼,視覺經過AE這種製做動畫的工具去導出動畫。要有業務邏輯,再經過前端加入業務邏輯。若是不要業務邏輯的話,就無需前端界入了。
AE導出的不是json數據,它作出一個視頻,而後前端再經過代碼繁衍。
經過動畫編程語言進行實現,要什麼效果就能繁衍出什麼效果。
咱們提出了一個「動畫工程師」的概念。咱們團隊目前還在思考動畫工程師應該作什麼,動畫工程師是否是能直接實現動畫的過程就能夠稱之爲動畫工程師。但我我的認爲遠遠不止這些,咱們還在思考探索中。
我今天的分享就到這裏,感謝聆聽!