前幾天聊了 Rive 的基本介紹，Rive 的優缺點與其他動畫技術的比較，以及對設計師來說，使用 Rive 的一些注意事項。最後則是一些我們公司內部在採用 Rive 時，設計師提出來的一些 Q & A。希望經由這幾天的文章，可以讓讀者試著使用 Rive。

為什麼不同的前端工程師，要求的 Rive 邏輯寫法也不一樣？

這個問題可以分成幾個層面，首先 Rive 有點像在請設計師切版或寫程式，不同的工程師寫程式，他們拆分任務或邏輯的方式都有點不太一樣，所以整體來說這點還算正常。

不過如果是站在團隊的角度來說，畢竟團隊對外還是要統一工作流程與程式風格，這樣開發效率與後續的維護性才會比較好，所以這部分的確應該要求團隊中的前端設計師們討論好，得出一個統一的結論後，再提交給設計師。不過這是站在同一個團隊的角度來說，如果是不同的團隊或專案之間要求的 Rive 邏輯寫法，通常還是會有一些差異。

製作 .riv 檔之前，可以先訂好所有需要的 input 或 event 嗎？

我先幫大家翻譯一下問題，這有點像是在問說：「請問前端在開發前，可以先跟後端訂好 API 需要的所有參數跟回傳值嗎？這樣後端會比較好做，不用開發到一半再改東西。」

當然理論上是要可以，這理論上的確是前端的責任，但現實面上很困難。一來前端提的需求與設定，也是根據規格書或 API 提的，但這兩者在開發中多少還是會變。二來有些東西做下去才發現要改。我們當然會盡量避免，但實際上還是有可能發生。

白話文就是：我們盡量但是有點難，而且人在江湖走跳，很難不挨隕石。當然我們還是要平衡報導一下，就算有時候會被隕石打到，也不能說完全放棄治療。工程師應該至少就當下可以合理預見的情況，盡可能的先跟設計師講好需要的 input, event, text 等等，盡人事聽天命的概念，不盡人事，不得天命。

我們還沒開始介紹 Rive 的語法，所以讀者現在還不知道 input 或 event 是什麼是很正常的，可以先看一下官方文件，或是繼續閱讀後面幾天的文章，先大概知道一下這就是前端餵給 .riv 檔的參數就可以了。

需要設計師限制 Rive 檔案大小嗎？

標準答案是不太需要，但可以的話當然是越少越好，跟圖片一樣。通常不要太誇張的堆效果的話，檔案大小應該都在合理範圍內，如果有特別大的檔案的話，可以先跟我們說一下，我們可以做一些額外處理，讓他不要載入太慢。

不過在我回這個答案給設計師後，設計師們的動畫就……越來越精緻，所以老實講各位還是要針對自己專案或公司的條件斟酌一下🥲🥲我個人後來覺得這有點像彼得定律，如果一直提升動畫效果的話，最終還是會遇到某個臨界點要處理，不過這就扯比較遠了。

小結

以上是我遇過設計師在改用 Rive 後，提出來的一些問題與回應，到這邊關於 Rive 的 why 就告一段落了，接下來就會進入到 how 的部分，也就是一些語法與細節的實作，工程師們可能會更有興趣。