適配小米「中」折屏，不一定要先買一臺：adb 指令把折疊測試搬進終端機

（本文話題源自 2026 年 9 月 8 日發布於掘金的技術文章，適逢小米「中」折屏發布前夕，開發者圈的適配討論再度熱起來。）

手機螢幕的形狀越來越多，寫 App 的人最先感受到。小米的「中」折屏還沒正式開賣，Android 開發者已經在問一個很實際的問題：要為這種新形態做適配，是不是得先買一臺回來測？

答案是：多數情況下不用。Android Studio 內建的 Resizable Emulator，加上幾條 adb 指令，就能把折疊、展開、旋轉、姿態切換這些測試動作全部塞進命令列。這件事技術味很重，但它影響的是很日常的成本問題：一臺折疊旗艦的售價，對獨立開發者或小團隊來說從來不是小錢，而測試設備的清單還在一年一年變長。

為什麼「測試」比「寫布局」更花時間

Android 一直在推自適應布局。同一套功能，要能在手機、平板、折疊屏展開與收合、甚至車機上正常顯示。寫出會自動伸縮的界面只是第一步，真正喫掉時間的，是確認每一種形態下畫面沒跑版、狀態沒丟失。

打個比方，這就像開餐廳的人研發了一份菜單，標榜內用、外帶、外送三種形式都好喫。研發菜色是一回事，每種形式的包裝、溫度、送達時間都要實際跑一輪才知道問題在哪。測試就是那個跑一輪的過程，而設備形態增加的速度，比多數團隊採購測試機的速度快得多。

華為靠鴻蒙系統在硬體形態上走得早，其他 Android 陣營廠商快速跟進。這與我們先前分析的九月摺疊屏大戰的檔期競爭邏輯是同一件事的不同切面：廠商擠在同一檔期推新形態，開發者端就得同時面對好幾種新的螢幕規格。小米這次的「中」折屏，只是清單上最新的一行。

Resizable Emulator：一臺虛擬機扮演所有尺寸

Android Studio 目前自帶的 Resizable Emulator，等於一臺可以變身的虛擬設備。建立時選 Resizable 類型，就能在手機、平板、折疊形態之間手動切換，驗證布局。

不過第一個坑就在建立設備之後。用指令 adb emu fold 要折疊模擬器時，很多人第一次輸入會發現設備毫無反應，或者收到 KO: Device is not foldable 的錯誤。原因不在指令，而在模擬器面板左上角的設備類型還停在預設，要手動選成 Foldable，這臺虛擬設備才真正具備折疊身分。

選對之後，指令就會照著字面工作：

adb emu fold 會把展開狀態的折疊屏折起來，點亮虛擬外屏，進入小屏配置。adb emu unfold 則反過來，內屏重新亮起。這一來一往之間，開發者能立刻驗證兩件事：應用在形態切換時有沒有保住狀態（例如使用者填到一半的表單、播放到一半的影片），以及不同顯示尺寸下的布局是否符合預期。全程不用碰滑鼠。

如果同時跑多臺模擬器，還能用序列號指定目標：adb -s <serial> emu <command> <parameter>，讓指令只作用在特定那臺上。

旋轉與姿態：命令列也能模擬硬體狀態

折疊之外，另外兩組指令處理的是更傳統但同樣容易出錯的環節。

旋轉用 adb emu rotate，設備順時針轉 90 度。這條指令的價值在於觸發配置變更：Android 應用在旋轉時預設會重建 Activity，狀態沒存好就會畫面閃一下、資料歸零。靠指令反覆觸發，比手動轉模擬器窗口省事得多。

姿態模擬則更貼近折疊屏的實際使用情境。輸入 adb emu posture 會列出可用姿態與對應編號：closed（閉合）、half-opened（半開）、opened（全開）、flipped（翻轉）、tent（帳篷）。想要模擬折疊屏立起一半的桌面模式，下 adb emu posture 2 就行。

要注意的是，並非每個虛擬設備都支援全部姿態。Pixel Fold、Resizable AVD 這類標準模板只支援前三種，設定 flipped 或 tent 會回傳 Failed to set posture 的錯誤。這也提醒開發者：模擬器覆蓋的是主流情境，特殊姿態的極端案例仍可能需要真機驗證。

尺寸切換：一條指令換一個預設

Resizable Emulator 也可以直接切換尺寸預設。先用 adb emu resize-display 查詢可用清單，會得到 phone、unfolded、tablet 三個選項，傳入對應編號即可切換，例如 adb emu resize-display 2 把模擬器變成平板尺寸。

原文章作者也老實提醒了一點：這條指令執行後模擬器變化特別慢，看起來還沒優化好。命令列工具不等於完美工具，但它把切換動作從「開好幾臺模擬器、逐臺點開」壓縮成一行文字，省下的時間和系統資源，對筆電就被模擬器喫滿記憶體的開發者來說很有感。

這對一般讀者意味著什麼

這幾條指令覆蓋的是自適應測試裡最機械的那部分：折疊、旋轉、姿態、尺寸。把它們加進命令列工作流，開發者就不必為了驗證一個畫面同時開好幾臺模擬器。

對非開發者的讀者，這件事的意義在成本結構。折疊手機每多一種形態，整個 Android 應用生態就多一批適配工作。大公司可以採購一堆真機輪流測，獨立開發者和小團隊靠的是模擬器和命令列這種免費手段。工具越好用，小開發者跟上新形態的速度就越快，消費者買到新折疊機那天，常用的 App 才不會出現「展開後畫面兩邊留白」的窘況。

這也呼應了一個正在發生的趨勢：終端機正逐漸成為 Android 開發的第一等入口。圖形介面適合探索，命令列適合重複，而測試恰恰是最重複的工作。小米的「中」折屏上市後，真正決定使用者第一印象的，有一部分就是這些看不到的適配細節，類似我們在小米折疊機型命名與產品線布局分析裡談過的：硬體排好座位之後，軟體生態得跟著把每個位置坐滿。

所以，回到最初的問題：適配小米「中」折屏，非得買一臺嗎？對多數布局驗證來說，先打開 Android Studio，建一臺 Resizable 模擬器，在終端機裡輸入那幾條指令，就已經能覆蓋大部分情境。真機採購留給最後的臨界驗證，錢花在刀口上，這才是這套工具真正想解決的問題。