H5踩坑系列(一)

提到移動端適配,首先內心可能會問,咱們爲何要作移動端的適配,怎麼去作移動端端的適配css

咱們爲何要進行移動端的適配

首先一個頁面在pc上邊打開,是正常顯示的,可是咱們用手機打開的時候,因爲手機的屏幕尺寸並不能完整的吧頁面所有顯示出來,就算是手動進行縮放也會出現好比說滾動條,頁面佈局錯亂等等各類五花八門的問題,對於用戶的體驗很是的很差html

因而乎就有了移動端的適配,
移動端適配的目的是在不一樣尺寸的設備上,頁面達到合理的展現(自適應)或者說是可以保持統一效果。前端

在咱們瞭解移動端適配以前 咱們首先要先了解一下viewport的基本概念android

viewport的概念

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經常使用於定義頁面的說明,關鍵字,最後修改日期,和其它的元數據。這些元數據將服務於瀏覽器(如何佈局或重載頁面),搜索引擎和其它網絡服務。

meta標籤的主要屬性有兩個

  • http-equiv
  • name
  • 還有一些簡單明瞭的 好比說charset
  • content 和上邊兩個關聯的

http-equiv 這個屬性有點定義http參數的意
他的經常使用參數簡單說明以下

  • content-Type(設定網頁字符集)

  • refresh(自動刷新並指向某頁面)

  • Set-Cookie(cookie設定)

  • expires(網頁到期時間 這個須要到服務器從新上傳)

上邊那個屬性...說實話用的不是不少,有的一些參數甚至是前幾天纔看到的,
name裏邊的參數就用的比較多了,
一樣先介紹一下name屬性裏邊的參數

  • 首先keywords(關鍵字),這個屬性對於seo來講可謂是事關重要,固然也存在爭議,有人說如今搜索引擎已經不太在乎這個標籤了,可是我我的作了這麼久的seo,不加這個標籤總感受少了一些什麼

  • description(網站內容的描述),網站的描述,這個標籤在我眼裏和keywords 還有title一個等級,被我當成是網站不可缺乏的三個標籤,畢竟站長工具神馬的都會有顯示,我不相信他沒用

  • robots(定義搜索引擎爬蟲的索引方式),這個能夠告訴爬蟲 哪些頁面不須要抓取,通常來說,我會把一些簡介性的頁面設置nofollow,避免權重分散

  • author(做者)

  • copyright(版權)

  • viewport(移動端的窗口),這個是今天主要要說的一個參數

  • 還有其餘的一些巴拉巴拉的,

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爲固定單位的元素大小也會發生響應式的改變,可是須要注意的是,

    控制font-size的js代碼必須放在在頁面第一次加載完成以前,而且放在引入 的css樣式代碼以前。

    //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 上,軟鍵盤被彈起的時候,整個頁面會被壓縮,準確的來講是視圖會被壓縮,以前高度減去彈起後的高度是軟鍵盤的高度

而且在點擊軟鍵盤的收起的時候 軟鍵盤的input不會失去焦點

因此總結以下
在 IOS 上,能夠監聽 聚焦和失焦事件來判斷鍵盤的狀態
在 Android 上,監聽 頁面高度變化能夠判斷鍵盤的狀態

還記得當時是第一次寫移動端的頁,碰到這個軟鍵盤的問題真的是把我折磨的生無可戀,但願對你們有幫助。

以上是我對H5的一些認知,有不對的地方,歡迎指出

相關文章
相關標籤/搜索