h5的rem代替px作移動端界面的自適應就是這麼簡單又強大，以及個人一些經歷和認識

　　這兩天要把公司之前的觸屏設備的客戶端應用作成h5的web應用，並且有針對不一樣設備和同一設備下的不一樣狀態(有windows豎屏和橫屏和android的平板)，並且都有設計師爲其針對的不一樣設計標準包括字體大小和不一樣ui組件的大小，雖然當時通過討論，公司老員工建議就按照這個標準去作，不用考慮自適應，由於設備就這幾種，可是我是一直不甘心，總想把它作成能適配不一樣設備分辨率的東西，因此來研究這個問題(在瞭解rem以前，我會作自適應，但只是在作了佈局上的自適應，不包括字體)。

　　由於在以前的公司作過的項目中的某些模塊參照過別的產品，發現過有用rem和em的，而後就來網上研究學習瞭解了下這幾種相對單位。其中就找到了這篇文章：http://isux.tencent.com/web-app-rem.html，發現這篇文章對除了rem來設計界面的其餘方法作了介紹和總結。文章總結了rem相對於其餘幾種設計方法的好處，其餘幾種方法的壞處，具體那些壞處朋友能夠去看下這篇文章。

　　之因此以前沒有去研究學習rem，包括以前沒有去研究接受其餘的新技術，好比es6,前端mvvm框架、模塊化開發、項目構建,編譯,打包發佈工具等等。是由於在以前的所在公司，公司任務比較充實，天天都有任務要作，那時用的基本都是老技術，單純的用html,css,js,jq,easyui,bootstrap開發，雖然有點厭倦，寫的代碼比較low，但還好業務邏輯這方面比較有趣，有些界面實現也比較有趣(一直很喜歡作界面)，加上我自己工做責任心強，因此那時天天還算過得充實。充實的結果致使我天天都在作任務，幾乎天天晚上7，8點下班回家，而後吃飯，再洗涑，再搞會其餘的，基本上就9點過，10點了，這樣下來一天也比較疲倦，就常常致使我無意再學習其餘新技術，只想休息放鬆下，那時我周6加班仍是比較頻繁，而後就基本只有週日了，可是因爲想睡懶覺和要洗衣服，打遊戲，因此學習時間也變得比較少了,總得意思就是學習時間變少了（可是我不是徹底不學習，但那時主要學習js和css去了，那本es5我看了好多遍，每次都有新收穫。），固然這其中很大緣由仍是我懶，其實我仍是寫了好些博客草稿，只不過都由於這個懶的緣由沒有去整理髮布(10篇沒有發佈)。。。。。

　　可是那段時間仍是過得頗有價值的，鍛鍊了我編程的思惟邏輯(我是後臺出身，仍是有點面向對象的概念，學習js也不是那麼吃力。在學校學習了一年C#.NET,而後當初應聘的第一份工做是.net，可是公司框架已成熟，對前端需求大，我就去作了前端，而後愛上了前端，可是公司的幾個簡單經常使用的小接口仍是我寫的，雖然借鑑了些百度。到了如今的公司，因爲公司須要，我也會偶爾負責後端開發，好比公司如今的一個小型cms，我獨立開發，徹底獨立開發，從數據庫到c#.net的數據層，業務層（業務層不多，業務主要在前端，除了通用的數據接口，後端的業務層主要是一些安全驗證，好比對前端編碼過的where條件解碼，過濾sql，避免sql注入；全部的通常處理程序只是做爲一個入口，具體的代碼編譯進dll，雖然做用可能小，可是總比沒有好）等等（後臺用三層架構，沒用mvc），通用的數據接口和比較經常使用的接口是本身參照以前公司接口思想寫的(包括樹，grid分頁等)，沒有用第三方框架。固然個人C#.NET仍是隻是皮毛，數據庫設計也是會相對比較簡單的的東西，表建立和視圖本身寫，存儲過程用的別個現成的稍微改了一點點(主要是分頁存儲過程等通用的，只是加了個where條件參數。等我把前端想學的學完了，我可能會去學sql，學存儲過程)，固然我主要喜歡前端，之後也會一直向前端發展，後臺我只須要懂點皮毛就能夠了，有後臺那個概念就OK，主要就是了解B&S的先後端的交互,即瀏覽器http和服務器的交互，以及先後端的生命週期。)。由於業務邏輯複雜好玩，任務多，當業務邏輯多到我以爲個人代碼是垃圾，不堪入目，當時一直沒有好的方法去解決這些痛點，如今才體會到原來這些新技術就是解決這些痛點的，而且這些技術會規範你的項目開發邏輯，深深的體會到mvvm設計模式很適合web前端（這裏我很推崇vue，漸進式的前端框架，組件化的思想，相對其餘框架來講，它作模塊化開發，開發大型應用會比較簡單，環境搭建也很簡單，有官方的腳手架工具vue-cli（安裝cli以前，先安裝webpack，最好是用淘寶鏡像cnpm安裝），地址：http://cn.vuejs.org/v2/guide/installation.html）。

　　到了如今的一家公司，因爲公司的任務不是那麼多，時間也比較足，因此我在空閒時間會去研究怎麼讓個人代碼更簡潔、更具可讀性，更抽象、更高效的去實現功能業務需求，讓項目模塊具備可擴展，可複用，易於變動，高內聚低耦合等等。而後就去探索，發現不少驚喜，發現還有不少須要學習的新技術，實際上當你認真的去了解這些技術後，發現也沒有想象種那麼難，反而是讓你的開發變得更簡單。

 

　　迴歸正題，我之前作界面就是上面那篇文章裏提到的流式佈局(主要用bootstrap柵格佈局)，寬度百分比，高度固定（最開始我高度也百分比，顯然不行），這種方式的壞處就是兼容性不是很好,只適應特定的幾種分辨率，也很差維護。下面我就來介紹下最終我以爲很好的rem（若是設計師沒用給出明確的組件大小，能夠結合bootstrap柵格佈局實現快速佈局，而且後期能夠改形成響應式佈局，能夠到bootstrap官網定製下載只包含柵格的css代碼）。

　　

     下面是引用知乎的一位用戶的回答：https://www.zhihu.com/question/21504656

 

 /***************START*************************************/

在移動端能夠作到適配不一樣的手機分辨率，若是保持總體縮放，沒有設計上的差別能夠不須要用到`media query`

假設設計師的視覺稿是按照iPhone6的寬度來設計的，即375px (若是是高清的視覺稿750/2=375)
那麼，咱們能夠徹底按照視覺稿上的尺寸來賦值給元素的樣式，好比視覺稿上的尺寸是80px，那麼在css中就能夠直接定義width:80px; 頁面中全部的尺寸都這樣來設置。

當全部的網站全部的頁面樣式都設置好以後。

咱們須要作兩件事情：
1. 設置頁面的rem大小
```css

html { font-size: calc(100vw/3.75); }

```
100vw是設備的寬度，除以3.75可讓1rem的大小在iPhone6下等於100px

2. 替換頁面中的單位，把全部的px單位替換成rem，除以100，好比前面的80px，就是0.8rem
這樣在iPhone6下，全部元素的尺寸仍是和視覺稿的尺寸同樣，而iphone5中，由於設備的寬度變小了，100vw/3.75獲得的值，會相應的變小，即rem的單位值會變小，頁面中全部的尺寸會等比例縮放。

這樣就能夠作到針對任何分辨率的設備保持視覺一致了。
最後，前面用到vw單位，可是低版本的設備可能不支持，那麼就須要js來處理一下：
```javascript

document.documentElement.style.fontSize = window.innerWidth/3.75 + 'px'

```

之因此前面讓1rem等於100px，而不是1rem等於1px，是由於在chrome下針對中文的最小字體是12px。


固然，這種步驟是針對如今的情況改rem來作的，若是一開始就是使用rem，那麼寫css的時候，能夠直接寫rem單位，按視覺稿除以100，其實也沒有什麼計算過程。或者用預處理器的話，也能夠寫一個`px2rem`的函數，直接改這個函數就能夠了。

 

 /*************END******************************/

 

個人最終總結：我認爲比較好的方式就是讓1rem在設計師給的標準尺寸下等於100px,而後咱們用的時候若是用到14px,直接用0.14rem替換就ok，而後經過js動態根據不一樣設備寬帶給html的font-size進行計算。假如設計師設計的頁面寬度尺寸是1080，js就這樣寫：

document.documentElement.style.fontSize = window.innerWidth/10.80 + 'px'，這樣在1080設備上的html的font-size=100px，0.14rem就等於14px；這樣就能兼容不一樣設備分辨率了，好比，若是在2160px設備分辨率下，html的font-size經計算就等於200px,那麼0.14rem=0.14rem*200=28px了。