不會做動畫的前端不是好開發

作者｜續彬 & 池建強 今天這篇文章來自 MacTalk——池建強老師的公眾號，非常值得一讀。很慶幸此時池大大已經成為極客邦的一員，和前端之巔同屬一個大家庭，因此澱粉們也可以近水樓台先得月，獲得較快轉載后的推送了（竊喜中 O(∩_∩)O）。廢話不多說，快來一起看文吧！

池建強：今天推送一篇前端雄文，讀了這篇文章，你會有一種前端已經上了天的感覺，甚至有可能忘記催我寫 Python 系列。不過這篇不是我親手所寫，而是我的一位老朋友的團隊成員給 MacTalk 寫的。我的老朋友叫恩陽，阿里高 P，非常高，他最知名的地方並不是技術好，管理團隊牛逼，而是常年以一輛馬二在杭州餘杭地區縱橫馳騁，天下聞名。可惜，最近他換了兩輛豪車，一下子變得無趣了很多。（小編註：池大大現在經常加班，生活十分有趣。）

續彬是恩陽的同事，是我的朋友，也是阿里的技術專家，他最近在我的「攻城獅群」做了一次前端技術的分享，我建議他寫一篇相關技術的文章，也就是今天的成文 —— 前端里的高級動畫技術。

他的簡介如下：

鄧紅春，在阿里的花名是續彬，現在負責天貓互動團隊的終端技術，包括了 Web 前端以及 Native 客戶端開發。我在 08 年剛畢業那會做了一段時間的 PHP + MySQL，做得比較雜，之後很長一段時間專註於前端開發。2010 年加入了騰訊專業寫 JavaScript，再到 2012 年加入天貓一直到現在，這 7 年的時間內我一直聚焦在用戶體驗這件事情身上。

以下是正文。

至從有了前端開發這個概念以來，其實這個崗位所做的事情都是圍繞著人機交互來開展的，主要包括展示信息給用戶看，然後獲取用戶的意圖並做出響應（本文提到的前端主要是指大部分人認為的 Web 前端，其實 iOS 和 Android 的客戶端開發本質上講也是完成類似的工作，但技術棧還是不一樣，而且擁有更多的底層能力，所以我用客戶端便於區分，後面會提到，所以提前說明一下）。

隨著終端設備以及業務的快速發展，前端工程也越來越複雜，所以分工也進一步精細化，有側重做工具化與模塊化架構的，有側重無線體驗或者 Web 與 Native 融合方面的，也有側重複雜的商家後台或者數據可視化的，甚至有部分公司把 HTML+CSS 與 JS 的工作也分開的，所以出現了不同前端工程師會有不一樣的側重點。

在這種大背景下，提出『不會做動畫的前端不是好開發』的論點顯然是很難站住腳的，因為動畫僅僅是前端技術的一部分，很多人在其他前端領域也做出了很高的成就。但是，作為一個多年從事於互動領域的我來說，寫這樣標題的文章出來其實是有私心的，因為我們的業務有越來越高的動畫類需求，而在動畫方面能緊跟技術趨勢的優秀前端實在是比較難找，希望通過這麼一篇文章，讓那些想在動畫方面有些提升的朋友有所幫助。

本文討論的主題是動畫，是屬於剛剛所說的展示以及響應，也就是輸出的那部分，我認為一個高質量的動畫在很多情況下都能大大提升用戶的視覺體驗，前提是使用得當並把握好度，理由如下：

1、更形象化的表現力。因為人們的現實世界就是動態的，有時候用靜態的圖片與文字很難把場景描述清楚，比如我們要展示狂歡的節日氛圍。所以，天貓雙 11 的狂歡城與晚會的頁面就用了大量的動畫來表現；

2、更自然的過渡效果。一個有趣的 loading 能緩解用戶在等待響應過程中的焦慮情緒，就像是在等待上菜時可以看看京劇表演一樣。而且，即便是性能 DIAO 炸天的 iPhone7plus，也有很多賞心悅目的界面切換動效。

3、更具互動性。這個不想多解釋，試想一下一個一動不動樹立在你面前的人和一個扭動身姿而且做出豐富表情的美女哪個更讓你想有進一步交互？

所以，只要恰當的用好動畫這個技能，能在非常多場景上大大提升用戶體驗，進而讓用戶更有參與感。在競爭激烈的互聯網行業，好的體驗能為業務帶來巨大價值。比如，如果用戶能在手機上和一件商品進行很好的交互，而不再只是看靜態的圖文詳情，那用戶會更樂意去體驗它，從而提升購買轉化率等等。

隨著硬體與底層系統的發展，用戶的終端對動畫的表現能力越來越強，所以將會有更多的場景大量使用動畫，從 2D 到 3D、從虛擬到現實，對前端團隊的要求也越來越高，不再是能用 jQuery 的 animate 或者 CSS 的 transition 做個 loading 可以了的時代了。

講了這麼多背景與趨勢，下面進入正題，那前端可以使用哪些技術來實現動畫呢？

1、對程序員而言最省事的就是視頻或者 gif 圖片了，而且目前在很多情況下也在廣泛使用，優點是對業務方來說沒有太多限制，溝通成本低，缺點是在色彩、透明度的表現力上不如 PNG，而且交互性差，不過也可以通過碎片組裝的創新方式達到可以互動的效果；

2、又愛又恨的 Flash，具備成熟易用的 IDE 與強大的 ActionScript，簡直就是為動畫而生，而且兼容 IE。可是依賴插件、耗資源、安全性等問題讓它在手機端幾乎寸步難行，我想這個技術其實已經沒有再考慮的必要了；

3、通過 JS 改變 Dom 節點的 CSS 屬性應該是集開發成本低、兼容性好、具備互動性，加上 PNG 圖片很好的色彩與透明度的表現力基本能滿足很多動畫需求，也是目前大部分前端使用的方法。但是在複雜的大場景中性能較差，並不是特別流暢，而且也解析 3D 模型；

4、Canvas 的到來彷彿是上帝為前端同學提供了神來之筆，而且是眾多大廠推崇的官方標準，不需要插件，瀏覽器內核支持，可以繪製各種圖形以及具備高性能的圖片渲染能力，而且能比 flash 更好的與頁面中其他元素交互等等，但純手工編寫 canvas 程序的成本其實較高（原因可以 google），動畫實現起來較為繁瑣，但可以通過封裝一些方法進行解決；

5、大廠對 WebGL 的支持相當於為前端的那支神來之筆賦予了新的魔法，在 Canvas 的基礎之上增加了 OpenGL ES 的 3D 繪製能力，並且能開啟硬體 3D 加速渲染，讓前端動畫的世界充滿了更多想象的空間，天貓雙 11 狂歡城、年貨節以及眾多 AR 項目中已經在大規模嘗試基於 Web3D 的渲染技術。

可見，隨著技術的發展，實現動畫的方式有非常多，大家可以根據自己的業務與團隊情況選擇合適的方式進行開發，但為了給用戶帶來更極致、更創新的體驗，需要我們掌握這些技術以便在需要的時候能馬上實施。

具備更強表現力與想象空間的 Canvas+WebGL 顯然是未來的大趨勢，iOS 與 Android 對 WebGL 的支持越來越完善，目前已經能覆蓋 80% 的手機用戶了，而且很多 APP 的 WebView 底層做了很多優化，加上硬性的發展，覆蓋率會持續升高。

隨著 AR/VR 等虛擬技術以及硬體的發展，扁平化設計的小潮流逐步向更具景深感、立體感、動力慣性等物理效果發展，因為這才是更真實的世界，三維動效已經成為了大趨勢，3D 模型會成為前端團隊很難逃避的內容。

雖然本文主旨就是圍繞著 Web 前端開發來講的，然而客戶端開發其實也有些同學也在做動畫相關的一些事情，而且擁有更極致的性能與兼容性的表現，但也有開發成本高、無法開放、依賴發版、熱更新有局限等問題，所以會更偏向於日常的標準化產品，如手游或者日常 APP 中的一些轉場效果。當然，有些 Native 的渲染引擎在通過一系列設計與封裝，在跨平台和熱部署方面也取得了不錯的進展。

由於 Canvas 和 WebGL 屬於世界公認的 Web 標準，所以除了在開發成本、跨終端、熱部署、開放性等方面擁有絕對優勢之外，也具備活躍的生態和大量的儲備開發力量，底層 runtime 不斷在優化的情況下，將能滿足快速的業務發展訴求。

所以，不管是 Native 前端還是 Web 前端，在動畫方面都在快速發展，就像在 web 中可以選擇多種渲染技術一樣，採用 Native 還是 Web 也要根據業務與團隊情況進行選擇。由於我們團隊的業務量較大，而且需要為不同的品牌商甚至不一樣的商品進行個性化開發，同時需要運行在不同的 APP 和不同類型的設備裡面，長遠來看，我個人更看好 Web 渲染技術的發展，而我們團隊的客戶端同學我會更傾向於更多的底層建設與更多的創新。從天貓近一兩年的實施來看，我更加堅信這個方向，所以，接下來我會繼續回到 Web 層面展開分享。

高質量的動畫包括幾個要素：

其實這三者之間存在一定的矛盾，需要根據需求去平衡，做出一些取捨。但其實老闆也業務方是不太喜歡取捨的，都能達到那是最好，所以作為技術人我們必須要有追求極致的鑽研精神，下面我通過一些案例來分享一下我們是怎麼做的。

先看一下效果，如下是 2014 和 2015 年的雙 11 狂歡城的頁面（gif 太大隻給 url 吧）：

做這個項目的時候，要同時滿足業務與性能的要求，還是面臨這不少挑戰的：

• 圖片多：100 多個品牌 logo，還有場景地皮

• 動畫多：大量精靈動畫，每個至少 3 幀

• 場景大：在手機上共有連續 8 屏的超長頁面

所以這個頁面將消耗大量內存與 GPU 資源，通過 Dom 實現會非常卡，所以我們選擇了 canvas 進行實現，每年都會做一系列優化措施，比如：

• 除了 CDN+ 客戶端預載入等常規緩存機制之外，我們在頁面的運行時進一步做了 Canvas Cache，使用一個額外的 Canvas 來保存已經繪製過的內容，下一次使用的時候直接從這個 Canvas 上讀取，這樣就可以大大減少 Canvas 的繪製次數，例如原先首屏繪製次數約為 75 左右，使用 cache 后的次數約為 28，減少了 62.67%。

• 為了減少地皮圖片的數量，2015 年的狂歡城我們與設計師溝通后決定嘗試一下，使用地皮拼合的方案，重複使用一些圖片進行對地皮的組裝，由於圖片的內存佔用是根據圖片尺寸轉換為 2 的 N 次方，然後計算大小，所以圖片尺寸越大佔用內存可能導致指數級增長，狂歡城中的圖片都是小圖 (地圖區塊都是 256 以下，其他基本上也是 512 以下)，所以內存佔用上會小很多。

• 通過 Hybrid 介面獲取硬體信息（內存、GPU、屏幕等）判斷如果是低端機器，我們採用非高清圖片以及 Dom 的渲染方式進行優雅降級。

再來看看基於 WebGL 的 Web3D 案例，如下是 2016 年狂歡城項目：

當時我們希望通過 3D 為用戶帶來全新的視覺體驗，但由於場景還是非常大，如果所有元素全部採用模型的話那面數將面臨巨大的性能挑戰。承載著眾多品牌商的流量入口的業務壓力下，我們和設計師經過大量的測試與探討，最終實現了一個滾筒 + 紙片風的效果。過程中也嘗試了用 CSS3 和 cavans 模擬 3D 來實現，但有各種閃爍以及卡頓問題，最終還是基於 WebGL 的 3D 圖形進行實現的。說實話，從效果上講我們並不是非常滿意，畢竟做了一些妥協，但從技術上講，是一次非常大的突破。

2017 年貨節我們再一次挑戰 Web3D 的極限，用更加有衝擊力的體驗展現過年的快樂氛圍，拉近消費者與品牌之間的距離，我們設計了一個全模型的場景來構建，如下：

這個場景的模型有 30M，通過 WebGL 渲染出來之後就有些卡頓了，我們決定把更多的資源讓給互動的主題內容，而不是場景，所以把外圍場景轉化成了一張全景圖：

然而輸出的全景圖我們不打算放在一個球體上。因為有曲面就會有變形，但是天空部分因為是純色，所以這部分形變是看不太出來的。可是如果這部分形變作用在建築上就會非常明顯。所以我們把球形換成一個「壓扁柿餅形狀」:

最終我們實現的效果如下（其實攝像機可以做更多變換，有做導演的趕腳了）：

可見，這時候的動畫開發，除了考慮對圖片的處理之外，還有模型文件的處理以及攝像機的使用。

說完從 2D 到 3D，再分享一下從虛擬到現實的動畫應用，也就是我們所說的 AR（增強現實），如下是天貓 AR 業務裡面的兩個案例（一個是天貓互動 2015 年初首次嘗試，一個是近期我們的合作夥伴使用天貓的介面實現的）:

本文先不討論 AR 的識別與跟蹤演算法，但對需要與演算法對接的動畫渲染技巧要求會更高，要與攝像頭裡面的現實場景混合在一起面臨兩個主要的新挑戰：

• 除了虛擬的那部分動畫需要足夠的流暢之外，還要隨著現實場景的變化而變化，攝像頭的方位或者識別物本身可能都在高頻晃動，所以虛擬物體怎麼與攝像頭以及演算法進行絕對同步呢？實際上是非常難做到的，而且如果使用 Web 的方式進行渲染，問題會更大，因為攝像頭與演算法層通常是在客戶端，部分演算法能力可能在服務端。在攝像頭獲取圖像，到演算法計算，再到顯示攝像頭圖像，最後到渲染反饋，任何一個環節都會有時間消耗，需要設計一個巧妙的同步機制才能讓整個 AR 體驗更加的順暢，不然就會容易抖動。

• 在 AR 的場景中比在純虛擬的場景中，對材質與光照的要求更加的強烈，因為如果渲染效果不真實，就算動畫與跟蹤做得再流暢也會出現格格不入的情況。

由於篇幅有限，更多的技術細節就不進行展開了，看到這裡，你應該清楚自己是不是一個會做動畫的前端了。

開頭有提到，自己完全手工去基於原生介面開發動畫的成本還是比較高的，所以需要把通用的能力沉澱下來，為開發者提供更高效的開發體驗，這樣大家才能更專註於業務本身，避免很多重複勞動。所以，最省心的做法就是選擇一個現成的產品進行使用，但前提是需要選擇合適的，早期有 Egret、Pixi、unity、Cocos、three.js 等相關的動畫引擎的產品，大家可以自己的需求進行選擇。當然，如果發現沒有非常適合的，可以選擇進行擴展或者自己研發，以便滿足自己團隊的業務需要。

在 2014 年阿里選擇了自研一個叫 Hilo 的引擎，其實根本原因是我們沒找到一個適合電商業務的，否則可能就用了，就不會有今天的 Hilo，主要原因有：

• 性能要求高。天貓和淘寶大部分互動頁面都是運行在 APP 中的 Webkit 的 Webview 容器中，而且和複雜的業務混合在一起，要求足夠小、輕量、高性能；

• 需要易上手、易擴展。電商類業務開發節奏非常快，不能有太高的學習成本，也需要大型遊戲的那麼多功能，只要有極致的渲染以及物理能力即可，其他的可以根據情況選擇性擴展，同時需要與其他業務保持同樣的開發語言，而不是 TypeScript 或者其他腳本；

• 兼容性要求高。對於阿里的用戶體量來說，10% 的用戶就已經是很大一批用戶了，所以對 IE 以及低端手機的支持不能完全不考慮；

• 開放性與安全性。

經過多年的實戰，Hilo 支持了阿里很多動畫相關的業務，比如上面提到的多年雙 11 狂歡城，并行成了很多周邊工具，天貓互動團隊在 2016 年決定對 Hilo 進行開源，希望給有需要的團隊多一個選擇，其主要特點有：

• 極簡內核，2D 部分已經開源（ https://github.com/hiloteam/ ），壓縮后只有 24KB；

• 採用前端工程師熟悉的 JS 標準語法，支持 ES6，支持 CommonJS/AMD/CMD/Standalone 引用方式；

• 支持 Webgl/canvas/weex/dom/flash 五種渲染模式，能兼容更多的運行環境；

• 充分的 API 與 UI 測試，安全穩定；

• 使用 Yeoman 腳手架，可以快速生成一個動畫應用；

• 無縫銜接的豐富工具集（DragonBones 骨骼系統、TiledMap 地圖編輯器、ChipmunkJS 物理系統、粒子編輯器、Flash&AE IDE 插件等等）；

所以，Hilo 除了支持大場景的互動頁面之外，像如下這些簡單的動畫都是可以由工具直接導出為 Hilo 動畫做成的（可交互可控制的 Canvas 動畫，非 GIF）

上文提到了很多 3D 和 AR 項目，也沉澱出了 Hilo3D，目前正在阿里集團內測，感興趣的朋友可以到 github 提 issue，Hilo3D 的主要特點有：

• 沿用 Hilo2D 的設計風格與開發方式，極簡 + 易上手

• 支持 glTF 模型，提供在線格式轉化器

• 聚焦在渲染效果、性能、兼容性三方面

是不是有了適合你的工具箱就能放心大膽的走天下了呢？引用我常說的一句話，那就是「巧婦難為無米之炊」，技術再牛，沒有原材料也是「英雄無用武之地」。所以還需要關注怎麼提升模型素材的生產效率，降低業務落地成本，這部分內容下次有時間再分享。

回到標題那個問題，是不是不會做動畫的前端就不是好開發呢？顯然太過絕對，如果說是，那肯定會被罵。不過我覺得能精通動畫技術並與時俱進的前端開發肯定會很受歡迎，因為你是離用戶最近的貼心人。

最後推薦一下 Hilo，以前我就推薦過，現在越來越成熟了。

收藏指數滿格！幫你打包前端之巔一整年好文！

InfoQ 主辦的移動和前端開發領域的精品大會【GMTC 2017】今天開幕，作為首屆以「大前端」為主題的大會，GMTC 涉及移動、前端、跨平台、AI 應用等多個技術領域，幫助你方方面面提高技術水平。關注前端之巔，回復「GMTC」即可查看或下載 PPT。

「前端之巔」是 InfoQ 旗下關注前端技術的垂直社群，加入前端之巔學習群請關注「前端之巔」公眾號后回復「加群」。推薦分享或投稿請發郵件到 [email protected]，註明「前端之巔投稿」。