移動端頁面重構之二三事。

標籤：性問題   ejs   選型   工具   邏輯   圖片   瀏覽器   項目   包括   

現在的前端工作中，移動端的地位甚至已經超過了PC端，也趁著有時間，來全面總結一下移動端頁面重構的注意事項和一些小技巧。

話不多說，首先項目開始前，首先要進行整體規劃和準備工作。

一.整體規劃與準備

1.項目構建目錄

前端項目如火如荼的發展著，項目開發之處的準備工作也越來越複雜，IT項目的發展都是為了更高效的開發，也就是易用性、高擴充性、高維護性三個方面。構建目錄時應就具體情況進行分析，不外乎以下幾點：

（1）生產環境與發布環境目錄（是否使用打包工具、編譯器等，例如webpack、less、sass、postCSS、babel，項目測試無誤後輸出發布發布環境。）

（2）構建工具目錄（gulp、grunt、webpack）

（3）模組載入器目錄（require、sea、webpack）

（4）測試環境目錄

（5）真機調試（在此注意，瀏覽器端預覽是基於像素比和視口，對移動端裝置大小進行的類比，無法完全類比移動端裝置。）

若不使用額外工具，此項可以忽略。之前常用gulp的browser-sync，會在gulp的構建目錄中存在。

（6）主檔案目錄（大學時剛接觸前端可能就這一個目錄，在此用於自嘲 ^_^）

包括css目錄、js目錄、圖片、字型等。小項目中，第（3）條的載入器也可包含在此，此目錄具有靈活性。

（7）模板與路由等邏輯層目錄等（注意：此處針對於使用node.js為後端語言的前端開發人員，若後端語言為php、java等可不作考慮）

node.js是趨勢，模板目錄以express+ejs為例（鄙人只用過express），一般將ejs檔案放於一個目錄之下，而路由檔案放於route目錄之下，主檔案（app.js）經路由分發後再route下拿到具體的邏輯檔案進行執行，然後返回給瀏覽器端進行渲染（大多後端語言的模板都是如此）

2.選擇合適的技術棧

在此不作過多解釋，基於儘可能高的開發與執行效率，根據公司要求或個人喜好進行選擇。

3.頁面單位選型與布局

單位的選型直接關係到頁面呈現的效果，根據我的經驗有以下幾種選擇：

（1）簡單粗暴的完全使用媒體查詢

簡單粗暴但確實是想要什麼效果就有什麼效果，只要你不嫌麻煩。在追求高效開發的前端行業，這項選擇可以抹去。

（2）純純的使用em

個人更喜歡在響應式的時候使用em在根節點用於區分PC端和移動端的基礎字型大小。不過，在純移動端也不乏為一種不錯的解決方案。但是，因為em在計算字型大小時是相對於父節點的字型大小計算的，所以要處理好父節點的fontsize大小就顯得尤為重要，而一旦處理不好就會有牽一髮而動全身的趕腳。純純的使用em，個人不是很建議，因為一個節點使用em不但取決於父節點，更影響著子節點。獨立操作的空間稍顯不足。

（3）純純的使用rem

但從想法上看，完全的流體布局，是最佳解決方案，但存在相容性問題，如Chrome的最小字型為12px，但其他多數瀏覽器最小字型可在12像素下。真機調試時你就會發現，12像素是正常使用者可容忍的最小字型，但使用rem稍有不慎就會使字型小於12像素，因此，此選擇要求開發人員時刻謹記最小字型的臨界大小。

（4）VW、VH（這裡的V指viewport）

VW：視口寬度的百分比。如1VW為視口寬度的1%，VH同理；vmin視口寬度和視口高度中得最小值，vmax同理；

使用視口單位是真正意義上實現流體布局的選擇，因為它除了基於視口大小外不受任何其他因素影響。個人很看好視口單位的後續發展，畢竟是直截了當的根據響應式設計的。但由於種種原因，目前使用還不是很廣泛，但在局部布局或解決具體問題時時往往會起到點睛的效果。

（5）em+媒體查詢

建議使用，常規單位操作使用em，具體操作使用媒體查詢。

（6）rem+媒體查詢

建議使用，常規流體布局操作使用rem，具體操作（如最大最小字型等）使用媒體查詢。

搭配使用是最佳選擇，特殊項目還需要具體分析，以上分析與建議建立在常規的純移動端項目中。

 

移動端頁面重構之二三事。