[Day 30] 總結

2026 iThome 鐵人賽

DAY 30

Modern Web

Rive 的一些進階主題系列第 30 篇

18th鐵人賽

rayrayyyyy0507

2026-10-14 23:06:10

93 瀏覽

分享至

今天是鐵人賽的最後一天，會總結一下這 30 天的文章做一點摘要跟總結，幫大家複習一下。

Data Binding

首先我們在簡單複習完 Rive 後，就進到 Rive 新出的 Data Binding API。以前我們是用 State Machine Input 在控制 Rive 檔，做出 stateful 的動畫，現在改用 Data Binding 來做這些事。

Data Binding 除了有一些比較 boilerplate 的程式碼要稍微寫一下以外，主要的語法本質上就是 key-value pair，設計師把可以改變的資料挖好洞，前端工程師往裡面填 value，就這樣。除了本來 State Machine Input 就有的 number, boolean, strigger 以外，還多了 string, color, enum, image 四種，基本上動畫用的到的、可以動態改的數值，應該都找得到對應的型別。

常見問題 & Rive RWD 的方法

我們也回答了一些跟 Rive 有關，常常被問到的問題。關於 Rive 能不能拿來做 UI 這件事，首先 Rive 至少目前只是一個做動畫的工具，所謂的 UI 不只有動畫或是視覺，還包含互動元件、使用者操作後的回饋、以及整個介面的資訊架構。這幾個部分瀏覽器幫我們做的很好，但是換成用 Canavs 就會三不五時有哪個地方卡卡的，所以做 UI 可以是可以，還是讓 Rive 做它擅長的事，讓瀏覽器做它擅長的事，通常會是更划算的選擇。

至於大家最喜歡問的，Rive 有沒有效能問題這件事，通常是七分靠前端、三分靠裝置、剩下九十趴靠設計師，所以低情商的回答很簡單：沒有。當然高情商一點的回答就會是：恩恩這是一個很好的問題，通常的情況下不會有效能問題，Rive 的檔案大小非常小，而且前端可以用快取或其他策略進一步最佳化載入時間，渲染的部分也有用 canvas 加上 requestAnimationFrame 處理。不過效能的最佳化牽涉到關鍵渲染路徑上的很多層面，如果你有特別想問哪一層的話，我可以再深入回答。同時實務上來說，如果能跟設計師們密切合作、對齊認知的話，就算有效能的問題，也可以更早一步的解決，盡早發現盡早治療。

最後是大家也很關心的，Rive 要怎麼做到 RWD 這件事，我們提出了從前端做等比縮放、用 Rive 內建的 layout、以及暴力切換不同版本的 Rive 檔三種方法。第一種很簡單，就是監聽 resize 後改 transform scale。第二種是 Rive 最標準的作法，可以的話請優先使用。第三種好吧嚴格說起來是 AWD 不是 RWD。

一些實務建議

實務建議的部分，我們講了一些實務上常用的技巧，包括 virtualization、音樂音效的引入、切分 Rive 檔案、以及 preload 的策略。這些是實務上非常細的東西，大概知道一下，之後真的有遇到再去看就好。其實這些都是 web 開發的基本功，只是剛好在 Rive 遇到而已，可能再被那些 Rive 的印度工程師包裝一下換個名詞拿出來當 feature 這樣。

文章導讀 & 一些對 Rive 的反思

文章導讀的部分，我們先讀了 Rive is what Flash should've become 這篇文章，得知了 Rive 本質上就是 Flash 穢土轉生，以及 Rive 的賣點就是簡單快速做出漂亮的動畫這兩件事，接下來幾天就以此為核心，重新來看 Rive 的一些優缺點與特性。

首先關於 Rive 省成本的這件事，他其實是省下簡單快速漂亮的動畫的製作成本，如果不是這種動畫，那 Rive 當然還是可以做，就好像可樂還是可以加珍珠一樣。也因爲 Rive 省下的成本夠多，所以簡單漂亮的動畫，跟精緻的動畫，不一定是互斥的，可以兩個都做，我全都要。

再講到有限狀態機這件事，如果認同 Rive 的賣點是省成本的話，那有限狀態機就跟這個賣點有衝突。他增加了太多的複雜度，增加學習成本與溝通成本，徒增困擾，很高興看到 Rive 官方改邪歸正、棄暗投明、改用 Data Binding 了。

最後也提到說，所謂 Rive 省成本這件事，也有一點把刻動畫這件事拋給設計師處理的味道在，這裡除了再次讚嘆各位設計師大大有多偉大以外，也提到說設計師看事情的角度跟工程師有非常非常非常大的不同。設計師跟所有其他正常人一樣，看事情是整體的，不像工程師會分點分層分拆得很細，如果不意識到這一點，雙方會多一些溝通成本。