今天聊的內容是淘寶虛擬互動實驗室的@渚薰大神 在2017年06月在北京GMTC大會上分享的一個主題。未能親臨聽到相關的精彩分享，但還算是有幸的，在內部聽到@渚薰大神 的分享。個人對Web動畫這方面的課程非常的感興趣，而且現(xiàn)在和團隊一直在致力于手淘互動動效相關的研究。經(jīng)歷了從Gif、視頻到CSS Animation的零至一的過程，并且致力于JavaScript驅動的動效開發(fā)，以及現(xiàn)在致力于研究的數(shù)據(jù)化驅動的動效。這樣的一個過程是幸福的，而且也是具有挑戰(zhàn)力的。我想很多喜歡動畫的同學也對這樣的一個課程會感興趣，所以接下來，我們根據(jù)@渚薰大神分享的PPT的思路來聊聊漸進式動畫解決方案。

PWA

最早聽到PWA(Progressive Web Apps)這樣的一個概念是2016年在上海Qcon的分享會上聽到@黃弦 大大的分享，但我們今天要聊的并不是Progressive Web APPs，而是其變身Progressive Web Animation。我們把其稱為漸進式動畫。那問題來了，什么才是漸進式動畫呢?這是值得每位愛好動畫的同學去思考的?為了更好的闡述自己對漸進式動畫的理解，將分幾個方向來介紹：

重新認識動畫

如何操作動畫

如何管理動畫

如何制作動畫

重新思考動畫

接下來一一聊聊。

重新認識動畫

要重新認識動畫，那么其中有兩個非常重要的概念：動效和插值。

動效

動效是源于電影動效。動效是錄音學范疇，簡言之，指各種動作的聲音效果，又被稱為擬聲。比如武打片里，骨折的聲音是芹菜制造的，下雨的聲音是由洗臉的聲音制造的。

看上并不是我們所要說的動效，這并不要緊。如果需要和我們的實際工作中緊密聯(lián)合在一起，我們的Web也可以有音效，特別是早期的Flash，各種的配合音效，得到與眾不同的效果。隨著CSS和HTML以及JavaScript相關技術不斷的革新，同時各種特性能得到眾多現(xiàn)代瀏覽器的支持。現(xiàn)在的Web展示形式也不斷的變化，不管是Web頁面或者說APP應用，都會或多或少的添加一些動效效果。

俗話說得好，顏值不夠，動效來湊，Web動效已經(jīng)不僅僅是Web設計的潤滑劑了，它的功能更多的體現(xiàn)在交互邏輯、視覺渲染和創(chuàng)新實踐上，上能引人注目，下能潛移默化。對于Web開發(fā)人員而言，更喜歡把這些動效稱之為Web動畫。為了接地氣，后面也將稱之為動畫。

迪士尼動畫大師乃特維克的畢生經(jīng)驗對Web動畫濃縮成一句話：

動畫的一切皆在于時間點和空間幅度!

事實上，動效設計和做動畫是一脈相通的，我們不要做寫實主義的動畫，而是要通過時間點和空間幅度的設置為用戶建立運動的可信度。這樣描述感覺有點繞。其實我們可以這樣來描述動畫的概念：

動畫是指由許多幀靜止的畫面，以一定的速度(比如每秒16張)連續(xù)播放時，肉眼因視覺殘象產生錯覺，而誤以為畫面活動的作品。為了得到活動的畫面，第個畫面之間都會有細微的改變。

其實我更喜歡說動畫就是以時間置換空間。比如下圖：

圖形A狀態(tài)(一個正方形)經(jīng)過時間的變換到了圖形B的狀態(tài)(一個圓形)。從正方形變成圓形這樣的一個過程就是一個動畫效果(動效)。當然為了制作這樣的一個動畫，會添加控制動畫的一些手段，比如控制持續(xù)時間、延遲時間、緩動函數(shù)、動畫次數(shù)和方向之類的等。當然根據(jù)不同的制作動畫的方式，這些控制動畫的參數(shù)或者說手段吧，其方法不一樣。這里暫且不深入的介紹。

剛才也說過了，這樣的一個過程就是一個動畫效果，專業(yè)一點稱之為Motion Effect。而這個Motion Effect又受眾多因素的影響。同樣拿上面的示例來說，正方形是一下子變成圓形呢還是慢慢的變形圓形呢?又是經(jīng)過多少時間才變成圓形呢?這一切的一切都會影響到。而其中有一個較好的方案就是在運動的過程中將插值引進來。

插值

這里所說的插值其實是指線性插值。線性插值是數(shù)學、計算機圖形學等領域廣泛的一種簡單插值方法。在平常實際運用當中，把插值稱之為lerp，簡單而言：

lerp是兩點之間的線性插值的別稱。

同樣的回到面的示例，正方形狀態(tài)A是一個點，圓形狀態(tài)B是一個點。如果我們把狀態(tài)A稱為0點，把狀態(tài)B稱為1點。那么在這個過程中我們可以有很多個值，比如0.1、0.2....9之類，比如下圖所示：

從0至1這樣的一個過程就是一個插值過程。用到圖形變化中來，比如正方形是四個點連起的圖形，那么變成圓形，這個點數(shù)越多這個圓就越圓，比如16、32、64、128等等，也可以說點數(shù)越多，越趨向于圓。而這個程，我們使用插值原理來計算，效果會更佳。比如下面兩個圖：

一個高級動畫或者動畫藝術家都手繪的關鍵幀定義的一個動畫。不管你是怎么一個高級的動畫設計師，手繪總是有所限制的，如果我們換成插值來繪制：

插值能增加很多中間幀，讓動效變得更為絲滑。

上面演示的是幀之間的插值，事實上我們除了這個之外，還有顏色的插值，圖形插值等等。這里想要表達的觀點是：插值能讓動效變得更為絲滑。有關于插值方面的相關介紹，可以閱讀：

線性插值

理解動畫中的線性插值

如何操作動畫

操作一個動畫，其實具有兩個過程，其一制作動畫的場景，其二拼接動畫場景。把它們結合起來就是操作一個動畫。那么操作一個動畫，就目前的技術常見的有：

CSS Animation

SVG Animation

JavaScript-Driven Animation

我想大家最早接觸動畫的控制方式應該類似于jQuery的.animate():

$( "#clickme" ).click(function() {

$( "#book" ).animate({

opacity: 0.25,

left: "+=50",

height: "toggle"

}, 5000, function() {

// Animation complete.

});

});

對于這種制作動畫的方式不做過多的評介。但隨著CSS技術的發(fā)展，使用純CSS就可以很好的實現(xiàn)Animation。在CSS中主要是使用@keyframes和animation-*屬性來控制動畫。CSS Animation雖然實現(xiàn)一個動效較為容易，成本也較低，但對于一些復雜的動畫場景，他就變得非常的雞肋。除此之外，這兩年SVG Animation也越來越多在實際場景中使用。

不過，這里需要特別提出的是JavaScript-Driven Animation，也就是JavaScript驅動動畫。最簡單的就是W3C規(guī)范提供的Web Animation API簡稱為WAAPI。其原理非常類似于CSS Animation，具有@keyframes的概念，也具有類似于animation-*屬性樣的方法，用于控制動畫。同時還提供了對應的Timeline的概念，而Timeline又是動畫中一個至關重要的一個概念，稍后或多或少會介紹一些。

雖然有了WAAPI，可以使用原生的JavaScript制作動畫，但還是有一些功能性的限制，而且實現(xiàn)方式，制作流程等等，都有待于改善。但對于Web社區(qū)而言，這一切都不是問題。因為很多開發(fā)者，都會針對于自己的業(yè)務，或者說自己的需求，在某一方面做出優(yōu)秀的成績，并且分享給社區(qū)。正因為如此，社區(qū)中有很多使用JavaScript來驅動動畫的庫，比如：GreenSock、CreateJS、Anime和Motion等：

不管是哪種制作動畫的JavaScript庫或者說工具都有各自的利弊。只能說選擇最適合自己的，俗話說：

站在巨人的肩膀上，看得比別人更遠些。(If I have been able to see further, it was only because I stood on the shoulders of giants.)

除了上述制作動畫之外，我們還可以采用Canvas和WebGL。特別是WebGL，在當今算是一個熱門的話題，國內外很多團隊都在研究這方面的技術，其中最具代表性的作品就是ThreeJS。

制作動畫另一個不可避免的問題，那就是動畫的性能問題。這是一個很深的、很復雜的話題。不過我們可以借助一些其他的工具幫助我們在底層做一些變化，比如采用GPU來渲染：

GPU.JS：使用JavaScript給GPU加速

PixiJS：一個HTML5引擎，也是最靈活的2D WebGL渲染器

除了借助工具之外，我們也可以在自己的代碼層面做一些優(yōu)化，比如使用requestAnimationFrame這個API：

const raf = requestAnimationFrame;

const running = [];

const idle = [];

export const add = tick => running.push(tick);

export const remove = id => (running[id] = idle[id] = undefined);

export const run = () => raf(function tok() {

raf(tok);

running.forEach(t => t());

});

export const pause = id => (idle[id] = running[id]) && (running[id] = undefined);

export const resume = id => (running[id] = idle[id]) && (idle[id] = undefined);

有關于這方面的介紹大家可以閱讀下面幾篇文章：

requestAnimationFrame for Smart Animating

requestAnimationFrame API: now with sub-millisecond precision

Using requestAnimationFrame

Animating with javascript: from setInterval to requestAnimationFrame

CSS3動畫那么強，requestAnimationFrame還有毛線用?

requestAnimationFrame

使用requestAnimationFrame更好的實現(xiàn)javascript動畫

requestAnimationFrame 性能更好

以前在站上也整理了一些優(yōu)化動畫性能的相關文章，對這方面感興趣的同學可以閱讀下面的文章：

使用瀏覽器開發(fā)者工具檢測CSS動畫性能

CSS Animation性能優(yōu)化

高性能的動畫

使用CSS3實現(xiàn)60FPS動畫

使用 FLIP 來提高 Web 動畫的性能

CSS動畫之硬件加速

如何管理動畫

制作出來動畫，我們可以將整體的動畫細分出來，那么怎么管理動畫變得就很重要了。我常常喜歡把動畫比喻成一場舞臺劇，整個劇會有演員，演員什么時候出場之類的。而控制演員出場順序和時間之類的由導演來負責。回到我們的動畫中來，我們可以把整個動畫當作一個舞臺劇(一個故事)，故事中有很多個片段(也就是我們的動畫分場景)，而串起整個動畫是由時間軸來控制，常常稱之為Timeline。

比如：

正如上圖所示，這里有三輛小汽車向右行駛的動效，那么藍、黃、紅怎么出現(xiàn)，就由時間軸來控制了。而整個過程，它其實也是一個流式的過程。有接觸過Flash的同學應該知道。在Flash中有兩種動畫方式：

流式動畫

交互式動畫

所謂流式動畫，就是像電影那樣按既定順序一直播放，不會停，也不會發(fā)生改變的動畫。你在電視上看到的所有動畫片都可以說是流式動畫。流式動畫最顯著的特點就是你無法對流式動畫施加影響，比如你無法期待單擊流式動畫中的某個器物(動畫元素)而指望因此而發(fā)生什么事情?？傊?，流式動畫中所有的一切都是注定的，有一種宿命的感覺。盡管流式動畫的能力有限，但不可否認，流式動畫的應用還是非常廣泛的。

說到這里，大家可能會想到，我們CSS Animation。眾所周知，一旦我們定制好了一個CSS Animation，我們是無法通過一些事情讓動畫中的某些動畫元素做其他的事情。這也是令我們頭痛的地方之一。比如我們做一個互動的動畫，希望動畫播放到一定的位置，彈一個彈框出來，告訴用戶你可以領起紅包了。

除了流式動畫，還有一種交互式動畫。所謂交互式動畫，簡單地說就是動畫隨時準備因你的命令或某些事件的出現(xiàn)而發(fā)生變化。例如，當你用鼠標點擊動畫中一只小狗的頭時，它會高興地沖你搖尾巴。在這里，鼠標的單擊就是一個命令(或者說是一個事件)，而小狗搖尾巴就是對這個命令(或說事件)的響應，整個過程就可以被看作是一次交互。

到目前為止，僅使用CSS Animation，或者后面將提到的一些制作動畫的IDE或軟件，他們做出來的動畫都是流式動畫，只能通過時間軸來控制動畫，整個動畫中沒有任何可交互性而言，這對于大多數(shù)業(yè)務場景是無法達到需求方的要求。但對于JavaScript驅動的動畫而言，我們的交互行為就要豐富的多，比如SVG Animation，Canvas Animation等。

感覺有點跑題了，這一節(jié)我們要說的是管理動畫，其實除了管理動畫中的交互行為之外，更為重要的是管理動畫的播放。前面也提到過了，不管是CSS Animation動畫，還是JavaScript驅動的動畫，都是通過Timeline來管理。只不過JavaScript更具優(yōu)勢。來看兩個小場景。

先來看CSS Animation中的Timeline，如下圖所示：

上圖演示的是一個紅包火山的動畫場景(喜歡手淘的同學，應該在去年的雙十一看到過這樣的動畫)，在這個動畫中我們包括了火山升起(valcaoRising)、火焰柱噴發(fā)(expulsion)、巖漿流動(flow)和紅包噴發(fā)(blowout)。在這個動畫中，我們要人工的去計算動畫的延遲時間(animation-delay)和持續(xù)時間(animation-duration)。比如火山升起，我們花費了1s，火焰柱噴發(fā)等火山升起才開始，這樣一來，其延遲時間為1s，并且持續(xù)了.4s，在此同時巖漿流動的效果也同時發(fā)生，也就是說巖漿流動的延遲時間也是1s，而其持續(xù)了2s，其實動畫進行到1.4s時，火焰柱噴發(fā)的動效是已經(jīng)停止了。除此之外，還有紅包噴發(fā)的一個動畫，而這個動畫是在火焰柱噴發(fā)結束的時候開始，這樣其延遲時間是1.4s，并且持續(xù)了15s。其實整個動效花了16.4s。

如果這樣做就能滿足業(yè)務方的需求，那是開發(fā)者的福音，但是要變動某個時間，比如火山升起需要持續(xù)2s，那么后續(xù)的三個動畫的時間都需要變更。而這個過程是一個痛苦的過程。

但在JavaScript驅動的動畫中，我們依舊是通過Timeline來管理動畫，但會變得輕松和靈活的多，比如下圖：

在JavaScript中，我們可以通過技術手段，將相關功能封裝成函數(shù)，然后在動畫流中調用：

add(me) => (

playAt: () => number

) => assign(me, {playAt});

tick(elapsed) => queue.forEach(me => {

if (me.playAt() >= elapsed && !me.started)

me.start();

});

同樣拿上圖來說，如果我給火山升起通過playAt()來得到起始時間，并且函數(shù)能拿到其停止時間，并且在其停止的這個時候通知其他動畫什么時候開始播放。這樣我們控制動畫會變得輕松的多。哪怕是我們需要改變其中某一個或某兩個的時間，也可以很好的自動獲取。

() => me1.finished;

let fetched;

fetch(url).then(() => fetched = true);

() => fetched;

() => store.getState() === ‘BTN_CLICKED’;

() => me2.started && (me2.startAt + 500);

簡單點講，我們把動畫的控制、決定和管理都交互兩個函數(shù)，比如playAt()和stopAt。比如下圖：

這樣是不是感覺爽得多了。

如何制作動畫

其實前面我們簡單的提到了如何制作動畫，比如通過CSS Animation、SVG Animation或者說JavaScript。但在這一節(jié)，我們繼續(xù)來聊這個話題。在具體聊這個話題之前，咱們先來看一下開發(fā)者和設計者之間的合作關系。

早期的Gif動畫、視頻動畫或者說Flash動畫，這些可以說都不需要開發(fā)人員去做什么(這些都是流式動畫，無交互可言)。但隨著市場的變化或者說技術革新后，開發(fā)人員想嘗試著新的技術來實現(xiàn)動畫，并且在提供給業(yè)務方，這樣做多NB，跟老板說，這樣能節(jié)約多少成本。沒想到，這個時候自己挖了一個巨坑讓自己和自己的小伙伴跳進坑中。

別的不說，咱先上一張圖：

可以說這是一個痛苦的過程，視覺設計師將想要的動效制作成視頻文件或者Gif文件以及可切圖的PSD文件給開發(fā)人員，然后開發(fā)人員將Gif動效或者說視頻演示的動畫轉成Web動畫。大家可能會問，這不是蛋疼?為什么需要制作視頻或Gif文件呢?提供一個PSD文件不就行了?其實視覺設計師也是這么認為的。但話說回來，有多少開發(fā)人員能不看效果，通過視覺設計師或者說業(yè)務方的描述就能理解所需的動效呢?不知道你行不行，反正我經(jīng)歷之后告訴我，我是不行。

這樣的一個過程，其實也增加了設計師和開發(fā)者的溝通成本，也增加了設計師的工作量。特別是當需求變更之后，設計師欲哭無淚。這個時候老板會說，成本、成本、效率、效率。設計師會說麻煩、麻煩。需求方會說，就這樣吧，其實離我需要的還是有差距的。

隨著時間變化，不管是自己的Boss還是需求方，都希望有所改變：動效能不能變得更絲滑一些、效果還原度能不能更接近一些、能不能更有一些創(chuàng)意和創(chuàng)新，能不能玩一些更有意思的...

開發(fā)人員心中千萬個草昵瑪就出來了。但活還是要繼續(xù)做的，只是換個方式做而以。這也是我和我們團隊小伙伴近一年多來一直在研究的一個課程：可量化和數(shù)據(jù)驅動。

這個流程讓我們有了更多的變化。視覺設計師專業(yè)的做他的設計，開發(fā)人員專業(yè)的做他的業(yè)務開發(fā)。為什么這樣說呢?因為動效的轉換我們通過工具或者軟件來實現(xiàn)，然使用JavaScript的將業(yè)務插入到轉化后的動效中。

簡單講，我們的開發(fā)過程變成了這樣：

其實這樣的過程，并不是我們有的，最早的時候有些團隊使用Animation CC設計動畫，然后直接轉換出Web動畫，它依賴于CreateJS這個庫。另外也有團隊使用After Effects CC制作動畫，然后借助bodymovin將動畫轉出來。其中最具代表性的就是Airbnb的Lottie:

有關于這方面的DEMO，可以點擊這里查閱。

這是別人家的產品，也是巨人的肩膀。其實在Lottie和Bodymovin還沒有開源出來的時候，我們團隊也有一個類似的產品，AFT(Animation Flow Tools)。AFT沒有開源，我不能聊得太多，簡單的說，AFT具有自己的渲染引擎、也可以借用別人的渲染引擎，比如Canvas、Weex之類。但其主要功能和特點是用來管理動畫，擴展動畫。而且AFT也具有類似Lottie的特性，只不過我們的Player層是自己寫的。下面的示例就是使用AFT通過AE轉出來的一個動效，并且在實際項目中運用的：

我們把這樣制作動畫稱之為可量化和數(shù)據(jù)驅動。主要原理其實在上面也提到過了。這里簡單的復述一下：

通過類似AE這樣的制作動畫的軟件，將動畫導出成一份JSON數(shù)據(jù)，這份JSON數(shù)據(jù)將描述動畫。同時使用Player層結合DSL，將JSON數(shù)據(jù)和業(yè)務邏輯整合，完成帶有可交互的動畫。

雖然我們初步完成了這些樣的一個開發(fā)模式，但路還很長，我們也在不斷努力。希望有一天能讓她面世，與眾多動畫愛好者共享。

重新思考動畫

經(jīng)過這一系列的變化，并且隨著技術越來越先進。我們有必要重新思考動畫。除了思考其制作過程和動畫效果之外，我們更多的時候去思考其中的模式和工程化相關的東西。

在我們的意識中，動畫就是設計師與開發(fā)者之間的故事。但有沒有想過，我們可以換一種模式：

上圖我不想用再多的語言來描述，因為這個過程我和我們的團隊還在探討，等哪一天有了答案和大寫一起分享。在這里我們提出一個動畫工程師的職能，那么真正的動畫工程師應該支承擔一些什么呢?又需要去思考些什么呢?我們一起來思考吧，我想有一天會有答案的。

總結

經(jīng)過一段從事動畫開發(fā)的體驗和感受。我和我們的團隊一直在探索一種好的模式，希望這種模式能幫助我們降低開發(fā)成本，提高開發(fā)效率，滿足更多需求。同時讓自己參與到創(chuàng)意當中，或者在這些方面有一些創(chuàng)新。

本文名稱：漸進式動畫解決方案
網(wǎng)頁地址：http://jinyejixie.com/news32/167982.html

網(wǎng)站建設、網(wǎng)絡推廣公司-創(chuàng)新互聯(lián)，是專注品牌與效果的網(wǎng)站制作，網(wǎng)絡營銷seo公司；服務項目有解決方案等

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)