移動web

移動web的基礎知識（the basic knowledge of mobile web）

·px:css pixels邏輯像素，瀏覽器使用的抽象單位，根據不一樣的設備，會變大或者變小

　　iphone5的分辨率是640*1136（使用的物理像素）。320px*568px(使用的邏輯像素)

·dp,pt:device independent pixels設備無關像素，不會隨設備的變化而變化的大小

·dpr：devicePixelRadio設備像素縮放比

 

平面上：1px = 2*2*dp   緯度上：1px = 2*dp   

dp與px之間的關係是經過dpr進行控制的，計算公式爲1px = (dpr)*(dpr)*dp。由於iphone5的dpr=2，因此iphone5的分辨率是320px*568px,也能夠說是640dp*1136dp。

因此640px*1136px的圖片不能在iphone5上徹底展現。

·DPI：打印機每英寸能夠噴的墨汁點（印刷行業）

·PPI：屏幕每英寸的像素數量，即單位英寸內的像素密度

在計算機顯示設備參數描述上，兩者意思表達的都是單位面積內的像素密度。以iphone5爲例子進行計算說明

ppi = √(1136²+640²)/4 = 326ppi(視網膜Retina屏)，計算ppi的時候應該用物理像素計算

ppi越高，像素數越高，圖像越清晰。但可視度越低（小），系統默認設置縮放比越大（好比：pc的分辨率越高，則桌面上的icon越小）

表1

ppi 默認縮放比	ldpi	mdpi	hdpi	xhdpi
	120	160	240	320
	0.75	1.0	1.5	2.0

Retina屏（高清屏）：dpr都是大於等於2

以iphone5爲例設備分辨率轉爲像素分辨率：官方指導iphone5的設備分辨率爲1136*640dp,根據公式獲得其爲326ppi，326ppi屬於retina高清屏，根據表1獲得默認縮放比dpr=2，再根據公式1px = dpr²*dp獲得iphone5的屏幕爲320*568px

·Viewport

pc端的頁面會把整個頁面渲染在移動端的一個viewport裏面，來保證能夠在移動端看到頁面的全貌。

ios的viewport廣泛爲980px，安卓的viewport可能有640px,1000px,1200px等等

手機瀏覽器默認爲咱們作了兩件事情：

　　一 頁面渲染在一個980px(ios)的viewport中

　　二 頁面渲染在viewport中後，進行縮放。

　　這樣作的目的能夠防止屏幕太小時排版的混亂，因此在pc頁面在移動端進行渲染時，虛擬了一個viewport來保證排版的正確。

viewport能夠細分爲兩層，一層是visual viewport(視圖viewport,控制窗口縮放的大小),一層是layout viewport(佈局viewport,這個viewport就指的移動端瀏覽器默認的viewport，如ios的980px)

設計移動web通常不使用默認的980px佈局的viewport，緣由有如下幾點：

　　1，寬度不可控制，不一樣系統不一樣設備的默認值均可能不一樣

　　2，頁面縮小版顯示，交互不友好

　　3，連接有時不可點

　　4，有縮放，縮放後有滾動

　　5，font-size爲40px纔等於PC上的12px同等物理大小，不規範

可使用meta標籤改變默認的viewport

·meta標籤

<meta name="viewport" content="width=device-width,initial-scale=1.0"> 保證默認viewport的寬度始終等於設備寬度

　　width:設置佈局viewport的特定值（「device-width」）

　　inital-scale:設置頁面的初始縮放

　　minimum-scale:最少縮放

　　maximum-scale:最大縮放

　　user-scalable:用戶可否縮放

 　　移動頁面的最佳設計比爲：佈局viewport = 設備寬度 = 度量viewport。所以meta標籤最佳設置爲

　　<meta name='viewport' content='width=device-width,initial-scale=1,user-scalable=no'

 ·設計移動web

　　方案一：根據設備的實際寬度來設計（經常使用）

　　　　　　手機寬320px，就拿320px設計

　　方案二：1px = 1dp

　　　　　　縮放0.5，根據設備的物理像素dp等於抽象像素px來設計。1px邊框和高清圖片都不須要額外處理

 

高效的移動web佈局（efficient mobile CSS layout）

PC端的頁面常使用的兩種佈局爲固定佈局和流體佈局，其中固定佈局佔主導。

可是移動端頁面沒法使用固定佈局，由於移動設備的屏幕及分辨率很是多，因此在移動端常用響應式佈局及flex彈性佈局。

·使用flex彈性盒子佈局，實現根據元素個數不一樣，自動填充容器，如下是flexbox的幾種經常使用佈局模式

　　flex等比劃分

　　　　父容器 display:-webkit-flex   子容器1  flex:1(等比佔1/3)    子容器2  flex:2(等比佔2/3)

　　flex混合劃分

　　　　父容器 display:-webkit-flex   子容器1  flex:1(等比佔1/3)    子容器2  flex:2(等比佔2/3)   子容器3  width:100px;

　　　　這種佈局方式在移動web的應用場景更加普遍，好比圖文混合的狀況，通常圖片爲了保證清晰度不宜放大，因此圖片採起固定寬度，而文字則能夠根據容器的大小而變化

　　不定寬高的水平垂直居中

　　　　父容器  { display:-webkit-flex;justify-content:center;align-items:center}

 flex兼容性

　　1，ios可使用最新的flex佈局；2，android4.4一下，只能兼容舊的flex佈局；3，android4.4以上，可使用最新的flex佈局

·響應式設計

 　　使用百分比佈局

　　　　僅僅使用媒體查詢來適應不一樣的固定寬度設計，只會從一組css到另外一組css的切換。兩種之間的沒有任何平滑漸變（好比使用media爲iphone和ipad air都設置了樣式，可是兩者之間的ipad mini沒有設置樣式，這樣會致使ipad mini上的樣式錯亂）

 　　 彈性圖片

　　　　圖片也使用百分比，不管什麼狀況下，都全包在圖片的元素寬度範圍內，以最大的寬度同比完整的顯示圖片。如img{max-width:100%}

　　 從新佈局，顯示與隱藏

　　　　當頁面達到手機屏幕寬度的時候，不少時候就要放棄一些傳統的頁面設計思想。儘可能保證頁面的簡單、整潔。能夠採起下述方法進行處理

　　　　1,同比縮小元素的尺寸；2，調整頁面結構佈局；3，隱藏冗餘的元素；

　　常常須要切換位置的元素使用絕對定位，減小重繪，提升渲染性能

　　響應式的利弊

　　　　1，根據響應式的設計理念，一個頁面包含全部設備不一樣屏幕的樣式和圖片，當一個移動設備訪問一個響應式的頁面，就會下載PC、ipad、iphone等不一樣設備對應的樣式，而這些樣式倒是冗餘的，沒有必要的。

　　　　2，雖然響應式的設計性能不是最優的，可是卻能夠減小重複開發，一個樣式同時適配多端。

·移動web特別樣式處理

　　高清圖片

　　　　好比100px*100px的圖片在Retina屏幕上渲染，則是在200dp*200dp的屏幕上渲染的，因此會拉大。因此在移動web頁面上渲染圖片，爲了不圖片產生模糊，圖片的寬高應該用物理像素單位渲染，便是100*100的圖片，應該使用100dp*100dp

　　　　width:(w_value/dpr)px;  height:(h_value/dpr)px

　　一像素邊框

　　　　Retina屏幕下的問題，根本緣由是border:1px使用2dp進行渲染

　　　　因爲border:0.5px的這種解決方式在安卓上不適用，因此通常能夠採用scale(0.5)進行一下縮放

·相對單位rem

　　爲了適應各大屏幕的手機，px不能根據尺寸的大小而改變，使用相對單位更能體驗頁面兼容性

　　em:根據父節點的font-size爲相對單位；這個單位在多層嵌套下，會變得很困難

　　rem:根據html的font-size爲相對單位；這個單位更加能做爲全局統一設置的度量

　　爲了適應各大手機屏幕，rem的基值設置爲rem=screen.width/20

　　html{font-size:32px}  iphone5

　　@media (min-device-width:375px){html{font-size:37.5px}}   iphone6

　　@media (min-device-width:414px){html{font-size:41.4px}}   iphone6 plus

　　通常font-size不使用rem等相對單位做爲單位，由於字體的大小是趨於閱讀的實用性的，並不適合於排版佈局。

·多行文本溢出

　　單行文本溢出 .inaline{overflow:hidden;white-space:nowrap;text-overflow:ellipsis;}

　　多行文本溢出 .inmoreline{display:-webkit-box!important;overflow:hidden;text-overflow:ellipsis;word-break:break-all;-webkit-box-orient:vertical;-webkit-line-clamp:3;} -webkit-line-clamp的值表示在第幾行用「...」表示溢出

終端交互優化(interactive optimization in mobile web）

　　移動web頁面上的click事件響應都要慢上300ms。是由於移動設備訪問的web頁面都是pc上的頁面，在默認viewport(980px)的頁面每每都是須要「雙擊」或「捏開」放大頁面以看清頁面。而正是爲了確認用戶是「雙擊」仍是「單擊」。safari須要個300ms的延遲來判斷，然後來的iphone也一直延續這種設計，而借鑑iphone的android也沿用這樣的設計。因而「300ms的延遲」成爲了一道規範。

　　使用tap事件代替移動web中的click事件。使用touch事件進行模擬。

　　tap事件在移動端的點透的bug，這個bug和300ms的延遲有關

　　　　移動端click事件的觸發過程：touchstart,touchend....300ms......click觸發

　　　　移動端點透發生的過程：touchstart致使蒙層消失,touchend冒泡到btn上.....300ms.....btn的click觸發

　　tap透傳的解決方案

　　　　1，使用緩動動畫，過渡300ms的延遲

　　　　2，中間層dom元素的加入，讓中間層接受這個‘穿透’事件，稍後隱藏

　　　　3，‘上下’都使用tap事件，原理上解決tap透傳事件（但不可避免原生標籤的click事件，好比<a>）

　　　　4，使用fastclick庫或者最新的zepto

Touch基礎事件的經常使用屬性

　　-touches:跟蹤觸摸操做的touch對象數組

　　-targetTouches:特定事件目標的touch對象數組

　　-changeTouches:上次觸摸改變的touch對象數組

var touchHandler = function(e){ var type = e.type; //touchend的touches和targetTouches爲空，
　if(type !== 'touchend'){ 　　var pos = { 　　　　x:e.touches[0].clientX, 　　　　y:e.touches[0].clientY 　　} 　　switch(type){ 　　　　case 'touchstart':break; 　　　　case 'touchmove':event.preventDefault();break;//安卓4.4.4.0的bug，只觸發touchstart,和一次touchmove,touchend不觸發。加入preventDefault會解決這個bug，可是會致使阻止默認事件，好比scroll,致使頁面不滾動。
　　　　case 'touchend':break; 　　} 　} }

touch.js

var touch = { startX: 0, startY: 0, endX: 0, endY: 0, touchStart: function (event) { var touchPoint = event.touches[0]; this.startX = touchPoint.pageX this.startY = touchPoint.pageY this.endX = 0
        this.endY = 0 }, touchMove: function (event) { var touchPoint = event.touches[0]; endX = touchPoint.pageX endY = touchPoint.pageY }, isSwipe: function (strX, endX, strY, endY) { var flag = false; if (endX && endY) { flag = Math.abs(endX - strX) > 80 || Math.abs(endY - strY) > 80 } return flag; }, swipeDirection: function (strX, endX, strY, endY) { var swipeDirection = Math.abs(endX - strX) > Math.abs(endY - strY) ? ((endX - strX) > 0 ? "Right" : "Left") : ((endY - strY) > 0 ? "Down" : "Up"); return swipeDirection.toString(); } }; var touchEvents = { touchstart: "touchstart", touchmove: "touchmove", touchend: "touchend", /** * @desc:判斷是否pc設備，如果pc，須要更改touch事件爲鼠標事件，不然默認觸摸事件 */ initTouchEvents: function () { if (!isAppBrowser()) { this.touchstart = "mousedown"; this.touchmove = "mousemove"; this.touchend = "mouseup"; } } }; function isAppBrowser() { var userAgentInfo = navigator.userAgent; var Agents = ["Android", "iPhone", "SymbianOS", "Windows Phone", "iPad", "iPod"]; var isAppBrowser = false; for (var v = 0; v < Agents.length; v++) { if (userAgentInfo.indexOf(Agents[v]) > 0) { isAppBrowser = true; break; } } return isAppBrowser; }

移動web效果之彈性滾動

當客戶端的頁面滾動到頂部或者底部的時候，滾動條會收縮並讓咱們多滑動必定距離。經過緩衝反彈的效果，帶給用戶良好的體驗。這種效果通常在原生APP中出現，移動web頁面也能夠作到，但滾動有幾種狀況須要考慮：

　　-body層滾動：（系統特殊化處理）自帶彈性滾動，overflow：hidden失效，GIF和定時器暫停

　　-局部滾動：沒有彈性滾動，沒有滾動慣性，不流暢

　　　　局部滾動開啓彈性滾動方法：body{overflow:scroll;-webkit-overflow-scrolling:touch;}。可是android不支持原生的彈性滾動，即上述樣式沒有生效，能夠藉助第三方庫iScroll來實現。

移動web效果之下拉刷新

頂端下拉一小點的距離，頁面彈性滾動向下

移動web效果之上拉加載

使用scroll事件，而不是touch事件（android有bug）