聊聊安卓摺疊屏給交互設計和開發帶來的變化

時間 2019-11-06

原文原文鏈接

不少年前，前端同窗都以爲PC端的適配（兼容處理）難，都認爲移動端的時代適配會容易得多，也無需考慮那麼多的事情。事實並不是如此，移動端的時代一樣面臨着各類適配的處理。特別是劉海機的出現，前端須要考慮劉海機適配。而現在隨着三星Galaxy Fold和華爲Mate X摺疊屏手機的面世，前端同窗接着又要處理摺疊屏幕的適配。css

就咱們團隊而言，在上個月就接到相關的通知，須要處理摺疊屏的適配。礙於真機可貴，前段時間就經過模擬機，作了一些簡單的適配測試，不過幸運的是，今天拿到了真機（三星Galaxy Fold) ，寫了一個簡單的Demo，作了一些適配的測試。特此將相關心得和你們一塊兒共享，但願對你們有所幫助。html

摺疊屏設備的相關參數

爲了更好的作相應的適配處理，咱們有必要先對設備相關的參數作必定的瞭解。前端

簡單地說，三星Galaxy Fold和華爲Mate X的最大區別便是 雙屏內摺疊對單屏外摺疊！

三星Galaxy Fold搭載了兩塊屏幕，一塊位於機身外側的一邊，適合摺疊狀態下使用。這塊外屏是一塊4.6英寸1960 x 840 Dynamic AMOLED顯示屏：git

Galaxy Fold的另外一塊屏幕只有在機身被展開時纔會出現。這塊內屏尺寸達到了7.3英寸，比例爲4.2:3，分辨率爲 2152 x 1536：github

外屏的使用方式和如今手機同樣，只不太小了些、邊框寬了些。web

內屏的大尺寸則能在玩遊戲、看視頻、看地圖、拍照和視頻通話等狀況下提供更多的內容顯示。大尺寸也讓多任務處理再也不是雞肋，發佈會現場展現的三任務同時處理讓人印象深入。segmentfault

華爲Mate X的摺疊採用了一塊外置屏幕。徹底展開時，呈如今眼前的是一塊 8英寸、8:7.1的 2480 x 2200 OLED顯示屏:windows

摺疊起來後，一塊大屏會變成兩塊分別位於機身正、反面的「小」屏。正面屏幕爲 6.6英寸，分辨率爲2480 x 1148，比例爲19.5:9，是目前主流手機的屏幕比例。背面的屏幕則是一塊 6.38 英寸 2480 x 892分辨率顯示屏，比例爲25:9。瀏覽器

對於Web前端而言，咱們主要關注的幾個參數是 分辨率、 DPI 和 屏幕寬度*等。簡單的將相關參數列入：安全

參數	三星 Galaxy Fold (摺疊狀態)	華爲 Mate X （摺疊狀態）	三星Galaxy Fold (展開狀態)	華爲 Mate X (展開狀態)
屏幕尺寸	`4.58`英寸	`6.6`英寸(正面)；`6.38`英寸(背面)	`7.3`英寸	`8`英寸
分辨率	`1960px x 840px`	`2480px x 1148px`(正面)；`2480px x 892px`(背面)	`2152px x 1536px`	`2480px x 2200px`
屏幕密度DPI	`420dpi`	（待真機肯定）	`420dpi`	（待真機肯定）
寬高比	`21:9`	`19.5:9`(正面)；`25:9`(背面)	`4.2:3`	`8:7.1`
設備像素比 `dpr`	`2.625`	`3.5`(待真機肯定)	`2.625`	`3.5`(待真機肯定)
屏幕寬度(`window.screen.width`)	`320px`	(待真機肯定)	`586px`	(待真機肯定)
屏幕高度(`window.screen.height`)	`747px`	(待真機肯定)	`820px`	(待真機肯定)
視窗寬度(`window.innerWidth`)	`980px`	(待真機肯定)	`981px`	(待真機肯定)
視窗高度(`window.innerHeight`)	`1725px`	(待真機肯定)	`1147px`	(待真機肯定)

有關於設備相關的參數，咱們能夠經過相應的API來獲取（這個很重要）：

DPI：window.devicePixelRatio
UserAgent：window.navigator.userAgent
屏幕寬度：window.screen.width
屏幕高度：window.screen.height
視窗寬度：window.innerWidth
視窗高度：window.innerHeight

而屏幕尺寸、分辨率、像素密度三者關係之間存在相應的計算關係：

好比屏幕分辨率爲：1920px x 1080px，屏幕尺寸爲 5英寸的話，那麼對應的DPI爲440，即：

摺疊屏給交互設計帶來的差別化

無論是三星 Galaxy Fold的內摺疊屏仍是華爲 Mate X的外摺疊屏給咱們最直觀的效果相似於iPhone和iPad的差別：

摺疊狀態相似於iPhone；展開狀態相似於iPad。

屏幕寬窄的變化給咱們的交互設計也會帶來相關的變化。

對於Web設計而言，當摺疊屏從小屏模式轉變成大屏模式時不該該只是畫面的等比例變大，而是要考慮響應式佈局設計。描述響應式設計最著名的一句話就是：

「Content is like water，即若是將屏幕看做容器，那麼內容就像水同樣」。

在之前響應式設計更多用在PC Web設計上，但如今摺疊屏手機的出現，咱們在移動端也應該考慮響應式設計，如下是設計時須要考慮的細節：

不是簡單的響應式設計

摺疊屏幕在「展開」態時要考慮是平板模式仍是雙屏幕模式，若是是平板模式，那麼內容應該在一個總體裏；如果雙屏幕模式則能夠考慮不一樣屏幕展現不一樣內容。設計時須要根據實際需求和場景進行模式選擇。

如上圖所示，內容在同一個總體裏，只是視覺（排版）效果上有差別。

或者

上兩圖展現了不一樣的屏幕展現不一樣的內容。

考慮經過Fragment（片斷）來設計

Fragment是Android3.0提出的API，出現的初衷是爲了UI更靈活地適應大屏幕的平板電腦。

Android官方對Fragment的描述是：

「Fragment表示Activity中的行爲或用戶界面部分。能夠將多個Fragment組合在一個 Activity 中來構建多窗格 UI，以及在多個 Activity 中重複使用某個Fragment。

採用不一樣的Fragment來設計，能夠作到不一樣內容在不一樣的屏幕展現，甚至在同一屏中能夠展現多個不一樣的內容。對於這樣的場景，交互的方式和行爲都將會有所變化。好比進入每一個不一樣的Fragment應該是怎麼樣的一個交互方式；好比返回按鈕，滑屏等又是怎麼一個交互方式。這一切都值得咱們去探討。

好比說，頗有可能未來手淘就能像下面這樣，在展開狀態打開多個Fragment：

參考微軟的UWP設計概念

UWP即Windows 10中的 Universal Windows Platform（Windows通用應用平臺）。

UWP應用的理念並非爲某一個終端而設計，而是同一套代碼和設計能夠在全部Windows10設備上運行，包括Windows 10 Mobile / Surface / PC / Xbox / HoloLens等等。它的響應式設計設計技巧包括如下6點：

下面的內容摘自《 UWP 響應式程序設計介紹》一文。

調整位置

你能夠改變 UI 元素在不一樣屏幕上的位置。好比下面這個例子：爲了確保同時展現兩個元素，在手機上咱們必須採用縱向滾動界面，而在平板電腦上，咱們能夠調整框架的位置，變爲橫屏滾動界面。若是你用網格設計這些位置，你也能夠不改變內容框架，但其餘 UI 元素可使用響應式設計。

這是一個圖片應用的例子，內容框架在大屏幕上被改變了位置。

調整尺寸

你能夠經過調整空白和 UI 元素的尺寸來優化框架，好比下面這個例子，能夠經過簡單的增大內容框架尺寸來提高大屏幕的閱讀體驗。

調整順序

經過調整 UI 元素的順序和方向，優化內容顯示效果。舉個例子，在大屏上運行時，能夠再添加一欄，而且加入分類列表，這些都是合理的。

這個例子展現了在手機上使用一欄縱向滾動，而在平板上使用兩欄橫向滾動的優化。

展示

你能夠基於屏幕的真實大小，設備支持的功能，特定的狀況或者屏幕方向展現界面。

下圖是一個含有相機按鈕的 Tab 的例子。平板電腦和臺式機可能沒有攝像頭，因此相機按鈕不被顯示出來。另外一個例子是媒體播放器，小屏幕上這些按鈕一般是被刪減的，但在大屏幕上這些按鈕是被徹底保留的。PC 上的媒體播放器比手機上的有更多的功能。

換位

這項技巧是爲特定屏幕尺寸或屏幕方向切換特定的界面。下面這個例子是導航菜單：小屏幕上他是隱藏在漢堡菜單中縱向排列的，可是在大屏幕上，更大的 Tab 是更好地選擇。

改變結構

你能夠爲特定的設備優化特定的結構。下面這個例子就是兩種不一樣的接合結構。

下圖是一個智能家庭程序，運用了改變結構的技巧

摺疊屏下的手淘將多是這樣的

UWP設計概念是一個很是好的一個概念。若是不久的未來，摺疊屏爲成爲一個主流之一的話，除了UWP設計帶來的設計和交互的變化以外，還會有其餘更優秀，或更合理的交互設計概念嗎？

或者簡單地說，摺疊屏時代的手淘將會是什麼樣的呢？

前面咱們提到兩個（或多個）Fragment的設計，若是未來的App中能在寬屏模式（摺疊屏展開模式）啓用多個Fragment時，咱們的交互設計可許將會是這樣的。

在2019年愚人節當日， 淘寶設計 提出了手淘在摺疊屏下的概念設計。

在該文章中，做者提出摺疊屏幕時代下，手淘App針對摺疊屏的兩大特性具體展開相應的設計。

大屏內容更豐富

在摺疊屏中，頂部和底部導航性質的組件屬於頁面的公用功能，採起直觀的 橫向拉伸適配方式；而當中頁面能夠採用內容填充適配方式，將次級重要內容展現在第二屏。

有可能未來在消息的第二屏內容是聊天窗口，能快速預覽消息裏的最新內容，提高聊天切換的效率。

多任務效率提高

在平常使用手機處理主任務時，常常會碰到臨時通知消息等分支任務處理，主任務與分支任務場景的頻繁切換給用戶帶來很高的操做成本。

摺疊屏的 「第二屏」 可讓用戶能夠不離開當前場景便可便捷的處理子任務，提高多任務的處理效率。下面舉例淘寶上的案例幫助你們體會多任務帶來的種種便捷。

好比說，在摺疊屏展開狀態的模式下，你將能夠一邊看淘寶直播，還能夠讓寶貝列表呈現出更大更多的圖片以及簡要的信息幫助用戶作初步的判斷，邊看邊逛互不干擾。

摺疊屏適配姿式

都說 底層建築將決定上層設計。這一點都不假。

在PC時代，衆多前端開發者都疲於奔波處理各類不一樣版本瀏覽器客戶端的兼容處理；在移動端時代，本來覺得將會改變這一情況，事實並不是如此。

隨着iPhone6，iPhone6+的出現，不只限於處理不一樣屏幕的Android設備，還須要考慮雜屏時代的iOS設備。在那個時候設計和開發爲了更好的適配，採用了一種適中的設計，好比手淘設計師和前端開發的適配協做基本思路是：

選擇一種尺寸做爲設計和開發基準
定義一套適配規則，自動適配剩下的兩種尺寸(其實不只這兩種，你懂的)
特殊適配效果給出設計效果

手淘設計師常選擇iPhone6做爲基準設計尺寸，交付給前端的設計尺寸是按750px * 1334px爲準(高度會隨着內容多少而改變)。前端開發人員經過一套適配規則自動適配到其餘的尺寸。

開發人員針對該場景提供了不一樣的適配解決方案。好比業務較爲主流的一種適配方案，經過lib-flexible庫配合CSS的rem單位來作相應的等比縮放適配。

flexible.js方案也就手淘團隊提供的一種優秀的適配解決方案。即：《使用Flexible實現手淘H5頁面的終端適配》

事實上，flexible.js方案（業務常稱rem適配方案）基本原理是模擬視窗單位vw、vh、vmin或vmax原理。隨着視窗單位獲得更多設備的支持以後，不少團隊開始棄用flexible.js的適配方案，而改用vw-layout的適配方案。

vw方案（常稱vw-layout方案）讓咱們在移動端適配變得更爲容易。

vw方案若是運用於PC端或者屏幕較寬的終端設備上，會有必定的缺陷。

但這一切並無結束。隨着蘋果公司（Apple）的劉海機iPhone X、iPhone XS、iPhone XR、iPhone XS Max的出現，無論是設計仍是開發又要開始面對於劉海機終端的適配處理。

到目前爲止，雖然安卓也有不少品牌有相應的劉海機，但面對不一樣的App（或者說團隊），安卓劉海機不會作相應的考慮。

在劉海機中（或者說iOS11起）提出一個安全區域的概念。設計師也針對安全區域作出相應的處理：

前端開發也有相應的屬性env()來作相應的適配處理。有關於劉海機的適配，請移步閱讀：

而現在咱們又將不得不開始着手於摺疊屏的適配處理。

華爲摺疊屏官方適配方案建議

摺疊屏在視覺效果來講就是，屏幕變大了，手機變平板了。這樣就要求咱們的APP在可摺疊設備展開時，當前應用頁面必須無縫延續到另外一個屏幕，並可自動調整大小匹配新的佈局，反之亦然。也就是說，應用程序須要準備好在多個屏幕（不一樣分辨率、密度等）之間切換。

其實Google以前有其應對的策略，在去年的 Android Dev Summit 上，Google 就已經宣佈將要對摺疊屏提供「Screen Continuity（屏幕連續性）」的原生系統支持，並將這項技術稱之爲：Foldables。利用這種柔性顯示技術，App 能夠作到摺疊屏設備上的適配工做。

事實上，華爲官方針對摺疊屏也提供了一些適配方案。

X 軸方向自適應

儘可能保持Y軸方向上元素不變，X軸方向上自適應：

該方案較 適用於界面元素相對單一，沒有大量列表類、或較多顯示元素的頁面。

佈局內容擴展

參考 iPad（平板）佈局顯示更多內容，對於區分了手機和iPad佈局的應用，在展開態優先考慮參考iPad的大屏佈局適配展開態界面，顯示更多內容；儘可能保證Y軸方向元素的不變：

該方案 通常適用於 WEB 類應用，頁面特徵通常爲元素多，適配原則以儘可能顯示較多元素優先。

分欄佈局

對於設計過度欄能力的模塊，須要在展開態體現分欄佈局：

該方案通常有明顯 list 二級菜單的元素結構比較適合。

橫豎屏佈局一致

考慮到展開態 8:7.1 的比例，展開態的橫屏和豎屏建議一套佈局。橫豎一致；不對展開態的橫屏特殊處理，挪移佈局不用體現。

若是仔細對比，不難發現華爲官方提供的適配方案（展開狀態模式）和微軟的UWP設計概念有些類似之處。

兩個（或多個）Fragment設計

前面也提到過，在將來，摺疊屏在展開狀態或許能夠同時展現兩個或更多個Fragment。對於這樣的場景，前端或者設計都相對而言要更容易。由於多個Fragment更和咱們如今的適配方式接近（未展開狀態，和目前主流移動設備類似）。固然，在展開狀態時，多個Fragment同時展現不一樣內容之時，或許每一個Fragment所佔屏幕的比例會有不一樣，針對於這種場景，咱們目前採用的vw-layout適配方式，將毫無壓力。

不過，同時打開兩個或多個Fragment時，針對不一樣的場景在設計中也須要有所不一樣。好比說頂部Bar和底部Bar採用比例拉伸，中間主內容打開多個Fragment，在不一樣的Fragment中顯示不一樣的內容。

採用響應式設計方案

有了解過響應式設計的同窗或許都知道，響應式設計在PC上的客戶端獲得較大範圍的使用場景。對於移動端上，響應式設計的身影並不常見。但現在天，安卓摺疊屏幕的出現，或許在將來的一些Web應用或Web頁面中將會看到響應式設計的影子。

若是你決定在你的應用中採用響應式設計來適配摺疊屏展開狀態的效果，那麼就有必要簡單地瞭解一下響應式設計的幾個基本原則。

@Sandijs Ruluks早在2014年就針對響應式設計提出九大基本設計原則。

響應式 vs. 自適應網頁設計

不少初學都都容易把響應式設計和自適應設計混淆。事實上，它們看起來彷佛是相同的，但事實並不是如此。這兩種方法相輔相成，並無說哪一個是正確的那個是錯誤的，內容決定一切。

內容流動

隨着屏幕尺寸變小，內容將會佔據更多的垂直空間，而下方的內容就會被接着往下推，這就是所謂的流動。若是你是使用像素或磅來進行設計的，這可能會有點棘手，可是當你習慣了以後，就會變得頗有意義了。

相對單位

畫布大小能夠是Desktop、Mobile或是它們之間的任何尺寸。像素密度也可能有所不一樣，因此咱們須要靈活的、在各類屏幕上均可以使用的單位。這就是相對單位（如%、vw等）派上用場的時候了。因此設置50%的寬度也就意味着它會佔據屏幕（或視窗，即打開的瀏覽器窗口的尺寸）的一半。

在CSS的世界中，相對單位有多個，不一樣的場景都有其優勢：

上面提到%來作適配處理並沒有大礙，但%的計算相對而言會較爲蛋疼，慶幸的是，咱們能夠採用視窗單位，好比vw、vh、vmin或vmax來替代%。

無論是%仍是視窗單位，它們計算方式都有所不一樣。他們也沒有好壞之分，只有適合不適合之分。

在 vw-layout適配方案，採用的就是視窗單位。

斷點

斷點是響應式設計中一個很是重要的概念。它容許佈局在預約義的點改變相應的UI風格。例如：PC端瀏覽器佈局是三列，可是在手機移動端上只展現一列。大多數CSS屬性能夠根據斷點改變。一般你會根據具體的內容來設置斷點。

這裏所說的斷點就是採用CSS中的媒體查詢特性，但這樣一來將會增長很多的代碼量、開發成本和維護成本。

隨着技術不斷的革新，CSS的特性也愈來愈強大，就到目前爲止，能夠藉助CSS Grid、minmax()、repeat()、auto-fill和fr等特性，更易於實現響應式效果。固然一些特殊的場景仍是須要強度依賴斷點（媒體查詢）來處理。

`min-width`和`max-width`

前面提到過，在響應式設計中，最爲關鍵的就是條件CSS中的媒體查詢，即@media。媒體查詢能夠有條件的應用CSS規則，它告訴瀏覽器應該忽略或應用哪些CSS規則，而這些都取決於用戶的設備終端。

在媒體特性中，大多數的媒體特性均可以帶有min或max的前綴，好比說min-width和max-width，用於表達「最小的...」或者最大的...。用兩張圖來幫助你們來理解min和max的實際含義。

好比，設置width爲100%，而後max-width是1000px，那麼內容會填滿屏幕，可是不會超過1000px。

嵌套對象

還記得相對位置嗎？讓不少元素的位置依賴於其它元素來定位是很難控制好的，所以使用容器來包裹元素可讓它更易理解，也更整潔。這就是靜態單位（好比像素）發揮做用的時候了。對於你不想要模塊化的內容（好比logo或按鈕），它們是有用的。

Mobile優先仍是Desktop優先

從技術上講，若是一個項目是從一個較小的屏幕開始，變成較大的屏幕（Mobile優先），仍是反過來（Desktop優先），並無太大的差異。然而它仍是增長了額外的限制，能夠幫助你決定是否從Mobile優先開始。一般你們在一開始的時候都會兩端一塊兒寫，因此，仍是看看哪一個運行起來更好。

網頁字體 vs 系統字體

但願你的網站上有很酷的字體嗎？可使用網頁字體！雖然它們看起來很是棒，可是記住字體放得越多，你加載頁面的時間也會越長。在另外一方面，加載系統字體確是快如閃電，但當用戶本地沒有這套字體時，它就會返回默認的字體。

位圖 vs 矢量圖

你是否想過在圖標上添加不少的細節和花哨的效果？若是想過的話，使用位圖比較合適。若是沒有，能夠考慮使用矢量圖。對於位圖，使用的是jpg、png或gif格式的圖像，而對於矢量圖，最好的選擇是SVG或圖標字體。每一個都有對應的優點和缺點。可是圖片的大小也須要重視——網頁上的圖片必須通過優化。另外一個方面，矢量圖一般比較小，可是一些舊版的瀏覽器不支持。此外，若是它有不少曲線的話，它也可能會比位圖要重。因此，慎重選擇。

有關於Web中圖片或圖標的使用，更詳細的介紹能夠閱讀：

上面提到的九大基本原則，雖然提出的時間早，但對於使用響應式設計來設計Web頁面或Web應用都具備極好的參考。固然，時至今日或將來，咱們實現響應式設計能夠借用其餘的一些CSS特性，會讓咱們變得更爲簡單：

藉助calc()函數，vw等視窗單位，能夠對font-size進行精準設置：

在不一樣大小窗口下實現不一樣的字號。

經過CSS 的 grid佈局、minmax()、repeat()函數、fr單位以及auto-fill（或auto-fit）再配合min-content、max-content、fill-content會讓響應式佈局愈來愈簡單。

vw-layout和媒體查詢相結合

無論是華方官方提供的適配方案或是淘寶設計團隊提供的摺疊屏幕的設計概念仍是響應式設計（或者說UPW概念），對於摺疊屏幕的適配都有不一樣的幫助。

vw-layout佈局可讓咱們輕易地達到X軸方向自適應或者橫豎屏佈局一致或橫豎屏佈局一致
響應式設計（藉助媒體查詢）可讓咱們輕易地達到佈局內容擴展或分欄佈局

若是採用多個Fragment來展現內容，那麼vw-layout或其餘的相對單位佈局均可以很是輕易的幫助咱們實現摺疊屏在不一樣狀態的適配效果。

若是你只想同比例放大，那麼vw-layout也將是一個最佳方案。

若是你想在摺疊狀態和展開狀態有不一樣的佈局風格，那麼響應式設計或者UWP概念將是不錯的選擇。在這種場景之下，把vw-layout和媒體查詢（響應式設計）結合起來，將是最佳選擇。

建立新屬性或提出新標準

劉海機的出現，蘋果公司針對該類型設備提出了env()函數和安全區域的概念。讓咱們在處理劉海機適配的時候將變得更容易。

雖然env()最初只用於iOS的系統，但隨着這方面的需求更多，業內同行將該函數提到W3C規範的方案中，讓其成爲W3C規範。根據相同的一個概念，咱們是否也能夠針對安卓摺疊機，提供一個相似的函數或者屬性。好比folding()。另外，對於移動端，咱們在媒體查詢中orientation: landscape或orientation: portrait來判斷設備是否橫豎屏。一樣的原理，咱們是否是也能夠藉助相似媒體查詢這種方式來對安卓摺疊屏作類似的設置呢？

咱們手淘或者說集團不少App在安卓上都採用的是UC的內核，就算沒法在W3C規範中推進，咱們UC內核的同窗是否能夠針對摺疊屏提供相應的判斷條件呢？期待UC同窗能提供。

案例

自接到要適配安卓摺疊屏的需求時，其實咱們團隊在這方面的壓力並不太大，由於咱們採用的是vw-layout佈局方案，再加上咱們是Web頁面（也就是你們所說的H5頁面），在這方面具備自然的適配功能。只是在展開狀態或許須要作一些細節化的處理。好比金幣莊園：

藉助媒體查詢，能夠輕易解決這樣的細節問題。

另外爲了更好的體驗一下本身的想法：

vw-layout、grid和@media查詢相結合，對三星摺疊屏幕作相應的適配處理（華爲尚未拿到真機）。

因而我寫了一個簡單的小示例：

Demo在線效果能夠點擊這裏。

手淘卡片的佈局：

最基本的方案是咱們團隊一直使用的vw-layout佈局方案，再配合CSS Grid:

.card {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(340px, 1fr));
    grid-gap: 18px;
    grid-auto-flow: dense;
}

若是不作任何處理，咱們在摺疊屏兩個狀態下的效果以下：

若是咱們想讓在展開狀態展現更多的內容時，或者說不一樣狀態採用差別化的設計，那麼咱們能夠藉助媒體查詢來處理。爲了精準達到，先用JavaScript一些API獲取設備相關參數：

<script>
    window.onload = function () {
        var winDPI = window.devicePixelRatio;
        var uAgent = window.navigator.userAgent;
        var screenHeight = window.screen.height;
        var screenWidth = window.screen.width;
        var winWidth = window.innerWidth;
        var winHeight = window.innerHeight;

        alert(
            "Windows DPI:" + winDPI +
            ";\ruAgent:" + uAgent +
            ";\rScreen Width:" + screenWidth +
            ";\rScreen Height:" + screenHeight +
            ";\rWindow Width:" + winWidth +
            ";\rWindow Height:" + winHeight
        )
    }
</script>

輸出咱們想要的數據：

藉助媒體查詢，咱們就能夠作咱們想要的事情：

@media only screen and (device-width: 320px) and (device-height: 747px) and (-webkit-device-pixel-ratio: 2.625){ 
  body {
        background-color: blue;
  }
  body::before {
      content: '三星摺疊機：摺疊狀態';
      position: absolute;
      top: 0;
      left: 0;
      z-index: 999;
      background-color: rgba(0,0,0,0.3);
      color: #fff;
  }
}

@media only screen and (device-width: 586px) and (device-height: 820px) and (-webkit-device-pixel-ratio: 2.625){ 
  body {
        background-color: orange;
  }
  body::before {
      content: '三星摺疊機：展開狀態';
      position: absolute;
      top: 0;
      left: 0;
      z-index: 999;
      background-color: rgba(0,0,0,0.3);
      color: #fff;
  }

  #app {
      grid-template-columns: repeat(auto-fill, minmax(22.6665vw, 1fr));
  }
}
</style>

這個時候你看到的效果以下：

若是你稍加處理，還能夠獲得更不同的佈局：

藉助媒體查詢來實現差別的設計，對於開發而言是較爲蛋疼的，會增長很多的開發成本和維護成本。而助上面的媒體查詢是隻針對於三星摺疊屏，但隨着更多摺疊屏設備的出現，事情會變得愈來愈困難：

因此咱們仍是但願有一個統一性的判斷屬性。

這個示例向你們演示的是H5在三星中的適配。對於其餘的摺疊屏設備，咱們能夠按一樣的方式或原理來進行。

摺疊屏設備調試

若是你沒有真機的話，在調試摺疊屏的時候能夠採用模擬機：

能夠運行相應的模擬機，好比華爲Mate X模擬機：

若是你是使用Chrome進行調試，你還能夠建立相應的模擬機。好比三星的UserAgent信息以下:

Mozilla/5.0 (Linux; U; Android 9; zh-CN; SM-F9000  Build/PPR1.180610.011) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.108 UCBrowser/12.1.2.992 Mobile Safari/537.36

這樣就能夠建立摺疊和展開的兩種狀態：