Ⅰ h5和web前端的區別
一、指代不同
1、h5：是Web中核心語言HTML的規范，用戶使用任何手段進行網頁瀏覽時看到的內容原本都是HTML格式的，在瀏覽器中通過一些技術處理將其轉換成為了可識別的信息。
2、web前端：是創建Web頁面或app等前端界面呈現給用戶的過程，通過HTML，CSS及JavaScript以及衍生出來的各種技術、框架、解決方案，來實現互聯網產品的用戶界面交互。
二、發展不同
1、h5：結合了 HTML4.01 的相關標准並革新，符合現代網路發展要求，在 2008 年正式發布。
2、web前端：從網頁製作演變而來，在互聯網的演化進程中，網頁製作是Web1.0時代的產物，早期網站主要內容都是靜態，以圖片和文字為主，用戶使用網站的行為也以瀏覽為主。隨著互聯網技術的發展和HTML5、CSS3的應用，現代網頁更加美觀，交互效果顯著，功能更加強大。
三、技術構成不同
1、h5：由不同的技術構成，其在互聯網中得到了非常廣泛的應用，提供更多增強網路應用的標准機。
2、web前端：掌握HTML是網頁的核心，是一種製作萬維網頁面的標准語言，是萬維網瀏覽器使用的一種語言，它消除了不同計算機之間信息交流的障礙。
Ⅱ h5為什麼稱之為響應式web設計
h5配合css3藉助媒體查詢技術可以控制不同設備、不同解析度中的css樣式，使頁面顯示出不同的效果，故稱之為響應式web設計。
Ⅲ 新手開發移動端 H5 頁面有哪些注意事項
1、首先我們來看看webkit內核中的一些私有的meta標簽，這些meta標簽在開發webapp時起到非常重要的作用
<meta content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" name="viewport">
<meta content="yes" name="apple-mobile-web-app-capable">
<meta content="black" name="apple-mobile-web-app-status-bar-style">
<meta content="telephone=no" name="format-detection">
1
2
3
4
5
6
代碼laycode - v1.1
第一個meta標簽表示：強制讓文檔的寬度與設備的寬度保持1:1，並且文檔最大的寬度比例是1.0，且不允許用戶點擊屏幕放大瀏覽；
第二個meta標簽是iphone設備中的safari私有meta標簽，它表示：允許全屏模式瀏覽；
第三個meta標簽也是iphone的私有標簽，它指定的iphone中safari頂端的狀態條的樣式；
第四個meta標簽表示：告訴設備忽略將頁面中的數字識別為電話號碼
2、HTML5標簽的使用
在開始編寫webapp時，哥建議前端工程師使用HTML5，而放棄HTML4，因為HTML5可以實現一些HTML4中無法實現的豐富的WEB應用程序 的體驗，可以減少開發者很多的工作量，當然了你決定使用HTML5前，一定要對此非常熟悉，要知道HTML5的新標簽的作用。比如定義一塊內容或文章區域 可使用section標簽，定義導航條或選項卡可以直接使用nav標簽等等。
3、放棄CSS float屬性
在項目開發過程中可以會遇到內容排列顯示的布局，假如你遇見這樣的視覺稿，哥建議你放棄float，可以直接使用display:inline-block;
4、利用CSS3邊框背景屬性
這個按鈕有圓角效果，有內發光效果還有高光效果，這樣的按鈕使用CSS3寫是無法寫出來的，當然圓角可以使用CSS3來寫，但高光和內發光卻無法使用CSS3編寫，
這個時候你不妨使用-webkit-border-image來定義這個按鈕的樣式。
-webkit-border-image就個很復雜的樣式屬性。
5、塊級化a標簽
請保證將每條數據都放在一個a標簽中，為何這樣做？因為在觸控手機上，為提升用戶體驗，盡可能的保證用戶的可點擊區域較大。
6、自適應布局模式
在編寫CSS時，我不建議前端工程師把容器（不管是外層容器還是內層）的寬度定死。為達到適配各種手持設備，我建議前端工程師使用自適應布局模式（支付寶 採用了自適應布局模式），因為這樣做可以讓你的頁面在ipad、itouch、ipod、iphone、android、web safarik、 chrome都能夠正常的顯示，你無需再次考慮設備的解析度。
7、學會使用webkit-box
上一節，我們說過自適應布局模式，有些同學可能會問：如何在移動設備上做到完全自適應呢？很感謝webkit為display屬性提供了一個webkit-box的值，它可以幫助前端工程師做到盒子模型靈活控制。
8、如何去除Android平台中對郵箱地址的識別
看過iOS webapp API的同學都知道iOS提供了一個meta標簽:用於禁用iOS對頁面中電話號碼的自動識別。在iOS中是不自動識別郵件地 址的，但在Android平台，它會自動檢測郵件地址，當用戶touch到這個郵件地址時，Android會彈出一個框提示用戶發送郵件，如果你不想 Android自動識別頁面中的郵件地址，你不妨加上這樣一句meta標簽在head中
<meta content="email=no" name="format-detection" />
9、如何去除iOS和Android中的輸入URL的控制項條
你的老闆或者PD或者交互設計師可能會要求你：能否讓我們的webapp更加像nativeapp，我不想讓用戶看見那個輸入url的控制項條？
答案是可以做到的。我們可以利用一句簡單的javascript代碼來實現這個效果
setTimeout(scrollTo,0,0,0);
請注意，這句代碼必須放在window.onload里才能夠正常的工作，而且你的當前文檔的內容高度必須是高於窗口的高度時，這句代碼才能有效的執行。
10、如何禁止用戶旋轉設備
我曾經也想禁止用戶旋轉設備，也想實現像某些客戶端那樣：只能在肖像模式或景觀模式下才能正常運行。但現在我可以很負責任的告訴你：別想了!在移動版的webkit中做不到！
至少Apple webapp API已經說到了：我們為了讓用戶在safari中正常的瀏覽網頁，我們必須保證用戶的設備處於任何一個方位 時，safari都能夠正常的顯示網頁內容（也就是自適應），所以我們禁止開發者阻止瀏覽器的orientationchange事件，看來蘋果公司的出 發點是正確的，蘋果確實不是一般的蘋果。
iOS已經禁止開發者阻止orientationchange事件，那Android呢？對不起，我沒有找到任何資料說Android禁止開發者阻止瀏覽器orientationchange事件，但是在Android平台，確實也是阻止不了的。
11、如何檢測用戶是通過主屏啟動你的webapp
看過Apple webapp API的同學都知道iOS為safari提供了一個將當前頁面添加主屏的功能，按下 iphoneipodipod touch底部工具中的小加號，或者ipad頂部左側的小加號，就可以將當前的頁面添加到設備的主屏，在設備的主屏會自動 增加一個當前頁面的啟動圖標，點擊該啟動圖標就可以快速、便捷的啟動你的webapp。從主屏啟動的webapp和瀏覽器訪問你的webapp最大的區別 是它清除了瀏覽器上方和下方的工具條，這樣你的webapp就更加像是nativeapp了，還有一個區別是window對像中的navigator子對 象的一個standalone屬性。iOS中瀏覽器直接訪問站點時，navigator.standalone為false,從主屏啟動webapp 時，navigator.standalone為true， 我們可以通過navigator.standalone這個屬性獲知用戶當前是否是從主屏訪 問我們的webapp的。
在Android中從來沒有添加到主屏這回事！
12、如何關閉iOS中鍵盤自動大寫
我們知道在iOS中，當虛擬鍵盤彈出時，默認情況下鍵盤是開啟首字母大寫的功能的，根據某些業務場景，可能我們需要關閉這個功能，移動版本webkit為 input元素提供了autocapitalize屬性，通過指定autocapitalize=」off」來關閉鍵盤默認首字母大寫。
13、iOS中如何徹底禁止用戶在新窗口打開頁面
有時我們可能需要禁止用戶在新窗口打開頁面，我們可以使用a標簽的target=」_self「來指定用戶在新窗口打開，或者target屬性保持空，但 是你會發現iOS的用戶在這個鏈接的上方長按3秒鍾後，iOS會彈出一個列表按鈕，用戶通過這些按鈕仍然可以在新窗口打開頁面，這樣的話，開發者指定的 target屬性就失效了，但是可以通過指定當前元素的-webkit-touch-callout樣式屬性為none來禁止iOS彈出這些按鈕。這個技 巧僅適用iOS對於Android平台則無效。
14、iOS中如何禁止用戶保存圖片＼復制圖片
我們在第13條技巧中提到元素的-webkit-touch-callout屬性，同樣為一個img標簽指定-webkit-touch-callout為none也會禁止設備彈出列表按鈕，這樣用戶就無法保存＼復制你的圖片了。
15、iOS中如何禁止用戶選中文字
我們通過指定文字標簽的-webkit-user-select屬性為none便可以禁止iOS用戶選中文字。
16、iOS中如何獲取滾動條的值
桌面瀏覽器中想要獲取滾動條的值是通過document.scrollTop和document.scrollLeft得到的，但在iOS中你會發現這兩 個屬性是未定義的，為什麼呢？因為在iOS中沒有滾動條的概念，在Android中通過這兩個屬性可以正常獲取到滾動條的值，那麼在iOS中我們該如何獲 取滾動條的值呢？
通過window.scrollY和window.scrollX我們可以得到當前窗口的y軸和x軸滾動條的值。
17、如何解決盒子邊框溢出
當你指定了一個塊級元素時，並且為其定義了邊框，設置了其寬度為100％。在移動設備開發過程中我們通常會對文本框定義為寬度100％，將其定義為塊級元 素以實現全屏自適應的樣式，但此時你會發現，該元素的邊框(左右)各1個像素會溢了文檔，導致出現橫向滾動條，為解決這一問題，我們可以為其添加一個特殊 的樣式-webkit-box-sizing:border-box;用來指定該盒子的大小包括邊框的寬度。
18、如何解決Android 2.0以下平台中圓角的問題
如果大家夠細心的話，在做wap站點開發時，大家應該會發現android 2.0以下的平台中問題特別的多，比如說邊框圓角這個問題吧。
在對一個元素定義圓角時，為完全兼容android 2.0以下的平台，我們必須要按照以下技巧來定義邊框圓角：
1＼-webkit這個前綴必須要加上（在iOS中，你可以不加，但android中一定要加）；
2＼如果對針對邊框做樣式定義，比如border:1px solid #000;那麼-webkit-border-radius這屬性必須要出現在border屬性後。
3＼假如我們有這樣的視覺元素，左上角和右上角是圓角時，我們必須要先定義全局的(4個角的圓角值)-webkit-border- radius:5px;然後再依次的覆蓋左下角和右下角，-webkit-border-bottom-left-radius:0;-webkit- border-bottom-right-border:0;否則在android 2.0以下的平台中將全部顯示直角，還有記住！-webkit這個前 綴一定要加上！
19、如何解決android平台中頁面無法自適應
雖然你的html和css都是完全自適應的，但有一天如果你發現你的頁面在android中顯示的並不是自適應的時候，首先請你確認你的head標簽中是否包含以下meta標簽：
<meta name="viewport" content="width=device-width,initial-scale=1.0,maximum-scale=1.0,user-scalable=0;" />
如果有的話，那請你再仔細的看清楚有沒有這個屬性的值width=device-width，如果沒有請立即加上吧！
20、如何解決iOS 4.3版本中safari對頁面中5位數字的自動識別和自動添加樣式
新的iOS系統也就是4.3版本，升級後對safari造成了一個bug：即使你添加了如下的meta標簽，safari仍然會對頁面中的5位連續的數字進行自動識別，並且將其重新渲染樣式，也就是說你的css對該標簽是無效的。
<meta name="format-detection" content="telphone=no" />
我們可以用一個比較齷齪的辦法來解決。比如說支付寶wap站點中顯示金額的標簽，我們都做了如下改寫：
<button class="t-balance"style="background:none;padding:0;border:0;">95009.00</button>元
Ⅳ 移動端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
Ⅳ 移動端H5頁面的設計稿尺寸（上）
由於HTML5和微信內置瀏覽器的火爆，移動端H5網頁越發流行。在設計製作移動端網頁的時候，你是否疑惑，這種網站設計稿應該做成的多少屏寬，是否應該跟手機的解析度一致，還是應該按照iPhone的解析度來設計（注意H5網頁區別於APP，APP的設計稿直接按照手機解析度來設計）？那麼對於現在2K屏幕的手機，應該如何製作設計稿和前端稿呢？
作為本次文章系列的「上」部，將解決一些基本概念：像素（pixel）、ppi、解析度、物理像素（physical pixel）、CSS像素、設備獨立像素（deviceindependent pixel）等等。
為圖像顯示的基本單位，表示「圖像元素」之意。 每個這樣的信息元素不是一個點或者一個方塊，而是一個抽象的采樣。 仔細處理的話，一幅圖像中的像素可以在任何尺度上看起來都不像分離的點或者方塊；但是在很多情況下，它們採用點或者方塊顯示。
這一段是出自維基網路的解釋。其實很多會Photoshop的人都有一個誤區： 認為像素是一個寬高相等的小方塊，並且的像素都是「那麼大」，但是不知道這個寬高的具體數字。
像素是一個抽象概念，它是一個相對單位。
像素描述的是圖像在某一點的顏色值。一般來說，一個像素只能描述一種顏色值。
先可以跳過這個話題，介紹ppi概念，像素沒有大小就好理解了。
PPI的復雜之處在於如果他所屬的上下文環境不同，意義也會完全不一樣。 當我們在談論顯示設備的PPI時，它代指的屏幕的像素密度；當我們在談論和圖片相關時，我們談論的是列印時的解析度或者列印機的列印精度。這里我們主要描述的前一種情況。
PPI全稱為Pixel Per Inch，譯為每英寸像素取值，更確切的說法應該是像素密度，也就是衡量單位物理面積內擁有像素值的情況。
舉例1：
中的七張圖，假設圖片尺寸都為1x1寸，那麼 PPI 分別為 1、2、5、10、20、50、100 。 在同一物理尺寸內 ，隨著像素數的增大，圖像細節越多， PPI 增大，圖像越清晰，像素所佔空間相對越小。
因此，從討論像素大小的角度來說，圖①中各個方框像素的寬度（單位為英寸）分別為：1、1/2、1/5、1/10、1/20、1/50、1/100。像素在每個不同ppi下大小都不同，因此討論像素的大小也就變得無意義了。像素是沒有大小的。像素是一個抽象概念，它是一個相對單位。
像素描述的是圖像在某一點的顏色值。一般來說，一個像素只能描述一種顏色值。
舉例②：
在photoshop中分別建立兩個文檔：①800x600px，72ppi，②800x600px，300ppi。那麼這兩個文檔在PS或者生成圖片時，顯示的視覺效果是完全一樣的，因為寬高的像素點數是完全一樣的，在設備上渲染出來的效果圖是一致的。當你把文檔②中的任意圖層復制到文檔①中，從視覺上發現圖層不會變大或者縮小。只有把這兩個文檔作為圖片1:1列印出來時，才會發現72ppi的圖片要大於300ppi的圖片（注意ppi的含義），前者寬（高）大約是後者的4.16（300/72）倍。
任何圖片作為數據信息被保存在存儲盤中時，只有寬高像素數是有意義的，ppi對於圖片來說時沒有任何意義的，也並不能描述這個圖片有多少英寸的寬度或者高度，而只有在被列印出來後才有他的意義。
解析度泛指顯示系統對細節的分辨能力。能顯示圖像都能叫顯示系統，比如顯示器，投影儀，照片。
解析度常用的單位有：dpi（點每英寸）、lpi（線每英寸）和ppi（像素每英寸）。從單位來看，解析度是一個比值，與物理單位的比值。
日常所說的「這張圖片的尺寸（或解析度）是100x100像素」，一般都是在描述數字圖片，這樣的描述只是說明了圖片文件包含多少個像素。比如圖1中的七張圖，我們習慣於說，第1張圖的解析度是1x1像素，第5張圖的解析度是20x20像素，其實只是說明了圖片的像素數而已。
這是一種顯示技術，可以將把更多的像素點壓縮至一塊屏幕里，從而達到更高的解析度並提高屏幕顯示的細膩程度，這種解析度在正常觀看距離下足以使人肉眼無法分辨其中的單獨像素。
最先使用retina屏幕是iphone 4，屏幕解析度為960 * 640（326ppi）。
對比如下兩幅圖，可以清晰地看出是否 Retina 屏的顯示差異：
圖2 iPhone 3GS
圖3 iPhone 4
兩代iPhone 的物理尺寸（屏幕寬高有多少英寸）是一樣的，從上圖可以看出，iphone 4的顯示效果要明顯好於iphone 3GS，雖然 iPhone 4 解析度提高了，但它不同於普通的電腦顯示器那樣為了顯示更多的內容，而是提升顯示相同內容時的畫面精細程度。這種提升方式是靠提升單位面積屏幕的像素數量，即像素密度來提升解析度，這樣做的主要目的是為了提高屏幕顯示畫面的精細程度。以第三代 MacBook Pro with Retina Display為例， 工作時顯卡渲染出的2880x1880個像素每四個一組，輸出原來屏幕的一個像素顯示的大小區域內的圖像。這樣一來，用戶所看到的圖標與文字的大小與原來的1440x900解析度顯示屏相同，但精細度是原來的4倍。
注意：在桌面顯示器中，我們調整了顯示解析度，比如從 800 * 600 調整到 1024 * 768 時，屏幕的文字圖標會變小，顯示的內容更多了。但 Retina 顯示方式不會產生這樣的問題，或者說， Retina 顯示技術解決的是顯示畫面精細程度的問題，而不是解決顯示內容容量的問題。
為什麼是「每四個一組」？而且要讓這四個一組來顯示「原來屏幕的一個像素」？這大概就是 Retina 顯示技術的一種表現吧。而這「每四個一組」的「大像素」，可以被稱作「設備獨立像素」， device independent pixel ，或者 density-independentpixel ， 它可以是系統中的一個點，這個點代表一個可以由程序使用的虛擬像素，然後由相關系統轉換為物理像素。
「設備獨立像素」也有人稱為「CSS像素」，一種形象的說法，更傾向於表明與 CSS 中尺寸的對應。
設備獨立像素與物理像素的對應關系，可以這樣看：
圖4
類似的每四個一組的對應關系，也許正是 Retina 顯示技術所做的。
作為Web開發者，我們接觸的更多的是用於控制元素樣式的樣式單位像素。這里的像素我們稱之為CSS像素。
CSS像素有什麼特別的地方？我們可以借用quirksmode中的這個例子：
假設我們用PC瀏覽器打開一個頁面，瀏覽器此時的寬度為800px，頁面上同時有一個400px寬的塊級元素容器。很明顯此時塊狀容器應該占頁面的一半。
但如果我們把頁面放大（通過「Ctrl鍵」加上「+號鍵」），放大為200%，也就是原來的兩倍。此時塊狀容器則橫向占滿了整個瀏覽器。
吊詭的是此時我們既沒有調整瀏覽器窗口大小，也沒有改變塊狀元素的css寬度，但是它看上去卻變大了一倍——這是因為我們把CSS像素放大為了原來的兩倍。
CSS像素與屏幕像素1：1同樣大小時：
圖5
CSS像素(黑色邊框)開始被拉伸，此時1個CSS像素大於1個屏幕像素
圖6
也就是說默認情況下一個CSS像素應該是等於一個物理像素的寬度的，但是瀏覽器的放大操作讓一個CSS像素等於了兩個設備像素寬度。在後面你會看到更復雜的情況，在高PPI的設備上，CSS像素甚至在默認狀態下就相當於多個物理像素的尺寸。
從上面的例子可以看出，CSS像素從來都只是一個相對值。
設備像素比=設備物理像素/設備獨立像素
設備像素比在 js 中可以通過 devicePixelRatio 的參數取得（需要頁面的 viewport 設置為 content=」width=device-width」 此處為前端布局知識，較為專業，筆者也只是意會，無法說清楚，請自行網路）
iPhone 4 的設備像素比為2，線長（橫向、縱向、對角線）上的物理像素數與設備獨立像素數的對應關系即為2。
根據這個對應關系，一般可以通過屏幕的物理解析度和設備像素比確定設備獨立像素數。
那麼在我們做移動端網站時，將viewport設置了content=」width=device-width」，設備獨立像素也就等於CSS像素。
經常在做移動端網站時，我們會聽到一些人說原型稿屏寬做成320px，設計稿做2倍640px，網上也有很多文章說這樣說，H5網頁的設計稿做成2倍普通屏解析度就行了。
這是一個歷史遺留問題，這里提到的屏寬，更確切的說，是將viewport設置為width=device-width時的寬度，習慣稱這個寬度為屏寬，也就是設備獨立像素的寬度。筆者從其他文章中找到了一些答案。（原型圖屏寬是320px是為了滿足原型軟體在1：1比例顯示上適當，二是為了保證早期iphone320px屏寬的顯示需求）
「其實這個屬性值很有意思，字面意應該是 viewport 寬度等於設備寬度，但在實際中不同的瀏覽器都給出了個定值：320px；這個值還是源於 Apple ，因為早期 iPhone 的解析度為 320px*480px ，大量為 iPhone 量身定製的網站都設置了 viewport:width=device-width ，並且按照寬度 320px 來設計製作，所以其他瀏覽器加入 viewport 支持時為了兼容性也將 device-width 定義為了 320px 。」
那麼到了後來的iPhone4的屏幕是960x640px，幾乎所有人都知道Retina顯示屏，所有方向上的像素都成了原來的2倍。而設備獨立像素的屏寬還是保持著320px。其它智能手機早期的解析度基本上也使用了大致相同的屏幕尺寸與解析度，因此才有了 320px 這個不約而同的約定。
當然，如果把 viewport 的 width 屬性設置為一個定值，比如 320、 480、 700 等等，那 viewport 的寬度即為設定的寬度。此時，設備獨立像素寬度，也即所設定的寬度，而物理像素與設備獨立像素的比值，則不再是最初始的設備像素比值了（比如 iPhone 4 中的2）。
現在的智能手機屏幕尺吋多樣，解析度有很多種，相應地，設備像素比也不一致，有1、1.5、2、2.25、3等等，而在一般情況下（指 viewport 設置為 width=device-width 時）的設備獨立像素寬度，也不再只是 320px 了，還有 360px 、 400px等等。 這是從 http://screensiz.es/phone 統計的大部分手機獨立像素數據。
若設備像素比是N，就表示該手機屏幕上的N個物理像素來顯示一個CSS像素。
本文對已移動端網站涉及到的一些概念進行了較為基礎的解釋，在下一篇中，會介紹H5網頁在做設計稿以及前端布局時的最為省力的方法。
Ⅵ 移動端的h5頁面的尺寸是多少
近來，大尺寸手機屏幕日趨主流，意派Epub360根據對主流大屏的計算，現新增大尺寸手機屏幕的畫布，並命名為「微信Plus」。原來的普通微信尺寸將繼續保留。
內容安全區：375*603（750*1206）
出血區：422*748（844*1496）
左右邊框各：23.5px
上下邊框各：72.5px
根據該畫布，後續將會推出配套的layer組件等尺寸，即當選擇使用該微信尺寸時，layer畫布跟layer容器尺寸自動默認尺寸：375X603PX，方便調整。
Ⅶ h5頁面設計的原理是什麼
1、h5頁面設計的原理——在代碼中實現
設計人員創建了一個很好的層圖，包括PSD文件、PNG剪貼圖、適當的文件、MP3音頻文件、視頻文件等等，並將它們與他們的前端工程師同事打包在一起，由他們專門將它們放在伺服器上。在代碼編輯方面，元素被合並到我們通常看到的H5 web頁面中。前端也是H5的最終執行者。它們對恢復設計非常重要。一個好的前端往往決定了一個作品的最終命運。前端工程師可以說是設計師最好的行業導師。我們必須虛心向他們學習網路編碼技術。
整個H5頁面將被推到互聯網後，代碼編輯和測試。有時，前端工程師的工作量遠遠高於設計，這取決於項目的形式和難度。
2、h5頁面設計的原理——沒有代碼實現
沒有代碼並不意味著你不需要前端工程師，但現在互聯網上有很多H5頁面生成工具，以網站的形式，命名為第三方平台，由大量的工程師開發，以幫助沒有前端資源的設計師。您可以將設計好的數據上傳到第三方平台的伺服器上，自己編輯發布。這個過程不涉及程序員，可以節省大量的人力成本，而且簡單快捷。但缺點是平台功能單一，效果有限。它通常以幻燈片的形式出現。工程師生成的H5頁面可以定製。現在市場上有很多這樣的平台。
無論是第三方網站設計工具，還是誕生於H5的前端工程師，都需要h5頁面設計的原理。與前端工程師的溝通應該從設計開始就開始。盡量避免所有設計都做得好，前端無法實現的尷尬局面。所以設計師和前端工程師之間的溝通是非常重要的。後續將會有更多關於ui設計中各個分類的設計技巧與資訊，可以點擊本站的其他文章進行學習。
Ⅷ web前端只要會H5和css,加上js就可以了嗎
剛剛入門web前端的同學，大多對前端學習路線有誤解，認為前端=HTML+CSS+Javacript。但實際情況要比這要復雜多，下面就來真正了解一下Web前端學些什麼內容吧！
1.入門篇：html基礎、css基礎、js基礎、純js操作dom和jquery。
2中級篇：深入css3、深入js、掌握主流mvc框架、升級後台語言nodejs、總結做項目。
3.進階篇：掌握面向對象編程、函數式編程、MVC / MVVM / MVC。還需要把握好安全性、平台兼容等等。
所以說，Web前端的學習路程是路漫漫其修遠矣，大家要靠不停地學習來充實自己的知識技能，才能在前端方向成為技術大牛！