歷時2個月，整理了這篇動效落地輸出指南！

針對動效輸出的選擇變得越來越多，然而作為設計師僅僅對動效輸出有所了解，往往產出的結果還是不盡如人意。了解動效落地背后的原理，可以幫助我們在設計的前期階段，就了解應該如何做設計才能更容易的對接和落地。

隨著技術革新，用戶對于產品細節的感知度和挑剔程度正在日益劇增，越來越多的產品都在嘗試通過不同的手段來打造產品的差異化，而動效設計作為近年來大火的設計趨勢之一也被越來越多的產品所青睞。動效日漸從「錦上添花」慢慢變成「必不可少」的優秀產品的構成元素。但是當我們去觀察身邊很多的線上產品，對于動效落地把控的現實結果往往并不盡如人意，很多優秀的概念在想法階段到最終落地幾乎被打磨得體無完膚。以往的經驗告訴我們，可以通過簡單的方式輸出我們的設計作品，并且加以跟進就可以使線上的結果達到很高的完成度。但是當我們面臨動效輸出的時候會發現，輸出的選擇在日漸變多，但是輸出的結果還是很難達到理想的狀態。

目前市面上針對動效的輸出與落地主要還是圍繞著基礎的幾種輸出方式，輸出方式的選擇就困擾著很多的設計師，而作為設計師我們要做的不僅是了解在什么情境下應該選擇什么樣的輸出方式，更應該了解這些流程化的輸出方式的原理，以及圍繞這些原理我們可以在整個產品的設計流程中能做到的更多的事情。

產品中的動效分類

在了解動效落地方式的選擇之前，我們需要明白的第一件事是互聯網產品當中的動效分類與一般意義上的動效有很大的區別。廣義的我們把 UI 動效分為三類。

1. 情感化動效

情感化動效偏向于感性的層面，主要目的是增加我們產品的氣質和傳達情緒，增加產品的魅力值，在一些小的細節上我們加入一些情感化的元素也可以以彩蛋的形式給用戶驚喜。比較常見的有 app 中的 loading 動畫，點贊動畫等。

2. 交互動效

產品流程、交互行為的串聯，不論可實際操作的交互原型，還是純做 demo 展示的動效過場都可以算作交互動效設計。交互動效最基礎的形態就是原型流程圖的串聯交互稿。交互動效又可以細分為轉場動效和微交互，分別應用于頁面銜接和基礎組件的交互反饋。前者可以傳達給用戶產品的層次結構和空間關系，后者可以使用戶減少操作成本。

3. 復合型動效

復合型動效不局限于感性層面的情緒傳達，也不局限于交互行為的串聯，往往真實場景當中更多的也是這一類動效，在與開發人員對接階段也更容易存在各種各樣的不穩定因素，對于設計師而言也存在更多層面的挑戰性。

影響輸出方式的因素

情感化動效一般情況下會受到三個方面的屬性影響他的輸出選擇，分別是尺寸、時間、動畫復雜度。

1. 動畫尺寸

動畫尺寸越大，占用系統空間越大，占用的系統性能也越大，但是這個等式僅僅成立于我們常見的一些所見即所得的格式上，例如 gif/視頻/webp/apng 等。

類似這樣的一些格式，是我們的設備所能接受的最簡單最直白的格式。他產出一個動畫的邏輯，一般都是不同的靜態圖像的堆棧，通過給定的次序和時間逐個播放。這里的每一個靜態構成圖，尺寸越大，整個動畫的占用內存相應的也就越大。但是產品包的容量始終有限，不能允許太大內存的動效存在。

另一方面，大尺寸的靜態圖在預覽過程中也需要耗費更多的設備計算。舉一個很簡單的例子，當我們在電腦上預覽一張 800*600 的圖和一張 2400*1800 的圖，電腦打開它所需要的時間是不同的。相應的，動畫格式多個大尺寸靜態圖做預覽時耗費的系統性能是成倍數增長的。

2. 動畫時長

影響原因與尺寸的影響原因類似，當圖片堆棧的時間變長時，堆棧當中的圖片數量也會增加，動畫的占用內存相應的也就變得更大。所以，當我們的動畫時間過長時也不適合使用這些所見即所得的格式類型。

需要注意的一點是，動畫的時長對性能的影響會相對的小很多。

3. 動畫復雜度

動畫復雜度對在以上提到的輸出格式當中不存在任何問題，更多的是在近幾年比較時髦的輸出工具上出現問題。對于復雜動畫，我們要盡可能選擇輸出所見即所得的格式。當選擇了其他的格式時也要盡可能的減少動畫的復雜度，保留重點，去掉冗雜的細節。

情感化動效輸出選擇

一般情況下我們會根據動效的類型把輸出方式分為兩類：

• 所見即所得格式
• 所見非所得格式

所謂「所見即所得」就是輸出之后即可預覽的格式，比如 GIF 圖/視頻這種的格式，也是動效輸出最基礎的格式。

1. GIF圖格式

GIF 圖格式，可謂是作為設計師接觸得最多的動態格式了，GIF 格式自 1987 年由 CompuServe 公司引入后，因其體積小而成像相對清晰，特別適合于初期慢速的互聯網，而從此大受歡迎。因為時代背景使得他有非常強的兼容性，基本上可以在目前大多數的智能設備上直接預覽。不論動效落地還是在各個平臺上的兼容性也都是非常優秀的，尤其在一些設計平臺上，也是選擇最多的概念展示格式之一。也因為他在不同平臺設備之間的兼容，他的傳播性也是非常強的。

當然除了他自身所帶的這么多優點之外，GIF 格式也因為他的應用年代技術限制，會有很多其他的缺陷。前面提到的很多優點往往也是因為誕生早給他自身帶來的福利，他會有很多不可逆的問題。=第一點是對電腦的內存和性能占用非常大（根據 GIF 的時間尺寸等情況會有不同程度的影響）。第二點他是一個有損的文件格式，不論是色彩還是畫面質感都會有一定程度的壓縮。第三點是對透明通道的支持非常有限，輸出結果會非常差，時常會有鋸齒或白邊的情況。以上是我們在輸出 GIF 格式之前，需要提前思考是否可以接受的問題。

另外輸出 GIF 圖的過程也經常困擾著很多的設計師，我也為此錄制了一篇關于 GIF 輸出的經驗分享：

常規的 GIF 輸出（After effects）會有三種選擇。

第一種：首先 AE 輸出視頻格式，然后通過 PS 輸出 GIF 格式。這種方式是目前市面上最常見的輸出方式，內存占用一般，輸出質量一般。

第二種：在原有的基礎上做部分優化，首先 AE 輸出序列幀格式，然后通過 PS 選擇針對圖片的優化方式輸出。這是目前為止所有輸出方式中，內存最小、失真最低的方式。內存占用低，輸出質量高。但是存在問題是無法輸出 500fps 以上的動畫（PhotoShop自身限制）。

第三種：直接通過 GIF Brewery3 輸出。內存占用一般，輸出質量低。一般是針對前兩種方式無法輸出時的選擇， 優點是比較穩定，基本不會出現任何問題。

下圖為不同輸出方式輸出結果對比：

另外還有第四種選擇是通過 AE 插件 GIFGUN 直接導出，GIFGUN 插件是一個非常方便、操作簡單的插件，但是這里不推薦使用的原因是 GIFGUN 有一個限制只能輸出低的 30FPS 的動畫，很多時候輸出的結果會存在掉幀的情況。

EZGIF 壓縮 GIF 圖，當我們輸出 GIF 圖，內存無法達到理想大小時可以使用 https://ezgif.com 來壓縮。

2. 視頻格式

視頻格式在大多數的產品上也都可以直接兼容，相比 GIF 格式他的內存在一些派生出的制式下可以更小，我們的智能設備也可以在更小的系統性能下讀取視頻格式。他的問題是對透明通道的支持很差，并且他也是一種有損的輸出格式。所以在動畫輸出時我們也會盡可能地減少對視頻格式的使用。

Handbrake

我們可以通過 Handbrake 軟件來直接壓縮視頻格式，可以保證我們在輸出視頻格式時以最低的內存占用來呈現。

3. APNG/WEBP

前面提到的兩種格式是我們所接觸最古老，也最不容易出錯的兩種格式，但是隨著技術進步這些格式很顯然已經無法滿足我們現在的動效。針對情感化動效我們也衍生出了很多新的格式，像 APNG、WEBP 之類的格式。這些格式是基于我們現有的像 JPEG、PNG、GIF 格式所衍生出來的。

APNG 格式是 Mozilla 代碼社區出來的一個格式，是對 png 位圖格式的動畫擴展，但是目前還沒有得到 png 格式官方的認可，他在目前主流的所有瀏覽器上都可以完美支持，在移動的設備上通過一些代碼框架也可以完美支持，他相比 GIF 支持的色彩范圍更廣，更清晰，并且占用更低的內存，支持透明通道，有非常多的優勢。

WEBP 是由 Google 推出，他目前也基本兼容所有的主流瀏覽器，相同的效果，webp 格式要比 png 格式小出來大概一半的大小，同時他也兼容所有的安卓設備，像一些 iOS 設備需要通過一定的方式才可以支持，不過相比來說各方面的表現都是非常優秀的。

這里推薦一款工具 iSparta ，這款工具可以幫助我們導出 APNG、WEBP 格式，也可以幫助我們導出帶有透明通道的 GIF，但是以我的經驗來說導出 GIF 并不是很理想。像這兩種格式我們可以根據我們的設備不同，分開導出，可以在保證我們內容質量不被壓縮的情況下保證更小的體積和性能占用。這些格式我們也可以直接拖到瀏覽器當中查看。

這種新型的格式雖然可以彌補 GIF 或視頻帶來的負面影響，但是他們本身也面臨的問題是硬件需要各種輔助支持才能使用，很多時候在開發環節就不能很好的支持，這種時候就需要我們引出另一種格式──序列幀/精靈圖。

4. 序列幀/精靈圖

序列幀

在客戶端上，我們可以把我們的動畫導出單獨的圖層序列輸出，并且可以通過一些工具來壓縮單獨的圖層序列以達到最低的內存占用。

序列幀是一個無損且低內存的格式，但是他只能在客戶端環境中使用，不建議在 Web 環境中使用。原因是序列幀一般都是隨著 App 程序包一起下載下來的，但是 Web 中每次進入一個新的網頁都需要重新下載。舉個例子如果一個 60 幀的動畫就得重復向服務器請求 60 次，在這種高頻次的請求下很容易因為一個小的問題導致整個動畫無法正常播放，為了避免這種錯誤我們一般會把這個 60 張圖合并為一個，并且通過代碼在指定時間內顯示某一個區塊，所以這里我們引出另一種格式──精靈圖/雪碧圖。

精靈圖/雪碧圖（Sprite）

當我們把所有序列合并在一張圖片上往往還是不夠的，我們還需要提供給開發具體哪個時間顯示哪一部分的具體參數。我們可以直接通過 AE 插件 CSS Sprite Exporter（By Bigxixi）直接快速地輸出開發所需的代碼和精靈圖。

5. Lottie

Lottie 可以說是近兩年在動畫輸出方面不得不提的一個格式，它由 Airbnb 推出，并且迅速在國內外各種大小廠快速推廣開來，目前已經是一個非常普遍常用的格式，他在 AE 中的插件叫 Bodymovin，他的原理是把我們的各種矢量元素、位圖圖層以及他們的效果關鍵節點打包的形式行成一個 json 格式的文件。

我們的開發人員拿到 Bodymovin 輸出的 json 格式是無法直接使用的，他需要在代碼中加入 Airbnb 提供的 Lottie 第三方庫來讀取播放，相當于 lottie 文件在我們各個端口設備上的播放器的作用，它會占用一定的系統空間，但是一般情況下也不會很大，從產品長遠發展的角度來說肯定是可以給我們 App 節省非常多空間的，這也正是 Lottie 可以在這么短的時間內被這么多公司所認可的原因之一。

Lottie 是一個非常強大的輸出工具，它可以滿足很多種類的矢量動畫和圖片動畫。但是他也有一些自身問題，首先他對緩動曲線的解析會占用非常多的內存，這點后面會展開解釋；第二點是各平臺效果的支持都不是很穩定，很多時候容易出 Bug。

下圖為 Lottie 官方提供的對于 AE 特性的支持：

△ By Bigxixi

6. SVGA

針對 Lottie 對緩動曲線解析差帶來的性能問題和穩定性問題，我們會有第二種備選方案是 SVGA，不管是導出之后的內存占用，還是在各個端的表現穩定性都會好很多。但是他的內存占用會比 Lottie 稍高，并且支持的特性也會比 Lottie 少一些。

SVGA 與 Lottie 最本質的區別在于代碼對動畫過程記錄的方式， Lottie 基本上是按照我們在 AE 當中的關鍵幀及緩動的結合形式去記錄動畫。而 SVGA 則是通過記錄我們每一個圖層每一個時間上的動畫狀態，從而省去對緩動值的計算。跟序列幀的邏輯非常相似，但是因為他的素材可以復用，所以會比序列幀占用更低的內存。

基于實現方式，他會比 Lottie 穩定很多，相應的，他所支持的特性也要比 Lottie 少很多。

SVGA 格式可以組合 lottie 去使用，還有像很多效果在 Android 設備上 svga 的解析效果要比 iOS 好很多，所以很多安卓設備也會經常使用。

所見非所得格式與前幾種最大的區別在于輸出之后無法第一時間看到輸出的結果，因為他們是更垂直于我們的智能設備的格式。但是好在他們也提供了一些在桌面端和移動端可以直接預覽的軟件，可以幫助我們在開發完全落地之前排除一部分錯誤問題，以及提前預知到效果的可行性。

• Lottie預覽（區分安卓/iOS/Web）：https://airbnb.io/lottie/#/
• SVGA 在線預覽：http://svga.io/svga-preview.html

7. AE2CSS（By Bigxixi）

他可以幫助我們從 AE 當中導出 CSS 格式，理論上這個插件可以支持我們所有的 AE 動畫，并且在大多數情況下動畫的質量無損且占用內存比所見即所得格式要小。

他的原理非常簡單，他把所有的動畫分為兩種類型，基本動畫屬性記錄狀態信息，復雜效果變化屬性直接導出為精靈圖，并把他們的效果結合在一起打包，輸出一套文件。它可以忽略我們前面各種情況會遇到的所有問題，但是有個限制就是目前只能用在 web 和 h5 頁面上。

8. 第三方動效庫

要知道這種第三方的導出方式其實是非常多的，但是目前市面上大家都比較認可的并不多，Lottie 之類的輸出方式很大一個優勢是他自身的社區生態，尤其 Lottie 目前在網上有非常多的開源動畫資源可以下載使用，可以讓我們以最低的成本獲得一些動畫效果。

交互動效&特殊效果輸出選擇

所謂交互動畫，顧名思義動畫的內容跟我們的交互操作相關聯，根據我們的操作反饋相應的動效，因此他的實現原理也更多元更復雜。

1. 貝塞爾曲線

前文中我們提到大量的貝塞爾緩動曲線會帶來系統運算壓力上的問題，想要了解這點首先需要我們了解貝塞爾曲線是如何構成。并且我們在交互動畫交接的時候會涉及到很多的手寫緩動曲線，在這之前我們也需要簡單地去了解他的原理。

以下視頻為一個貝塞爾曲線在智能設備上構成的原理講解：

在開發環境中我們向開發人員提供一個貝塞爾曲線需要提供以下幾個參數：

• 錨點1（P0）
• 錨點2（P3）
• 操縱桿1（P1）
• 操縱桿2（P2）

在多數情況下我們完全可以按照前面提供的格式，直接對接我們的矢量形狀。在少數情況下，尤其在一些交互類動效的情況下，很多就需要我們手動的去提供每一個曲線的參數了。但是我們不可能每個點的參數挨個去測量去輸出，這是非常不現實的。目前在市面上大多數的設計軟件和輸出軟件上都會提供一些簡單的代碼參數給我們。

但是這些都只是基于靜態頁面的情況，在動效頁面的交接中我們如何去對接呢？以下圖作為例子：

像這樣一個例子，我們需要提供動畫的前后兩個狀態給到開發人員，即 icon 搜索框的形式和輸入光標的豎線形式。每一個路徑的 svg 信息我們可以直接輸出給開發人員，像 Sketch/Zeplin 這樣的工具我們可以直接輸出 Web 端所用的格式，但是他們都只是局限于 CSS 格式，但是在 Android 和 iOS 下就無法提供相應的代碼。為了解決這個問題，這里推薦另一款軟件──PaintCode 3。

PaintCode 3 是一款專門為設計師準備的簡單的矢量圖形繪圖軟件，通過 PaintCode 3，即使沒有編程經驗，設計師也可以輸出適量圖形的 iOS/Web/Android 相應的代碼。并且他跟 sketch 之間有非常強的關聯性，可以直接復制 sketch 當中的矢量形狀，也可以直接在軟件里編輯和新建矢量圖形，非常強大。

2. 緩動貝塞爾曲線

緩動貝塞爾曲線，即我們在設計動效時使用的緩動曲線，他可以控制我們動效的速度緩急，可以直接控制我們動效的整體節奏感。在大多數情況下我們看到的緩動貝塞爾曲線都是如下圖，他與我們的貝塞爾曲線非常類似，區別在于緩動貝塞爾曲線的兩個端點是固定的，而貝塞爾曲線的端點是動態的。也就是說當我們與開發人員對接緩動曲線時，可以只提供兩個控制桿的位置。像在下圖中我們的緩動曲線的參數，兩個端點的坐標位置，即（ 0.17，0.67，0.83，0.67 ）。

在 AE 當中我們如何獲得我們相應的緩動曲線的參數呢？我們在 AE 當中把緩動曲線圖表的顯示類型選擇為「編輯值圖表」即可調整為我們常見的緩動曲線的類型。

為了獲得我們在 AE 當中的緩動曲線的參數，我們可以以圖表左下角作為出發點，根據兩個控制桿的位置創建兩個矩形，以左側控制桿為基礎的矩形寬高（在整個區域寬高中的比例值作為數值）作為緩動曲線的前兩個數值，以右側控制桿為基礎的矩形寬高作為緩動曲線的后兩個數值。

雖然以上的方式可以使我們更方便地獲得 AE 緩動參數的具體數值，但是因為操作繁瑣只適用于我們已經完成了動畫需要去落地的情況。更多的情況下我們需要在動畫設計之前就使用參數的方式去使用緩動曲線。Flow 插件可以幫助我們完成這件事。

他可以幫助我們使用一般的緩動曲線的方式設計動畫，并且提供了 25 種在開發環境當中常用的緩動類型，我們也可以自定義一些緩動類型，可以備份成文件傳輸在團隊內部當成一份規范來使用，也可以導入外部的一些緩動參數的文件。當然在正常情況建議還是使用一些默認的緩動類型，原因有兩個方面，一方面是這樣默認的曲線在算法上更容易計算，對系統性能的占用默認也可以低一些，另一方面很多非系統默認的緩動差值需要開發再去寫一遍，無形中也會增加我們的對接成本和后期的代碼維護成本。

3. 手動標注

基于我們對貝塞爾曲線的理解和緩動曲線的理解，可以幫助我們在手動輸出標注時有更豐富的選擇。手動標注的情況下我們需要把動效中每一個具體元素的參數都參數化。一般情況下我們會把動畫的基礎單元分為以下六個部分：

• 元素（在發生變化的元素）
• 屬性（元素發生變化的屬性）
• 參數（屬性發生的具體數值變化）
• 時間（變化的起始時間/持續時間）
• 差值（動畫的緩動曲線）
• 備注（其他說明）

有了這些基本的參數之后，我們可以參照下圖中的方式完整的表述我們的動畫過程給開發人員。

另外我們也可以通過更加可視化的方式去標注，并且把這些樣式做成組件的形式在團隊內作為一種共識推廣開之后也能大大提高動效標注的交接效率。

動效落地拓展──代碼

當我們通過上述手動標注的方式交接給開發人員時，站在設計的立場上似乎已經做到盡善盡美了，但是我們回過頭時候，往往輸出的結果在大多數情況下還是不那么盡如人意。這其中有非常多綜合的因素，站在開發者的角度來看，往往我們對于結果輸出所做的事情非常有限。造成這種輸出與落地巨大差異的最大原因也是來自于設計師與開發者之間理解產品構成的巨大差異。

設計師在輸出動畫時更多的時間精力在于對動畫細節（緩動、時間等）的調整，而對于開發者來說有非常多的外部因素影響最終的輸出，一般情況下會有以下幾點：

• 開發者自身的水平
• 時間排期的影響
• 框架結構、代碼語言限制
• 其他影響

在大多數動畫中有非常多的圖層細節，挨個實現需要大量的時間，比方說制作下圖中這樣一個動畫，只需要使用 CSS 設置一下最外層面板的寬度，并且加一個過渡動畫。但是對于大多數的產品開發者來說，你需要同時設置外部和內部所有元素的動畫。

第二個更麻煩的事情是你在 sketch 當中的圖層與 html 當中的圖層不匹配。所以即使你在動效標注當中，標識某個矩形從 0 向右移動 10 像素，設計上非常容易。但是代碼會有非常多非常復雜的框架層，開發人員需要把設計塊調整到他們的代碼當中，每一個元素都需要單獨相同或不同的方式去實現。這是一個非常容易出錯的過程，完全取決于如何清楚地用文檔描述你的動畫，以及開發人員如何仔細地查看并實現你的內容。

第三點是修改動畫的效果非常麻煩，設計和產品開發是一個迭代的過程。但是當你對一個動畫效果進行調整的時候，不管是設計還是開發都需要大量的時間去對之前的文件和代碼進行重新了解，每個人都會根據自己的理解會有不同的實現方式，從重新熟識早期版本的實現邏輯，到調整，再到開發落地需要非常復雜的一套流程。

為了讓這個過程不那么痛苦，我們意識到需要跳出自己的舒適區，去用另外一種不同的邏輯去構建動畫，這也意味著不建議大家使用所見即所得的設計工具。相反的，我推薦大家使用 html/css/js 的方式去構建我們的動畫體系，你需要一些時間來適應他，但經過幾個動畫之后，很多過程就會變得特別容易，其實也并不需要你知道太多關于代碼的知識，就可以為開發人員創建一些基本的動畫。

一方面我們真正控制了動畫的微小細節，對于開發人員來說，這種方式更容易使我的代碼適應他們現有的代碼庫，而不是大多數標注軟件自帶的 css 屬性那么單薄，雖然各個平臺都會有不同的代碼語言差異，但是他們之間的跨度相比設計到代碼的跨度來說可以說是微不足道了。

我只需要將輸出的代碼放在 codepen上，開發人員就可以輕松看到我做了什么，也可以復制粘貼我的代碼部分來制作一些效果。

當然這么做也有一些問題，首先，我需要在開始設置動畫之前用 html 重構我的設計，不過因為我們只是去針對動畫發生的部分去做設計，所以不會因為框架和代碼邏輯對我們產生影響，相比之下就會容易很多，另外我們也可以在 sketch 中直接復制 css 代碼，只需要很少的步驟就可以重構我們的設計，甚至一些根本沒動畫的部分可以截個圖，貼圖進去也沒有問題。

另一種方式是我們直接從實際項目的代碼入手，但是會比我們自己去寫 demo 要復雜很多，因為實際產品的代碼框架更復雜，需要重新梳理。

雖然這種工作方式主要是使用代碼做一些動畫，但是大多數情況下還是需要先在一些動畫軟件上做想法的探索，不同的想法可能會需要比較久的代碼時間。因此，如果我不太清除自己想要什么樣的動畫，我還是會付出一部分時間在 demo 的制作上。

另一種可能性是我們在平時可以通過一些簡單的代碼，去繪制一些基礎組件的動效，我們稱這種東西為腳手架，可以給我們所有的一些基礎元素做一些小動畫，比方說開關，checkbox，按鈕點擊效果之類的。因為這些是我們大多數時間都會去反復使用的一些組件，做一個動畫相當于對整個系統動畫的貫穿。這種方向不管是自己去寫代碼還是通過開發人員去寫代碼都是非常容易的一個過程，并且帶來的效果其實是非常可觀的。

目前市面上也有一些針對設計師的代碼動效輸出工具，像 Origami / Framer，都是目前比較火熱的開發思維實現動效的產品，非常建議大家去嘗試使用。

總結

動效輸出的手段目前雖然非常多樣，而且隨著技術手段進步選擇會越來越多。但是目前來說沒有任何一種方案，可以完全解決我們落地動效當中的所有問題。并且目前市面上所提供的任何一款工具無法真正解決設計思維所帶來的局限性。作為設計師我們需要始終保持敏銳的觀察力，并且持續的更新自身的知識樹，才能應對多種多樣需求下輸出的動效效果的落地。另一方面我們也需要站在更長遠的角度去了解一個動效需求從產品邏輯到開發邏輯之間的鴻溝，并試著通過更多元的手段去跨越鴻溝。