自適應設計的最佳實踐

推薦的自適應設計最佳實踐包括：

在設計應用時，嘗試將大型、複雜的元件拆分為更小、更簡單的元件。

重構元件可以透過共享核心程式碼片段來降低採用自適應 UI 的複雜度。這樣做還有其他好處：

• 在效能方面，擁有許多小的 const 元件比擁有大型、複雜的元件能改善重建時間。
• Flutter 可以重用 const 元件例項，而大型複雜元件則必須在每次重建時重新設定。
• 從程式碼健康的角度來看，將 UI 組織成更小、易於管理的塊有助於降低每個 Widget 的複雜度。複雜度較低的 Widget 更易讀、更易重構，且不太可能出現意外行為。

要了解更多資訊，請檢視通用方法中的自適應設計 3 個步驟。

除了螢幕尺寸，你還應該花時間考慮不同外形規格的獨特優勢和劣勢。對於跨平臺應用來說，在所有地方提供完全相同的功能並不總是理想的選擇。考慮是否需要針對特定裝置類別專注於特定能力，甚至移除某些功能。

例如，移動裝置便於攜帶且配有攝像頭，但它們並不適合進行詳細的創意工作。考慮到這一點，你可能會在移動端 UI 中更專注於捕捉內容並新增位置資料標籤，而在平板電腦或桌面端 UI 中則專注於組織或處理這些內容。

另一個例子是利用 Web 極低的分享門檻。如果你正在部署 Web 應用，請決定要支援哪些深度連結 (deep links)，並據此設計你的導航路由。

這裡的關鍵點是思考每個平臺最擅長什麼，並觀察是否有你可以利用的獨特能力。

構建優秀的觸控 UI 通常比傳統桌面 UI 更困難，這部分原因在於缺乏右鍵點選、滾輪或鍵盤快捷鍵等輸入加速器。

應對這一挑戰的一種方法是優先專注於打造出色的觸控式 UI。你仍然可以使用桌面目標進行大部分測試以獲得迭代速度，但記得要經常切換到移動裝置，以驗證一切操作感覺是否正確。

在打磨好觸控介面後，你可以針對滑鼠使用者調整視覺密度，然後疊加所有額外的輸入。將這些其他輸入視為加速器——即能加快任務執行速度的替代方案。需要考慮的重要一點是，使用者在使用特定輸入裝置時會有何預期，並努力在你的應用中體現出來。

自適應應用應該在不同尺寸和形狀的視窗中看起來都很美觀。雖然在手機上將應用鎖定為縱向模式有助於縮小最小可行性產品 (MVP) 的範圍，但這會增加未來使應用實現自適應的成本。

例如，認為手機只會在全屏縱向模式下渲染你的應用是不準確的。多視窗應用支援正變得普遍，摺疊屏裝置也有許多在多應用並排執行時效果最好的使用場景。

如果你絕對必須鎖定應用的縱向模式（但其實不建議這樣做），請使用 Display API 而不是 MediaQuery 之類的方法來獲取螢幕的物理尺寸。

總結

• 鎖定螢幕對於某些使用者來說可能是一個無障礙性問題。
• Android 大屏分級要求在最低級別上支援縱向和橫向。
• Android 裝置可以覆蓋鎖定的螢幕。
• Apple 的指南指出目標應為支援兩種方向。

避免在元件樹的頂層使用 MediaQuery 的 orientation 欄位或 OrientationBuilder 來切換不同的應用佈局。這類似於不應為了確定螢幕尺寸而檢查裝置型別的指導原則。裝置的方向並不一定能告訴你應用視窗擁有多少空間。

相反，請使用 MediaQuery 的 sizeOf 或 LayoutBuilder，如通用方法頁面所述。然後使用 Material 推薦的那種自適應斷點。

當在寬屏裝置上執行時，那些使用視窗全寬來顯示框或文字域的應用通常表現不佳。

要了解如何避免這種情況，請檢視使用 GridView 佈局。

在進行佈局決策時，避免編寫檢查裝置是否為“手機”或“平板電腦”或任何其他特定裝置型別的程式碼。

應用實際獲得的渲染空間並不總是與裝置的整個螢幕尺寸掛鉤。Flutter 可以在許多不同平臺上執行，你的應用可能正在 ChromeOS 上以可調整大小的視窗執行，可能在平板電腦的多視窗模式下與另一個應用並排執行，甚至是在手機的畫中畫模式中執行。因此，裝置型別與應用視窗大小之間並沒有很強的關聯。

相反，請使用 MediaQuery 來獲取應用當前執行所在的視窗大小。

這不僅對 UI 程式碼有幫助。要了解抽象出裝置能力如何幫助你的業務邏輯程式碼，請檢視 2022 年 Google I/O 大會的演講：Flutter 聯合外掛開發經驗教訓。

應用應支援基礎滑鼠、觸控板和鍵盤快捷鍵。最常見的使用者流程應支援鍵盤導航，以確保無障礙性。特別是在大屏裝置上，你的應用應遵循鍵盤無障礙的最佳實踐。

Material 庫提供了在觸控、滑鼠和鍵盤互動方面具有出色預設行為的元件。

要了解如何為自定義元件新增此支援，請檢視使用者輸入與無障礙性。

要在裝置方向改變時保持列表的滾動位置且不改變佈局，請使用 PageStorageKey 類。當元件被銷燬時，PageStorageKey 會將元件狀態持久化到儲存中，並在元件重建時恢復該狀態。

你可以在 Wonderous 應用中看到此示例，它將列表的狀態儲存在 SingleChildScrollView 元件中。

如果 List 元件在裝置方向改變時會更改佈局，你可能需要進行一些數學計算（示例）來調整螢幕旋轉後的滾動位置。

當裝置旋轉、更改視窗大小或進行摺疊/展開時，應用應保留或恢復應用狀態。預設情況下，應用應該維護狀態。

如果你的應用在裝置配置更改期間丟失了狀態，請驗證應用所使用的外掛和原生擴充套件是否支援該裝置型別（例如大屏裝置）。某些原生擴充套件在裝置位置改變時可能會丟失狀態。

關於此情況的真實案例，請參閱 Medium 上的免費文章《開發 Flutter 大屏應用》中的問題：摺疊/展開導致狀態丟失部分。