本身接觸移動端開發是在2012年,那時候比較新潮的是製做WEB APP。什麼是WEB APP呢?所謂的WEB APP就是用網頁模擬出原生語言(如iOS)開發的APP交互效果。雖然在表現層面上,HTML5表現突出,但不得不認可的是,在系統性能層面,WEB APP明顯要差於原生應用(即Native APP)。這也就使得WEB APP這條路暫時性的被堵住了。html
因而,移動端的開發方向逐漸向移動端網頁傾斜。對於PC端,咱們一直使用的是px(像素)進行代碼的書寫,可是到了移動端,須要面臨不一樣的分辨率。在2012年的時候,本身和團隊成員在寫移動端的時候,因爲是初次接觸,仍是在使用px(像素)做爲單位。由於在2012年的時候,絕大多數的手機的屏幕大小都是320*480分辨率,因此,即使是使用像素做爲單位進行移動端網頁開發也是徹底能夠的。瀏覽器
關於視口的知識,可點擊查看——移動端H5知識-視口viewport框架
隨着移動端的繼續發展,在2012年9月,iPhone5上市,開始引領「特殊分辨率」的發展,因而,320*480分辨率的手機屏幕在整個手機市場當中佔有的份額愈來愈少,各類各樣的分辨率如雨後春筍般冒了出來。佈局
此時咱們再進行固定像素進行開發明顯是不明智的。因而,咱們開始採用百分比(相對度量單位)進行盒模型橫向屬性(width、左右內邊距、左右外邊距)的製做,使用em(相對度量單位)實現文字的處理。但盒模型縱向上仍是使用固定像素做爲單位。性能
可是,這種操做致使了一個問題——主要表如今img標籤的處理上。對於圖片來講,只須要設置橫向百分比,縱向會自動等比例縮放。在列表頁以及內容頁還好,畢竟內容是自動撐開父級高度的;可是在首頁或者二級頁,但凡涉及到父級元素高度固定的盒模型,裏面的img就會出現變形(壓縮或者拉伸)的問題。學習
這個問題也是困擾了本身許久,可是一直沒有找到一個很是好的解決辦法。測試
當本身還在糾結img的處理時,2013年,在北京流行起了一種新的技術——響應式佈局。經過媒體查詢,針對不一樣大小分辨率的設備,設置不一樣的樣式。應該說,對移動端頁面的開發幫助不大,緣由在於,響應式的出現主要是由於咱們但願一段代碼可以同時適配PC端、平板電腦以及手機。因爲三種平臺的樣式以及用戶體驗應該是迥然不一樣的,那麼此時,咱們就須要有「斷點」,在不一樣位置,有不一樣的樣式,而在兩個「斷點」之間的樣式,則使用相對單位作「漸變性的過渡」。字體
應該說,響應式佈局解決了典型的屏幕像素不一樣樣式的問題,可是卻依舊搞定不了以前的那個問題。flex
關於CSS3媒體查詢的知識,可點擊查看——移動端H5知識-CSS3媒體查詢優化
在橫向百分比,縱向像素值的方法無效時,本身可以想到的就是縱向也設置爲百分比了,可是卻發現,盒模型屬性在縱向上的一些設置上是存在問題的,如padding-top/bottom、margin-top/bottom等。而文本屬性中line-height在設置百分比時也並非按照當前元素高度計算的。
因而,橫縱向均設置爲百分比的方法就破滅了~
關於盒模型的一些問題以及背景的合理使用,可點擊查看——移動端H5知識-百變盒模型以及移動端H5知識-背景的妙用
隨着HTML5的發展,除了原來的em單位,又新增了rem單位。這兩個單位都是相對單位。1em表示的是當前元素一個字體大小的尺寸;而1rem,也表示的是一個字體大小的尺寸,可是是針對html標籤進行計算的。相比之下,rem的計算起來要簡單不少。因而,本身嘗試用rem解決橫向以及縱向的設置,捨棄掉了百分比,發現仍是挺不錯的,算是兼容了絕大多數機型和瀏覽器。以後,在使用一款華爲手機進行測試的時候,發現並不支持橫向的rem。因而,又須要想辦法啦~~~
針對華爲手機,我嘗試了橫向百分比,發現仍是可以支持的,因而就折中了一下,橫向使用百分比進行控制,縱向使用rem做爲單位。此時可以實現全部瀏覽器的兼容。
在橫向使用百分比,縱向使用rem時,會因爲計算產生必定的偏差,因而,運用學習過的一些HTML5技術,進行移動端頁面的優化,例如,使用CSS3的盒陰影替換掉邊框。而對於rem,在計算中一般是存在必定的字體偏差的(會計算出小數點),此時正好接觸了一下淘寶的移動端頁面,看到了一個不錯的JS框架——flexible.js,經過這個框架對頁面進行處理,可以防止小數點的出現。
關於flexible.js框架的具體用法,可點擊查看——移動端H5知識-處理rem小數點 flexible.js
上個月月初,發現網易移動端的製做方法有些特殊,查看代碼時發現,網易採用了固定像素進行書寫,而經過MetaHandler.js進行了頁面的控制。最近嘗試了一下,感受仍是挺不錯的,兼容也是比較好的,不失爲一種好方法。
關於MetaHandler.js框架的具體用法,可點擊查看——移動端H5知識-固定像素的實現方法