Google I/O 官方應用中的動效設計

版權聲明：本文爲博主原創文章，未經博主贊成不得轉載。 https://blog.csdn.net/jILRvRTrc/article/details/82881743

做者：Nick Butcher, Android 設計師 + 開發project師, Google

在爲 Google I/O 2018 Android 團隊工做期間，咱們的主要做品之中的一個就是這個官方的應用，贊成與會者和遠程人員瞭解會議細節，創建個性化的時間表，並在會場預訂座位。咱們在應用中構建了不少有趣的動效，而且咱們也開源了這個應用的代碼，如下我想強調一些這些設計實例，以及一些有趣的實現細節，但願能給你們平常的動效設計帶來靈感。

一般咱們會在應用中使用 3 種類型的動效：

• 主動效：用於強化品牌視覺，並帶來使人驚喜的視覺焦點

• 屏幕切換

• 狀態變化

接下來，我想具體介紹一下這些動效的設計細節。

倒計時動畫

可以這麼說，Google I/O 官方應用的當中一部分做用就是爲會議帶來興奮感和期待感。所以，咱們在首屏幕和信息頁面都顯示了大型的倒計時動畫。這也是將大會的活動品牌視覺進行呈現的絕佳機會，爲應用增添了很是多特點。

△ 主屏幕抓眼球的倒計時動畫

這個動效是由一位動效設計師設計的。並以一系列的 Lottie json 文件交到咱們手中：每秒顯示一個數字，讓它以動效的形式 「in」 而後 「out」。Lottie 格式的文件可以輕鬆地放入 assets，甚至提供了便利的操做方法，如 setMinAndMaxProgress，它贊成咱們僅僅播放動效的前半部分或後半部分 (從而僅僅顯示動效的進場或出場)。

真正好玩的地方是將多個單獨的動畫文件佈局成整體的倒計時畫面。

爲此，咱們建立了 CountdownView，一個至關複雜的本身定義 ConstraintLayout，當中包括了多個 LottieAnimationViews。在這裏，咱們建立了一個 Kotlin 託付來封裝啓動適當的動效。這樣咱們就可以簡單地爲每個應該顯示的數字的託付分配一個用來顯示的 Int，隨後託付就會完畢設置並啓動動效。咱們擴展了 ObservableProperty，確保咱們僅僅在數字更改時才執行動效。咱們的動效循環每秒僅僅公佈一個可執行狀態 (在和視圖關聯起來的時候)。這個狀態計算每個視圖應該顯示哪一個數字並對託付進行更新。

預定會議

應用的關鍵操做之中的一個是讓與會者預約座位。

所以，咱們在會議詳情屏幕上的 FAB 中突出顯示此操做。

咱們以爲應該僅當預約操做在後端成功完畢後再進行提示 (不像那些不過重要的操做。好比 「關注」 一場演講。咱們就差點兒是同步在界面上顯示關注成功)。等待來自後端的響應可能需要一些時間。爲了這個預約的過程感受更快捷，咱們使用動效圖標，代表咱們正在對預約進行處理，而後再平滑過渡到成功的狀態中。

△ 預約的動畫。有展現後端操做的動畫過程

這個圖標需要反映的狀態很是複雜：會議多是可預訂的。可能已經預留了座位，假設座位已滿。則可能產生等候名單，他們也可能出現在等待列表上。或是在會議即將開始時預定功能被禁用了。

這會致使應用需要顯示多種動效以表明各類不一樣的狀態。爲了簡化這些轉場效果。咱們決定始終顯示 「後端操做」 狀態，也就是上面動畫中的沙漏。

所以。每次動效切換實際上都是成對的：狀態 1 → 後端操做 & 後端操做 → 狀態 2。這樣就簡化了很是多事情 (否則您可以想象可能出現的排列組合會有多少)。接下來咱們使用 shapeshifter 構建了所有這些動效。

爲了顯示這些動效，咱們使用了本身定義視圖和 AnimatedStateListDrawable (ASLD)。假設你還沒實用過 ASLD，咱們簡介一下：正如其名，它是動效版的 StateListDrawable，讓你不只可以爲每個狀態提供不一樣的 Drawable，還可以提供過渡狀態之間的轉場 (以 AnimatedVectorDrawable 或 AnimationDrawable 的形式)。

咱們建立了一個本身定義視圖來支持這些本身定義的預約狀態。

視圖提供一些標準狀態，如已按下或已選中。相同，您也可以定義本身的狀態。並依據狀態顯示不一樣的 Drawable。咱們自行定義了 state_reservable，state_reserved 等，隨後咱們會再爲這些不一樣的狀態建立一個枚舉，封裝視圖狀態以及不論什麼相關的屬性，如相關的內容描寫敘述。

而後，咱們的業務邏輯可以簡單地從視圖上的這個枚舉中設置適當的值 (經過數據綁定)。這將更新 Drawable 的狀態，而後經過 ASLD 啓動動效。本身定義狀態和 AnimatedStateListDrawable 是實現這一點的一種巧妙方法，將多個狀態保留在聲明層中。從而產生最少的視圖代碼。

演講者動效

不少屏幕間的轉場動畫都可以直接用標準窗體動效。咱們另闢蹊徑的地方是。前往演講者介紹信息屏幕的轉場效果。例如如下圖，演講者頭像在演講信息和演講者信息兩個屏幕之間共享，是典型的共享元素轉場動畫，這樣也有助於理解先後兩個屏幕間的內容關聯。

△ 演講者頭像在兩個屏幕間共享

這裏是一個很是標準的共享元素轉換，在 ImageView 上使用了 ChangeBounds 和 ArcMotion 類。

更有意思的是。啓動這個轉場效果自己也會歸入咱們的導航設計/開發模式中來。大致上講，這樣的模式將輸入事件 (如點擊一位演講者) 與導航事件分離，讓 ViewModel 來負責怎樣響應輸入。在這樣的狀況下，這樣的解耦意味着，ViewModel 將會暴露出 Events 的 LiveData，它僅僅知道需要導航到哪一個 ID 的演講者。啓動共享元素轉場效果需要共享 View。而在這一瞬間這個 View 尚未。

咱們解決問題的方式是，在綁定時將演講者的 ID 做爲標籤存儲在視圖上，以便稍後當咱們需要導航到特定的演講者細節屏幕時檢索該視圖。

過濾器

會議應用的核心功能之中的一個是幫助用戶從不少會議中過濾出感興趣的那些。每個話題都有一個與之相關的顏色。以便識別。咱們收到的設計方案基於 「Chip」 動畫，便於用戶與各個話題進行操做。

△ Chip 列表很是適合用來挑選感興趣的話題

Material Components 裏提供了默認的 Chip 控件，但咱們決定使用本身定義視圖。以便更好地控制各個狀態的顯示內容和動效。

咱們使用 canvas 進行畫圖並使用 StaticLayout 來顯示文本。該視圖具備單一的 progress 屬性，即 0 - 未選中 / 1 - 已選中。在狀態切換的時候，咱們會同一時候改動視圖中的顯示元素。並使用線性插值來決定每一幀的形狀和顏色。

最初在實現這個控件時，我讓視圖實現了 Checkable 接口，並在 setChecked 方法被調用來給狀態賦新值的時候啓動動效。只是當咱們在 RecyclerView 中顯示多個過濾器時。會出現用戶的操做觸發的動效和數據綁定觸發的動效衝突的狀況。爲了解決問題，咱們單獨提供了一個觸發動效的方法來避免這樣的衝突。

此外，當咱們剛剛給應用裏引入這個動畫效果時。咱們發現它有丟幀。是個人動效代碼有問題嗎？這些控件位於一個 BottomSheet 中，且被放置在會議日程安排畫面的前面。

當過濾器裏的值被改動時。咱們會執行過濾會議造成的業務邏輯，而且更新關注列表裏的關注內容，這些看來都沒什麼問題。後來通過排查，咱們肯定問題在於。當過濾器裏的內容被改動的時候。負責顯示日程的 RecyclerViews 的 ViewPager 盡職盡責地啓動了，並依據新提供的數據進行了更新。

這致使不少視圖出現了因爲內容添加而「膨脹」的現象。更因爲這個視圖內容的添加而觸發了自適應佈局的邏輯，來又一次渲染當中的內容。

所有的這些邏輯都是本身主動的，也沒問題……除了會撐爆咱們的刷新率。但關注列表事實上在過濾器的 「後面」 (被遮住了)，因而咱們決定延遲執行關注列表裏的內容更新 (直到過濾器裏的值都被肯定，且動效開始執行時才更新)，咱們犧牲了一些實現的複雜性。換取了更加順暢的用戶體驗。最初我使用 postDelayed 實現它，但這致使了 UI 測試時出現故障。

因而，咱們改動了啓動動效的方法。贊成它接受一個 lambda 表達式。這樣一來，咱們就能在保持用戶操做的動效和高效的測試之間找到一個平衡。

一塊兒動起來吧！

總的來講。我以爲動效確實有助於改善應用的體驗，以及提高品牌表現力。

但願這篇文章能讓您明確咱們在各個環節使用動效的動機，以及具體實現它們的作法。更重要的是，咱們但願您的應用中也能出現豐富多彩的動效，在抓人眼球的同一時候也能很是好地表達品牌信息和交互意圖。

 點擊屏末 | 閱讀原文 | 獲取 「Google I/O 官方應用」 開源碼。

推薦閱讀：

· 頂尖開發人員們的實戰分享：怎樣有理有據地作產品決策

· 霓虹燈藝術家 Josefin Eklund 的故事

· 訂閱業務該怎樣作好升級？