流暢web動畫的十個法則

標籤：裝置   amp   特性   ret   為我   操作   自己   email   案頭   

from me:

　　web動畫能夠帶來一個非常酷炫的效果，能夠讓頁面有一個更好的使用者體驗。對於良好的動畫效能沒有高招，除了將大量的時間放在測試和最佳化，當然最重要的還是要易於維護。

流暢web動畫的十大法則：

　　· 不要改變除了opacity和transform之外的參數！
　　· 將內容藏在不起眼的地方
　　· 不要同一時間所有元素都做動畫
　　· 輕微地增加延遲，讓編排動作變得簡單_
　　· 使用全域倍數來設計慢動畫
　　· 拍下你的UI，並且重放他們，以擷取有價值的第三方關點。
　　· 網路活動導致滯後
　　· 不要直接綁定滾動
　　· 儘早&經常在手機上測試。
　　· 在不同的裝置上經常測試

 

原文：原文地址

譯文：流暢web動畫的十個法則

　　自從我們去年登陸了Gyroscope，許多人都問我有關用在我們網站上的javascript動畫庫。我們考慮過將此開源，但是這不是魔法真正實現的地方。

　　我不希望大家認為我們是依靠特殊的javascript外掛程式來解決這些問題的。對於大部分人來說，我們只是充分利用了近來瀏覽器效能的提升，GPU和CSS3規格.

　　對於良好的動畫效能沒有高招，除了將大量的時間放在測試和最佳化。然而，過了許多年的實驗和撞擊瀏覽器效能的極限，我們發現了一系列的設計和代碼準則，看上去似乎是良好動畫可靠的結果。這些技術讓你的頁面，在現代案頭和手機瀏覽器上變得流暢，運行良好。最重要的是，易於維護。

　　查看圖片

　　對每個人來說，技術和實現方式都有所不同，但是大體上的規則對大多是情況都會有協助。

什麼是動畫？

　　動畫在互連網出現之前就已經飽經世故了，並且如果你想做好它，這會是你一生的課題。然而對於應用於互連網的動畫，有一些特別的約束和挑戰。

　　對於60幀的流暢動畫，每一幀都需要在16ms內渲染！這並沒有多少時間，因此為了流暢的效能，我們需要找到非常有效方法來渲染每一幀。

　　查看圖片1

　　查看圖片2

　　查看圖片3

　　 一些經典的動畫規則

　　T 在web上有一打方法做動畫。比如，投影片是一種方法，在互連網之前就已經流行，通過輕微不同的手繪幀，在一秒內多次置換，來創造運動的視覺效果。

　　最近Twitter使用這種簡單的方法，製作了新的愛心動畫，通過切換一組雪碧圖切換實現。

　　這個效果不能用一堆小元素單獨做動畫，或者做一個SVG，但是那樣會產生十分不必要的複雜以及可能會不流暢。

 　  請查看

　　在許多例子中，你會想用CSS transition屬性來做自動動畫。這個技術也同樣以“補間動畫”聞名，在兩個不同的值之間的過渡。這個好處就是，你可以輕易地取消，而不需要建立所有的邏輯。這個對於“一勞永逸”樣式的動畫是理想的解決方式，就像介紹序列，等等，或者簡單如懸停的互動。

　　延伸閱讀: 你需要知道關於CSS Transitions的事

 　  查看圖片

　　在其他例子中，主要畫面格為基礎的CSS動畫屬性也許對於不間斷啟動並執行背景細節是非常理想的。舉個例子，在Gyroscope logo上的戒指計劃是不間斷地旋轉。其他受益於CSS動畫文法的是齒輪速比。

　　因此，事不宜遲，這裡有些建議能夠協助你很大程度上地提高你的動畫效能……

 

 #1

不要改變除了opacity和transform之外的參數！

　　即使你覺得這樣ok，也不要這麼做!

　　僅僅這一個基本的準則能幫你解決80%的問題，即使是在手機上。你可能在之前聽過這個——這不是最初的主意，但是是很少被跟隨。這相當於是web的“吃的健康和運動”的相同法則，這個聽上去是一個好的建議，但是你可能會無視。

　　一旦你如此想了，你會發現這個相對簡單，但是可能會是一個大跳躍，對這些習慣傳統CSS屬性的動畫。

　　舉個例子，如果你想讓元素變小，你可以使用transform: scale()，而不是改變他的寬度。如果你想移動他，不同於用外邊距或者內邊距混在一起——你可以僅僅使用一個簡單的transform: translateX或者transform: translateY。

為什麼這個是有效？

　　對於人類來說，改變寬度，外邊距或者其他屬性，看上去不是很大的交易——因為它更簡單，看上去更好——但是電腦需要做的事情和人類比起來簡直是天壤之別，他要做的更加多更加槽糕。

　　瀏覽器團隊花費了很大的力氣在最佳化這些操作。Transforms真的很簡單就能提高效率，並且經常能夠充分利用你的圖形介面，而不用重新渲染元素。

　　第一次載入頁面的時候，你可能會抓狂——在所有的角落，使用圖片，在每個元素上加上陰影，如果你覺得特別粗糙，你甚至可以加上一個動態模糊。如果這隻發生一次，一些額外的毫秒時間計算並不影響。但是一旦內容重新渲染，你不會想重新計算所有的內容。

　　延展閱讀：用translate移動元素 (Paul Irish)

#2

將內容藏在不起眼的地方

　　使用pointer-events:通過透明度為0來隱藏元素

　　這個屬性也許會有瀏覽器安全色的問題，但是如果你只是為webkit或者其他現代瀏覽器做東西，這會讓你的生活更美好。

　　過去很長一段時間，當動畫需要通過jQuery的animate()處理的時候，許多漸層元素的複雜來自切換“display“屬性實現的：在一個合

　　CSS的pointer-events屬性（這已經存在了很長時間了，但是不經常用），讓元素不回應任何點擊和互動，就像他們不在那邊一樣。它可以簡單地通過CSS切換開啟和關閉，而不通過打斷動畫或者以任何方法影響渲染/可見度。

　　與opacity為0結合使用，他基本上和display：none是一樣的效果，但是不觸發新的渲染而影響效能。當隱藏元素時，我可以常常只設定opacity為0，並且關閉pointer-events，然後遺忘元素，他會自己照顧自己。

　　這和絕對位置的元素一起工作地特別好，因為你會十分有信心，它對頁面其他的元素完全沒有影響。

　　這也給你更多的迴旋餘地，因為定時並不完美——這不是世界末日，如果一個元素是可點擊的或者在其他元素上遮蓋一秒或者更長，或者如果這僅僅能被點一次，然後就隱藏起來了。

#3

不要同一時間所有元素都做動畫

　　除非使用編排

　　一個單獨的動畫自己是流暢的，但是同一時間許多元素都做動畫，就會擾亂他們。建立單個的流暢動畫很簡單——但是一個數量級的動畫就很難確保效能達到滿分。因此，合理地規劃特別重要。

　　將時間分開，那麼所有的元素都不在一個相同的時間開始。典型的是，2，3個可以在同一時間運行，而不需要減速，特別是如果他們在稍不同的時間開始動畫。

　　除非你的頁面上只有一個元素，不然理解編排是很重要的。這可能看上去像一個舞蹈編排，但事對於動畫介面來說是同樣重要的。元素需要在一個合適得位置合適的時間進入。及時他們都是分開的，他們必須感覺是設計好的的一個單元。

　　Google素材設計在這個主題上又很有意思的建議。這不僅僅是做事的正確方式，也是你需要考慮的事情和測試。

　　延伸閱讀： Google素材設計 · 動機

 #4

輕微地增加延遲，讓編排動作變得簡單_

　　編排動畫真的十分重要，並且需要十分多的實驗和測試才能找到感覺。然而，他的代碼並不十分複雜。

　　我通常會改變父元素上的一個Class（通常是在body上），來觸發一系列變化，每一個在特定的時間有自己的過度延遲。從代碼觀點來說，你只需要關心狀態改變，並且不需要在javascript中維護一堆定時。

　　查看圖片

　　Gyroscope Chrome 擴充的動畫

　　交錯安排一系列元素，是最簡單的編排你的元素的方法。這很強大，因為這同時看上去很好，同時也帶來了珍貴的效能——記住只有一小部分元素在同一時間開始。你會將他們分開直至感覺足夠流暢，但是不要分得太開，導致整體看上去太慢。足夠應該是重疊，這感覺像一個不間斷的流，而不是一系列獨立的個體元素。

代碼範例

　　這裡有一系列簡單的技巧，交錯排序你的元素——特別是如果是一長串元素。如果有少於10個元素，或者有一個不可估量的數量（就像在靜態頁面），然後我通常在CSS指定值。這是最簡單的便於維護的方法。

　　一個簡單的SASS迴圈

　　對於很長的元素列表或者一個動態內容，定時器可能需要通過迴圈每個元素動態設定。

　　最簡單的javascript迴圈

　　這裡有兩個常用變數：你的基本延遲和每個元素之間的延遲。這是一個需要尋找的微妙的平衡，但是當你敲擊正確的數字集，這會感覺非常好。

#5

使用全域倍數來設計慢動畫

　　然後加速之後所有的元素

　　對於動畫設計，定時就是一切。20%的工具是實現他們，並且其他80%是找到正確的參數&讓一切同步的間距，以及感覺流暢。

　　特別是在編排一系列元素的時候，嘗試壓榨效能和頁面並發性，看看所有的元素在慢動作下會讓事情變得簡單。

　　無論你是否用javascript，或者一些CSS前置處理器，如Sass（我的最愛），這都需要直接做些額外的算數，和建立變數。

　　你必須確認嘗試一些不用的速度或者定時是很方便的。比如，如果一個動畫在十分之一的速度下都很卡頓，那麼有可能從根本上就有問題。如果將它調至50倍速度依然流暢，那麼問題就是要找到他所能達到的最快的速度。在全速之下，5毫秒的問題很難察覺，但是如果你降低了整體的速度，那麼他們就會變得特別明顯。

　　特別對於十分複雜的動畫，或者解決棘手效能的瓶頸，在慢動作下查看元素的能力可能十分有用。

　　最主要的問題是，你想封裝許多完美的細節，當它變得慢的時候，然後提高整體的速度，因此這感覺是十分棒的。這十分微妙，但是使用者會察覺流暢以及細節。

　　這些特性只是OS X的一部分——如果你點擊shift按鈕來減小按鈕或者一個app表徵圖，你會看到他在慢速運行。在這一點上，當你按shift按鈕的時候，我們甚至可以在Gyroscope實現啟用慢動畫。

#6

拍下你的UI，並且重放他們，以擷取有價值的第三方關點。

　　有時候一個不同的關點，能協助你看事物更透徹，並且視頻是一個極佳總這件事的方法。

　　一些人在AE中建立視頻，並且嘗試將他們在網站上實現。我經常換做其他的方式，然後嘗試做一個來自網站的UI好視頻。

　　能夠發表vine或者一些video，是十分高杆的。有一天，我十分激動於我做的東西，並且嘗試做成視頻，分享給一些小夥伴。

　　然而，當我再看一次的時候，我發現有一堆東西不夠完美。有一個大的滯後阻礙了之後的動畫，並且所以的定時器都有一些問題。這讓我有些擔心，我最後沒有發表它而是意識到我還有許多工作要做。

　　當要在正式環境使用它的時候粉飾這些很容易，但是看在視頻上的動畫——一遍又一遍或者在一個很慢的速度——讓所有的問題都變得十分明顯。

　　他們說相機加了10磅。也許這也增加了10幀。

　　I 這現在也變成了我工作流程中重要的一部分，查看頁面慢動畫視頻，以及如果有任何幀讓我感覺不對，就馬上做些改變。要怪罪於慢瀏覽器很容易，但是在一些更加最佳化的瀏覽器上，測試，有可能解決了所有的問題。

　　一旦你在視頻上捕捉滯後停頓不覺得尷尬的時候，並且感覺視頻夠好，能夠分享了，那麼頁面差不多就可以準備上線了。

#7

網路活動導致滯後

　　你需要提前或者滯後載入大的http請求

　　圖片是這個問題的最黑禍首們，是否一些大傢伙（也許是一個大的背景）或者大量地小圖片（想象50個Emoji載入），或者僅僅有許多內容（一個很長的到底都有圖片的頁面）。

　　當頁面第一次載入，大量的東西初始化和下載。有統計，廣告和其他的第三方指令碼讓事情變得更糟糕。有時候，延遲所有的動畫到載入完幾百毫秒之後對效能有極大的協助。

　　除非必要，不要過度最佳化，但是一個複雜的頁面也許需要十分準確的延遲和內容定時，然後才能運行路暢。通常上來說，你想要在開始載入儘可能少的內容，一旦重的部分和簡介動畫做完之後，不斷地載入頁面其餘的部分。

　　有許多資料的頁面，載入所有的元素的工作量似乎是巨大的。一旦在做動畫的同時開始載入真實資料，一個動畫和靜態頁面運行地很好也許看上去是分開的。如果一些東西看上去應該工作或者有時候工作地流暢其他時間不流暢。我建議減產網路活動，確認你沒有在同一時間做其他事情。

#8

不要直接綁定滾動

　　看上去是一個很酷的主意，但實際上不是。

　　在過去幾年中，滾動為基礎的動畫很受歡迎，特別是在視差或者其他特殊效果中。是否是好設計，有待辯論，但是有一些好或者槽糕的方法去實現他們。

　　在這個類別中，適度的最佳化做些的事是將達到滾動到一定距離作為一個事件——並且僅僅運行一次。除非你真的瞭解你在做什麼，我會建議避免這個類別，因為這很容易出問題而且真的很難維護。

　　更加糟糕的是，建立你自己的捲軸功能，而不是用預設的——也就是scrolljacking。請不要做麼做！

　　這條建議對手機來說特別有用，但是也可能是使用者體驗的好實踐。

　　如果你確實有一個特別的體驗，你想專註在滾動或者其他特殊事件，我會建議建立一個快速原型，以確保這在花費大時間設計的時候，能夠運行良好。

#9

儘早&經常在手機上測試。

　　大多數網站是在電腦上建立的，並且很有可能在他們建立的相同機器上運行測試。因此手機體驗和動畫效能經常是後知後覺的。一些技術（比如canvas）或者動畫技術在手機並沒有運行地這麼好。

　　然而，如果編寫&最佳化適當（看規則#1），一個手機體驗可能會比臨機體驗還要好。手機最佳化是一個非常棘手的課題，但是新的iPhone現在比大多數手提都要快！如果你按照之前的建議編寫，你會發現你做的東西在手機上有著極佳的效能。

　　手機用法會是對於大多數網站都是一個非常大而且重要的部分。這看上去和極端，但是對於一整個項目，我會建議將手機從你的項目中分離出來。這不應該感覺像是一個懲罰去做手機版本，雖然經常會這樣。

　　保持設計進步&效能加強，知道這感覺被打磨流暢已經像網站的大版本那樣方便。

　　如果你強迫自己只用手機網站一個禮拜，你很可能就會將它最佳化得向大型網站一樣，有著的極佳體驗。經常懊惱地使用是值得的，這意味著在你的使用者體驗之前解決問題。

#10

在不同的裝置上經常測試

　　螢幕大小，像素，或者裝置都有著極大的暗示 . 除了手機vs案頭，有許多關鍵點會徹底影響效能，就像是否螢幕是“retina”屏，視窗的總像素，硬碟多老了，等等。

　　即使Chrome和Safari都是webkit的瀏覽器，有著相同的文法，他們也都有各自怪異行為。每一次chrome更新都會修複一些東西以及引入新的bug，因此你需要一直保持警覺。

　　當然，你不僅僅只希望建立最低水準的效能，因此找到最機智的方法來漸進添加或者移除增強功能會十分有用。

　　我經常在我的小Macbook和大的iMac之間切換，並且每次切換都引出了一些小問題並且做些改進——特別是依據動畫效能，但是對於總體設計，資訊密度，可讀性，等等。

　　媒體查詢，常常是強大的工具來處理這些不同環節樣式，通過不同的高度或者寬度是最基礎的媒體查詢的用法。找出OS和裝置的類型會很有用，因為手機效能特性和電腦很不一樣。

　　查看圖片

　　我希望你在你的下一個項目中，會找到有用的技巧。好運！

 

流暢web動畫的十個法則