内容來源：2017年6月18日，手淘前端技術專家大漠在“2017 iweb峰會·第六屆html5峰會 ”進行《手淘互動動效的探索》演講分享。it大咖說作為獨家視訊合作方，經主辦方和講者審閱授權釋出。 閱讀字數：3089 | 6分鐘閱讀
<a href="http://www.itdks.com/dakashuo/detail/2199">http://www.itdks.com/dakashuo/detail/2199</a>
我們以前通路web頁面是沒有動畫和動效的，甚至點選跳轉的功能都很少。那時是純粹的文字展示，圖檔在網站上也很少能看見。
最初點選一個連結跳到一個新的頁面，這是一種互動。随着技術的變革，點選一個按鈕會彈出一個視窗，這也是我以前認識的一種互動。現在我們的互動行為變得更加複雜。
使用者無需進行任何操作，頁面隻是告訴使用者去點選某個按鈕可以進入一個頁面或一個會場。這種互動行為在内部我們稱之為引流。
還有一種是純氛圍的動畫互動效果。
櫥窗是加上一些動效或陀螺儀的功能，讓使用者覺得耳目一新。
抽獎是加入了一些使用者的互動行為，點選紅包就會告訴使用者中了多少錢或者運氣不好沒有中獎。
視訊現在也是一種傳替互動的表現形式，如果加上一些其它的技術手段上去，能表現出來的就不止是我們看到的視訊那樣。
我們目前嘗試在手淘互動裡加一些簡單的遊戲，這些遊戲就是利用前端的代碼加一些創意，把使用者吸引到互動的活動裡來，讓使用者在這裡駐留的時間更久。或者通過這些小遊戲給使用者帶來一定的收益。
提醒是一個時間倒計時，告訴使用者還有多少時間去參加“雙十一”搶紅包的活動。
互動在我們團隊就是以上這些表現形式。
最早我們隻能看到pc端的web頁面，随着移動端的快速發展，移動端的互動方式也會越來越豐富。
最早實作動畫的技術方案是gif、視訊，還有早期pc端看到的flash頁面，這些方案都是前端不用參與的。
但是gif圖放到移動端，會産生一些不好的後果。以及ios不支援flash，視訊也有一些存在的風險。
在css3出現以後，大家做簡單動畫的時候會經常用到。還有一些svg和canvas動畫。但其實這些都還不能滿足我們各種業務場景。
我們今天的重點會放在js-driven animation動畫。
2015年，我們團隊經曆了一個0-1的過程。在15年之前，各種大觸看到的氛圍和動效基本上是gif圖或是視訊。15年年貨節，我們嘗試了第一次的改變，通過前端css或js的技術手段，把一個gif圖轉換成動畫效果。完成這個效果的時候，無論是需求方還是産品都很滿意，因為這種方案可以随時更改動畫中的元素。
溝通成本高。
開發成本高：因為要通過css去繁衍一個視訊或gif圖示範的動效，除了要懂這方面的技術之外，還要讓gif圖通過代碼層面來實作。
還原度低：css實作動畫的手段是有限的，要做一些複雜的動畫還是有難度。
可控制性低：如果需求方改變了其中某一個動畫需求，我們至少要花2-3天來繁衍那部分的效果。
可互動性弱：css動畫無法實作在播到某個時間段突然彈出視窗告知使用者可以參加的活動。
日漸無法滿足業務場景：在0-1的過程中，需求方可能還是比較滿意的，但是如果每次的動畫效果都是用這種方案來實作，需求方會覺得很無聊，做出來也無法達到100%的還原度。
經過市場調研綜合結果之後，我們最終還是選擇自己“造輪子”。因為我們希望可以是自己控制的，不用擔心被别人起訴，也不擔心新功能無法在它的基礎上進行擴充。
後來我們經過一年的時間做了一個用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資料，它做出一個視訊，然後前端再通過代碼繁衍。
通過動畫程式設計語言進行實作，要什麼效果就能繁衍出什麼效果。
我們提出了一個“動畫工程師”的概念。我們團隊目前還在思考動畫工程師應該做什麼，動畫工程師是不是能直接實作動畫的過程就可以稱之為動畫工程師。但我個人認為遠遠不止這些，我們還在思考探索中。
我今天的分享就到這裡，感謝聆聽！
推薦文章
<a href="http://mp.weixin.qq.com/s?__biz=mzixodqxmjc0ma==&mid=2247487310&idx=1&sn=03cb2378f7563b4c3289a5ea5aea6166&chksm=97ebace5a09c25f3fb64a7104a307e9ae99ef642bd98668d919595abcec92a35d274670506d0&scene=21#wechat_redirect">mars在移動網絡的探索和實踐</a>
<a href="http://mp.weixin.qq.com/s?__biz=mzixodqxmjc0ma==&mid=2247486616&idx=1&sn=9d759f9fd8d83e2318bef089c7da2a95&chksm=97ebaf33a09c2625c5db5670f032cf05d91b1419bffc7b90ca59121c35693659aef1f37af4dd&scene=21#wechat_redirect">阿裡巴巴前端專家渚薰：h5互動的正确打開方式</a>
近期活動
<a href="http://mp.weixin.qq.com/s?__biz=mzixodqxmjc0ma==&mid=2247487942&idx=2&sn=aefa509c2a85ff4e0c9fac8f39c43236&chksm=97ebb26da09c3b7bb184015ca4e205fa75b18349933fce1dcbc4a4166c0a3f0cfde24cd72251&scene=21#wechat_redirect">直播 |【阿裡雲mvp meetup】一起把雲計算拆了玩兒</a>