一、情感化動效

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

二、交互動效

產(chǎn)品流程、交互行為的串聯(lián)，不論可實(shí)際操作的交互原型還是純做 demo 展示的動效過場都可以算作交互動效設(shè)計(jì)，交互動效最基礎(chǔ)的的形態(tài)就是原型流程圖的串聯(lián)交互稿。

交互動效又可以細(xì)分為轉(zhuǎn)場動效和微交互，分別應(yīng)用于頁面銜接和基礎(chǔ)組件的交互反饋。前者可以傳達(dá)給用戶產(chǎn)品的層次結(jié)構(gòu)和空間關(guān)系，后者可以使用戶減少操作成本。

三、復(fù)合型動效

復(fù)合型動效不局限于感性層面的情緒傳達(dá)，也不局限于交互行為的串聯(lián)，往往真實(shí)場景當(dāng)中更多的也是這一類動效，在與開發(fā)人員對接階段也更容易存在各種各樣的不穩(wěn)定因素，對于設(shè)計(jì)師而言也存在更多層面的挑戰(zhàn)性。

影響輸出方式的因素

影響輸出方式的因素

情感化動效一般情況下會受到三個(gè)方面的屬性影響他的輸出選擇，分別是尺寸、時(shí)間、動畫復(fù)雜度：

一、動畫尺寸

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

類似這樣的一些格式，是我們的設(shè)備所能接受的最簡單最直白的格式。他去產(chǎn)出一個(gè)動畫的邏輯一般都是不同的靜態(tài)圖像的堆棧通過給定的次序和時(shí)間逐個(gè)播放。

這里邊的每一個(gè)靜態(tài)構(gòu)成圖尺寸越大，整個(gè)動畫的占用內(nèi)存相應(yīng)的也就越大。但是我們的產(chǎn)品包的容量始終有限，不能允許太大內(nèi)存的動效存在。

另一方面，大尺寸的靜態(tài)圖在預(yù)覽過程中也需要耗費(fèi)更多的設(shè)備計(jì)算，舉一個(gè)很簡答的例子，當(dāng)我們在電腦上預(yù)覽一張 800*600 的圖和一張 2400*1800 的圖電腦打開它所需要的時(shí)間是不同的，相應(yīng)的，動畫格式多個(gè)大尺寸靜態(tài)圖做預(yù)覽時(shí)耗費(fèi)的系統(tǒng)性能是成倍數(shù)增長的。

二、動畫時(shí)長

影響原因與尺寸的影響原因類似，當(dāng)圖片堆棧的時(shí)間變長時(shí)，堆棧當(dāng)中的圖片數(shù)量也會增加，動畫的占用內(nèi)存相應(yīng)的也就變得更大。

所以，當(dāng)我們的動畫時(shí)間過長時(shí)也不適合使用這些所見即所得的格式類型。

需要注意的一點(diǎn)是，動畫的時(shí)長對性能的影響會相對的小很多
三、動畫復(fù)雜度

動畫復(fù)雜度對在以上提到的輸出格式當(dāng)中不存在任何問題，更多的是在一些近幾年比較時(shí)髦的輸出工具上出現(xiàn)問題。對于復(fù)雜動畫，我們要盡可能選擇去輸出所見即所得的格式。當(dāng)選擇了其他的格式時(shí)也要盡可能的減少動畫的復(fù)雜度，保留重點(diǎn)，去掉冗雜的細(xì)節(jié)

情感化動效輸出選擇

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

· 所所見即所得格式

· 所見非所得格式

所謂「所見即所得」就是輸出我們最常見的一些輸出之后即可預(yù)覽的格式，比如 GI比 圖/視頻這種的格式，也是我們很多的動效輸出最基礎(chǔ)的格式：

GIF 圖格式

GIF 圖格式可謂是作為設(shè)計(jì)師接觸過的最多的動態(tài)格式了，GIF格式自 1987 年由 CompuServe 公司引入后，因其體積小而成像相對清晰，特別適合于初期慢速的互聯(lián)網(wǎng)，而從此大受歡迎。因?yàn)闀r(shí)代背景使得他有非常強(qiáng)的兼容性，基本上可以在目前大多數(shù)的智能設(shè)備上直接預(yù)覽。

不論動效落地還是在各個(gè)平臺上的兼容性也都是非常優(yōu)秀的的，尤其在一些設(shè)計(jì)平臺上，也是大家最多的選擇用來做一些概念展示的格式之一。也因?yàn)樗诓煌脚_設(shè)備之間的兼之間，他的傳播性也是非常強(qiáng)的。

當(dāng)然除了他自身所帶的這么多優(yōu)點(diǎn)之外，GIF 格式也因?yàn)樗膽?yīng)用年代技術(shù)限制的原因會有很多其他的缺陷，前面提到的很多優(yōu)點(diǎn)往往也是因?yàn)檎Q生早給他自身帶來的福利，他會有很多不可逆的問題。

首先第一點(diǎn)是對電腦的內(nèi)存和性能占用非常大（根據(jù) GIF 的時(shí)間尺寸的等情況會有不同的程度的影響），作為設(shè)計(jì)師常有的一個(gè)經(jīng)驗(yàn)是在網(wǎng)頁上多開幾個(gè) GIF 之后電腦風(fēng)扇就開始飚起來了。

第二點(diǎn)是他是一個(gè)有損的文件格式，不論是色彩還是畫面質(zhì)感都會有一定程度的壓縮。第三點(diǎn)是對透明通道的支持非常有限，輸出結(jié)果會非常差，時(shí)常會有鋸齒或白邊的情況。

以上是我們在輸出 GIF 格式的之前需要提前思考是否可以接受以上的問題。

另外輸出 GIF 圖的過程也經(jīng)常困擾著很多的設(shè)計(jì)師，我也為此錄制了一篇關(guān)于 GIF 輸出的經(jīng)驗(yàn)分享

常規(guī)的 GIF 輸出（After effects）會有三種選擇：

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

第二種：在原有的基礎(chǔ)上做部分優(yōu)化，首先AE 輸出序列幀格式，然后通過 PS 選擇針對圖片的優(yōu)化方式輸出。

這是目前為止所有輸出方式中內(nèi)存最小失真最低的方式。內(nèi)存占用低，輸出質(zhì)量高。但是存在問題是無法輸出 500fps 以上的動畫（PhotoShop限制 自身限制）。

第三種：直接通過GIF Brewery3輸出。內(nèi)存占用一般，輸出質(zhì)量低。一般針對前兩種方式無法輸出時(shí)選擇， 優(yōu)點(diǎn)是比較穩(wěn)定，基本不會出現(xiàn)任何問題。

下圖為不同輸出方式輸出結(jié)果對比：

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

EZGIF 壓縮 GIF 圖

當(dāng)我們輸出圖 GIF 圖內(nèi)存無法達(dá)到理想大小時(shí)可以使用 https://ezgif.com 來壓縮。

視頻格式

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

壓縮視頻格式——Handbrake

我們可以通過 Handbrake 通過 軟件來直接壓縮視頻格式，可以保證我們在輸出視頻格式時(shí)以最低的內(nèi)存占用來呈現(xiàn)

APNG/WEBP

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

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

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

這里推薦一款工具 iSparta ，這款工具可以幫助我們導(dǎo)出APNG、WEBP 格式（也可以幫助我們導(dǎo)出帶有透明通道的 GIF，但是以我的經(jīng)驗(yàn)來說導(dǎo)出 GIF 并不是很理想）像這兩種格式我們可以根據(jù)我們的設(shè)備不同分開導(dǎo)出，可以在保證我們內(nèi)容質(zhì)量不被壓縮的情況下保證更小的體積和性能占用。這些格式我們也可以直接拖到我們的瀏覽器當(dāng)中查看實(shí)際預(yù)覽的查看。

這種新型的格式雖然可以彌補(bǔ) GIF 或視頻帶來的負(fù)面影響，但是他們本身也面臨一個(gè)問題是硬件需要各種輔助支持才能使用，很多時(shí)候會在開發(fā)環(huán)節(jié)就不能很好的支持，這種時(shí)候就需要我們引出另一種格式——序列幀/精靈兔。

序列幀/精靈圖

序列幀

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

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

精靈兔/雪碧圖（Sprite）

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

Lottie

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

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

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

。

SVGA

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

SVGA 與 Lottie 最本質(zhì)的區(qū)別在于代碼對動畫過程記錄的方式， Lottie基本上是按照我們在 ae 當(dāng)中的關(guān)鍵幀及緩動的結(jié)合形式去記錄動畫；而 SVGA 則是通過記錄我們每一個(gè)圖層每一個(gè)時(shí)間上的動畫狀態(tài)，從而省去對緩動值的計(jì)算。跟序列幀的邏輯非常相似，但是因?yàn)樗乃夭目梢詮?fù)用，所以會比序列幀占用更低的內(nèi)存。

基于實(shí)現(xiàn)方式，他會比 Lottie 穩(wěn)定很多，相應(yīng)的，他所支持的特性也要比 Lottie 少很多。

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

所見非所得格式的與前幾種最大的區(qū)別在于輸出之后無法第一時(shí)間看到輸出的結(jié)果，因?yàn)樗麄兪歉怪庇谖覀兊闹悄茉O(shè)備的格式。但是好在他們也提供了一些在桌面端和移動端可以直接預(yù)覽的軟件，可以幫助我們在開發(fā)完全落地之前排除一部分錯(cuò)誤問題?？梢詭椭覀冊陂_發(fā)結(jié)果落地之前提前預(yù)知到效果的可行性。

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

AE2CSS（By Bigxixi）

他可以幫助我們從 ae 當(dāng)中導(dǎo)出 CSS 格式，理論上這個(gè)插件可以支持我們所有的 ae 動畫，并且在大多數(shù)情況下動畫的質(zhì)量無損且占用內(nèi)存比所見即所得格式要小。

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

第三方動效庫

要知道這種第三方的導(dǎo)出方式其實(shí)是非常多的，但是目前市面上大家都比較認(rèn)可的其實(shí)并不多，Lottie 之類的輸出方式的很大一個(gè)優(yōu)勢是他自身的社區(qū)生態(tài)，尤其 Lottie 目前在網(wǎng)上有非常多的開源動畫資源可以之間下載使用，可以讓我們以最低的成本獲得一些動畫效果。

Lottie/SVGA 的優(yōu)勢

要知道這種第三方的導(dǎo)出方式其實(shí)是非常多的，但是目前市面上大家都比較認(rèn)可的其實(shí)并不多，Lottie 之類的輸出方式的很大一個(gè)優(yōu)勢是他自身的社區(qū)生態(tài)，尤其 Lottie 目前在網(wǎng)上有非常多的開源動畫資源可以之間下載使用，可以讓我們以最低的成本獲得一些動畫效果。

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

所謂交互動畫，顧名思義動畫的內(nèi)容跟我們的交互操作相關(guān)聯(lián)，根據(jù)我們的操作反饋相應(yīng)的動效，因此他的實(shí)現(xiàn)原理也更多元更復(fù)雜。

貝塞爾曲線

前文中我們提到大量的貝塞爾緩動曲線會帶來系統(tǒng)運(yùn)算壓力上的問題，想要了解這點(diǎn)首先需要我們了解貝塞爾曲線是如何構(gòu)。

在開發(fā)環(huán)境中我們向開發(fā)人員提供一個(gè)貝塞爾曲線需要提供以下幾個(gè)參數(shù)：

· 錨點(diǎn)1（P0）
· 錨點(diǎn)2（P3）
· 操縱桿1（P1）
· 操縱桿2（P2）

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

但是這些都只是基于靜態(tài)頁面的情況，但是在動效頁面的交接中我們?nèi)绾稳幽兀恳韵聢D作為例子：

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

PaintCode 3 是一款專門為設(shè)計(jì)師準(zhǔn)備的簡單的矢量圖形繪圖軟件，通過 PaintCode 3 即使沒有編程經(jīng)驗(yàn)，設(shè)計(jì)師也可以輸出適量圖形的 iOS/Web/Android 相應(yīng)的代碼。并且他跟 sketch 之間有非常強(qiáng)的關(guān)聯(lián)性，可以直接復(fù)制 sketch 當(dāng)中的適量形狀，也可以直接在軟件里編輯和新建適量圖形，非常強(qiáng)大。

緩動貝塞爾曲線

緩動貝塞爾曲線即我們在設(shè)計(jì)動效時(shí)使用的緩動曲線，他可以控制我們動效的速度緩急、可以直接控制我們動效的整體節(jié)奏感。在大多數(shù)情況下我們看到的緩動貝塞爾曲線都是如下圖，他與我們的貝塞爾曲線非常類似，區(qū)別在于緩動貝塞爾曲線的兩個(gè)端點(diǎn)是固定的，而貝塞爾曲線的端點(diǎn)是動態(tài)的。也就是說當(dāng)我們與開發(fā)人員對接緩動曲線時(shí)可以只提供兩個(gè)控制桿的位置就可以。像在下圖中我們的緩動曲線的參數(shù)即兩個(gè)端點(diǎn)的坐標(biāo)位置，即（ 0.17，0.67，0.83，0.67 ）。

在 AE 當(dāng)中我們?nèi)绾潍@得我們相應(yīng)的緩動曲線的參數(shù)呢？我們在 AE 當(dāng)中把緩動曲線圖表的顯示類型選擇為「編輯值圖表」即可調(diào)整為我們常見的緩動曲線的類型。

為了獲得我們在 AE 當(dāng)中的緩動曲線的參數(shù)，我們可以以圖表左下角作為出發(fā)點(diǎn)，根據(jù)兩個(gè)控制桿的位置創(chuàng)建兩個(gè)矩形，以左側(cè)控制桿為基礎(chǔ)的矩形寬高（在整個(gè)區(qū)域?qū)捀咧械谋壤底鳛閿?shù)值）作為緩動曲線的前兩個(gè)數(shù)值，以右側(cè)控制桿為基礎(chǔ)的矩形寬高作為緩動曲線的后兩個(gè)數(shù)值。

雖然以上的方式可以使我們更方便的獲得 AE 緩動參數(shù)的具體數(shù)值，但是因?yàn)椴僮鞣爆嵵贿m用于我們已經(jīng)完成了動畫需要去落地的情況。更多的情況下我們需要再動畫設(shè)計(jì)之前就使用一些方式去使用參數(shù)的方式去使用緩動曲線。Flow 插件可以幫助我們完成這件事。

他可以幫助我們使用一般的緩動曲線的方式設(shè)計(jì)動畫，并且提供了 25 種在開發(fā)環(huán)境當(dāng)中常用的緩動類型，我們也可以自定義一些緩動類型，可以備份成文件傳輸在團(tuán)隊(duì)內(nèi)部當(dāng)成一份規(guī)范來使用，也可以導(dǎo)入外部的一些緩動參數(shù)的文件。

當(dāng)然在正常使用是建議還是使用一些默認(rèn)的緩動類型，原因有兩個(gè)方面，一方面是這樣默認(rèn)的曲線在算法上更容易計(jì)算，對系統(tǒng)性能的占用默認(rèn)的也可以低一些，另一方面很多非系統(tǒng)默認(rèn)的緩動差值需要開發(fā)再去寫一遍，無形中也會增加我們的對接成本和后期的代碼維護(hù)成本。

手動標(biāo)注

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

· 元素（在發(fā)生變化的元素）
· 屬性（元素發(fā)生變化的屬性）
· 參數(shù)（屬性發(fā)生的具體數(shù)值變化）
· 時(shí)間（變化的起始時(shí)間/持續(xù)時(shí)間）
· 差值（動畫的緩動曲線）
· 備注（其他說明）

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

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

動效落地拓展——代碼

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

設(shè)計(jì)師在輸出動畫時(shí)更多的時(shí)間精力在于對動畫細(xì)節(jié)（緩動、時(shí)間等）的調(diào)整，而對于開發(fā)者來說有非常多的外部因素影響最終的輸出，一般情況下會有以下幾點(diǎn)：

· 開發(fā)者自身的水平
· 時(shí)間排期的影響
· 框架結(jié)構(gòu)、代碼語言限制
· 其他影響

在大多數(shù)動畫中有非常多的圖層細(xì)節(jié)，挨個(gè)實(shí)現(xiàn)需要大量的時(shí)間，比方說制作下圖中這樣一個(gè)動畫只需要使用 CSS 設(shè)置一下最外層面板的寬度并且加一個(gè)過度動畫，但是對于大多數(shù)的產(chǎn)品的開發(fā)者來說，你需要同時(shí)設(shè)置外部和內(nèi)部所有元素的動畫。

第二個(gè)更麻煩的事情是你的在 sketch 當(dāng)中的圖層與 html 當(dāng)中的圖層不匹配。所以即使你在動效標(biāo)注當(dāng)中標(biāo)識說某個(gè)矩形從0向右移動10像素，對于設(shè)計(jì)上來說非常容易，但是代碼會有非常多非常復(fù)雜的框架層，可能并不存在你在設(shè)計(jì)中的這個(gè)矩形，所以，他又增加了一個(gè)煩人的過程，開發(fā)人員需要把設(shè)計(jì)塊調(diào)整到他們的代碼當(dāng)中，每一個(gè)元素都需要單獨(dú)相同或不同的方式去實(shí)現(xiàn)。這是一個(gè)非常容易出錯(cuò)的過程，完全取決于你如何清楚的用文檔描述你的動畫，以及開發(fā)人員如何仔細(xì)的查看并實(shí)現(xiàn)你的內(nèi)容。

第三點(diǎn)是修改動畫的效果非常麻煩，設(shè)計(jì)和產(chǎn)品開發(fā)是一個(gè)迭代的過程。但是當(dāng)你對一個(gè)動畫效果進(jìn)行調(diào)整的時(shí)候，不管是設(shè)計(jì)也好開發(fā)也好需要大量的時(shí)間去對之前的文件和代碼進(jìn)行重新了解，不管是 ae 的文件也好還是開發(fā)實(shí)現(xiàn)的代碼也好，每個(gè)人都會根據(jù)自己的理解會有不同的實(shí)現(xiàn)方式，從重新熟識早期版本的實(shí)現(xiàn)邏輯到調(diào)整再到開發(fā)落地需要非常復(fù)雜的一套流程。以上的一些列操作都是我們需要針對單個(gè)的動畫過度需要去做的大量努力。

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

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

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

當(dāng)然這么做也有一些他自身的問題，首先，我需要再開始設(shè)置動畫之前用 html 重構(gòu)我的設(shè)計(jì)，不過因?yàn)槲覀冎皇侨メ槍赢嫲l(fā)生的部分去做設(shè)計(jì)，所以不會因?yàn)榭蚣芎痛a邏輯對我們產(chǎn)生影響，相比之下就會容易很多，另外我們也可以在 sketch 中直接復(fù)制 css 代碼，這只需要很少步驟就可以重構(gòu)我們的設(shè)計(jì)，甚至一些根本沒動畫的部分可以截個(gè)圖貼圖進(jìn)去也沒有問題。

另一種方式是我們直接從實(shí)際項(xiàng)目的代碼入手，但是會比我們自己去寫 demo 要復(fù)雜很多，因?yàn)閷?shí)際產(chǎn)品的代碼框架更復(fù)雜需要重新梳理

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

即使在學(xué)習(xí)之前從來沒有寫過一行代碼，非常鼓勵(lì)大家去嘗試，這些東西會給你非常的意外收獲，也有非常大量的優(yōu)質(zhì)材料提供給你學(xué)習(xí)。你也不需要從0-1去搭建自己的代碼知識體系，很多時(shí)候即使是我自己都是開始著手去做，邊查代碼邊寫，查不到的就去問公司的開發(fā)，你需要去學(xué)的可能就是對 html 和 css 代碼的基礎(chǔ)框架有一點(diǎn)了解，然后就開始著手去寫。有了基礎(chǔ)的知識之后你會發(fā)現(xiàn)你已經(jīng)可以寫出非常多的動畫。并且嘗試把它帶到工作當(dāng)中逐個(gè)的去克服它。

另一種可能性是我們在平時(shí)可以通過一些簡單的代碼去繪制一些基礎(chǔ)組件的動效，我們稱這種東西為腳手架，可以給我們所有的一些基礎(chǔ)元素做一些小動畫，比方說開關(guān)，checkbox，按鈕點(diǎn)擊效果之類的，因?yàn)檫@些是我們大多數(shù)時(shí)間都會去反復(fù)使用的一些組件，做一個(gè)動畫相當(dāng)于對整個(gè)系統(tǒng)動畫的貫穿。這種方向不管是自己去寫代碼還是通過開發(fā)人員去寫代碼都是非常容易的一個(gè)過程并且?guī)淼男Ч鋵?shí)是非常可觀的。

目前市面上也有一些針對設(shè)計(jì)師的代碼動效輸出工具，像 Origami / Framer 目前 都是目前比較火熱的開發(fā)思維實(shí)現(xiàn)動效的產(chǎn)品。也非常建議大家去嘗試使用。

總結(jié)

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