① WEB前端瀏覽器兼容性問題(pc端及移動端)2021-02-03
1.當使用transform:translate3d(-50%,-50%,0)居中彈框（div）時，在pc端，內部的文字會模糊。
解決辦法：給body定義樣式
2.用position:absolute/fixed;把一個按鈕固定在頁面的底部，在android系統中，當調用輸入法時，該按鈕會被頂起
3.IOS系統調用第三方輸入法時，系統無法監測到input的input、focus、change、blur事件
4.不同瀏覽器默認margin，padding不同。
5.不同瀏覽器的最小字體不同，有的是10px，有的是12px
6.透明度opacity
7.文字兩端居中text-align：justify；text-align-last：just；在移動端不起作用
② 移動端Web頁面適配方案（整理版）
@(概述)[基本概念|百分比|rem|vw/vh|響應式設計]
移動端web頁面的開發，由於手機 屏幕尺寸 、 解析度 不同，或者需要考慮 橫豎屏 問題，為了使得web頁面在不同移動設備上具有相適應的展示效果，需要在開發過程中使用合理的適配方案來解決這個問題。
早期網頁設計採用 靜態布局 ，通過 <meta> 標簽中的 applicable-device 應用設備標識識別移動設備，即 <meta name = 'applicable-device' content = 'mobile'> ，在 <meta> 標簽中的 viewport 標簽中設置 width ，通過 js 動態修改標簽的 initial-scale 使得頁面等比縮放，剛好占滿整個屏幕。一些文章中有提到靜態布局中頁面各個元素採用 px 為單位，這種方案實現簡單，不存在兼容性問題，但用戶體驗很不友好。
後面出現 流式布局 ，使用百分比 % 定義寬度，高度使用 px 固定，根據可視區域大小實時進行尺寸調整，通常使用 max-width/min-width 控制尺寸范圍過大或者過小。這種方案實現比較簡單，但在大屏手機或橫豎屏切換場景下可能會導致頁面元素被拉伸變形，字體大小無法隨屏幕大小發生變化。
順應不同頁面字體大小展現問題，出現了 彈性布局 。這種布局方案下，包裹文字的元素的尺寸採用 em/rem 為單位，頁面主要劃分區域的尺寸依據情況使用 px 、百分數或者 em/rem 。如一些高校的網站 jlu ，頁面的主要劃分區域使用 px 和百分比，包裹文字的元素和文字採用 em 。
上面的這幾種方案下，頁面元素的大小按照屏幕解析度進行適配調整，但是整體布局不變，對於 響應式web設計 ，網頁布局會隨著訪問它的視口及設備的不同呈現不同的樣式，在實現上可能會以上多種方案的結合，同時搭配 媒體查詢 技術使用，使得一個頁面在多個終端 (PC, mobile, pad) 呈現滿意效果，如 mashable 。
[TOC]
像素，是屏幕上顯示數據的最基本的點，表示相對大小。不同解析度下相同長度的 px 元素顯示會不一樣，是因為像素點的個數相同情況下，不同解析度下每個像素點對應的像素寬度不同。比如同樣是 14px 大小的字，在 1366×768 顯示屏下會顯示的小，在 1024×768 顯示屏下會相對大。也稱為 物理像素（設備像素 ），是解析度的尺寸單位。
印刷行業常用單位，能夠使用測量設備測得的長度，等於 1/72 英寸。
在不同屏幕上， css 像素呈現的物理尺寸一致，但 css 像素對應的物理像素具數不同。標準的顯示密度下， 1 個 css 像素對應一個物理像素，縮放時， 1 個 css 像素對應的物理像素會減增。是一種 設備獨立像素(device independent pixels: DIPs)
像素密度，每英寸所擁有的像素數。值越高，顯示畫面細節越豐富。計算公式為： ，其中 和 是解析度的寬高， 是屏幕尺寸。
列印設備每英寸印刷出來的點有多少個，值越高，圖片越細膩。
設備物理像素和設備獨立像素比 ，即 是指在理想布局寬度，使用多少個物理像素來渲染一個css像素。js中通過 window.devicePixelRatio 獲取，css中通過 -webkit-device-pixel-ratio , -webkit-min-device-pixel-ratio , -webkit-max-device-pixel-ratio 進行媒體查詢。
<meta> 標簽中定義了一些元數據信息，通過設置 <meta name = "viewport"> ，提供有關 視口初始大小 的信息，供 移動設備 使用。屬性值為
移動端涉及 布局視口 （Layout Viewport）、 視覺視口 （Visual ViewPort）和 理想視口 （Ideal ViewPort）。
與移動端web頁面適配有關的手機屏幕特性包括
硬體所支持的，屏幕每行的像素 * 每列的像素點數，單位是 px 。
設備獨立的，軟體可以達到的，個人理解是使得軟體/頁面在不同屏幕上顯示出來的效果一致。
像素解析度 ÷ 邏輯解析度等於 倍率 ，如 @3x 表示解析度的 3 倍。一個已知物理像素大小的元素，如果在普通屏中其設備像素等於 css 像素，但在一些高清屏中，如 Retina 顯示屏，一個css像素對應 2 或 3 個設備像素，這時顯示出來的元素會變小。為了讓元素如期待顯示，需要傳入 原始設計稿尺寸 × 倍率 的設計稿，根據 DPR 的定義，這樣載入後能夠達到同樣的效果。
手機屏幕對角線長度換算成英寸的大小
貼上 源碼 分析
視口 是瀏覽器中用於呈現網頁的區域，移動端的視口通常指的是 布局視口
使用 css 預處理器把設計稿尺寸轉換為 vw 單位，包括 文本 ， 布局高寬 ， 間距 等，使得這些元素能夠隨視口大小自適應調整。以 1080px 設計稿為基準，轉化的計算表示為
響應式設計 使得一個網站同時適配 多種設備 和 多個屏幕 ，讓網站的布局和功能隨用戶的使用環境（屏幕大小、輸出方式、設備/瀏覽器能力而變化），使其視覺合理，交互方式符合習慣。如使得內容區塊可伸縮與自由排布，邊距適應頁面尺寸，圖片適應比例變化，能夠自動隱藏/部分顯示內容，能自動折疊導航和菜單。
③ 移動前端開發和web前端開發有什麼區別
移動前端開發和web前端開發有什麼區別呢？既然都是前端開發，兩者肯定有緊密的聯系，移動前端開發和web前端開發其實都屬於前端開發的范圍，目前前端發展的趨勢就是大前端，可以說是包羅萬象，當然也就包含PC端和移動端領域，而現在的前端開發人員也已早就不是當年的切圖仔了，需要學習和掌握大前端體系方方面面的知識才能在日常的開發中游刃有餘，但是不論趨勢如何發展，目前來看HTML、CSS和Java依然是整個前端開發的三大基石。不論是想做移動前端開發還是web前端開發，這三樣基礎技術都必須熟練掌握。移動前端開發和web前端開發有什麼區別呢？
1、業務的應用場景
web前端開發主要指傳統的PC端網頁開發，頁面主要是運行在PC端瀏覽器中，移動前端開發出來的頁面主要是運行在手機上；直觀上會感覺，PC端頁面大一些，移動端頁面小一些，但是根據開發經驗，頁面大可並不代表書寫的代碼復雜，頁面小也並不意味著開發簡單，難與易主要還是取決於具體的業務需求。
2、新技術的使用
由於在移動端主要以webkit內核為主，對於HTML5等新技術支持的更好，所以可以更大范圍的使用新技術;而PC端開發由於很多場景下要求兼容IE等老版本瀏覽器，出於瀏覽器兼容性的考慮，有些情況下限制了新技術的使用。
3、頁面的適配性
傳統PC端的頁面開發一般都會選擇給頁面設定一個固定寬度，兩側有留白，但是移動端的頁面由於其載體手機屏幕比PC要小很多，一般都會選擇盡可能多的在手機屏幕上顯示內容，這就要求移動端頁面要能夠充分適應各種屏幕尺寸的手機並進行最大程度的利用。從這一點上來說移動端頁面的適配難度更高一些。
4、頁面的性能
PC端的網路情況一般比較穩定，都是通過網線或者Wi-Fi連接網路;但是移動端就比較復雜，除了Wi-Fi，還有2G、3G、4G甚至是在幾種不同的網路連接中交替切換也經常發生，不穩定的網路連接對頁面性能帶來的挑戰是移動端的頁面資源不能太大，否則在惡劣網路情況下時，頁面將會無法訪問 ，嚴重影響用戶體驗。移動前端開發和web前端開發有什麼區別
5、框架選型
由於移動端網路情況的不穩定，導致我們在移動端頁面框架選型時，一般只考慮小而美的框架，例如像zepto.js這樣的壓縮之後只有9.6K，就能滿足一般業務的需要，如果是想要構建更復雜的單頁面應用，可以選擇像vue.js這樣的框架，功能強大，但體積壓縮後卻只有20多K。而web端相對選擇的范圍就比較大，一些比較重型的框架也可以根據項目需求加以考慮，例如古老但龐大的ext.js，依然憑借著眾多UI組件活躍在一些企
④ 移動端H5頁面適配問題研究
剛開始做移動端web開發的同學應該都碰到過頁面適配問題，為什麼我在開發手機上調試好的頁面在其他手機會有這樣或那樣的樣式問題？ viewport 我也設置了，為什麼還是顯示不正常？難道我要為每種手機屏幕寫媒體查詢，有沒有簡單的方式，可以不用關注手機屏幕的差異性呢？
網路中搜索 移動端H5頁面適配 關鍵字，大概可以得到180多萬的搜索結果，由此可見這個問題也得到很多人的關注。本文的目的主要是分析解決移動端H5頁面適配問題過程中牽扯到的知識點，然後梳理分析目前常見的適配解決方案。
由於本文內容較長，下面先給出文章的提綱：
1.1理解移動端單位
1.2理解viewport
2.1圖片高清適配
2.2字體大小適配
2.3布局寬度適配
---這里是分隔符，正文開始---
不知道正在看文章的你對上面列出來的這些單位是不是很熟悉，如果是的話，就可以跳過了。
理解這些單位的用法以及區別，對理解移動端頁面適配有很大的幫助。為了讓你對上面的單位有個大體的認知，這里把上面的單位分成了三類：
下面分別對每個單位展開分析：
*** dpi / ppi ***
** dpi ** , dot per inch ，每英寸的點數；列印或印刷領域使用的單位，代表列印機每英寸可以列印出的點數 。
ppi , pixel per inch ，每英寸的像素數，像素密度；表示圖像或者顯示器單位面積上像素數量。
dpi 和 ppi 都是描述解析度的單位，但是兩者是有區別的，但是在描述手機解析度時，可以認為兩者意義相同，以前android設備偏向於使用 dpi ，ios設備偏向於使用 ppi ，目前android和ios統一使用 ppi 描述手機屏幕的像素顯示密度。
ppi的計算方法：
*** ldpi、mdpi、hdpi、xhdpi、xxhdpi ***
android對移動設備不同屏幕解析度的分類。
*** pt，pc，sp ***
** pt ** ，磅（point的音譯），印刷中使用的表示字型的大小單位，1inch = 72pt （印刷中這個關系成立，ios中不成立），ios開發中使用的邏輯單位，是和設備無關的單位。
** pc ** 印刷中使用的單位，1pc = 12pt，不需要關注。
** sp **， scale independent pixel ，android設備中用來顯示字體大小的，和設備無關的尺寸，當設置字體大小單位為sp時，android系統字體大小會影響設置的字體渲染時的大小。
*** dip / dp ***
** dp/dip**， device independent pixel，表示設備獨立像素，和設備無關的尺寸，相同的dp/dip值，不同設備展示的效果是一樣的。
android使用的單位，之前偏向使用dip，目前建議使用dp。
android設備中，規定160ppi的屏幕，1dp = 1px；320ppi的屏幕，1dp = 2px，所以android設備中dp的計算方法：dp = px * (ppi / 160)，這里的px是指設備的物理像素點。
和ios開發中用的pt單位類似。
*** px ***
** px ** ，像素，有兩種像素概念，一種是網頁設計中使用的css像素，一種是原生移動系統使用的物理像素。
作為css像素時，表示的也是一種設備無關單位，與android中使用的dp類似，默認情況下與系統解析度下的像素大小相同，標清設備中，一個css像素和一個設備物理像素大小相同；在高清設備中，一個css像素可以大於或者等於多個設備物理像素，具體一個css像素，需要多少個物理像素來展示，瀏覽器會根據dpr計算。
原生移動系統中使用px單位時，表示的就是屏幕的物理像素點，每種屏幕的物理像素點大小可能不一樣。
*** dpr ***
** dpr ** ，device pixel ratio， 橫向或者縱向設備物理像素數量與設備獨立像素數量的比值，瀏覽器中可以通過window.devicePixelRatio獲取(存在兼容性問題)。
對於原生app，ios和android系統會自動根據dpr計算出渲染時需要的px值，最終不同屏幕上展示出來的大小很接近；而移動端頁面渲染時想要做到這一點，就必須首先得到設備的dpr，然後再根據dpr計算渲染需要的px值。
ios設備中iphone3的dpr為1；iphone4,5,6,7的dpr為2；iphone6+,7+的dpr為3。iphone6+和iphone7+實際計算出來的dpr應該時2.6左右，但是官方還是建議dpr為3，這是因為ios系統利用了一種「縮減像素采樣」演算法，自動縮減到2.6。
android設備中dpr值有多種，可知的有0.75，1，1.5，1.75，2，2.5，2.75，3，4等。
*** em，rem ***
** em ** 相對單位，CSS2引入的單位，作為字體大小使用時和百分比單位類似，都是相對於最近的父元素設置的字體大小，在body上設置字體大小為100%和設置字體大小為1em是一樣的效果，默認情況下瀏覽器的字體大小為16px，這樣只要瀏覽器默認得字體大小不變，1em = 16px。
** rem ** 相對單位，root em，CSS3新增的單位，作用和em類似，唯一的區別就是em是相對父元素的，rem是相對html根節點的，即所有使用rem單位的子元素的字體大小都是相對根節點的，所以使用rem可以避免使用em帶來的子元素字體大小逐層復合的連鎖反應。
更多關於em，rem的知識參見這篇文章 理解web開發中的em單位和rem單位 。
*** 解析度 ***
平時說的手機屏幕解析度，也稱為物理解析度或者原生解析度，通常包括縱向解析度和橫向解析度，例如iphone6的物理解析度是1334 x 750，其中縱向解析度是1334px，橫向解析度是750px，表示縱向方向可以顯示1334個物理像素點，橫向上可以顯示750個物理像素點，這里描述解析度使用的px單位，和css中使用的px單位意義不一樣，這里代指物理設備的像素點。
還有一種解析度叫做系統解析度，例如iphone6的系統解析度是667 x 375，其中高度是667pt，寬度是375pt，這里描述解析度使用了pt單位，是一種設備無關單位。
屏幕尺寸相同的設備，物理解析度越高，ppi也就越大，絕對單位面積上展示的物理像素數量越多，展示圖片也就越細膩。
蘋果把ppi > 300的屏幕稱為視網膜屏,Retina屏。
傳統桌面web頁面布局通常是定寬布局，但是定寬布局的方式對移動端卻不適用，原因手機屏幕尺寸大小各異，定寬布局可能在某些手機上出現橫向滾動條，導致閱讀效果比較差。
為了讓手機有更好的網頁瀏覽體驗，蘋果引入了viewport，為頁面提供了一個虛擬的布局窗口，在這個虛擬的布局窗口中渲染頁面，然後系統會把渲染好的頁面自動縮放到手機屏幕大小。
雖然viewport還沒有成為正式的規范，但是現在絕大部分瀏覽器都支持viewport。
在桌面瀏覽器中，viewport嚴格等於瀏覽器窗口大小，頁面渲染時，頁面寬度不會超過瀏覽器的寬度。
移動端屏幕太窄，為了提供更好的頁面體驗，移動端提供了兩種viewport： 可視viewport ， 布局viewport 。
可視viewport 就是當前屏幕正在展示的區域，也就是移動設備屏幕的寬度，寬高通過window.innerWidth和window.innerHeight獲取（存在兼容性問題）。
布局viewport ，頁面布局實際用到的viewport，通常比可視viewport要寬，寬高通過document.documentElement.clientWidth和document.documentElement.clientHeight獲取。
移動端還有一種viewport概念，可以理解為 理想viewport ，作用就是在理想viewport下，不同移動設備，展示的字體大小接近，並且不需要用戶縮放就可以展示全部的頁面內容。
理想viewport的寬度默認等於可視viewport的寬度，但是對同一台設備來說，這個理想viewport的寬度是可以改變的，而可視viewport的寬度是不可變的。
如何使用理想viewport來布局頁面呢？只需要設置viewport的width等於device-width。
viewport的屬性，推薦使用以及支持度較廣泛的屬性只有6個： width ， height ， initial-scale ， maximum-scale ， minimum-scale ， user-scalable 。
width 設置viewport布局寬度，內核是webkit的瀏覽器默認值是980px，取值范圍在200-10000px，也可以取值為設備寬度device-width（等於橫向設備無關像素數量）。
height 設置viewport布局高度，默認值依賴設備長寬比以及寬度值，取值范圍在223-10000px，也可以取值為設備高度device-height。
initial-scale 設置初始縮放比例，頁面第一次載入時的縮放比例。默認比例依賴於顯示密度。在密度低於200 dpi的顯示設備上，比例為1.0。在密度介於200及300 dpi之間的顯示設備上，比例為1.5。對於具有300 dpi以上密度的顯示設備，比例為密度/150 dpi向下取整的結果。取值范圍由 maximum-scale 屬性以及 minimum-scale 屬性決定。如果設置 initial-scale 值為1， width 默認是device-width， height 默認是device-height
initial-scale 設置的縮放大小會改變理想viewport的大小，不會改變可視viewport的大小，也不會改變布局viewport的大小，這是某些適配方案依賴的基本原理，也是解決 1px問題 的關鍵。後面分析適配方案時，動態viewport適配方案就依賴這個知識點。
maximum-scale 允許用戶縮放到的最大比例，默認值是0.5，范圍從0到10.0。
minimum-scale 允許用戶縮放到的最小比例，默認值是5.0，范圍從0到10.0。
user-scalable 用戶是否可以手動縮放，值可以是：yes/true允許用戶縮放；no/false不允許用戶縮放。
圖片適配的目的是為了在頁面中可以高清還原設計圖中用到的圖片。
頁面中用到的圖片是否清晰和展示頁面的硬體設備的dpr以及圖片解析度這兩個因素有關，下面會通過三個例子來說明這個問題。
***示例一 ***
例如dpr=2的設備，1個設備無關像素(android中的1dp，ios中的1pt)需要4個設備物理像素點填充。對於尺寸為100 x 120 (px)的圖片，如果用 <img> 來展示，圖片顯示時會產生模糊現象。
原因：渲染圖片時，寬度是100px，所以橫向會佔用100個設備無關像素，高度是120px,所以縱向會佔用120個設備無關像素，每個設備無關像素又需要2x2個物理像素點來填充，而圖片在每個設備無關像素(px)單位上提供的像素點只有1x1個，這時，系統通過一定的演算法在這1個像素點上就近取色，取到4個顏色(這4種顏色接近但是有一定區別)之後，當成4個像素點，然後填充到1個設備無關像素點上，這樣就導致圖片顯示時模糊，dpr越大，這種方式顯示的圖片越模糊。
示例二
還是dpr=2的設備，但是准備了一個尺寸為200 x 240 (px)的圖片，還是用 <img> 來展示，這時顯示的圖片就比較清晰了。
原因：這時圖片本身可以在一個設備無關像素單位上提供2x2個物理像素點，設備展示圖片時直接拿圖片提供的像素點來填充就可以了，不用對像素點進行處理，所以可以比較清晰的顯示圖片。
示例三
還是dpr=2的設備，這次准備一個尺寸400 x 480 (px)的圖片，還是用 <img> 來展示時，這種情況展示的圖片缺少銳利度，也影響了圖片的清晰度，但是很難看出來。
原因：圖片本身在一個設備無關像素點單位上提供了4x4個物理像素點，而設備本身只需要2x2個物理像素點，所以會通過縮減采樣演算法，在圖片提供的4x4個物理像素點中，選取顏色接近的2x2個物理像素點填充到設備無關像素點上，所以也會產生一定的色差，這種情況下圖片尺寸越大，這種色差也就越明顯，但是人眼很難區分這種色差。
下面是我在oppo的一款手機上的測試結果，結合這張效果圖就可以很好的理解上面的三個示例了：
圖片適配最佳實踐
要想高清顯示圖片，如果條件允許(有單獨的圖片伺服器)最直接的解決辦法，肯定是根據設備的dpr，為不同dpr的設備載入不同倍率大小圖片顯示；沒這種條件的或者對用戶體驗沒有很高要求的，只能選一種折中的方案了，一般情況下只需要提供布局尺寸2倍大小的切圖就可以了，也就是只高清適配dpr=2的設備，但是dpr為3或者4的設備展示效果也能接受，不容易看出來模糊現象。目前主流機型的dpr也就在2和3之間。
字體適配目標主要還是看設計要求，主要有兩種：
1.不同屏幕下，字體顯示大小都一樣，即需要等寬顯示字體；
2.不同屏幕下，一行能顯示的字數固定，即需要按比例縮放字體大小；
開始分析之前，先看下這兩種字體適配的示例：
第1種字體適配方案的示例
第2種字體適配方案的示例
下面就來具體分析下兩種字體適配方案的原理以及優劣。
** 第1種字體適配方案原理 **
在開始分析這種方式的原理之前，先通過一張圖理解下px和dp以及絕對長度之間關系。
由上圖可知字體大小隻與css單位px有關，而每個設備上px的絕對寬度又和設備的絕對寬度以及絕對寬度上劃分出的設備無關像素點dp有關；只要設備的橫向dp數量與絕對寬度的比值(dp/cm)相同，就可以保證px在不同設備上展示的絕對寬度是一樣的；如果dp/cm的比值過大，那麼px的絕對長度就會變小，看起來就會顯小；如果dp/cm的比值過小，那麼px的絕對長度就會變大，看起來就會顯大；一般來說手機屏幕解析度越高，相同px值的字體看起來就會越小。
iphone5和6的dp/cm比值十分接近，所以12px大小的字體在這兩種手機上顯示的大小基本一樣，看不出來區別，但是iphone6+的dp/cm比值要比iphone5,6的略大，這就導致12px大小的字體在6+上顯示的比5，6上顯示的略小，上面的淘寶對比圖仔細分辨可以看出來。
android的手機屏幕dp/cm比值在各個設備之間也有差異性，並且比較有多樣性。所以同樣12px大小的字體，各個設備顯示時也是有差別的。
這種顯示差別在iphone系列手機中可以忽略不計，但是android碎片化比較嚴重，完美兼容各種機型沒有必要，主流機型中這種顯示差別也可以忽略不計，所以採用這種方式進行字體適配只需要px值設置成一樣的就可以了。
** 第1種字體適配方案優缺點**
優點：1.不同設備中字體大小顯示一致，比較統一；2.大屏手機可以顯示更多的文字；
缺點：1.由於單個字體寬度是定死的，所以在有些機型下可能會影響頁面布局；
** 第2種字體適配方案原理 **
在設計稿中，計算出字體大小相對於基準字體大小（基準字體大小可以選擇設計稿寬度，一般為了計算方便，會把設計稿寬度/10得到的值作為基準字體大小）的比值，然後在不同布局寬度下，先得到基準字體大小，再根據上面計算出來的比值，就可以計算出來不同布局寬度下的字體大小，也就是不同布局寬度下等比例縮放字體。
利用rem的特性，在頁面的html標簽上設置一個基準字體大小，就可以實現這種方式。
例如，寬是750px的設計圖中，字體大小是32px，計算出基準字體大小為75px，比值為 32 * 10 / 75 = 0.426667。
如果布局寬度是414px，此時基準字體大小變成 414 / 10 = 41.4px，然後設置<html style="font-size:41.4px">，字體大小是0.426667rem，計算出來的字體大小為41.4x0.42667=17.66px。
如果布局寬度變成360px，此時基準字體大小變成36px，然後設置<html style="font-size:36px">，字體大小仍然用0.426667rem表示，計算出來的字體大小為36x0.42667=15.36px。
750/32 約等於 414/17.66 約等於 360/15.36，這樣就做到了等比縮放字體了。
** 第2種字體適配方案優缺點**
缺點：1.小尺寸設備屏幕上字體顯示小，大尺寸設備屏幕字體顯示大，導致字體顯示不一致；2.不能發揮大屏手機的優勢（顯示更多的字）；3.字體大小會出現奇數或者小數點大小的值，某些字體不支持這些值，渲染時增加計算量；
優點：1.適配簡單，不同設備不會影響頁面布局，可以和設計稿布局保持一致；
布局中對寬度的適配，也是採用rem來實現，和上面第2種字體大小適配方式中的原理類似，也是計算出一個比例值，然後不同布局寬度中等比縮放，這里偷下懶，不在贅述。
目前的解決方案有兩類
第一類就是js動態生成viewport標簽，標簽中的initial-scale值根據設備的dpr計算，不同dpr設備的viewport值不同。
第二類就是js不操作viewport，每個設備都使用理想viewport來布局。
** 動態viewport解決方案分析 **
這里分析兩個動態viewport解決方案：
1.手機淘寶的flexible方案；
2.hotcss方案；
手機淘寶的flexible方案 ，特點：
1.僅針對iphone生成動態viewport，因為目前iphone的dpr只有1，2，3三種，android的dpr很有多種，不具有一致性；
2.字體大小不用rem做縮放處理，仍然使用px單位，設置不同dpr下對應的字體大小；
3.寬度利用rem等比縮放；
4.允許強制定義dpr;
使用時頁面頭部需要引入 flexible.js .
hotcss方案 ，特點：
1.不區分iphone和android，dpr只取三種1,2,3，android的dpr做近似處理；
2.寬度以及字體利用rem等比縮放；
3.允許強制定義dpr;
使用時頁面頭部需要引入 hotcss.js
動態viewport方案之所以會稱為動態viewport是因為，這個適配過程會根據系統dpr值設置initial-scale屬性的大小，大小等於1/dpr。
** 靜態viewport解決方案分析 **
利用rem特性，先根據標注圖算出各元素相對於設計稿寬度的比值，這個比值就作為rem值，然後頁面布局時就用算出的rem值表示，並且在html根元素設置當前布局頁面寬度作為基準。更rem值計算具體的解釋可以參考這篇文章 使用Flexible實現手淘H5頁面的終端適配 。通過這種方式設置標簽元素的寬高，位置以及字體大小，這樣利用rem特性就可以在不同手機屏幕上實現等比縮放。
參考資料
https://github.com/amfe/article/issues/17
http://www.cnblogs.com/pigtail/archive/2013/03/15/2961631.html
⑤ 什麼是移動適配
移動適配是指使不同尺寸的手機設備頁面「相對性的達到合理的展示（自適應）」或者「保持統一效果的等比縮放。手機設備屏幕尺寸不一，做移動端的Web頁面，需要考慮安卓/IOS的各種尺寸設備上的兼容，針對移動端設備的頁面，設計與前端實現更好地適配不同屏幕寬度的移動設備。
(5)web移動端適配擴展閱讀：
完美的移動適配不需要用戶縮放和橫向滾動條就能正常的查看網站的所有內容；顯示的文字、圖片等其他元素大小合適，無論是在何種密度屏幕，何種解析度下，顯示出來的大小都是差不多的。
適配不同屏幕寬度以及不同dpr，通過動態設置viewport(scale=1/dpr) + 根元素fontSize + rem, 輔助使用vw/vh等來達到適合的顯示。
若無需適配可顯示1px線條，也可以不動態設置scale，只使用動態設置根元素fontSize + rem + 理想視口。