提到移動端適配,首先內心可能會問,咱們爲何要作移動端的適配,怎麼去作移動端端的適配css
首先一個頁面在pc上邊打開,是正常顯示的,可是咱們用手機打開的時候,因爲手機的屏幕尺寸並不能完整的吧頁面所有顯示出來,就算是手動進行縮放也會出現好比說滾動條,頁面佈局錯亂等等各類五花八門的問題,對於用戶的體驗很是的很差html
因而乎就有了移動端的適配,
移動端適配的目的是在不一樣尺寸的設備上,頁面達到合理的展現(自適應)或者說是可以保持統一效果。
前端
在咱們瞭解移動端適配以前 咱們首先要先了解一下viewport的基本概念android
viewport在pc端是指視窗、視口,瀏覽器上用來顯示網頁的那部分區域。ios
移動端則有三個不一樣的視口概念css3
佈局視口:就是在瀏覽器窗口css的佈局區域,通常都會比移動端窗口大不少。web
視覺視口:用戶經過屏幕看到的頁面區域,說白了就是手機屏幕看到的那一塊canvas
還有最後一個理想窗口,下邊是從別處摘下來的一句話瀏覽器
理想視口:通常來說,這個視口其實不是真是存在的,它對設備來講是一個最理想佈局視口尺寸,在用戶不進行手動縮放的狀況下,能夠將頁面理想地展現。那麼所謂的理想寬度就是瀏覽器(屏幕)的寬度了。
服務器
實現這個理想窗口須要在html裏邊加上一個標籤
<meta name="viewport"content="width=device-width,user-scalable=no,initial-scale=1.0, maximum-scale=1.0,minimum-scale=1.0">
這個標籤相比你們都不會陌生,確定之前都用過
那麼這個meat標籤他究竟是起到了什麼樣的做用呢
meta經常使用於定義頁面的說明,關鍵字,最後修改日期,和其它的元數據。這些元數據將服務於瀏覽器(如何佈局或重載頁面),搜索引擎和其它網絡服務。
meta標籤的主要屬性有兩個
http-equiv 這個屬性有點定義http參數的意
他的經常使用參數簡單說明以下
content-Type(設定網頁字符集)
refresh(自動刷新並指向某頁面)
Set-Cookie(cookie設定)
expires(網頁到期時間 這個須要到服務器從新上傳)
上邊那個屬性...說實話用的不是不少,有的一些參數甚至是前幾天纔看到的,
name裏邊的參數就用的比較多了,
一樣先介紹一下name屬性裏邊的參數
首先keywords(關鍵字),這個屬性對於seo來講可謂是事關重要,固然也存在爭議,有人說如今搜索引擎已經不太在乎這個標籤了,可是我我的作了這麼久的seo,不加這個標籤總感受少了一些什麼
description(網站內容的描述),網站的描述,這個標籤在我眼裏和keywords 還有title一個等級,被我當成是網站不可缺乏的三個標籤,畢竟站長工具神馬的都會有顯示,我不相信他沒用
robots(定義搜索引擎爬蟲的索引方式),這個能夠告訴爬蟲 哪些頁面不須要抓取,通常來說,我會把一些簡介性的頁面設置nofollow,避免權重分散
author(做者)
copyright(版權)
viewport(移動端的窗口),這個是今天主要要說的一個參數
還有其餘的一些巴拉巴拉的,
width 設置佈局視口 的寬度,爲一個正整數,或字符串"width-device",這個字符串表示設備的屏幕寬
initial-scale 設置頁面的初始縮放值,爲一個數字,能夠帶小數
minimum-scale 容許用戶的最小縮放值,爲一個數字,能夠帶小數
maximum-scale 容許用戶的最大縮放值,爲一個數字,能夠帶小數
height 設置佈局視口 的高度,通常來說高度不會固定
user-scalable 是否容許用戶進行縮放,值爲"no"或"yes", no 表明不容許,yes表明容許
在平常開發中因爲手機屏幕尺寸不同,分辨率不同,真的是多姿多彩(千奇百怪)
css3媒體查詢 (響應式)
根據不一樣的分辨率去更改樣式,這種方法在我剛接觸前端的時候我用過,恕我直言這種方法真的是賊酸(dan)爽(teng)
他大概是長成這個樣子的
@media screen and (max-width: 320px){ .... } @media screen and (max-width: 375px){ .... } @media screen and (max-width: 414px){ .... }
可是後來我發現一個問題,我不可能把全部的寬都寫進去,並且代碼多的時候巨難維護
我記得我當時大概寫了這麼多的樣式
我甚至一度想放棄作移動端...
百分比佈局
這個佈局我以前也寫過,適配卻是不錯,沒有媒體查詢那麼麻煩,可是每一個元素的寬高都要計算,,百分比後邊的小數算到好幾位也是常常地事...(原諒我是個小白)
須要補充說明的是margin和padding的百分比:在垂直方向和水平方向都是相對於直接父親元素的width,而與父元素的height無關
rem方案
這個是我比較喜歡的,rem是一個只相對於瀏覽器的根元素(HTML元素)的font-size的來肯定的單位
補充一點em和rem的區別
em若是自己有font-size的話,會根據自身的font-size肯定,自己沒有的話是根據父元素的font-size來肯定的
可是最後他們都會轉換成px這個單位
只要改變根元素的font-size的值,以rem爲固定單位的元素大小也會發生響應式的改變,可是須要注意的是,
//onresize 能夠監聽到視口的變化
//方便動態的更改font-size
window.onresize = resize;
function resize()
{
alert("檢測到resize事件!");
}
vm、vh 方案
這個vm vh 是相對於屏幕的寬高去計算的 100vm表示全屏款
100vh表示全屏高 可是兼容性不是太好,有時候並不能達到理想的效果,我記得有一次我使用了一次100vh 結果發現個人手機(安卓)並不能沾滿
響應式網頁設計(英語:Responsive web design,一般縮寫爲RWD),或稱自適應網頁設計、迴應式網頁設計、對應式網頁設計。 是一種網頁設計的技術作法,該設計可以使網站在不一樣的設備(從桌面計算機顯示器到移動電話或其餘移動產品設備)上瀏覽時對應不一樣分辨率皆有適合的呈現,減小用戶進行縮放、平移和滾動等操做行爲。 對於網站設計師和前端工程師來講,有別於過去須要針對各類設備進行不一樣的設計,使用此種設計方式將更易於維護網頁。 此概念於2010年5月由國外著名網頁設計師Ethan Marcotte所提出 採用 RWD 設計的網站使用CSS3 Media queries,即一種對 @media 規則的擴展,以及流式的基於比例的網格[9]和自適應大小的圖像以適應不一樣大小的設備:
(百科全書)
這個問題...我以爲放一張圖自行體會吧
我我的認爲響應式能夠不用js純css就能實現,
自適應須要一點點js來支撐
另外我覺的自適應是包含響應式的,好比說博客園,F12能夠看下,這裏有對響應式與自適應理解不當的地方,歡迎指出
touch事件
touchstart:手指放在一個DOM元素上。
touchmove:手指拖曳一個DOM元素。
touchend:手指從一個DOM元素上移開。
//僞裝上邊有個canvas window.onload = function startup() { var el = document.getElementsByTagName("canvas")[0]; el.addEventListener("touchstart", handleStart, false); el.addEventListener("touchend", handleEnd, false); el.addEventListener("touchmove", handleMove, false); log("初始化成功。") }
以前咱們經常使用的事件
mousedown,mouseup、click等等都是在這個touch事件以後纔會觸發的
這個問題我簡單說說我以前踩過的一個大坑,就是H5軟鍵盤的問題
//fixed定位 //1.ios下fixed元素容易定位出錯,軟鍵盤彈出時,影響fixed元素定位 //2.android下fixed表現要比iOS更好,軟鍵盤彈出時,不會影響fixed元素定位 //3.ios4下不支持position:fixed //解決方案:使用Iscroll,如: <div id="wrapper"> <ul> <li></li> ..... </ul> </div> <script src="iscroll.js"></script> <script> var myscroll; function loaded(){ myscroll=new iScroll("wrapper"); } window.addEventListener("DOMContentLoaded",loaded,false); </script> //position定位 //Android下彈出軟鍵盤彈出時,影響absolute元素定位 //解決方案: var ua = navigator.userAgent.indexOf('Android'); if(ua>-1){ $('.ipt').on('focus', function(){ $('.css').css({'visibility':'hidden'}) }).on('blur', function(){ $('.css').css({'visibility':'visible'}) }) }
在 Android 和 IOS 上,獲知軟鍵盤彈起和收起狀態存在差別,事件不一樣。
在IOS 上,輸入框獲取焦點,鍵盤彈起,頁面(webview)總體往上滾動,當鍵盤收起後,不回到原位,致使鍵盤原來所在位置是空白的。
在 IOS 上,使用第三方輸入法,高度計算存在誤差,致使在有些輸入法彈起,將輸入框擋住一部分。
就這麼一個軟鍵盤 記得我當時弄了一個晚上,越着急越弄很差,越弄很差越着急...
ios的軟鍵盤彈起的時候是整個頁面網上滾的,scrollTop發生變化的高度就是軟鍵盤的高度,可是在軟鍵盤收起的時候這段距離並不會收回
Android 上,軟鍵盤被彈起的時候,整個頁面會被壓縮,準確的來講是視圖會被壓縮,以前高度減去彈起後的高度是軟鍵盤的高度
因此總結以下
在 IOS 上,能夠監聽 聚焦和失焦事件來判斷鍵盤的狀態
在 Android 上,監聽 頁面高度變化能夠判斷鍵盤的狀態
還記得當時是第一次寫移動端的頁,碰到這個軟鍵盤的問題真的是把我折磨的生無可戀,但願對你們有幫助。
以上是我對H5的一些認知,有不對的地方,歡迎指出