移動端開發基礎 乾貨分享

移動端開發

咱們如今關注的點還在移動M站上，或者咱們能夠叫作webapp，其實就是運行在移動端瀏覽器中的web網站

app:application應用程序。手機軟件:主要指安裝在智能手機上的軟件，完善原始系統的不足與個性化。

移動端開發是與PC端確定是有很大不一樣的，因此咱們須要學習如何在移動設備上開發完美適配的app

開發移動端應用咱們須要學習的知識點能夠分紅以下幾個：

1. 移動端佈局適配

2. 移動端事件

3. 移動端交互效果

4. 移動端前端框架

5. 移動端調試

移動端佈局適配

從屏幕尺寸、屏幕類型等方面來看的話，移動設備和PC設備大有不一樣，因此從佈局、適配等方面都須要咱們考慮到

Viewport視口的做用

在好久之前，咱們的設備還不是智能設備的時候，設備訪問智能訪問到網頁的左上角（當時都是pc網站），查看所有內容須要經過滾動條

慢慢的咱們發現，咱們的一個頁面放到移動端中訪問的時候，沒有滾動條了，可是內容都縮小了

這是由於咱們有了一個叫作viewport的一個東西

網頁不是直接放入瀏覽器中的，而是先放入到viewport中，而後viewport在等比縮放到瀏覽器的寬度，放入瀏覽器，viewport在縮放的過程當中，網頁內容也被縮小了

這樣的話咱們須要作一些處理，其實問題的根源在於viewport的寬度和瀏覽器寬度不同，若是咱們能將其設置爲同樣的話，不會出現這樣的問題了

咱們能夠經過meta標籤來設置viewport將其設置爲瀏覽器的寬度，也就是設備的寬度，這樣的話佈局就會簡單多了

viewport的寬度

當瀏覽器寬度小於980的時候，寬度就是980，當瀏覽器尺寸寬度大於980的時候，寬度和瀏覽器寬度一致

經過meta標籤來設置viewport

標籤提供關於 HTML 文檔的元數據。它不會顯示在頁面上，可是對於機器是可讀的。可用於瀏覽器（如何顯示內容或從新加載頁面），搜索引擎（關鍵詞），或其餘 web 服務。

meta標籤大全

meta viewport 的6個屬性：

width	值
initial-scale	設置layout viewport 的寬度，爲一個正整數，或字符串"width-device"
minimum-scale	設置頁面的初始縮放值，爲一個數字，能夠帶小數
maximum-scale	容許用戶的最大縮放值，爲一個數字，能夠帶小數
height	設置layout viewport 的高度，這個屬性並不重要，不多使用
user-scalable	是否容許用戶進行縮放，值爲"no"或"yes", no 表明不容許，yes表明容許

移動端佈局方式與設計圖

現有的佈局方式：

1. 固定佈局，每個元素都是固定的尺寸，內容區域居中在瀏覽器中間

   內容區域的尺寸：980,1000,1100,1200

2. 響應式佈局，利用媒體查詢來實現不一樣尺寸的瀏覽器顯示結構不同

   通常會有三張設計圖，PC,平板,手機

3. 自適應佈局，屬於響應式裏的一種，利用rem、百分比、vwvh等佈局單位來實現

   設計圖通常只有一張，640、750居多

移動端佈局

移動的屏幕和PC的屏幕有一個很大的區別，移動端是視網膜高清屏（Retina）

retina屏幕有一個屬性叫DPR（設備像素縮放比） = 物理像素/邏輯像素

例如，iphone 5s手機商宣傳手機的尺寸是：640寬，這個值就是物理像素，而從開發者眼裏咱們所指的實際上是320px（邏輯像素）

在dpr爲2的手機中，咱們的一個邏輯像素會從橫縱兩個方向分別以2個像素點來渲染

若是無論dpr的話，其實咱們佈局依然能夠，由於咱們設置一個像素寬高的東西的話，在手機上看見的基本也就是這麼大，至於手機設備用多少個物理像素去渲染，大小仍是不會變化的

設計師出圖都是2倍的，是由於，在頁面中除了字體（矢量圖）大部分都是位圖，也就是若是一個像素寬高的盒子裏準備放入圖片，若是圖片的尺寸也是一個像素寬高的話，由於其實在移動端渲染的時候是用四個像素來渲染，圖片會失真，可是若是咱們給一像素寬高的盒子放入2像素寬高的圖片的話，不就失真

佈局單位

由於咱們的移動設備有不少種，因此咱們的佈局不多是固定佈局，因此咱們要使用自適應佈局

咱們在開發中能夠選用不少自適應佈局單位，這些單位必須知足一個條件

1. %比佈局

   優勢：簡單，無需設置，兼容性好
   缺點：基於父元素的屬性來設置，若是父元素沒有寬高，設置無效

2. vwvh

   一個vw等於viewport寬度的百分之一，一個vh等於viewport高度的百分之一
   vmax等於vw和vh中較大的那個 vmin等於vw和vh中較小的那個

   優勢：簡單，無需設置
   缺點：兼容性很差

3. rem

   一個rem等於根元素（html）的字體大小，兼容性很好

   優勢：兼容好，使用簡單
   缺點：須要設置

rem與適配

當咱們想使用一個自適應單位的時候，發現%有缺陷，vwvh兼容性差，彈性盒所針對的是元素排列的問題，只適用於某種狀況，因此咱們就想，能給我一個沒啥上面的缺陷的單位，想到了rem

rem的兼容性好一點，它也確實是一個佈局單位，不受父子元素的影響，設置了rem以後，也不會對px、em等單位形成影響，它是一個理想的單位

rem也有一個致命的問題，就是它不是一個自適應的單位，不會跟着設備尺寸不一樣而不一樣，可是沒有關係，咱們有萬能的js，能夠去動態的設置它

方法1：

咱們能夠將1rem設置成屏幕的某一個比例，好比將1rem設置成屏幕的十分之一

假設咱們的設計圖是640寬的，咱們拿到以後量了一下a的寬度爲480px，獲得比例a所佔屏幕3/4，根據rem與屏幕的關係，最後設置成7.5rem

就是說在設置元素的寬度是時候，會根據設定好的比例關係去進行換算

方法2：

若是設計圖是640的圖，這個時候咱們知道它是照着i5來的，咱們如今假設世界上全部的手機都是320的，也就是每個人用的都是i5，在這個理想的狀況下，由於手機都同樣，尺寸都同樣，和pc端的固定佈局也就同樣了

假設有一個在640的圖上咱們量得的寬度是320，由於是二倍圖，因此咱們知道，它的實際寬度是160px，這樣的話，咱們直接給這個設置設置width：160px就能夠了，這個時候，咱們玩個花子，不要單純的使用px來設置，用rem來設置，例如，我能夠將rem設置爲100px，這樣的，剛纔的盒子設置爲width：1.6rem，算法就是 量的寬度/(dpr*100) = 要設置的rem值

這樣咱們就能夠開心的開發，量一個尺寸，除個2，再小數點推兩位，設置就性了，可是咱們也知道，手機的尺寸並不可能都是320，這樣的話，沒有關係，咱們能夠根據一個比例來算rem到底設置爲多少

在手機寬度爲320的時候，咱們設置的1rem=100px，因此有一個比例 b = 100/320

那麼在W寬度的手機上，1rem應該是多少呢？設爲x 那麼x/w = b

獲得x = w/3.2

那麼就不要寫死html的fontsize爲100了。而是用js去設置：

document.documentElement.style.fontSize = document.documentElement.clientWidth/3.2 + 'px'

這樣，咱們就能夠獲得一個自適應的rem

方法3：

設計圖若是是640的，咱們知道設計的依據屏幕依然是320，假設全部的手機都是320的

有一個div量得320，咱們知道它的實際寬度是160，因此咱們在css裏直接設置160px。佈局就很簡單了，由於量多少，除以2就能夠直接設置了

可是手機不能只有這一個尺寸，不過不要緊，咱們能夠想辦法，咱們知道，頁面是放在viewport裏的，頁面的寬度就是viewport的寬度，咱們在前面的方法會會將viewport經過meta標籤設置爲手機屏幕的寬度，可是如今咱們就將viewport的寬度強行設置爲320px，那麼咱們頁面就會認爲它的屏幕寬度就是320px，若是是在屏幕寬度不等於320的手機裏，viewport也會進行縮放，縮放到手機屏幕大小，可是這個時候，頁面依然認爲手機屏幕是320的，也就是說，佈局使用固定佈局，自適應由viewport去作了，讓它將我們320的頁面縮放到不一樣尺寸的移動設計，達到表現一致

餓了麼的作法：認爲世界的手機都是二倍寬的，而後再調整viewport

常見的須要注意的問題

1. 1px邊框

   在移動端中，若是給元素設置一個像素的邊框的話，那麼在手機上看起來是會比一個像素粗的。

   解決方法：使用僞類元素模擬邊框，使用transform縮放

.a::after{
        content: '';
        display: block;
        width: 100%;
        height: 1px;
        background: #333;
        position: absolute;
        left: 0;bottom: 0;
        transform: scaleY(0.5)
    }

1. 響應式圖片

   在移動端中，圖片的處理應該是很謹慎的，假設有一張圖片自己的尺寸是X寬，設置和包裹它的div同樣寬，若是是div寬度小於圖片寬度沒有問題，可是若是div寬度大於圖片的寬度，圖片被拉伸失真

   解決方法：讓圖片最大隻能是本身的寬度

   img{
        max-width: 100%;
        display: block;
        margin: 0 auto;
    }

移動端webkit

移動端的瀏覽器的內核百分之99都是webkit內核

---

移動端事件

移動端中的事件和PC的事件有一些是不一樣的，例如，mouse部分事件在移動端裏沒有了

取而代之的是touch事件：

touchstart/touchmove/touchend/touchcancel

添加事件的時候能夠用ontouchstart，可是有的時候極可能失效，建議使用addEventListener的方式

touchcancel比較少見，在系統取消觸摸的時候觸發

touch事件對象裏面的屬性和mouse的略有不一樣，例如在mouse事件裏能夠直接從事件對象裏取出pageX,clientX,screenX

touch事件對象裏有touches,changedTouches,targetTouches三個屬性，上面保存着關鍵的位置信息

它們裏面保存的是觸發事件的手指的信息，可是要注意，雖然三個裏面保存的信息看似都同樣，可是在touchend事件裏，只能使用changedTouches

click的300ms延遲問題

在移動端中，click事件是生效的，可是它有一個問題，點擊以後會有300ms的延遲響應

緣由：safari是最先作出這個機制的，由於在移動端裏，瀏覽器須要等待一段事件來判斷這次用戶操做是單擊仍是雙擊，因此就有click300ms的延遲機制，Android也很快就有了

1. 不用click，用自定義事件tap

   tap是須要自定義的：若是用戶執行了touchstart在很短的時間又觸發了touchend，且兩次的距離很小，並且不能觸發touchmove

   使用zepto類庫的時候，裏面自帶tap事件,，可是須要在zepto.js後面加上一段js

   zepto官網;Touch模塊

   百度有一款touch.js的插件教程

   hammar.js也是一個手勢事件庫文檔

2. 引入fastclick庫來解決

點透bug的產生

點透bug有一個特定的產生狀況：

當上層元素是tap事件，且tap後消失，下層元素是click事件。這個時候，tap上層元素的時候就會觸發下層元素的click事件

解決方式：

1. 上下層都是tap事件，缺點：a標籤等元素自己就是自帶的click事件，更改成tap比較困難
2. 緩動動畫，讓上層元素消失的時候不要瞬間消失，而是以動畫的形式消失，事件超過300ms就能夠了
3. 使用中間層,添加一個透明的中間元素，給它添加click事件並消失，這個時候接收點透的是透明的中間層
4. 使用fastclick

移動端測試

1. 使用chrome瀏覽器有移動設備模擬功能，在這裏能夠作一些模擬測試，可是要注意的是，畢竟不是真機，會有一些測試不到的問題

2. 手機鏈接上電腦的無線，總之使其在同一個網絡裏，而後就能夠經過ip訪問

須要測試的瀏覽器：

chrome，firefox，UC,百度，QQ，微信，Android，safari

移動端交互

動畫效果所有使用css3

JQ生成二維碼

可使用jquery.qrcode.js插件，能夠快速的生成基於canvas繪製的二維碼

兼容查閱網站

can i use,在這裏能夠查看不少屬性、api的兼容性

375/52.08 = X/100 x = 37500/52.08