手淘互動動效的探索


內容來源:2017年6月18日,手淘前端技術專家大漠在「2017 iWeb峯會·第六屆HTML5峯會 」進行《手淘互動動效的探索》演講分享。IT大咖說做爲獨家視頻合做方,經主辦方和講者審閱受權發佈。html

閱讀字數:3089 | 6分鐘閱讀


摘要

如今的營銷活動,用一張簡單的圖片去吸引消費者已經遠遠不夠,必需要有能給消費者帶來視覺衝擊的東西,或者在動畫過程當中提供更好的引導部分。手淘的前端團隊經歷了從Gif、視頻到CSS Animation的從0-1的過程,並致力於研究的數據化驅動的動效。大漠將爲咱們帶來在手淘互動動效上的探索分享。前端

嘉賓演講視頻地址: t.cn/RCWCDu5

「互動,是鏈接用戶的橋樑」


咱們之前訪問Web頁面是沒有動畫和動效的,甚至點擊跳轉的功能都不多。那時是純粹的文字展現,圖片在網站上也不多能看見。編程

最初點擊一個連接跳到一個新的頁面,這是一種交互。隨着技術的變革,點擊一個按鈕會彈出一個窗口,這也是我之前認識的一種交互。如今咱們的交互行爲變得更加複雜。json


用戶無需進行任何操做,頁面只是告訴用戶去點擊某個按鈕能夠進入一個頁面或一個會場。這種交互行爲在內部咱們稱之爲引流。瀏覽器

  • 還有一種是純氛圍的動畫交互效果。
  • 櫥窗是加上一些動效或陀螺儀的功能,讓用戶以爲耳目一新。
  • 抽獎是加入了一些用戶的交互行爲,點擊紅包就會告訴用戶中了多少錢或者運氣很差沒有中獎。
  • 視頻如今也是一種傳替交互的表現形式,若是加上一些其它的技術手段上去,能表現出來的就不止是咱們看到的視頻那樣。
  • 咱們目前嘗試在手淘互動里加一些簡單的遊戲,這些遊戲就是利用前端的代碼加一些創意,把用戶吸引到互動的活動裏來,讓用戶在這裏駐留的時間更久。或者經過這些小遊戲給用戶帶來必定的收益。
  • 提醒是一個時間倒計時,告訴用戶還有多少時間去參加「雙十一」搶紅包的活動。

交互在咱們團隊就是以上這些表現形式。網絡

最先咱們只能看到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數據,它作出一個視頻,而後前端再經過代碼繁衍。

正確的作法


經過動畫編程語言進行實現,要什麼效果就能繁衍出什麼效果。

思考探索


咱們提出了一個「動畫工程師」的概念。咱們團隊目前還在思考動畫工程師應該作什麼,動畫工程師是否是能直接實現動畫的過程就能夠稱之爲動畫工程師。但我我的認爲遠遠不止這些,咱們還在思考探索中。

我今天的分享就到這裏,感謝聆聽!

相關文章
相關標籤/搜索