很多年前，前端同學都覺得PC端的適配（相容處理）難，都認為移動端的時代適配會容易得多，也無需考慮那麼多的事情。事實並非如此，移動端的時代同樣面臨著各種適配的處理。特別是劉海機的出現，前端需要考慮劉海機適配。而如今隨著三星Galaxy Fold和華為Mate X摺疊屏手機的面世，前端同學接著又要處理摺疊螢幕的適配。

就我們團隊而言，在上個月就接到相關的通知，需要處理摺疊屏的適配。礙於真機難得，前段時間就通過模擬機，做了一些簡單的適配測試，不過幸運的是，今天拿到了真機（三星Galaxy Fold) ，寫了一個簡單的Demo，做了一些適配的測試。特此將相關心得和大家一起共享，希望對大家有所幫助。

摺疊屏裝置的相關引數

為了更好的做相應的適配處理，我們有必要先對裝置相關的引數做一定的瞭解。

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

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

Galaxy Fold的另一塊螢幕只有在機身被展開時才會出現。這塊內屏尺寸達到了7.3英寸，比例為4.2:3，解析度為 2152 x 1536：

外屏的使用方式和現在手機一樣，只不過小了些、邊框寬了些。

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

華為Mate X的摺疊採用了一塊外接螢幕。完全展開時，呈現在眼前的是一塊 8英寸、8:7.1的 2480 x 2200 OLED顯示屏:

摺疊起來後，一塊大屏會變成兩塊分別位於機身正、反面的“小”屏。正面螢幕為 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的適配方案。

• 再聊移動端頁面的適配
• 如何在Vue專案中使用vw實現移動端適配

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

vw方案如果運用於PC端或者螢幕較寬的終端裝置上，會有一定的缺陷。

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

到目前為止，雖然安卓也有很多品牌有相應的劉海機，但面對不同的App（或者說團隊），安卓劉海機不會做相應的考慮。

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

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

• iPhone X的缺口和CSS
• 手淘Web頁面Bar和縱向適配的設計
• 移動端上的設計和適配

而如今我們又將不得不開始著手於摺疊屏的適配處理。

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

摺疊屏在視覺效果來說就是，螢幕變大了，手機變平板了。這樣就要求我們的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上圖片使用方式
• 影象優化

上面提到的九大基本原則，雖然提出的時間早，但對於使用響應式設計來設計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

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

這樣就可以直接在Chrome中除錯了：

對於其他摺疊屏裝置，如果你有相關的引數，也可以按上面類似的方式進行裝置。

小結

還是那句話，底層建築永遠決定上層設計！不管時代怎麼變化，做為技術人員都應該不斷的去探索，尋找相應或最佳的解決方案。

在這篇文章中，雖然我們以摺疊屏為主線進行展開介紹，但全文除了摺疊給我們帶來的變化之外，還介紹了響應式設計、rem適配、vw-layout適配以及劉海機適配等方案。

事實上，這也是一篇有關於移動端適配大全或指南。

最後希望該文對大家有所幫助。

原文連結
本文為雲棲社群原創內容，未經