很多年前，前端同學都覺得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適配以及劉海機適配等方案。

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

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

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的聊聊安卓折叠屏给交互设计和开发带来的变化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。