Material Design指南中更新的相關內容

Android 的覆蓋范圍在遞增，體驗也在變得越來越好，現(xiàn)已有超過 2.5 億臺大屏設備搭載了 Android 系統(tǒng)，包括平板電腦、可折疊設備以及 Chrome OS 設備。如何適配不同的屏幕尺寸并保障良好的體驗，一直以來都是開發(fā)者的一大難題。尤其隨著可折疊設備等新興產品的涌現(xiàn)，適配工作也愈發(fā)迫切。本文將重點介紹 Material Design 指南中更新的相關內容，并提供一些建議來幫助開發(fā)者按照自適應界面的原則來構建應用，從而解決在平板電腦和可折疊設備上的適配問題。

本文將重點討論 View 系統(tǒng)中的適配，如需了解更多有關如何利用 Compose 構建大屏幕應用的信息，請參閱文章《為任意屏幕尺寸構建 Android 界面》。

設計指南

2021 年年初，我們在 Material Design 網站上發(fā)布了針對大屏設備的指南文檔。Android 開發(fā)者峰會期間我們更新了一些內容，以幫助開發(fā)者為可折疊設備等更多其他類型的設備做好準備。

深入理解布局指南介紹了布局容器的相關概念，它提供了一個整體框架，可幫助開發(fā)者思考如何在屏幕上排列導航欄、工具欄和內容等界面元素。

指南中的組合部分帶您了解如何充分利用屏幕空間以保障可讀性，并且以尊重用戶心智模型的方式在不同的場景下合理排布重要內容和操作選項。包括適當縮放以展示更多內容，如示例中的副標題和日期，以及較小的組合技術，例如在緊湊型的布局中對內容進行視覺分組并保持其相關性等。

以 Fortnightly 示例應用為例，它在平板電腦上的界面布局十分均衡，這得益于它遵從了指南里對容器的建議。而且可以看到，F(xiàn)ortnightly 使用了視覺分隔線 (Visual Divider) 用于分隔最新新聞，在屏幕的另一邊，則利用留白和排版對不同類別的新聞報道進行分組。

網格系統(tǒng)

現(xiàn)在，許多應用將屏幕視作一個大畫布或單欄，以水平和垂直的方式按相互關系繪制元素，有些應用也會在一側整體留出邊距。這一做法在小屏上或許行得通，當屏幕尺寸較大時就會出現(xiàn)明顯的問題。網格系統(tǒng)則將您的布局劃分為一系列欄，從而幫助您在規(guī)范網格中設計更具表現(xiàn)力的布局。在布局中使用欄式網格 (如下圖)，能夠讓大屏設備的體驗呈現(xiàn)更貼心，更組織有序的印象，使得設備和內容更自然地融為一體。

您可以通過這些欄將屏幕劃分為不同區(qū)域，用于容納相關的信息和操作，進而改善信息層次結構。如下圖所示，這里分了三個區(qū)域，這些區(qū)域將按照設計者期望用戶閱讀的順序，把用戶的注意力吸引到這些區(qū)域對應在屏幕的主要信息片段或信息組上。最重要的一點是，欄式網格提供了一種合理的方式來思考當屏幕尺寸變大或變小時如何將內容進行重排，從而幫助您對不同的屏幕尺寸作出一致響應。

在本例中，三個主要區(qū)域通過重排來保持相同的信息層次結構，但以更加人性化的方式在小屏幕上顯示。

記住網格系統(tǒng)有助于您選擇組件行為，在不同的布局中，以對設備尺寸和場景最有意義的方式決定替換還是更改組件。例如，在大屏設備上，您可使用 Navigation rail (左側邊欄導航條) 代替底部導航 (Bottom navigation)，兩者功能相同，視覺表現(xiàn)方式也類似，但 Navigation rail 能夠更加人性化地排布頁面。手機上的全屏對話框 (Full-screen dialog) 在大屏幕上可以采用簡單對話框 (Simple dialog) 替代，以保持用戶當前操作的上下文。

尺寸類別

請記住，替換組件時，首先要滿足用戶的功能性和人性化需求。找到調整界面的正確閾值，這是實現(xiàn)響應式界面的重要步驟。因此我們定義了新斷點值，這有助于將設備劃分到預設的尺寸類別中，這些尺寸代表了市場上實際設備的尺寸。它們有助于將應用版面的原始尺寸轉換為離散的標準化組，您可以據(jù)此做出更高層次的界面決策。例如，幾乎所有標準手機在豎屏模式下都采用了較小 (Compact) 寬度和中等 (Medium) 高度的組合，由于普遍使用垂直滾動，對大多數(shù)應用而言，根據(jù)寬度的尺寸類別進行適配就已足夠。

這些尺寸類將作為新的 API 出現(xiàn)在 1.1 版 Jetpack Window Manager 庫中。從 Android Studio Bumblebee 開始，我們還以參考設備 (Reference devices) 的形式，將尺寸類別整合到工具中，在此基礎上實現(xiàn)界面有利于保持一致性，操作也更加簡單。而且開發(fā)者不需要去檢查實際物理尺寸或屏幕方向，或其他容易出錯的標識。您在設計和構建不同的尺寸類別時，請想想人們會如何手持和觸摸這些類別所代表的設備。關注設備的形狀和尺寸，有助于您打造出更加人性化的體驗。例如，在平板電腦或大屏手機上，如果不完全調整握持姿勢，人們可能很難觸及屏幕的頂部區(qū)域，因此請將重要操作和內容放在容易觸及的區(qū)域中。

規(guī)范布局提供了一系列通用布局方案，對設計大屏幕應用非常有幫助。第一種是列表/詳情，或列表網格視圖的簡單組合，同時在開始展示內容的屏幕起始側，設置/不設置導航容器。

支持面板可用于人們需要集中精力的體驗中，例如文檔。在屏幕尾側或底部添加一塊面板，以便于使用工具或上下文控件。

信息流是新聞或社交類應用中的常見模式，模板采用圖塊 (Tile) 的形式來吸引用戶發(fā)現(xiàn)更多內容。這種交互與移動手機一樣——打開一項即表示打開一個新頁面，但這種體驗更具沉浸感，而且專為大屏幕尺寸而設計。

主頁橫幅優(yōu)先將內容排列在屏幕頂部，并在內容周圍和下方設計了支持元素，這對以媒體為中心的應用來說，是非常棒的體驗。

規(guī)范布局實踐

采用響應式界面不僅僅是為不同屏幕尺寸提供并行結構，應用還要足夠靈活，這樣才能根據(jù)各種需要調整尺寸，例如旋轉設備、多窗口模式以及折疊和非折疊姿態(tài)。因此在運行期間，應用可從一個尺寸類別過渡到另一個尺寸類別，并再次過渡回去。重要的是，不要將尺寸類別視作完全獨立的桶，應用也需保證連續(xù)性 (即不中斷用戶體驗)，所以應用狀態(tài)或數(shù)據(jù)不能丟失。

設想一下，當您調整瀏覽器窗口大小時，如果瀏覽器回退了一個頁面，或者重定向到另一個頁面，又或者修改了歷史記錄，這種體驗非常奇怪。因此，每個頁面都應足夠靈活，而且應當能夠在尺寸過渡期間保持狀態(tài)不變，這個時候規(guī)范布局就能發(fā)揮重要作用。針對每個頁面，您可以思考一下，當屏幕尺寸變大時，可以添加什么內容。當屏幕尺寸變小時，可以刪除哪些內容。然后再選擇合適的策略。這可能意味著您需要重新審視導航圖，尤其是當您目前的設計以手機為主時更應如此。

如需構建響應式界面，我們應該優(yōu)先考慮界面中長駐元素的位置，例如導航元素。遵循 Material 指南，我們可以根據(jù)寬度的尺寸類別提供替代布局，將導航調整到最方便使用的位置。例如，小屏幕采用底部導航視圖，中等屏幕采用 Navigation rail，大屏幕采用完整導航視圖。請大家注意，這些布局采用的是寬度限定符 "-w"，而非最小寬度限定符 "-sw"。剩余空間用于排列內容，我們可以在這些空間應用規(guī)范布局。

列表/詳情

對列表/詳情而言，AndroidX 中有個名為 SlidingPaneLayout 的專用控件，使用前需為它的兩個子元素指定 layout_width，在運行期間，SlidingPaneLayout 會判斷是否有足夠空間同時展示兩個窗格:

…><>      <>              android : id=”@+id/list_pane”              android : layout_width=”300dp”              android : layout_weight=”1”              …  />
      <>              android : id=”@+id/detail_pane”              android : layout_width=”360dp”              android : layout_weight=”2”

當屏幕空間足夠，則兩個窗格至少都要達到指定的寬度，剩余空間可通過 layout_weight 分配，如左圖所示;如果空間不足，如右圖所示，則每個窗格都使用父視圖的全寬，詳情窗格將被滑到一邊，或直接覆蓋第一個窗格。

viewModel.selectedItemFlow.collect { item ->// 更新詳情窗格的內容detailPane.showItem(item)// 將詳細信息窗格滑動到視圖中// 如果并排放置兩個窗格// 并不會產生實際效果slidingPaneLayout.openPane()}

如上代碼所示，您可以通過代碼控制滑動窗格，當用戶從列表中選擇一個項目，我們從 ViewModel 的 Kotlin 流中接收到該項目，然后更新詳情窗格的內容，并通過調用 openPane 將其滑入視圖。在 Trackr 應用中效果如下圖所示:

關于如何使用 SlidingPaneLayout 實現(xiàn)雙窗格布局的相關內容，請參閱 Android 開發(fā)者網站: 創(chuàng)建雙窗格布局，該頁面還介紹了其他內容，例如集成系統(tǒng)返回按鈕以實現(xiàn)側滑回退窗格等。

信息流

我們可以通過信息流沉浸式地展示一個數(shù)據(jù)集，因此 RecyclerView 是非常適合的選擇，我們可以通過改變 RecyclerView 使用的 LayoutManager 來改變其展現(xiàn)形式。LinearLayoutManager 適合用于較小型寬度，但在中等寬度和展開型寬度場景下，頁面內容則會出現(xiàn)過度拉伸和變形的情況，這時改用 GridLayoutManager，或 StaggeredGridLayoutManager 甚至 FlexBoxLayoutManager，可能會更合適。

主頁橫幅

我們還可以改變單項布局，使某些項比其他項更高或更寬，以此凸顯其重要性，打造更有趣的視覺效果。在主頁橫幅布局中，我們強調某個特定元素，重新排布它周圍的其他支持元素。當然我們有很多方法可以實現(xiàn)這一點，但 ConstraintLayout 的靈活性最大，因為它提供了很多種方式來約束子元素的尺寸，以及相對于其他子元素的位置。在如下媒體類示例應用，它的首圖限制在 16:9 的寬高比內，描述窗格占 60% 寬度，剩余空間留給其他元素。約束條件可以改變甚至還可以用 MotionLayout 設置動畫，它是一個特殊的 ConstraintLayout。

對于支持面板而言，從 LinearLayout 到 ConstraintLayout 的任何布局控件，都可以當作容器來定位面板。我們考慮一件事，當過渡到小屏幕尺寸時，面板上的內容應該放在哪里。我們有許多可選方案，比如使用屏幕尾側的側邊抽屜式導航欄，或者使用上滑式底部動作條，或者使用選項菜單，甚至可以將內容完全隱藏起來。

適配可折疊設備

可折疊設備不僅配備了更大的屏幕，它們還可以根據(jù)設備的折疊方式和用戶的使用方式調整設備的方向/姿勢。

目前有三種常見的設備形態(tài): 折疊、未折疊和桌面模式 (懸停)。另外，我們稍后也將看到其他理論上存在的狀態(tài)，例如書本模式。

與其他大屏幕設備一樣，我們需要多想想用戶會怎樣握持未折疊設備?如平板電腦，部分屏幕區(qū)域難以用大拇指觸及，用戶也很難騰出整只手來自由操控屏幕。用戶輕易就能觸及屏幕的底部角落，但可能無法觸及屏幕最頂端，尤其是在豎屏模式下。這意味著如果您使用 Navigation rail 這類組件，將導航按鈕居中或固定在屏幕底部，這會更便于用戶的操作。

同時，我們還需要考慮鉸鏈位置對交互的影響。鉸鏈會帶來明顯的觸覺差異，甚至兩個屏幕會存在物理分離。因此，請您避免將按鈕和其他重要操作項直接放在鉸鏈區(qū)域。大多數(shù)設備上的鉸鏈區(qū)域寬度約為 48 dp，在桌面模式下也請避免將界面元素放在鉸鏈區(qū)域，因為在這種設備模式下，用戶幾乎無法使用該區(qū)域的任何功能。

當設備從折疊模式轉換到非折疊模式時，有兩種主要的技術方案可用于設計布局。第一種是擴大屏幕，該方案采用了一種簡單的響應式布局，在該布局下應用會擴展內容并填充到屏幕上。通常情況下，我們會根據(jù)前面提到的 Material 指南來擴展欄式網格:

第二種是增加另一個頁面，根據(jù)您構建的應用不同，可以采用與列表/詳情或者以另一個面板補充主面板功能相同的方案。

在這兩種情況下，根據(jù) material.io 的指南，您需要創(chuàng)建一個平均分布在鉸鏈區(qū)域兩側的八欄網格，當添加 Navigation rail 等導航容器時，屏幕起始側會被壓縮以容納導航容器。

適配示例

現(xiàn)在我們來看如何在運行期間利用好折疊狀態(tài)。Jetpack Window Manager 庫提供了相應的 API，可以檢測應用窗口是否存在折疊。任何 Activity 都可以獲得一個 WindowInfoRepository 實例。然后，在 Started 和 Stopped 這兩種生命周期狀態(tài)之間，我們可以安全地從窗口布局信息流中收集信息。每當流發(fā)射一個值時，我們都可以檢查 displayFeature，然后有針對性地尋找 FoldingFeature。

override fun onCreate(savedInstanceState: Bundle?) {        super.onCreate(savedInstanceState)
        val windowInfoRepo = windowInfoRepository()
        // 在 STARTED 和 STOPPED 這兩種生命周期狀態(tài)之間安全地從 windowInfoRepo 中收集數(shù)據(jù)        lifecycleScope.launch(Dispatchers.Main) {            lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) {                windowInfoRepo.windowLayoutInfo.collect { info ->                    for (feature in info.displayFeatures) {                        val fold = feature as? FoldingFeature ?: continue                        // 使用 FoldingFeature                    }                }            }        }}

掌握了折疊姿態(tài)的相關信息后，我們可以通過一些方法來查看設備是否處于前面提及的某種姿態(tài)。在書本模式下，設備的狀態(tài)為 HALF_OPENED，且其方向為 VERTICAL;在桌面模式下的狀態(tài)為 HALF_OPENED，且其方向為 HORIZONTAL。

// 書本模式是半打開的垂直折疊模式fun FoldingFeature.isBookMode() =    state == FoldingFeature.State.HALF_OPENED &&        orientation == FoldingFeature.Orientation.VERTICAL
// 桌面模式是半打開的水平折疊模式fun FoldingFeature.isTableTopMode() =    state == FoldingFeature.State.HALF_OPENED &&orientation==FoldingFeature.Orientation.HORIZONTAL

FoldingFeature 中還包含窗口中的折疊位置，當折疊導致內容視圖被割裂時，我們應該及時更新布局參數(shù)。您可以做些調整，比如將支持面板置于一側，或者在折疊的上半部分展示主頁橫幅。首先，我們需要知道內容視圖在窗口中的位置，通過 getLocationInWindow 可以獲取位置信息。我們將使用這些坐標以及寬度和高度創(chuàng)建一個 Rect 對象，這樣我們便得到了窗口坐標空間中的視圖邊界。

FoldingFeature 給出了在窗口的坐標空間中的折疊邊界，因此我們可以直接檢查這兩個區(qū)域是否相交，如果相交，我們可以將 featureRect 的邊界轉換為視圖的坐標空間并將其返回。順便說一下，如果您使用 SlidingPaneLayout 來實現(xiàn)列表/詳情布局，您會自動獲得對書本模式的支持。只要兩個窗格都能容納進去，SlidingPaneLayout 會將窗格置于折疊姿態(tài)的另一側。

fun getFoldBoundsInView(       foldingFeature: FoldingFeature,       view: View): Rect? {       // 獲取視圖在窗口坐標空間中的邊界       val viewLocation = IntArray(2)       view.getLocationInWindow(viewLocation)
       val (viewX, viewY) = viewLocation       val viewRect = Rect(           left = viewX, top = viewY           right = viewX + view.width, bottom = view + view.height       )    …
       //顯示功能的邊界已經在窗口的坐標空間中       // 檢查 view 的邊界和顯示功能的邊界是否相交       val featureRect = Rect(foldingFeature.bounds)       val intersects = featureRect. intersect (viewRect)
       if (featureRect.isEmpty || ! intersects)           return null       }
       // 將功能的邊界坐標轉換為 view 的坐標空間       featureRect.offset(-viewX, -viewY)       return featureRect}

測試

如果您的應用存在與折疊狀態(tài)相關的特殊行為，您需要為此編寫單元測試。Jetpack Window Manager 里面有一條測試規(guī)則，支持在插樁測試期間模擬 FoldingFeature。由于測試需用到視圖，我們添加了 WindowLayoutInfoPublisherRule，以及 ActivityScenarioRule，兩者一起組成了一個測試規(guī)則鏈。在該測試方法中，我們通過 activityRule 獲取 Activity，然后創(chuàng)建窗口特性來模擬桌面模式，構建 WindowLayoutInfo 對象并使用 publisherRule 發(fā)布該對象。之后，我們可以使用 Espresso 和 JUnit 斷言來檢查 Activity 在桌面模式下能否正常運行。

private val publisherRule = WindowLayoutInfoPublisherRule()private val activityRule = ActivityScenarioRule (MyActivity: :class.java)
@get :Ruleval testRule = RuleChain.outerRule (publisherRule) .around(activityRule)
@Testfun testDeviceOpen_TableTop(): Unit = testScope.runBlockingTest {    activityRule.scenario.onActivity { activity ->        val feature = FoldingFeature (activity, HALF_OPENED, HORIZONTAL)        val testWindowInfo = WindowLayoutInfo.Builder( )                .setDisplayFeatures (listOf (feature))                .build()
        publisherRule.overrideWindowLayoutInfo(testWindowInfo)    }        // 編寫基于桌面模式的斷言}

界面測試存在一定難度，因為有些測試須在特定設備上進行。為此，Android Studio 正在增加對 Gradle 托管的虛擬設備的支持。您可以使用 7.1 及以上版本的 Android Gradle 插件來體驗該功能。

在應用級的 build.gradle 文件中的 testOptions 模塊下，指定虛擬設備配置文件，就像您平時在 Android Studio 管理和運行虛擬設備那樣。例如，這里使用的是 Pixel C 平板電腦鏡像，接下來 Gradle 會創(chuàng)建能夠在指定設備上執(zhí)行測試的目標，甚至還能根據(jù)需要下載設備鏡像。

android {    testoptions {        devices {            pixelCapi30 (ManagedVirtualDevice) {                device = "Pixel C" // 平板電腦設備                apilevel = 30                systemImageSource = "aosp" // 如需 GooglePlay 服務，使用 “google”                abi = "x86”            }        }    }}
#Gradle target = {device name} + {build variant} + "AndroidTest"./gradlewpixelCapi30debugAndroidTest

為便于區(qū)分哪些測試是針對哪些設備的，我們將創(chuàng)建自定義注解 LargeScreenTest，并用該注解來標記測試函數(shù)。運行前面的 Gradle 命令時，我們會為 AndroidTestRunner 添加一項參數(shù)，確保只運行具有此注釋的測試。若您不使用注釋，也可以使用 TestRunner 的其他過濾選項，比如運行特定類中的測試。將這些特性加以組合，我們可以為測試設置一致運行配置。

annotation class LargeScreenTest
@RunWith(AndroidJUnit4: :class)class MyActivityTest {
    @Test @LargeScreenTest    fun largeScreenDeviceTest() {        // 在平板電腦設備上測試界面    }}
# 只運行帶有指定注解的測試. /gradlew pixelCapi30debugAndroidTest -Pandroid.testInstrumentationRunnerArguments.annotation=com.mypkg.LargeScreenTest

更多信息

除了讓屏幕上的內容看起來更大之外，大屏幕還帶來了一些其他機會，幫助您的應用大放異彩。在多窗口模式下，您的應用可以與其他應用并排使用，除了響應式調整之外，還可以考慮如何讓應用在這種模式下發(fā)揮更大作用，比如支持拖拽等。這種小功能可以提高用戶的工作效率，用戶便更樂意使用您的應用。

多窗口模式

除了通過觸摸進行交互外，大屏幕設備還支持其他交互形式。設備的屏幕尺寸越大，用戶就越有可能使用鍵盤、手寫筆、鼠標、游戲手柄或其他外接設備。如果您想提高應用在這些情況下的易用性，可以計劃支持其中一些輸入方式，如需了解更多詳情，請參閱文章《是時候為各式設備適配完善的輸入支持了》。

在如此多樣化的硬件生態(tài)系統(tǒng)中，您可能很難擁有各種形狀和尺寸的設備，如今 Android SDK 為可折疊設備提供了模擬器圖像，這些模擬器允許您隨時將折疊狀態(tài)更改為鉸鏈的角度。即將推出的 Android Studio Chipmunk 也會配備可調整尺寸的模擬器，允許您自由改變應用窗口的尺寸，每個開發(fā)者都可以在幾乎任何類型的設備中試用他們的應用。

我們也一直在 Android Studio 中開發(fā)新工具，希望為大家開發(fā)大屏幕應用提供支持。新的 Layout Validation 工具可以在覆蓋了各種尺寸類別的參考設備上預覽布局，并提示問題區(qū)域 (例如文本使用了長行)，以及為不同斷點推薦不同界面組件。

最后，我們在 Android 開發(fā)者網站上列出了針對大屏幕的應用質量指南，指南中的前面部分介紹的是基本兼容性預期，比如應用是否同時支持橫屏和豎屏模式，后面幾部分重點介紹支持各種屏幕類型和狀態(tài)，并使用特定屏幕類型或狀態(tài)打造不同的體驗。

我們希望大家都能夠利用今天分享的內容，并參考新的質量指南，構建出在各種屏幕尺寸下都能讓用戶心動的應用。

原文標題：折疊屏上應用設計規(guī)范，了解一下?

文章出處：【微信公眾號：谷歌開發(fā)者】歡迎添加關注!文章轉載請注明出處。

審核編輯：湯梓紅