179
技術社區[雲棲]
手淘互動動效的探索
內容來源：2017年6月18日，手淘前端技術專家大漠在“2017 iWeb峰會·第六屆HTML5峰會 ”進行《手淘互動動效的探索》演講分享。IT大咖說作為獨家視頻合作方，經主辦方和講者審閱授權發布。
閱讀字數：3089 | 6分鍾閱讀
嘉賓演講視頻
https://www.itdks.com/dakashuo/detail/2199
“互動，是連接用戶的橋梁”
我們以前訪問Web頁麵是沒有動畫和動效的，甚至點擊跳轉的功能都很少。那時是純粹的文字展示，圖片在網站上也很少能看見。
最初點擊一個鏈接跳到一個新的頁麵，這是一種交互。隨著技術的變革，點擊一個按鈕會彈出一個窗口，這也是我以前認識的一種交互。現在我們的交互行為變得更加複雜。
用戶無需進行任何操作，頁麵隻是告訴用戶去點擊某個按鈕可以進入一個頁麵或一個會場。這種交互行為在內部我們稱之為引流。
還有一種是純氛圍的動畫交互效果。
櫥窗是加上一些動效或陀螺儀的功能，讓用戶覺得耳目一新。
抽獎是加入了一些用戶的交互行為，點擊紅包就會告訴用戶中了多少錢或者運氣不好沒有中獎。
視頻現在也是一種傳替交互的表現形式，如果加上一些其它的技術手段上去，能表現出來的就不止是我們看到的視頻那樣。
我們目前嚐試在手淘互動裏加一些簡單的遊戲，這些遊戲就是利用前端的代碼加一些創意，把用戶吸引到互動的活動裏來，讓用戶在這裏駐留的時間更久。或者通過這些小遊戲給用戶帶來一定的收益。
提醒是一個時間倒計時，告訴用戶還有多少時間去參加“雙十一”搶紅包的活動。
交互在我們團隊就是以上這些表現形式。
最早我們隻能看到PC端的Web頁麵，隨著移動端的快速發展，移動端的互動方式也會越來越豐富。
“動畫，用於點綴”
最早實現動畫的技術方案是Gif、視頻，還有早期PC端看到的Flash頁麵，這些方案都是前端不用參與的。
但是Gif圖放到移動端，會產生一些不好的後果。以及iOS不支持Flash，視頻也有一些存在的風險。
在CSS3出現以後，大家做簡單動畫的時候會經常用到。還有一些SVG和Canvas動畫。但其實這些都還不能滿足我們各種業務場景。
我們今天的重點會放在JS-Driven Animation動畫。
0-1的過程
2015年，我們團隊經曆了一個0-1的過程。在15年之前，各種大觸看到的氛圍和動效基本上是Gif圖或是視頻。15年年貨節，我們嚐試了第一次的改變，通過前端CSS或JS的技術手段，把一個Gif圖轉換成動畫效果。完成這個效果的時候，無論是需求方還是產品都很滿意，因為這種方案可以隨時更改動畫中的元素。
CSS動畫的痛點
溝通成本高。
開發成本高：因為要通過CSS去繁衍一個視頻或Gif圖演示的動效，除了要懂這方麵的技術之外，還要讓Gif圖通過代碼層麵來實現。
還原度低：CSS實現動畫的手段是有限的，要做一些複雜的動畫還是有難度。
可控製性低：如果需求方改變了其中某一個動畫需求，我們至少要花2-3天來繁衍那部分的效果。
可交互性弱：CSS動畫無法實現在播到某個時間段突然彈出窗口告知用戶可以參加的活動。
日漸無法滿足業務場景：在0-1的過程中，需求方可能還是比較滿意的，但是如果每次的動畫效果都是用這種方案來實現，需求方會覺得很無聊，做出來也無法達到100%的還原度。
JS-Driven Animation
經過市場調研綜合結果之後，我們最終還是選擇自己“造輪子”。因為我們希望可以是自己控製的，不用擔心被別人起訴，也不擔心新功能無法在它的基礎上進行擴展。
後來我們經過一年的時間做了一個用JS驅動動畫的工具Animation Flow Tool。
動畫管理
我個人喜歡把動畫的管理當作是導演一場舞台劇，要指揮每個演員何時出場，出來做什麼，何時退場。在我們的動畫管理中有一個timeline，它很像導演的角色。
通過時間軸可以很好地控製動畫的場景，包括它何時播放、何時停止、何時退出。
CSS處理動畫銜接的短板
CSS是通過持續時間來實現控製，如果所有時間點都已經確定了，這樣做是沒有問題的。
比如動畫“火山升起”的時候發來1秒的時間，第二個動畫“火焰柱噴發”是在“火山升起”結束後開始播放。這時就可知它的延遲時間是1秒，“岩漿流動”同時播放也是1秒。到了“紅包噴發”的時候就需要進行計算，前麵的動畫播放4秒後再播放“紅包噴發”，它的延遲是1.4秒。如果這時“火山升起”的持續時間有所變動，那麼後續的所有時間都要重新進行計算。這是CSS管理動畫最大的缺點之一。
動畫（片段）之間有重疊
後來我們改變了一種模式，通過JS來監控第一段動畫，並告訴後麵的動畫什麼時候結束再可以開始播放。這時無論第一段動畫如何改變，都不用擔心後麵的動畫。
擴展動畫
互動常見的動畫類型
CSS在手淘上實現的動效性質都是相同的，我們把它定義為精靈動畫和路徑動畫。經過一年我們發現這兩種動畫是我們業務中最常見的動畫效果，於是就對它們進行了封裝。
精靈動畫
以前要把所有圖案拚成一張圖，然後通過Animation控製每一幀的播放。後來我們通過API來控製。
比如一個圖案從底部出現到頂部隱藏一共經曆了80幀。按照以前CSS的動畫實現方案，需要拚80張圖片。在這80張小圖裏有40張可能是相同的，CSS卻不能把相同的圖片利用起來。
而AFT的方案是可以的，也就是說在這個基礎上最起碼節省了40張圖片。
CSS路徑動畫
在沒有AFT的情況下，我們做的是路徑動畫，通過translate來改變x和y軸的軌徑位置。
我們當時做這個動畫效果描點描了很久，但是產品經理突然提出不要Z形的路徑，要改成S形，我們又隻好重新描S形的路徑出來。有一位同事描了七套路徑，需求方還不是很滿意，因為用translate來描點，不管怎麼描到無法達到流暢的效果。
AFT路徑動畫
後來我們改用SVG的路徑，無論需求方想要什麼路徑，隻要找個SVG的製圖軟件導出路徑節點就可以。這是我們後來對路徑動畫做的改變。
如果以後CSS的路徑動畫屬性得到瀏覽器的支持，可以直接用原生的CSS路徑動畫，也支持SVG導出的路徑，實現路徑動畫，AFT就要退出曆史舞台了。
AFT骨骼動畫
骨骼動畫是借助第三方平台的工具把骨骼動畫做出來，導出它的json數據，拿到json數據再出動畫效果。
AFT架構的演變
最早的時候我們是利用IDE導出一份json數據，通過第三方JS庫來實現DOM的動畫效果。
我們的第二種方案是通過An/AE導出一份json數據，再通過前端的DSL層麵來實現動畫效果。
經過實驗，這兩種都不是我們想要的實現方案，後來我們對它進行了一些簡單的改造。
aft.js架構細節
第一部分是元素，第二部分是動效器，第三部分是引擎，最關鍵的一點是動畫管理，也就是時間軸。
元素和動效是分離的，隻要做動效，然後把動效賦予到元素上，再找引擎來渲染。
我們專注於做管理動畫，怎樣把動畫描述出來，怎樣把動畫串起來構成我們所需業務的動畫。這是AFT後麵實現的底層架構，看上去沒有以前那麼複雜。
業務開發模式
曾經開發模式
視覺設計提供一個Gif或視頻文件和一個PSD文件，交付到前端。前端根據Gif或視頻的動畫效果，把整個動畫繁衍出來。也就是AFT動畫繁衍的過程。這個模式的溝通成本非常高。
現在的業務開發模式
前端隻負責業務層的邏輯代碼，視覺通過AE這種製作動畫的工具去導出動畫。要有業務邏輯，再通過前端加入業務邏輯。如果不要業務邏輯的話，就無需前端界入了。
“可量化和數據驅動”
粗獷的做法
AE導出的不是json數據，它做出一個視頻，然後前端再通過代碼繁衍。
正確的做法
通過動畫編程語言進行實現，要什麼效果就能繁衍出什麼效果。
思考探索
我們提出了一個“動畫工程師”的概念。我們團隊目前還在思考動畫工程師應該做什麼，動畫工程師是不是能直接實現動畫的過程就可以稱之為動畫工程師。但我個人認為遠遠不止這些，我們還在思考探索中。
我今天的分享就到這裏，感謝聆聽！
推薦文章
Mars在移動網絡的探索和實踐
阿裏巴巴前端專家渚薰：H5互動的正確打開方式
近期活動
直播 |【阿裏雲MVP MeetUp】一起把雲計算拆了玩兒
最後更新：2017-08-31 11:33:10