到目前為止，我已經嘗試了幾種移動終端尺寸適配的方案。從最初的百分比單位，到rem，到vh，vw，再到結合flex布局使用這些適配單位，我還在不斷優化和嘗試新的方案，我也嘗試將這幾種方案結合起來使用。應用到生產環境後，取得了壹些小成績，也發現了壹些小缺點。下面將簡單討論這些方案，並分享作者在使用它們時遇到的壹些問題以及使用場景。
百分比單位是您在學習前端時接觸到的最快的大小單位，%將根據父元素的大小進行分配。如果父元素是200px * 400px的方框，子元素設置為寬度:80%，則寬度將設置為160px。同樣，百分比將根據父元素的大小來計算。當父元素的大小固定時，百分比非常有用。因此，如果父元素沒有固定的大小，那麽根據子元素的大小擴展它會怎麽樣呢？然後我們會發現實際顯示的高度是0，但寬度不是0。未設置大小的父元素的寬度將繼承其父元素的寬度，而高度不會。默認值為0。那麽我們的子元素設置的百分比和寬度是正確的，高度是0。因為百分比是根據父元素的大小計算的，所以如果父元素的寬度不為0，則可以計算非零值，如果高度為0，則只能計算為0。因此，當父元素沒有固定大小並且需要由子元素擴展時，高度使用百分比將為0。因此，應謹慎使用高使用百分比。然後，如果我們使用百分比來適應不同尺寸的手機屏幕，並確保UI設計可以在所有尺寸的手機屏幕上以正確的比例重現，那麽我們應該在根元素處設置特定的大小，以便可以基於此大小逐級計算百分比。
事實上，我們可以直觀地發現，如果我們的UI需求是壹個可以無限加載的滾動列表，那麽無法在根元素上設置特定的高度，百分比將在高度上無效。那麽我們只能為列表項設置特定的高度，但這無法保證不同大小的列表項的比例與UI設計保持壹致。這是百分比單位自適應的壹個明顯缺點。但是，如果用戶界面設計不要求單個比例與用戶界面壹致，那麽仍然可以使用百分比單位。
然後，由於百分比單位不能滿足我們的需求，我們開始尋找新的方案。這時候很容易找到大家壹直在說的rem單元。rem也是網絡支持的眾多尺寸單位之壹。它與em非常相似，那麽em和rem有什麽區別呢？Em基於父元素的字體大小屬性，而rem基於根元素的字體大小屬性。如果父元素設置為font-size: 50px，則子元素的1em == 50px。此外，如果沒有為子元素設置字體大小，默認情況下將繼承父元素的字體大小，因此子元素的子元素也滿足1em == 50px。那麽可以直觀地理解，如果子元素設置自己的字體大小，那麽上面的等式將不再滿足。因此，如果父元素需要設置自己的font-size，而其子元素想要根據祖父元素（父元素的父元素）來設置大小，則會陷入尷尬的境地。
那麽rem有什麽不同呢？我們前面提到rem基於根元素的字體大小。如果根元素設置為font-size: 50px，我們將通過在其任何子元素或嵌套的多級子元素中使用width: 1rem獲得width: 50px的反饋，而不管父元素的font-size設置為什麽值。也就是解決了em單位上面提到的尷尬情況。但是需要註意的是，由於font-size可以逐級傳遞，因此最好在根元素下的第壹級元素上將font-size設置回默認值。這樣做的原因是，如果在逐步嵌套的過程中出現了文本節點，但沒有設置相應的字體大小，那麽文本節點的字體大小將是根元素設置的字體大小，並且字體將非常大。如果大多數文本節點需要相同的字體大小，則在每個文本節點重置字體大小的值將很不方便。因此，如果根元素下第壹級的子元素設置了font-size的大小，那麽所有文本節點都將繼承font-size的值，而不是根元素的值。因此，沒有必要在每個文本節點設置字體大小。
EM&簡介；Rem這兩個單位，我們發現EM &；Rem有自己適合的使用場景，但相比之下，rem可能更適合整體的適配方案。那麽我們應該如何確定1rem的大小呢？在線數據中有許多確定的方案，其中主要有兩種核心計算方法。
第壹種是根據尺寸範圍來確定，即在移動終端的各種尺寸中，劃分多個範圍，並在每個範圍中確定固定值。其具體實現是結合媒體查詢，在不同的範圍內為屏幕尺寸設定壹個固定值，以便進行自適應。
另壹種是根據屏幕的寬度和設計稿的寬度進行計算得到壹個數值。這種計算可以在所有維度中獲得相應的唯壹值。它的具體實現是通過js獲取設備的屏幕寬度，然後用設計稿的寬度進行轉換，計算出壹個值，然後通過js動態設置為根元素。
這兩個思路基本就是上面的，但是不同的公司對於具體的換算計算有不同的思路。具體換算可以點擊這裏。我自己的方案是第二種，根據屏幕的寬度和設計稿的寬度進行換算。那麽下面將介紹作者是如何轉換的。
其實筆者的換算計算方法和網易手機的是壹樣的，只是我沒有網易那麽理解這個換算計算方法。只是這個樣本計算會很方便。因為我拿到的設計稿是750 mm寬，我壹開始嘗試把750px換算成75rem，那麽實際設備的1rem的大小是1rem（實際設備）除以屏幕寬度，即1rem（實際設備）= w（屏幕寬度）/75。但後來，我試圖發現1rem=10px（設計稿）的計算在chrome上是無效的。chrome最低只能達到12px，但實際計算的1rem遠小於12px，因為手機的寬度大多在360到480之間，是這樣計算的。後來改為1rem=100px（設計稿），意思是750px=7.5rem .所有將是1rem=10px或1rem=100px，只是由於這種計算方式，很方便地削減設計稿的大小。如果設計草圖的元素為130px * 80px，則只需要1.3REM。計算時只需除以100，切圖時直接計算即可，無需使用計算器逐壹計算。後來這個方案用久了，看到上面鏈接的博客被引入網易手機，想的比想象的多得多，才發現自己瞎了眼，碰上了死耗子。
長期以來，這種方案壹直是我在移動終端適配時的主要選擇，直到我發現在ios的webview上使用rem動態加載網絡圖片時，圖片無法顯示。經過調查，我發現通過js接口獲取的網絡圖片在加載時無法正確顯示。這是我開始思考與rem結合是否有更好的事情可以做得更好的時候。因為我在微信上做h5的時候，在使用rem的時候從來沒有遇到過刻度錯誤。在我看來，rem仍然可以很好地適應大多數界面。但是我們在使用過程中也發現了壹些小問題，因為rem的單位計算是基於7.5的屏幕寬度，而1rem（實際設備）的值不能保證是整數，所以設計稿上面的壹些小空格，例如那些小於10px的空格，在css中會寫成0.06rem，但由於1rem，但是，如果間距由px完成，那麽rem將變得不準確，尤其是在7.5rem本身是壹個屏幕寬度，但是加上px後，去掉px後還剩下多少rem可以計算出來。
然後我開始全面擁抱flex。使用flex布局後，我發現結合flex和rem可以做得更好。因為如果間距使用px，而壹些元素使用rem，那麽其余的元素可以直接通過flex進行拉伸和擴散，因此您不必擔心刪除px後還剩下多少rem。移動端基本兼容flex，可以直接使用，但需要添加相應的內核前綴。flex的使用極大地優化了布局上的書寫。
後來，大眾&；vh對，vw實際上基於window.innerWidth，vh基於window.innerHeight 100vw等於屏幕可視範圍的寬度，100vh等於屏幕可視範圍的高度，這是移動端webview的大小。而且發現vw與750px=100rem（設計稿）的情況非常相似。在這種情況下，1rem的大小與1vw的大小相同，因此vw的使用與rem的使用基本相似。並且壹個屏幕的寬度等於100vw，這也像percentage壹樣，但vw是基於屏幕寬度的，而不是像percentage壹樣基於父元素的，因此它在水平適配方面取得了非常好的效果。但是vh呢？因為有時需要制作壹個具有屏幕寬度和高度的H5界面，這時vh將發揮其作用。正常情況下，100vh是壹塊屏幕的高度。然而，在使用vh的過程中存在壹個問題，就像帶有輸入標簽的單屏幕H5註冊頁面壹樣，它需要用戶填寫信息。將背景圖像的高度設置為100vh。當輸入框獲得焦點時，手機鍵盤彈出，然後背景圖像將被壓縮，因為屏幕的可見高度是壹個屏幕的高度減去手機鍵盤的高度，因此100vh將成為此高度而不是壹個屏幕的高度。這個問題是使用vw和vh時遇到的唯壹問題。我還沒有想出好的解決辦法。如果鍵盤不會彈出，並且需要壹個屏幕的高度，強烈建議使用vh。另壹方面，大眾還沒有遇到任何問題。
在改編中嘗試了幾種方法，每種方法都有其優缺點。但如果根據使用場景選擇組合使用，可以達到相當不錯的適配效果。