Android 設計
如何以 Material 3 Expressive 來設計 Android 應用程式，並將其轉化為設計決策與 Compose 程式碼。Expressive 並非獨立的設計語言，它是 Material 3 加上 Google 稱之為「擴充套件」的選擇性 API、元件與設計策略。此處的指南、研究與 API 名稱均來自 m3.material.io、Android 設計指南 (developer.android.com/design/ui)、Wear OS 設計指南、Google I/O 與 Android Developers 演講，以及 androidx 原始碼。
貫穿主軸：當畫面能刻意分配視覺強調時，它才會顯得有設計感。 先區分畫面的目標優先級，然後將尺寸、色彩對比、形狀、字體、容器與動態效果分配給首要目標，次要目標少一些，其餘目標則幾乎不分配。原始的 Material 程式碼會給予每個元素相同權重，這就是為什麼它看起來像模板的原因。
標記為 (Google) 的引述與規則來自 Google 的指南。標記為 (default) 的規則是此技能的預設起點：除非畫面的方向有理由不遵循，否則請依此執行。
適用範圍。 此技能適用於手機、平板、桌面電腦與 Wear OS 應用程式的畫面。對於 Wear OS 畫面，請先閱讀 references/wear-os.md；當兩者存在差異時，以該文件為準。請使用 wear-compose-m3 技能進行結構搭建與遷移。Wear 的動態方塊、錶面與主螢幕小工具不在此技能範圍內：請使用 wear-widgets 技能處理 Wear 小工具與動態方塊，並使用 Glance 技能處理主螢幕小工具。
視覺工具
實施或審查實際的 Compose 程式碼時，需要 compose-preview CLI 以及 compose-preview 和 compose-ui-builder 技能：請閱讀並遵循 compose-preview，它負責工具選擇、渲染與問題排除。對於 UI Builder 的設計創作請求，請遵循 compose-ui-builder。此技能負責設計決策與畫面檢查。如果某個依賴項不可用，請回報問題，並引導使用者參閱此儲存庫 README 的設定章節，而不是自行安裝工具或替代渲染器。
探索或實作
當需求涉及新應用程式、新畫面或重新設計（要求打磨、視覺方向、Material 3 Expressive，或指名此技能）時，即使需求中寫著「建置」，也應以提案開始：遵循 android-design-explore 技能，在預覽器應用程式中展示其提案，並等待使用者批准一個方向後，再開始撰寫任何 Compose。當使用者明確指示跳過提案時（例如「跳過提案」、「直接寫程式碼」），或現有的已批准提案已經存在時，則跳過提案；使用該技能的「批准與移植」步驟（從 export_kotlin 開始）來移植已批准的提案。
一個不涉及設計的純建置需求則直接進入程式碼編寫，並應用下文所述的決策與畫面檢查。
對現有設計的修改（修正、微調、審查、批准的畫面新增狀態）應在其自身的批准與分支規則下，直接對實際專案進行修改，並應用下文所述的設計決策與畫面檢查。
0. 撰寫 UI 之前
在提供任何程式碼之前，請在回覆中回答這些問題，每個問題一兩句話。跳過此步驟是產生通用畫面的主要原因。
- 排列目標優先級。 此畫面的首要任務是什麼？次要與第三順位的任務是什麼？(Google: 「將每個頁面簡化為一個主要任務。」)
- 選擇一個方向。 說出畫面的情感特質、定義它的內容或互動，以及一個將字體、圖像、顏色和形狀結合在一起的視覺概念。每個答案都必須指定一個決策（例如「頂部三分之一處以大號數字顯示總數」），而不是一個形容詞（例如「現代、簡潔」）。如果這個概念描述了這類應用程式大多數的現有外觀，那它還不算是一個真正的概念。
- 決定英雄時刻。 這個畫布是產品中一兩個英雄時刻之一嗎（最情緒化或最核心的互動）？如果是，規劃如何在此處結合多種策略。如果不是，則保持平靜 (Google)。
- 選擇色彩來源。 動態（桌布）、品牌（生成的配色方案）或基於內容（來自畫面中的影像）。請參閱第 4 節。
- 根據優先級分配視覺強調。 首要目標獲得最多強調，通常優先使用尺寸。次要目標的策略較少；第三順位的目標則使用容器與字體 (Google)。當內容本身就是產品時，它可以主導畫面，但主要操作必須始終清晰可辨。
- 從第 9 節的表格中挑選元件，而不是根據對舊版 Material 的記憶。
- 回答適配問題。 針對你要渲染的每個尺寸類別（緊湊、中等或展開、大型或超大型），說明額外的空間揭示了什麼：第二個窗格、展開的導航欄、更多細節。使用 references/layout.md 中的五個問題，從「應該揭示什麼？」開始。導航保持一致：如果較大的佈局有導航欄，則緊湊佈局也應為相同的目標使用導覽列。對於像媒體播放器這類以控制項為主的畫面，控制項會重新排列，並揭示內容。一個僅將手機內容橫向展開的較大佈局，並未回答這個問題：「額外的空間不僅僅意味著把同樣的東西放大。」(Google)
然後組合畫面（第 8 節），建置它，並在渲染結果上執行畫面檢查。
1. 主題設定
Expressive 需要 androidx.compose.material3:material3 1.5.0-alpha 或更高版本。穩定的 1.4.0 幾乎沒有這些 API。請查閱 Maven 元資料 尋找最新的 1.5.x 版本，而不是相信記憶中的版本；Alpha API 在不同版本之間仍可能發生變化。目前的 Alpha 版本也需要 compileSdk 37 和 Android Gradle Plugin 9.1 或更高版本。
@Composable
fun AppTheme(dark: Boolean = isSystemInDarkTheme(), content: @Composable () -> Unit) {
val context = LocalContext.current
val colorScheme = when {
Build.VERSION.SDK_INT >= 31 -> if (dark) dynamicDarkColorScheme(context) else dynamicLightColorScheme(context)
dark -> darkColorScheme()
else -> expressiveLightColorScheme()
}
MaterialExpressiveTheme(
colorScheme = colorScheme,
motionScheme = MotionScheme.expressive(),
typography = AppTypography, // Google Sans Flex 語音加上可選的品牌字體，請參閱第 5 節
content = content,
)
}
- 沒有
expressiveDarkColorScheme；請使用darkColorScheme()或生成的暗色配色方案。 MaterialShapes、toShape()、LoadingIndicator和ContainedLoadingIndicator仍然需要@OptIn(ExperimentalMaterial3ExpressiveApi::class)。在 1.5.0 Alpha 版本中，此處的其他內容都是非實驗性的。- 完整設定、種子方案、自訂字型縮放、形狀變形、動態規格、間距和版本說明：在設定或變更主題時，請閱讀 references/theming.md。
2. 強調與層級
強調是指人們如何找到主要操作：更大、更關鍵的操作以及有意識的層級結構可以減少錯誤，並讓關鍵 UI 元素更快被找到 (Google)。
- 尺寸是最響亮的槓桿，而且是相對的。「最重要的操作或主要呼籲行動 (CTA) 應該是最大的元素」(Google)：更大的關鍵操作意味著更少的錯誤和更滿意的使用者，因此主要操作主導著它周圍的其他操作，無論它們的尺寸如何。內容並非要與其競爭：摘要卡片或列表行實際上可以更大。從元件的預設尺寸和最強的填充開始（一個小按鈕；對於 FAB，Google 建議「大多數情況下推薦使用中型 FAB」），然後只將其增加到足以主導同級元素為止；每個畫面只有一個焦點，當所有東西都很大時，就等於沒有重點。分組的操作預設共享一個尺寸（「同一標準組中的所有按鈕應具有相同尺寸」），而主要操作透過填充或形狀來主導：Google 的群組規則是「最大、最寬或視覺上最突出」。超大型尺寸屬於以控制項為主的英雄畫面，例如播放器或呼吸練習，其中的控制項就是畫面的內容。標籤設定了下限：Google 說「不要截斷或換行標籤文字」，且容器「不應窄於其標籤文字」。當標籤在所選尺寸下無法容納於其容器內（手機寬度的卡片、窗格）時，將其縮短為 1 到 3 個單詞，為按鈕提供更多空間，或減少一個尺寸 (Google: 尺寸可以「在不同中斷點之間」變化，而強調可以「透過尺寸、顏色或形狀」實現)。
- 位置： 將關鍵操作放在手和眼睛已經在的地方。Google 的電子郵件研究：將「傳送」從頂部欄的小圖示移到鍵盤正上方一個更大的次要按鈕，使人們找到它的速度快了 4 倍；Aura 的主畫面將其超大型開始按鈕放在底部，垂直流向的最後一個位置。根據互動方式和內容所需的空間來選擇位置 (default)。
- 主要操作獲得最強的填充 (Google: 主要角色用於關鍵的呼籲行動；謹慎使用填充按鈕)。次要操作使用色調或標準樣式；像「收藏」這樣的切換開關使用填充圖示或色調容器來顯示狀態，而不是用第二個響亮的填充與主要控制項競爭。
- 角色之間的對比，而非處處相同角色： 主要操作使用
primary，輔助控制項使用secondary或secondaryContainer，狀態或重點使用tertiary。到處都使用primary和primaryContainer會使畫面變得扁平。 - 容器化： 將相關項目分組到容器中；為最重要的內容提供「充足的空間和最明亮的表面」。
- 摘要支援任務，但不凌駕於任務之上。 當主要目標是對列表進行操作時（例如勾選習慣、回覆訊息），下一個可操作的項目必須始終是畫面上最具吸引力的東西。統計卡片可以很大膽，但要為可操作的項目行提供清晰的容器，並讓已完成的項目退居幕後（較安靜的顏色，無強填充），按狀態分組而不是交錯排列（第 8 節）。選取高亮是針對使用者的選擇，而不是針對已完成的事項。
- 工作順序： 首先建立層級（尺寸、顏色、間距、位置、容器），然後再加入獨特的強調效果（形狀、縮放、變形）來慶祝成功或進展。
Google 的實際範例：Aura 呼吸應用程式
每個畫面根據目標優先級分配強調。以此作為思考模板。
| 畫面 | 優先級 | 強調策略 |
|---|---|---|
| 主畫面 | 首要：開始一個會話 | 柔軟表面上一個深色 primary 的超大型「開始呼吸」按鈕，位於畫面底部。設定分組為 secondary 的列表項目。每日訊息放在一個柔軟的容器中，強調最少。 |
| 會話 | 英雄時刻 | 畫面大小的花朵形狀 (MaterialShapes.Flower 和 Sunny) 隨著每次呼吸在彈性動畫中成長和收縮；吸氣時呈現鮮豔的黃色；巨大的倒數數字搭配小標籤；暫停/停止按鈕小尺寸位於底部；隱藏導航列。 |
| 報告 | 次要 | 「為減少認知負荷」而使用較少的策略：統一的形狀顯示指標，強調數字，一個中型（非 XL）的「完成」按鈕。 |
| 進度 | 第三順位 | 細微：primary 顯示關鍵資料，完成的日期以小尺寸次要形狀顯示，數字「大到足以瀏覽，但不至於主導。」 |
他們從 v1 到 v2 的經驗教訓：未分組的設定具有相似的尺寸和不一致的顏色，彼此競爭注意力；將它們分組在一個超大型按鈕上方，從「雜亂無章」變成了「寧靜有序」。
3. 英雄時刻與克制
「英雄時刻使用多種表現力策略，以突破可預測或統一應用的設計概念。」
- 英雄時刻在產品的關鍵互動上疊加字體、形狀、顏色、動態和靈活的元件：例如電話撥號器、媒體播放器、已達成的目標、呼吸會話。捫心自問：它在情感上有影響力嗎？ 以及 它是關鍵互動嗎？
- 每個產品一或兩個。 它們是「短暫、愉悅、驚喜且出乎意料的」；超過這個數量會讓人感到不知所措。
- 次要畫面使用較少的策略。不要到處都結合所有策略。
- 在英雄時刻中，只有一個自訂元素會移動：在形狀動畫時保持文字穩定 (Google)。內建的元件變形（例如按鈕在按下時改變形狀）不計算在內。
- 當內容本身就是產品時，內容就是英雄。 在播放器、畫廊和旅遊應用程式中，讓專輯封面或照片具有規模，並讓其顏色設定畫面色調。資料庫形狀遮罩、滿版出血或疊加在影像上的標題都是選項，而非必要條件：當周圍的構圖承載設計意圖時，普通的圓角裁切也同樣強大。
- 保持熟悉的模式。 Expressive 為模式增添風格，而非取代它們。在 Google 的測試中，一個重新排列成散落專輯封面的播放清單「看起來現代且令人興奮」，但人們不認為它是一個播放清單；從電子郵件操作中移除文字標籤則傷害了可用性。情境也很重要：適合媒體播放器的設計不一定適合銀行應用程式。
- 「任何數量的情感都無法彌補清晰度的缺失。」Expressive 可以強化一個已經運作良好的畫面；但它無法拯救一個混亂的畫面。
4. 色彩
- 產生器創建調色盤；你來分配角色。 Material 的色彩工具將一個來源顏色轉換為強調色、表面色、淺色和深色角色 (Google)。接受生成的調色盤，並將設計心力花在決定哪個元素獲得哪個角色上。
- 動態（桌布）是 Google 的推薦，並提供個人化。M3 Expressive 的更新使動態色彩在來源處更豐富（「所有色相的彩度更高」）；應用程式會自動獲得此效果。應用程式與手機的其他部分共享色相，因此其識別度來自層級、形狀和字體。
- 品牌賦予應用程式自己的識別度：使用 Material Theme Builder 從品牌顏色生成的配色方案，或在執行時使用 MaterialKolor 以預設調色盤風格生成（主題參考）。不要為了看起來「更具表現力」而提高調色盤風格：MaterialKolor 的
PaletteStyle.Expressive是一種色相偏移的方案變體，與 M3 Expressive 無關，它會將調色盤拉離品牌的色相。 - 基於內容的色彩可以為限定區域上色…
[後續內容已截斷以利翻譯]