移動端開發知識小結

meta標籤相關

viewport:能優化移動瀏覽器的顯示。

<meta name="viewport" content="width=device-width, initial-scale=1.0,maximum-scale=1.0, user-scalable=no"/>
<!-- `width=device-width` 會致使 iPhone 5 添加到主屏後以 WebApp 全屏模式打開頁面時出現黑邊  -->

若是不是響應式網站,不要使用initial-scale或者禁用縮放。
適配 iPhone 6 和 iPhone 6plus 則須要寫:css

<meta name="viewport" content="width=375">
<meta name="viewport" content="width=414">

大部分 4.7~5 寸的安卓設備的 viewport寬設爲 360px,iPhone 6 上倒是 375px,大部分 5.5 寸安卓機器(好比說三星 Note)的 viewport寬爲 400,iPhone 6 plus 上是 414px。html

width:寬度(數值 / device-width)(範圍從200 到10,000,默認爲980 像素)
height:高度(數值 / device-height)(範圍從223 到10,000)
initial-scale:初始的縮放比例 (範圍從>0 到10)
minimum-scale:容許用戶縮放到的最小比例
maximum-scale:容許用戶縮放到的最大比例
user-scalable:用戶是否能夠手動縮 (no,yes)
minimal-ui:能夠在頁面加載時最小化上下狀態欄。(已棄用)
注意,不少人使用initial-scale=1到非響應式網站上,這會讓網站以100%寬度渲染,用戶須要手動移動頁面或者縮放。若是和initial-scale=1同時使用user-scalable=no或maximum-scale=1,則用戶將不能放大/縮小網頁來看到所有的內容。前端

WebApp全屏模式:假裝app,離線應用。

<meta name="apple-mobile-web-app-capable" content="yes" /> <!-- 啓用 WebApp 全屏模式 -->

移動端的meta

<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black" />
<meta name="format-detection"content="telephone=no, email=no" />
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no" />
<meta name="apple-mobile-web-app-capable" content="yes" /><!-- 刪除蘋果默認的工具欄和菜單欄 -->
<meta name="apple-mobile-web-app-status-bar-style" content="black" /><!-- 設置蘋果工具欄顏色 -->
<meta name="format-detection" content="telephone=no, email=no" /><!-- 忽略頁面中的數字識別爲電話,忽略email識別 -->
<!-- 啓用360瀏覽器的極速模式(webkit) -->
<meta name="renderer" content="webkit">
<!-- 避免IE使用兼容模式 -->
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<!-- 針對手持設備優化,主要是針對一些老的不識別viewport的瀏覽器,好比黑莓 -->
<meta name="HandheldFriendly" content="true">
<!-- 微軟的老式瀏覽器 -->
<meta name="MobileOptimized" content="320">
<!-- uc強制豎屏 -->
<meta name="screen-orientation" content="portrait">
<!-- QQ強制豎屏 -->
<meta name="x5-orientation" content="portrait">
<!-- UC強制全屏 -->
<meta name="full-screen" content="yes">
<!-- QQ強制全屏 -->
<meta name="x5-fullscreen" content="true">
<!-- UC應用模式 -->
<meta name="browsermode" content="application">
<!-- QQ應用模式 -->
<meta name="x5-page-mode" content="app">
<!-- windows phone 點擊無高光 -->
<meta name="msapplication-tap-highlight" content="no">
<!-- 適應移動端end -->

移動端事件

zepto封裝的手勢事件

  • tap —元素tap的時候觸發。

singleTap and doubleTap — 這一對事件能夠用來檢測元素上的單擊和雙擊。(若是你不須要檢測單擊、雙擊,使用 tap 代替)。android

  • longTap — 當一個元素被按住超過750ms觸發。
  • swipe, swipeLeft, swipeRight, swipeUp, swipeDown — 當元素被劃過期觸發。(可選擇給定的方向)

手機瀏覽器經常使用手勢動做監聽封裝

現今大多數觸屏手機webkit內核提供了touch事件的監聽,讓開發者能夠獲取用戶觸摸屏幕時的一些信息。web

其中包括:touchstart,touchmove,touchend,touchcancel 這四個事件windows

touchstart,touchmove,touchend事件能夠類比於mousedown,mouseover ,mouseup的觸發瀏覽器

而touchcancel許多人不知道它在何時會被觸發而忽略它,其實當你的手指尚未離開屏幕時,有系統級的操做發生時就會觸發touchcancel,例如alert和confirm彈框,又或者是android系統的功能彈窗
這4個事件的觸發順序爲:緩存

touchstart -> touchmove -> …… -> touchmove ->touchend性能優化

點擊穿透bug

點擊穿透場景及緣由

咱們常常會看到「彈窗/浮層」這種東西,整個容器裏有一個底層元素的div,和一個彈出層div,爲了讓彈出層有模態框的效果,我又加了一個遮罩層.而後爲底層元素綁定 click 事件,而彈出層的關閉按鈕綁定 tap 事件。
點擊關閉按鈕,touchend首先觸發tap,彈出層和遮罩就被隱藏了。touchend後繼續等待300ms發現沒有其餘行爲了,則繼續觸發click,因爲這時彈出層已經消失,因此當前click事件的target就在底層元素上,因而就alert內容。整個事件觸發過程爲 touchend -> tap -> click。cookie

  而因爲click事件的滯後性(300ms),在這300ms內上層元素隱藏或消失了,下層一樣位置的DOM元素觸發了click事件(若是是input框則會觸發focus事件),看起來就像點擊的target「穿透」到下層去了。
所以,點擊穿透的現象就容易理解了,在這 300ms 之內,由於上層元素隱藏或消失了,因爲 click 事件的滯後性,一樣位置的 DOM 元素觸發了 click 事件(若是是 input 則觸發了 focus 事件)。在代碼中,給咱們的感受就是 target 發生了飄移。
通用解決方案:採起fastclick

性能優化

技術相關

離線緩存
css優化【3d動畫優化】
js優化 【js worker】
spdy,http2
service worker
入口dns預解析
域名收斂
cookie壓縮
網速及網絡狀況偵測
webp

策略相關

前端資源壓縮去重
首屏前置與資源lazyload
頁面模板與數據分離
適當的base64,首屏css不建議使用
script 異步
後臺智能加載下一頁
圖片漸進顯示

參考資料

HTML head 頭標籤
點擊穿透原理及解決
各位前端er(或所在的前端團隊)在項目中都是怎麼處理移動端的點擊事件的?

相關文章
相關標籤/搜索