方法二：使用 Layout（官方推薦，可真正做到重新排版）

如果上一個方法的 Scale 解決的是「大小」的問題，那麼 Layout 解決的就是「版面」的問題。

當畫面中的元件需要根據不同螢幕尺寸重新排列，例如手機版按鈕往下移、資訊區塊改為垂直排列或需要調整間距時，單純依靠等比例縮放就無法滿足需求。這時候，就很適合使用 Rive 官方提供的 Responsive Layout。

與 Scale 最大的不同在於，Layout 並不是將整個 Artboard 放大或縮小，而是根據你在 Rive Editor 中事先定義好排版規則（Layout 與 Constraints），讓畫面在不同尺寸下自動重新計算元件的位置與大小，從而實現真正的響應式排版。

Layout 解決的不只是「大小」的問題，而是真正解決了「版面」的問題。

什麼情況適合使用？

以下幾種情境，我會優先考慮使用 Layout：

• 不同裝置之間使用相同的 UI 元件，只是排列方式不同。
• 有較複雜的 UI 結構，例如按鈕群、卡片列表、導航列等。
• 希望只維護一份 .riv 檔案，不想為不同裝置製作多個版本。
• 希望兼顧設計彈性與後續維護性，讓元件能隨著螢幕尺寸自動調整位置、間距與大小，並在不同解析度下維持一致的視覺體驗。

實作方式

使用 Responsive Layout 時，需要同時完成 Editor 與 Runtime 兩個部分的設定。

首先，在 Rive Editor 中替 Artboard 建立 Layout，並設定各個元件的排版規則，例如 Row、Column、Pin 或百分比尺寸等。

// 關鍵差異在於 fit: rive.Fit.Layout
const riveInstance = new rive.Rive({
  src: 'your-animation.riv',
  canvas: document.getElementById('rive-canvas'),
  autoplay: true,
  layout: new rive.Layout({
    fit: rive.Fit.Layout,     // ← 最重要的設定
    alignment: rive.Alignment.Center,
  })
});

// 監聽視窗大小變化（與 Scale 相同）
window.addEventListener('resize', () => {
  riveInstance.resizeDrawingSurfaceToCanvas();
});

如此一來，Rive 就會根據 Editor 中設定好的 Layout 規則，自動重新排列元件。

優缺點總結

• 優點：可以真正重新排版元件、調整間距與結構，只需維護單一 .riv 檔案就能適配多種裝置，是官方推薦且長期來說最彈性的方案。
• 缺點： 開發成本主要落在前期的 Layout 規劃。負責製作 Rive 的人需要先理解 Responsive Layout 與 RWD 的設計概念，才能規劃合適的排版規則；如果初期規劃不完整，後期往往需要反覆調整 .riv 檔案與程式碼，增加修改與溝通成本。

需要特別注意的開發成本

Layout 真正的開發成本，不是在前端的程式碼，而是在前期的版面規劃。

Layout 雖然是我最推薦的 RWD 方案，但它的開發成本並不只是前端多寫幾行程式，而是需要製作 Rive 的人與前端在設計初期就一起規劃。

由於 Layout 的排版規則是在 Rive Editor 中完成，因此設計 Rive 的人需要對 Responsive Layout 有基本的概念，例如元件應該固定尺寸還是使用百分比、哪些元件需要跟隨父層縮放、哪些區塊需要使用 Row、Column 或 Pin 等設定。

如果一開始就將 Layout 規劃完整，前端通常只需要使用 Fit.Layout 並在畫面尺寸改變時呼叫 resizeDrawingSurfaceToCanvas()，整個串接流程會相對順暢。

反之，如果 Rive 在製作時沒有考慮不同裝置的版面需求，等到開發後期才開始補 Layout，往往會遇到許多問題，例如：

• 元件位置跑版，需要重新調整 Constraints。
• 不同解析度下元件間距不一致。
• 文字、圖片或按鈕發生重疊。
• 為了修正單一畫面而影響其他尺寸的版面。
• UI、前端需要反覆修改 .riv 檔案與程式碼，增加溝通與維護成本。

因此，我會建議如果專案一開始就確定需要支援多種螢幕尺寸，就將 Layout 一併納入設計流程，而不是等到開發完成後才開始補做。這樣不僅能降低後續修改成本，也能讓整個開發流程更加順暢。