iT邦幫忙

2026 iThome 鐵人賽

DAY 17
0
Modern Web

從實務需求出發:前端視覺與 UI 互動開發實踐系列 第 17 篇

【Day 17】主題樣式:稍作休息,復盤一下

  • 分享至 

  • xImage
  •  

前幾天我們用 SCSS、CSS 變數與 inline SVG 整理了主題樣式,能交給程式處理的顏色、按鈕,都盡量交出去了。不過專案裡還是有不少地方,得靠一張張圖片加上一個個 @keyframes 撐起來,尤其是畫面上那些會動來動去的吉祥物與主題裝飾。這是設計風格形成的必然結果。

今天我們停下腳步,不寫 Code。花點時間回頭看看專案的 UI 該如何管理:哪些地方可以先動手調整,以及如果要往下一個專案走,能挑什麼工具。這篇會偏向個人的碎碎唸,讀起來可能有點讓人摸不著頭緒。在這裡附上一張雞排獅薩,以表歉意。
https://ithelp.ithome.com.tw/upload/images/20261002/20184345UI9KsKkPW9.png


一、現有專案調整

目前專案有大量的圖檔、CSS 定位設定、CSS 動畫設定,理性上知道有其必要性,感性上卻阿雜到不行。盤點下來,問題大多不在 CSS 寫法本身,而是「重複」與「責任放錯地方」。

1. SVGO 壓縮 SVG 素材

光是吉祥物的素材加起來就有 70 多 MB,有些甚至一個檔案就超過 6 MB。這其實也是我之前踩過的坑,為了避免圖片在 iPhone 這類解析度較高的裝置上失真,習慣匯出 SVG。直到有次發現匯出的檔案大小以 MB 計算,嚇了一跳:只是匯出一個帶框的圖形,怎麼會這麼大?之後放到 Figma 檢查,才知道筆刷質感這類不平滑的設計,是會被匯出成數十萬段細碎的路徑。
可以先嘗試用 SVGO 這類工具,移除 SVG 多餘的資料,縮小檔案大小。必要時再和設計師討論是否改用點陣圖。

2. 封裝 UI 元件:動畫集中管理,單一引用來源

專案有好幾個吉祥物角色,每個角色又有多種主題服裝,需要隨主題切換。目前元件封裝的方式偏向一個個獨立包裝,要在父層設定索引表,再對照出要引用的元件。除了每次用的時候要寫一次索引表外,幾乎一樣的角色動畫也在每個元件各寫一份。
考慮合併內容類似的元件,並開放 themeName 等 props 來更動吉祥物的飾品或表情,並建立一份全專案共用的索引表。

3. 元件責任切分:元件只管內部設定,定位與大小交給父層

目前有點混在一起,例如在元件內部決定這個裝飾「在 A 頁面要放哪裡、在 B 頁面要多大」。不只讓修改時的 CSS 難追蹤,也讓這些會重複出現的元件通用性打折。
應該改用 CSS 容器與內容分離的概念,元件的 <style> 不涉及外部設定,專注處理內部的零件定位與動畫、尺寸改用相對單位或 props 設定,容器大小與定位交付父層決定。

💡 其他:

  • 目前動畫都是無限循環(infinite),即使角色已經捲出畫面、或使用者在系統中開啟了「減少動態效果」,動畫還是會一直播放。之後整理動畫時,可以考慮在這兩種情況下讓動畫暫停。
  • 細部動畫控制可改用 Web Animations API:像是「動作加快」、「離開畫面就暫停」這類需要程式控制的情境,用 WAAPI 會比切換 class 更直覺。

二、工具決策層面

其實專案的初期,我就有想:比起用原生 CSS,是不是有更合適的開發工具?除了這個專案外,另外還有個正在發想中的專案,需求方提到希望加入換裝、個人小屋等收藏要素。感覺更難用原生 CSS 處理。再加上純粹個人好奇驅使,詢問 AI 並 Google 搜尋,收集了兩個自己覺得合適的工具,並大概了解、思考了各自的優劣勢。

跨平台支援(iOS、Android、網頁)是基本需求,以下就不再贅述。

Rive

  • 優勢:
    • 最符合需求。從官方範例來看,能做到人物動態、換表情、換服裝。
    • 能做到互動性高的動畫,適合帶有遊戲性的專案。
    • 檔案大小最小。
  • 劣勢:
    • 學習曲線高,團隊沒有人有相關經驗,基本上要從 0 開始學。
    • 容易造成過度設計,許多 Rive 的實務分享都有提到這點。而且以我的角度來看,目前專案已經有點這種傾向了。
    • 有免費方案,不確定方案夠不夠用,但能確定公司一定不想多付錢 😂

Lottie

  • 優勢:
    • Airbnb 開源的套件。
    • 本身是 JSON 格式,檔案大小比一般的 GIF、影片小。
    • 專案裡已經有兩三個地方在使用,過往的專案也有用過,團隊相對熟悉。
  • 劣勢:
    • 需要由設計師用 AE 輸出動畫,但不確定設計師對 AE(After Effects) 的熟悉度。
    • 以「播放」為主,互動與動態調整內容較受限。只適合單純播放的情境。
    • 動畫效果太複雜時,容易占用裝置的記憶體與 CPU。之前就遇過在 Vue 建立動畫後,忘記在元件卸載時銷毀實體,導致網頁吃掉超多記憶體。

小結

Rive 看起來很好玩、很吸引人,但以團隊現況來看,導入的成本過高;Lottie 雖然熟悉,卻不太適合需要互動的動畫。有夢最美,希望相隨。如果有一天真的要做換裝系統,會試試看 Rive。目前比較務實的做法,是先把現有的 CSS 動畫整理乾淨。

而且這幾年原生 CSS 動畫其實進步不少,像是獨立的 translate、rotate、scale 屬性、@property、View Transitions API 等等。很多以前要靠 JS 函式庫才能做到的效果,現在 CSS 自己就辦得到。

明天開始,我們就正式進入動畫篇!先從 CSS 原生動畫的功能聊起,看看有哪些新面孔。


參考資料


上一篇
【Day 16】主題樣式:inline SVG 再臨
系列文
從實務需求出發:前端視覺與 UI 互動開發實踐 共 17 篇
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言