隨著智慧終端硬體的不斷革新，大尺寸裝置的種類越來越豐富，比如手機、摺疊屏裝置、平板電腦、ChromeBook、外接顯示器的 ChromeBox 和整合螢幕的 Chromebase 等。Google 團隊正在將更多研發精力投入到 Android 框架、Jetpack 和 Chrome 作業系統中。
△ Android 12L 和 Jetpack 增加了新的 API 和功能，使您的 APP 外觀更精美，功能更強大。
請繼續閱讀，檢視 Android 系統和 Chrome OS 對大螢幕裝置的支援的更新！
如果您更喜歡通過視訊瞭解此內容，請在此處檢視:
https://www.bilibili.com/vide...
△ Android 與 Chrome OS 中針對大螢幕裝置的更新
Android 12L
如下圖所示資料可以發現，使用者對更大螢幕空間的需求在不斷增長，僅 2020 年一年 Android 平板電腦的銷量增加 1 億臺，Chrome 作業系統增加超 92%。目前在使用的大螢幕 Android 裝置超過 2.5 億，所以這就需要應用針對這類裝置進行相應的適配。為了能夠適應日益增長的裝置數量和使用者需求，我們推出了針對大螢幕裝置的 Android 12L (下文簡稱 12L)。
△ 大螢幕裝置正在逐步成為主流 1 億新增 Android 平板電腦資料來源: 2021 年第二季度: IDC 單季度個人計算裝置跟蹤
一直以來，我們都與開發者緊密合作，及時瞭解他們針對大螢幕開發的需求以及上游裝置製造商的實時動向，並行改進功能和 API，這些更新將在 2022 年初落地，使 Android 12 能夠更好地執行在這些大螢幕裝置上。12L 包含多個專門針對開發者的優化，包括更出色的多工處理，重新設計的外觀以充分利用螢幕空間，同時還增加了相容模式，以確保在小螢幕手機上也可以正常執行。
多工處理
從 Android 12 開始多工處理已經成為日常操作，所有應用均可以在多視窗模式下執行。但是需要注意的是應用可能以分屏模式執行或以視窗形式出現在另一個應用旁邊。
在以下場景中尤其要注意:
- 自行渲染介面元素或需要特定的視窗尺寸；
- 應用需要訪問獨佔硬體裝置，比如攝像頭和麥克風。
多視窗模式
△ 多視窗支援相較之前更易訪問
為了支援多工處理，Android 12L 更新了介面，包括經過改進的供應用切換的工作列。我們都知道過去使用者要進入分屏模式的操作比較繁雜。全新的工作列簡化了應用之間的快捷切換方式，並且可以輕鬆返回主螢幕。
導航按鈕
△ 三按鈕導航相較之前更易訪問
在螢幕較大的裝置上，工作列可以很方便地將應用轉為分屏模式或者多視窗模式。這是因為所有應用無論是否宣告尺寸可切換，都可以在分屏模式或者單獨視窗下執行，所以有必要更新您的應用以適配尺寸變化，同時避免應用重啟或者進入相容模式。工作列還將三按鈕式導航欄移至螢幕一側，以方便使用者手持大螢幕裝置操作。
系統介面
△ 系統介面 — 現代化的外觀和質感
Android 12L 還帶來了多項系統介面相關的使用者介面更新。包括優化主螢幕佈局，大幅調整通知外觀和風格，加入了彈出視窗，使 PIN 碼輸入更加簡單。您無需採取任何操作就可以在應用中自動採用新的系統外觀。此外，我們還在更新設定、設定嚮導等系統應用，從而更好地利用螢幕空間。
改進的工作列
△ 優化體驗後的工作列 — 為了更好的應用切換體驗
為了能夠提升應用切換的體驗，我們優化了工作列。使用者可以快速實現應用切換、回到主螢幕等操作。在螢幕較大的裝置上，工作列可以拖動應用進入分屏和多視窗模式。
相容模式
△ 相容模式 — 穩定性和視覺提升
如果您的應用鎖定為橫向或者縱向模式，並且無法調整大小，那麼當使用者進入分屏、開啟摺疊裝置，亦或是在 ChromeOS 那樣的多視窗環境下，應用也能以相容模式顯示。從而確保應用外觀和功能能夠按照最初的效果呈現。
我們正在更新功能和相容模式下的樣式和呈現效果，雖然這些可以使使用者繼續使用那些不可改變尺寸的應用，並且也能夠和系統相契合，但是仍然無法提供理想的使用者體驗，而是否對應用做出優化的決定權在您手上。
Play 商店更新
△ Play 商店更新 — 展示適配大螢幕的應用
我們還針對 Play 商店做出了一些改進，幫助使用者找到適合大螢幕的最佳應用。
首先，我們正在將大螢幕裝置應用的評分和評論功能獨立出來；其次，我們正在針對應用的可變尺寸的功能和大螢幕上的佈局方面，優化我們的質量檢驗流程；最後，我們將對輸入的支援以及其他針對大螢幕的功能進行研究。通過這些途徑，我們就能為使用者挑選出能夠面向他們的裝置提供最佳體驗的應用。我們計劃在 2022 年推出這些改進屆時大家可以更加詳細地瞭解這部分內容。
如需要更多資料，請參閱如下文章:
Android 12L 的可摺疊屏模擬器
△ Android 12L/可摺疊模擬器 developer.android.google.cn/12L
12L 功能投放包含全新 API 以及新的 SDK 級別，即 32 級，方便您快速定位新功能。請注意，Play 商店每年增加目標 SDK 的要求，僅適用於 Android 12，即 SDK 31，不會強制要求您升級為 32。
今天就開始測試這些新功能和 API 吧，獲取 Android 12L 開發者預覽版，讓您的應用準備好迎接即將釋出的公開版本。您也能在 Android Studio 模擬器 中使用 12L 系統映像，嘗試分屏、摺疊和旋轉事件。確保應用在整個使用者使用過程中都能保持美觀。
很快大家就能使用 Lenovo P12 Pro、Samsung Galaxy Z Fold 3 測試這些功能。12L 功能的更新振奮人心，我們也期待著在今後的 Android 版本中加入更豐富的功能以及對大螢幕裝置更多的支援，我們將繼續努力讓 Android 成為更好的作業系統，為使用者和開發者提供更優質的服務。
Jetpack WindowManager
Jetpack WindowManager 是提供向後相容 API 的庫，能夠適配視窗規格和尺寸，還能提供關於顯示功能詳細資訊，比如摺疊、鉸鏈和裝置配置。本文將會講解庫中可用的穩定 API，還會介紹當前和未來版本中的一些全新實驗工具從而讓您的應用在大螢幕上顯得美觀。該庫採用了 12L 的最新功能，但也相容之前平臺版本，低至 API 級別 14。
WindowMetrics
△ 為任意螢幕尺寸構建 Android 介面
首先介紹 WindowMetrics。Android 11 引入了一套新的 WindowManager API，能夠給出應用當前執行視窗的準確測量資料。在大螢幕裝置上，由於使用者對於分屏和其他多視窗形式的使用頻率越來越高，您的應用很可能不會佔據整個螢幕。在 Samsung Galaxy Z Fold 系列手機中，我們發現其在分屏使用率上高達七倍於其它手機的現象。另一個例子是當大螢幕手機處於不同方向時，視窗帶有黑邊。使應用能夠在尺寸上完全可變是非常重要的，我們會大篇幅來討論這個主題。
那麼如何確定 Activity 的尺寸呢？
class MyActivity : Activity() {
override fun onConfigurationChanged(newConfig: Configuration) {
super.onConfigurationChanged(newConfig)
val windowMetrics = WindowMetricsCalculator.getOrCreate()
.computeCurrentWindowMetrics(this)
}
}WindowMetrics API 可以在所有可能的狀態下返回視窗的準確畫素尺寸，而且向下相容至 SDK 級別 14。如果使用者擴充套件了應用的顯示，它還會提示您可配置的最大尺寸，以便開發者選擇合適的資源提前載入。請記住，WindowMetrics 可在執行時更改，因此建議值更新時機為最初建立 Activity 的時候以及使用 WindowMetricsCalculator 更改配置的時候。請不要使用已經棄用的顯示相關的 API，比如 "getRealMetrics" 或者 "getRealSize"，否則您可能會得到異常的尺寸值。
WindowSizeClasses
在所有裝置型別上都能夠將應用直觀呈現給使用者的另一個關鍵要素是提供不同的佈局。我們從大家的反饋中瞭解到在紛繁複雜的裝置生態系統中，能夠清楚地知道針對哪種螢幕尺寸進行開發是非常困難的。
△ Jetpack WindowManager 中的視窗尺寸類
現在 Jetpack 增加了 WindowSize 類，使得這一困難迎刃而解。該功能引入了獨具特色的佈局斷點 (layout breakpoint) 可以幫助您瞭解如何適配介面。當需要針對不同的裝置型別選擇合適的佈局時或者在多視窗模式下需要響應視窗的變化時，就需要用到 WindowSize 類。
之前在豎屏模式下，使用者大多數時間僅僅操作一個應用，但是平板電腦通常是橫屏模式。而對於可摺疊裝置和不同的多視窗模式，應用經常需要在單次會話中將視窗尺寸變大或者變小。所以需要滿足儘量多的場景。如果您希望瞭解 WindowManager Jetpack 1.1 相關功能，請查閱我們的推文《為任意螢幕尺寸構建 Android 介面》。
可摺疊螢幕
△ 可摺疊螢幕
其中的創新潛力很大，特別是針對可摺疊裝置。隨著市場上此類裝置數量逐漸增加，您可以更進一步，不僅使應用能夠相容大螢幕，而且在應用正在執行的情況下，當使用者摺疊或展開裝置時，應用能夠適配裝置不同的狀態。
支援不同的模式能夠為應用帶來新的互動方式以及新的使用體驗。例如，現在的可摺疊裝置常放置於桌面使用，非常適合觀看視訊或接聽擴音電話。裝置的放置方式使螢幕的一部分處於舒適的觀看角度，而螢幕的另一部分則放在平穩的檯面上，使其非常適合各種互動元素。
FoldingFeature
△ FoldingFeature
我們來看看 API 庫能為您提供哪些幫助。您可以使用 FoldingFeature 判斷裝置的姿態。該類用於監測可摺疊裝置的狀態，並且使用特徵型別、螢幕方向和狀態更新介面在必要時更新周邊的介面。
val windowInfoRepo = windowInfoRepository()
lifecycleScope.launch(Dispatchers.Main) {
lifecycle.repeatOnLifecycle(Lifecycle.State.STARTED) {
windowInfoRepo.windowLayoutInfo
.collect { newLayoutInfo ->
updateCurrentState(newLayoutInfo)
}
}
}有兩種可能的狀態: 平開與半開。平開狀態下螢幕完全展開成平面，但某些情況下螢幕依然被鉸鏈分割而並非連續整體。而半開狀態下，視窗始終包含至少兩個邏輯區。功能佈局資訊通過 WindowInfoRepository 提供。要開始或停止監聽事件，可使用生命週期作用域，在 Activity 可見時進行追蹤。之後，您可以使用 windowLayoutInfo 物件中可用的資訊更新應用佈局。
private fun isTabletopPosture(foldFeature: FoldingFeature) =
foldFeature.state == FoldingFeature.State.HALF_OPENED &&
foldFeature.orientation == FoldingFeature.Orientation.HORIZONTALFoldingFeature 包含鉸鏈螢幕方向和狀態等資訊。可使用這些值來判斷裝置是處於桌面模式，還是鉸鏈平放的半開模式。如需瞭解更多詳情，請查閱文件瞭解 摺疊裝置構建的完整指南。
測試 WindowManager
為了長期保持此類新型佈局簡單易用，我們還在 JetpackWindowManager 加入了新的測試 API。還在庫中引入專門的視窗測試模組。
val testFeature = FoldingFeature(
activity: Activity,
center: Int = -1,
size: Int = 0,
state: State = HALF_OPENED,
orientation: Orientation = VERTICAL,
)
val expected = WindowLayoutInfo(listOf(testFeature))這個示例展示了建立主要類相關的測試例項。注意 Activity 是 FoldingFeature 函式的唯一引數沒有預設值。當前測試 FoldingFeature 的預設配置螢幕中間水平佈局為半開狀態。
private val activityRule = ActivityScenarioRule(TestActivity:class.java)
private val publisherRule = WindowLayoutInfoPublisherRule()
@get:Rule
public val testRule: TestRule
init {
testRule = RuleChain.outerRule(publisherRule).around(activityRule)
}WindowLayoutInfoPublisherRule 可用於測試介面以及介面如何響應 FoldingFeatures。可以將其關聯至 ActivityScenarioRule。但是應用上架規則不能完全替代在裝置上進行的端到端測試。比如，真實裝置可能會更新螢幕方向視窗布局資訊。但如果使用 publisherRule，就必須自行更新視窗尺寸和視窗布局資訊。
@Test
public fun testMyFeature() {
val feature = WindowLayoutInfo(emptyList())
publisherRule.overrideWindowLayoutInfo(feature)
activityRule.scenario.onActivity { activity ->
//應用相關測試
}
}測試規則設定完成後，可使用 overrideWindowLayoutInfo 方法替換當前佈局資訊物件。
Activity 巢狀
我們認識到轉換現有舊版程式碼庫使其支援大螢幕可能困難重重。對於長期以來針對單一螢幕進行開發使用 Activity 的應用，通過 Fragments 或其他工具切換為多窗格佈局可能需要大幅重構，消耗大量團隊資源。為了使轉換更加容易，我們推出了 ActivityEmbedding，這是一套 WindowManager Jetpack 功能集，可用於在目前主流大螢幕裝置端靈活組織 Activity 視窗。
並排顯示的 Activity
△ Jetpack WindowManager 中的 Activity embedding
它的初版介面實現專注於通過在多列布局中並排顯示 Activity 從而充分利用大螢幕空間。例如，您可以通過獨立的 Activity 顯示這些列表和詳細資訊，不過您可能希望在大螢幕上顯示這些內容。雖然我建議您以單一 Activity 的方式重構應用，不過能理解，這麼做的成本非常高。該功能讓您能夠利用現有應用結構來優化大螢幕佈局。而且最令人興奮的是採用該功能只需略微調整程式碼，某些情況下程式碼甚至無需調整。
△ 小螢幕和大螢幕
我們來詳細看一下。該功能在設計之初就考慮到相容性。基於可用螢幕空間以及您提供的設定，庫可以自動選擇合適的展示型別，從而避免了分支應用內導航程式碼就能處理不同部分中的大小螢幕。該庫還支援執行時螢幕和視窗尺寸變更，如果使用者摺疊或展開裝置或在多視窗模式下重新調整視窗大小，展示將會自動更新，您無需額外操作。
Activity 堆疊
△ Activity 堆疊
我們還會遵循應用中 Activity 的現有排序，識別每個分塊中的主副、兩個容器或 Activity 堆疊。副容器始終位於主容器之上。如果螢幕空間較小 Activity 堆疊還與平常一樣；但如果空間足夠，兩個堆疊就可以並排顯示。
下面通過示例展現如果副容器中有多個 Activity，會發生什麼狀況？
△ Activity 堆疊
他們會自動出現在啟動時的相同邊界之內。現有的 Activity 啟動和預期解析度規則同樣適用。
△ 多重深度層級
庫還支援多層次導航，建立多個分塊，最多顯示兩個窗格。開啟新窗格時，之前建立的窗格將移至螢幕外。此示例中，如果現有分塊顯示 Activity A 和 B，而您需要將新的 Activity C 在一側顯示，則會建立第二個分塊顯示 B 和 C。同樣，容器的 Z-Order 依然認為在頂部。
△ 螢幕尺寸變化
這樣的順序意味著使用者關閉可摺疊裝置，繼續使用應用時您可以重新調整容器的大小和位置保持 Activity 的順序。副堆疊中的頂部 Activity 會自動擴充套件，但如果使用者展開裝置，可隨時再次並排顯示。
△ 佔位符
這是另一個不同的用例，我們稱之為「佔位符」。有時應用會在主頁顯示頂級導航列表，使用者做出選擇前沒有輔助內容可顯示。然而，為了充分利用可用空間，也出於一致性考慮，應該在應用開啟後立刻顯示分塊，此時輔助內容大部分留空。同時，如果在較小的螢幕上開啟應用，並且在裝置摺疊之後，我們不希望在頂部顯示空白頁。
我們在庫中新增了一個專門的選項來支援佔位符的使用場景，來一起看一下如何在應用中整合該功能。
分塊規則
<SplitPairRule>
<SplitPairFilter
window:primaryActivityName=”.ActivityA”
window:secondaryActivityName=”.AcitvityB” />
</SplitPairRule>首先，在構建檔案中宣告庫依賴；然後，在 assets 中建立一個 XML 檔案並提供規則定義: 哪些 Activity 應該分塊，以及分塊的屬性。
此示例中，當 B 在 A 之後被開啟的時候，我希望把 Activity A 和 B 放入分塊中。為了實現這一點，我使用預設配置新增了一個單獨的分塊配對規則，再加入一個過濾條件用於匹配 Activity 元件名稱。Activity B 從 A 中啟動後，會核對並匹配過濾器，並且庫會自動建立新的分塊。
我們針對不同的場景提供了不同型別的規則，從而給您一定的靈活性。您可以在我們的文件中找到更多的相關資訊，另外，也可以使用執行時 API 按需新增或移除規則。
配置
接下來，我們需要將規則定義告知庫。此示例中，我們使用的是 Jetpack AppStartup 庫。此示例中，在其它上傳元件和 Activity 啟動之前，我們使用 Jetpack AppStartup 庫進行初始化。要實現這一點，我們需要在構建檔案中新增庫依賴，並且在 AndroidManifest 中新增以下條目。這裡我們指定所使用的 initializer 類。
<provider
android:name=”androidx.startup.InitializationProvider”
android:authorities=”${applicationId}.androidx-startup”
android:exported=”false”
tools:node=”merge”>
<meta-data
android:name=”example.SplitInitializer”
android:value=”androidx.startup” />
</provider>最後，新增 initializer 類的實現。如果您已經在應用中使用 AppStartup，那麼應該比較熟悉這樣的結構。
class ExampleWindowInitializer : Initializer<SplitController> {
override fun create(context: Context): SplitController {
SplitController.initialize(context, R.xml.main_split_config)
return SplitController.getInstance(context)
}
override fun dependencies(): List<Class<out Initializer<*>>> {
return emptyList()
}
}要設定規則，可向 SplitController.initialize 提供 XML 資源 ID 和定義。
大功告成！庫將會追蹤在您的程式碼庫中不同位置啟動的 Activity，檢查所用到的 intent 以及啟動這些 Intent 的 Activity，如果找到匹配規則，會建立新的分塊，並由庫進行管理。
在最新版的 WindowManager Jetpack 擴充套件的大螢幕裝置上會提供該功能。
現在就能在 12L 模擬器中使用，而且很快就能在 Samsung GalaxyZ Fold 3 等真實裝置上找到它。在不支援該功能的裝置上顯示方式還會和之前一樣，Activity 仍然會堆疊顯示，互相完全覆蓋，因此無需擔心尚未支援的裝置會出現顯示異常。
如果您需要知曉該功能是否可用，可使用專用的執行時 API。我們也在嘗試其他與多屏顯示裝置相關的互動方式。具體實現程式碼，請參閱 WindowManager Jetpack Demo。
後側屏顯示模式
△ 後側螢幕顯示模式
一個酷炫的例子是後側螢幕顯示模式可在裝置展開狀態下，使用高質量主攝像頭自拍的同時顯示自拍預覽畫面。我們正在開發一套 API 支援此應用場景。您可在今後的版本的實驗性 WindowManager Jetpack API 找到上述功能。
Chrome 作業系統
△ Chrome OS 優化
多年來，Chrome 作業系統讓使用者能夠在大螢幕裝置上安裝和執行 Android 應用。
△ 畫中畫
最近，我們針對 Android 應用體驗進行了多方面改進，比如提升畫中畫支援、加入低延遲觸控筆庫，以及美化那些並非針對大螢幕裝置設計的應用的介面。現在畫中畫在 Chrome 作業系統中介面更精美、執行更流暢。使用標準 Android 畫中畫 API 無需額外投入，即可獲得最新外觀和功能。
接下來我們來快速瀏覽一下這些 API。首先，在清單檔案中指出畫中畫支援:
android:supportsPictureInPicture=”true”然後通過 enterPictureInPictureMode 啟動它:
pipButton.setOnClickListener {
enterPictureInPictureMode(
new PictureInPictureParams.Builder().build())
}您還可以使用 onUserLeaveHint 實現 Activity 在被使用者置入後臺時，自動進入畫中畫模式等功能:
override fun onUserLeaveHint() {
enterPictureInPictureMode(
new PictureInPictureParams.Builder().build())
}請注意，此模式下可能需要調整介面。如需進行調整，請找到 onPictureInPictureModeChanged 回撥，並按需做出相應修改:
override fun onPictureInPictureModeChanged(
isInPictureInPictureMode: Boolean,
newConfig: Configuration) {
if (isInPictureInPictureMode) {
// 畫中畫功能實現
} else {
// 返回常規介面
}
}2021 年 5 月我們宣佈推出 Chrome 作業系統低延遲時間觸控筆 API，儘量降低繪畫應用的延遲。您可以立刻前往 GitHub 檢視 API 和演示版應用。
相容性模式
△ 相容性模式
在大螢幕平板電腦 Chromebook 或外接顯示器上執行僅針對小尺寸豎屏 Android 手機設計的應用時，如果拉伸進入全屏檢視，那麼應用外觀和效能可能會差強人意。應用可能出現各種問題，包括佈局欠佳，以及應用因為無法正確處理多視窗或尺寸調整事件而發生的崩潰。像平板電腦和可摺疊裝置一樣，Chrome 作業系統現在也有了相容模式，針對小屏移動裝置設計的應用可在手機尺寸或平板尺寸的視窗中顯示。
使用者可輕鬆更改視窗的顯示模式或按需啟用視窗自由調整模式，但介面會告知使用者，應用在完整的大螢幕模式下執行可能出現與預期不符的情況。這有助於 Chrome 作業系統提供符合預期的效果和穩定性，同時使用者依然享有按照自己喜歡的方式與應用進行互動的自由。
在理想情況下您的應用不應該出現在相容模式下。接下來我們聊聊在 Chrome 作業系統以及 Android 平板電腦和可摺疊裝置中避免應用出現在相容模式中所需要做到的重要的幾件事:
△ 執行在開放形式模式充分利用螢幕空間
- 為不同的裝置型別提供合適的大螢幕佈局。
- 測試應用，確保應用能夠處理摺疊事件、旋轉，能夠移入分屏，能夠自由調整大小。類似 ViewModel 等 Jetpack 元件簡化了維護狀態，併為使用者提供符合預期的效果。一定要在真實裝置或模擬器中測試不同的佈局可能性。
- 根據應用需求妥善處理觸控、鍵盤、滑鼠、觸控板輸入以及觸控筆、遊戲控制器等更為專業的輸入方式。
如需更深入瞭解，請移步至我們在 Android 開發者峰會 上推出的更多關於大螢幕主題的技術分享，瞭解如何使佈局更加美觀、契合度更高，同時可以正確處理輸入。如果您的應用已經在 Chrome 作業系統上呈現非常完美的外觀，或是想了解從哪裡開始優化，請 告知我們。關於針對 Chrome 作業系統以及大螢幕進行優化的詳細文件，請訪問 chromeos.dev。
摺疊裝置、平板電腦和 Chromebook 越來越受大家歡迎。應用優化當前能做之事尚有很多，我們將繼續努力推出新功能進一步提升應用效果。
總結
相信大家對 12L 對於大螢幕和應用設計上的一些新特性有了一定的瞭解。歡迎通過使用模擬器下載 12L 開發者預覽版 探索 12L 中的全新 API。
可以嘗試使用 JetpackWindowManager 優化應用，根據精確的視窗尺寸調整顯示區域，啟用姿態探測等新功能。在新的版本中可以利用 Activity 內嵌 和測試 API 進而簡化大螢幕佈局維護。
別忘了加入美觀的大螢幕佈局，並新增鍵盤、滑鼠和其他輸入支援。希望大家能夠順利完成對於大螢幕裝置的應用改造來擁抱新的終端互動模式。
歡迎您 點選這裡 向我們提交反饋，或分享您喜歡的內容、發現的問題。您的反饋對我們非常重要，感謝您的支援！