動畫的現狀(2014)

動畫的現狀(2014)

在后Flash時代里，Flash動畫是很少見的。于是對手機和臺式機來說，CSS動畫就很快變成了實現用戶界面友好性的平臺，并且已經存在強大的 JavaScript類庫來處理復雜的交互動畫。伴隨著太多的“CSS VS JavaScript動畫”混戰而來，一個全新的并且專門為網頁動畫制作而生的API接口終于誕生啦，這件事可能會促使兩大陣營聯合。(CSS和 JavaScript)

2014年對網頁動畫來說，是一個激動人心的一年，也是一個銘記辭不達意和錯誤信息的一年。在2014年里，我有機會去環游世界來探討在用戶界面和設計中使用動畫。我遇見過并且采訪過許多使用過和支持CSS和JavaScript的人。然后采訪許多開發人員，設計師和瀏覽器生產商，我發現一個科技與人類的故事正娓娓道來。

你將閱讀到的以下內容包含純粹的觀察研究和你可以找到關于網頁動畫面向對象的無偏性解釋。

Flash時代可能成為過去，但是網頁動畫的時代已經開始

自從Flash時代以來，認為動畫不僅僅是要在調色方面使用簡單已經變成一種潮流，一個“閃現”的突發奇想，經常是給人一種不好的體驗，就像一個很討厭的閃爍標簽，但是除非我們想展示的東西僅僅是屏幕的復本，那么動畫仍然是我們的朋友。

對用戶界面設計師來說，動畫強調層次，人際關系，結構，起因和影響。調查重返90年代早期論證動畫幫助人們理解屏幕上發生什么。動畫可以將應用app狀態聯系在一起并且也可以使為大腦GPU工作的可視化皮質處于卸載狀態。

對交互設計師來說，大到平板電腦上的視頻游戲，小到儀表盤上的圖形等復雜的視覺是一定要使用動畫來將所有的動畫碎片粘合起來。即使我們想在Internet上實現類似的復雜特效，我們還是仍然要使用動畫。

難過的是，我們已經在運動設計比賽中落后啦，隨著使用動畫來讓用戶受益的產品越來越成功，競爭對手的那些靜止且濫用特效的產品將會失敗。事實就是如此，原生的app應用正在擊垮遠離互聯網的褲子行業。app應用開發工程師從一開始將動畫元素加入到產品設計中，如Flinto和Mitya等原型工具，然后在工作流程中具體化。

但是情況貌似正慢慢好轉，IOS Sarari團隊指出，CSS動畫以及轉型規范使得網站在用戶界面和用戶體驗方面能夠表現得和IOS應用一樣好。即使Google已經注意到這些，在它的 原材料設計指南中指出，將動畫前端化和中間化，出于使用動畫和做有意義的轉換的目的，應該注意什么東西該做，什么東西不該做。

在應用更新迭代和設備生態系統中，動畫自然而然成為下一步計劃。動畫使得數字世界對不同年齡段的用戶將變得更加直觀和有趣。并且只要我們的設備運行GPU，動畫將不會消逝。

讓所有的東西動起來

從動畫的本質來看，動畫僅僅是時間和速度以一定速率在改變的可視化載體。所有的動畫可以概括為三種類型：

靜態化的動畫是指沒有分支和任何邏輯，從一個起點運動到一個終點。這種動畫可以用CSS單獨實現,正如CSS載入動畫的豐度證實。

最簡單的狀態化的動畫形式需要boolean值的輸入——一次點擊打開菜單然后一次點擊關閉菜單，例如——在兩種不同到狀態下實現運動效果。在CSS動畫的范疇內，通過運用和移除類樣式，目前已經有JavaScript框架實現。

動態化的動畫可以有許多的動畫效果，這取決于用戶的輸入和其它的變量因素。動態化的動畫使用它本身的邏輯來決定自己如何運動和終點在哪里。動態化的 動畫可以根據你刷卡的速度來推測在你手指后面拖拽一個卡片，或者隨著新的數據進入動態改變圖像。在處理動畫的今天，用工具實現的動態化的動畫是最復雜的一 類動畫。

狀態多元化 != 動態化的動畫

"機智的"CSS開發者可能指出，只要有足夠的狀態，CSS動畫非常像動態化的動畫。從一點上來說這是正確的。但是真正的動態化動畫有很多你可以提前使用的終態。

想象一下，不大的載入進度條，是利用每一個用百分比實現"豐滿度"且擁有不同類樣式的像素點很輕易的可以發展為數以百計的CSS直線，而不是提及 JavaScript必須觸及DOM來更新類樣式和瀏覽器重繪的次數。因此，我們非常清楚要單獨用JavaScript編寫一個高性能的動態加載器。

CSS動畫聲明:除了少量的偽類樣式，例如:hover和:target，可以接受不是來自用戶也不是來自用戶周圍上下文環境的文本。確實只能讓作 者(CSS動畫)告訴它該做什么，并且不能對新的用戶輸入或者環境的改變做出響應。沒有辦法來新建一個"能夠在你的鼠標處于頁面的中部做這件事情否則做那 件事情"的CSS動畫，CSS不能提供分類的邏輯。

當CSS1.0開發者需要邏輯，他們經常通過CSS方法來聲明類樣式，然后通過JavaScript來處理需要應用聲明的樣式的邏輯。例如像 AngularJS框架支持這種聲明，然后許多UI交互設計師很輕易適應少量類似“loading”，“open”和“selected”的樣式聲明。這 些動畫也會減弱在老的瀏覽器的表現力，提供比較大需求的能夠支持CSS動畫和動畫轉換的UX驅動。

交互設計師經歷不同的CSS動畫時代，CSS動畫經常太苛刻導致不能處理開發人員想實現的特效。需要為客戶端要求可以兼容更多的瀏覽器的可靠的動畫 買單；所以，許多交互設計師和他們的工作室已經做了許多聰明的開發人員所做的事情：依據自己的工作進程，來編寫復用度高的類庫。類似這些類庫，像GSAP和Velocity類庫對大眾來說很容易獲得到而且很容易被發展。但是有很多人不會對外界發布，因為創建類庫的個人或者團隊沒有時間或者沒有錢來支持開源的項目。

這是我聽了一遍又一遍的深深的令人焦急的故事，并且表明許多開發人員正在重復造輪子，并沒有將web向前推進。這里沒有足夠的被認為"nice to have"的需求來支持許多的競爭對手。為了生存，很容易看到像GSAP類庫如何被商業化，或者如何像Velocity類庫被贊助。

由于給予交互設計師和UI設計師一個通用的能夠適應多種多樣的動畫和能夠編輯它們的平臺工作流程,所以Flash做了一件偉大的事情。但是自從Steve Jobs宣布2010年以后Iphone將不再支持Flash，許多正式的Flash開發人員已經陷入被棄用，隨身攜帶Flash知識。現在，相比較而言，web設計師這整個一代人一起交流時，并不知道這些可能性和我們所面臨的挑戰(當提升動畫的復雜度時)。

但是這些事情即將煥發生機。

網頁動畫API：一個最偉大的且你從來沒有聽過的API

這個web動畫API是一個按照W3C標準且為CSS動畫和SVG動畫提供統一的語言，為開發者調試開啟瀏覽器的動畫引擎。API包括以下內容：

1. 提供一個動畫引擎API，使得我們可以開發更多基于瀏覽器的動畫工具并且讓動畫類庫性能提升；
2. 提供(限定)動畫自己的多線程，廢除掉jank;
3. 支持運動路徑;
4. 提供后動畫回調；
5. 重新引進自從Flash以后就沒有見過的嵌套和順序動畫;
6. 能夠通過定時字典和動畫播放器讓我們暫停，播放，查找，倒退，慢放，或者快進回放。
</ol>

這是Web動畫API能夠實現而CSS不能單獨實現的一個事例。

通過Rachel Nabors(@racheInabors)在CodePen見識Pen(codepen)利用Web動畫API運行

支持

Web動畫API在創建的過程中已經超過了2年，API的特性已經在chrome和firefox發行版測試通過前前后后花了6個月。Mozilla是制訂這標準的主要力量。以此同時，chrome團隊已經為特性的支持設立優先級。

為IE瀏覽器“微軟正在考慮支持API”。令人吃驚的是，蘋果為Safari瀏覽器也采納wait-and-see的方法。然后我們只能幻想當Web API碰上被開源瀏覽器所過時的叉形指令所支持web應用引擎。

想瀏覽API的早期嘗試者可以試驗Web動畫API中的polyfill，正在隨時被Web Animation Next逐字取代(更多關于polyfill及其API詳見Polymer project)。然而，對瀏覽器來說，不支持Web API，意味著polyfill性能仍然會比GSAP(基于JavaScript動畫類庫的冠軍)差。因此，ployfill并不是開發人員想為了高性能項目的產品而加入其中的可交互的類庫。

Web API被全部支持還需些時日。一半的瀏覽器廠商推遲支持API以便來觀察開發人員如何使用API，并且大多數開發人員拒絕使用未廣泛支持的工具，Web API面臨雞和蛋的情境中。然而，舞臺上一次與Google的Paul Kinlan對話中，我表明，Web API在一個不公開的獲利系統中完美的支持像Google Player等web應用，在Web API未達到成熟穩定以及完全支持情況下，開發人員可以在"有墻的花園"中安全使用API。

性能

API的作者和參與者希望動畫類庫的開發人員可以開始嘗試尋找Web API支持提升自身的性能優勢的特性。因為Web動畫API使用的是CSS渲染引擎，所以我們預期CSS性能的好壞程度。只要動畫不依賴發生在類似 JavaScript或者布局的主線程的任何事情，這樣的話動畫就會依據自己的線程來運行。

說到布局，對瀏覽器而言回流存在一個最大的處理障礙。除非你通過WebGL動畫類庫(開發人員正在使用靈活性高的內部動畫類庫)直接將所有的東西輸 出到GPU，否則沒有哪個CSS動畫或者JavaScript動畫可以規避這個障礙。除了不透明度和變形以外，令我們倍受啟發的是，CSS屬性的改變會導 致回流的產生，例如布局上的一些改變或者屏幕上像素點的重繪。改變CSS屬性有助于這些像 促使我們指出一些問題，然后告訴瀏覽器，“CSS屬性將要改變，瀏覽器你要做的事情就是如何高效的改變CSS屬性”。希望瀏覽器在圖像處理能夠變得更靈 活，這樣的話，瀏覽器可以將圖像元素移動到瀏覽器的圖層中或者在另外方面優化瀏覽器處理圖像的方式。這是消除像translateZ(0) hack的第一步。

每當動畫正在(進行)閃避(動作)時，一些“性能hacks”就會被用來對動畫(的運動軌跡)進行神奇的修正，但是當無意識的使用性能hacks， 就經常會造成性能事故。從長遠來看，性能決策真的最適用于瀏覽器。幸運的是，瀏覽器制造廠商正在爭相讓瀏覽器實現觸發回流只需要更少的屬性(的功能)，這 樣的話，可以使動畫規避主線程。對動畫類庫開發人員而言，這就意味著在不久的將來，Web動畫API在性能上成為最大的贏家。

工具

與web動畫打交道的任何人迫切希望有合適的動畫開發工具必須具有以下功能：時間軸，審查元素，編輯器，能夠暫停和倒帶，在另外方面處于調試狀態下 可以檢測動畫。Web動畫API會對開發人員開放CSS渲染引擎內核，然后瀏覽器制造廠商基于CSS渲染引擎開發針對自己瀏覽器的工具。但是Chrome和Firefox正在為它們的開發工具實現支持動畫特性的功能。Web API讓這些事情的實現變成了可能。

今天的Web動畫社區

除了與Web動畫API打交道的人之外，還有不少的人知道Web動畫API。官方社區殷切希望獲得來自現實世界中交互的反饋以及動畫類庫開發人員的 青睞。然而，一些開發人員感覺標準化(讓他們感覺)像活在象牙塔里面，遠離戰場的殘酷，不用顧慮用戶的需求，不用再為Flash煩惱糾結。



公平地說，標準化的出現并不是在動畫這個領域迎合它們的忠實支持者。參與到官方的Web動畫API交流，必須通過層層審核，避免通過郵件鏈接導致任 何忙碌的開發人員的收件箱遭受爆滿威脅的情況。或者，你也可以使用IRC然后加入交流中來(只有設計師使用IRC)。需要開展的對話處于交流中占據重要地 位的人沒有參與交流的情況下，是很難開展下去的。瀏覽器供應商和標準制定者需要找到如何與重要的支持者交流的多條途徑，否則就要冒著沒有一個支持者的支持 風險來創建Web API。

標準化并不是唯一個有交流上的問題。作為一個社區，我們是具有批判精神的，并且能夠很快放棄我們認為不值得做的事情(Flash或者我們不喜歡的 API)。我們大多數人喜歡對自己(開發的)工具和項目進行自我投資。但是這些情況不能對我們進行定義。我們在一起創造的東西才能定義。

動畫類庫開發人員，閱讀這些標準，很長，但是如果GreenSock’s Jack Doyle可以做的話，你也可以。

交互設計師，這是一群沒有一整天時間來閱讀這些標準，僅僅是閱讀 詳見多邊形填充，完美的TLDR。既然你知道這些標準，就應該知道這些標準對你優化類庫的性能或者構建瀏覽器內置時間軸UI可能有很大的作用

設計師，工作上優先考慮JavaScript。鼓搗ployfill，把玩GSAP和Velocity。在你工作中找出CSS不能單獨完成的項目。

正因為有web動畫，我們才能有這少有的機會來撇開自我，然后一起為社區構建將來一代開發人員和設計師能夠用它做出偉大的東西的工具。為了(這個偉大的愿望)，我希望我們可以(創建這樣的工具)。

 “藝術挑戰科技，科技激發藝術。” – John Lasseter, CCO Pixar

資源

Rachel Nabors有Web動畫API更新的資源列表。加入非官方的交流，無論你在什么地方，只要你喜歡交流，就可以尋找#waapi標簽。

1.Web動畫(API標準)，W3C
2.Web動畫多邊形填充和Web動畫的下一步(下一個多邊形填充的實體)
3.GreenSock動畫類庫
4.Velocity Velocity.animate()代替jQuery的animate()

加入交流當中來

1.官方郵件列表：public-fx@w3.org，開啟[web-animations]...相關的主題列
2.IRC:irc.w3.org#webanimations
3.其他任何地方：使用標簽#waapi然后加入到這個社區

區別對待

熟悉C++代碼風格的工程師可以在FireFox中實現API。Brian Birtles可以指導你!然后Mozilla經常招人在MDN寫文檔。

對標準(語法，拼寫，矛盾等)的小改的提交可以像在GitHub上提交。

在推ter可以關注的工程師

Brian Birtles，Web Animation標準制訂主要作者，Mozilla日本

Alex Danilo，Google平臺成員和發起人

Tab Atkins—Googler，CSS標準發起人和制訂者

Jack Doyle，GreenSock成員和GSAP成員

Rachel Nabors，動畫頭部想法擊敗Tin Magpie

解決手機方面的問題令人很頭疼。這也是我們為什么和Peter-Paul Koch合作編寫移動web手冊(有效處理手機常見的前端問題的實戰新指南)，現在可以了解這本書

Rachel Nabors，交互設計開發人員和漫畫大賽獲獎的漫畫家。她環游世界，在web動畫的藝術領域培養團隊和談論web動畫。考慮到她從不在Portland騎車閑逛，她在公司 Tin Magpie里創作互動性強的漫畫。你可以在推ter @rachelnabors關注她或者她的主頁 rachelnabors.com。

來自：http://www.w3ctech.com/topic/1397