移動端開發系列——像素與viewport

JayChen 發布于2019-08-30 15:53 / 2607人閱讀

摘要：目錄移動端開發的基本觀點像素基礎知識原理解析彈性布局響應式設計的運用移動端的事件庫的使用移動端開發的基本觀點移動端開發的意義移動端用戶使用量市場需求市場供給公司需要移動端開發人才工資高，就業易涌現大波程序猿到了猴年馬月，工資才會

移動端開發的基本觀點

像素基礎知識

viewport原理解析

彈性布局

響應式設計

1rem的運用

移動端的事件

zepto庫的使用

移動端開發的基本觀點

移動端開發的意義
移動端用戶使用量 -> 市場需求 -> 市場供給 -> 公司需要移動端開發人才 -> 工資高，就業易 -> 涌現大波程序猿 -> 到了猴年馬月，工資才會降下來 -> 新的技術涌現，VR/AI -> 市場需求攀升 -> 重走一波老路......

扯遠了，以上大致就是學習移動端開發的動機；

移動端開發的認識
移動端開發就是手機端開發嗎？

No、No、No...
移動端是一個大的范疇，小羊認為應該包括智能手機、平板在內的移動設備，主要是這兩者；

移動端開發入門的學習路徑
目錄就是

像素基礎知識

先拋3個概念，
px(CSS pixels)：虛擬像素，可以理解為“直覺”像素，我要這個元素寬高10px；
dp(device pixels)：設備像素（物理像素），可以理解為實際的像素，這個寬高為10px的元素在設備中實際用了多少個物理像素點表示；
dpr(device pixels ratio)：設備像素比，公式為1px = (dpr)^2 * 1dp，可以理解為1px由多少個設備像素組成；

3個概念整合理解就是：
我為一個元素設置的寬高為10px，那么實際在顯示設備中用多少個設備像素真實表示呢？
dpr=2的話，那么1px由4個設備像素顯示，如果是10px，那么顯示設備實際用40個dp去顯示10px；
dpr=1，則1px由1個設備像素顯示；
px和dp的區別就是直覺認為只有10px和真實使用40dp；

為什么會出現dpr>=2的情形？dpr=1不是更加符合我的認知和理解嗎？

還不是人們為了追求更高的分辨率所致，分辨率越高圖像越清晰！！！；

但是Mac的Retina屏和一般PC的在相同尺寸下，圖像卻清晰許多，為腎？

dpr>=2所致啊！！！

別的品牌機子老老實實1px = 1dp，Mac卻是1px = 4 dp，所以你直覺認為大家都使用同樣多的像素點表示圖像（這是沒錯滴），實際背后Mac用了多1倍（指的是dpr）的設備像素顯示圖像；

實際應用中，顯示設備不會直接給你個px和dpr

你實際看到的是以下的參數，下面是腎6Plus的顯示屏參數信息：

再拋幾個概念，可別暈咯...

英寸：這里指的是屏幕主對角線的尺寸，1英寸=2.54cm，5.5英寸約等于14cm（13.97cm）

分辨率：1920*1080像素，這里指的是物理像素（設備像素）

ppi（pixels per inch）：每英寸的像素點，這里腎6Plus為每英寸有401個像素點

那么ppi是如何計算出來的呢？
顧名思義，每英寸的像素點（設備像素），已知屏幕分辨率和主對角線的尺寸，則ppi等于

var 斜邊尺寸 = V(1920^2+1080^2) V代表開根號
var ppi = 斜邊尺寸/5.5
ppi = 401ppi

現在我們知道，ppi越高，每英寸像素點越多，圖像越清晰；

和先前的知識點有什么關系？

畢竟這些參數是外國人先發明的，他們會優先選擇自己熟悉的計量單位作為顯示設備的工廠標準參數，因此ppi就用作顯示設備的工業標準；

告訴業界人士，ppi達到多少是高清屏，此時對應的dpr是多少，而不直接告訴你我現在的顯示設備dpr是多少

畢竟人們直接聽到像素分辨率會更加有反應

下面是不同ppi對應的dpi：

ldpi	mdpi	hdpi	xhdpi
ppi	120	160	240	320
默認縮放比	0.75	1.0	1.5	2.0

【注】Retina屏都是dpr>=2的高清屏

腎6Plus的dpr為3，是超高清屏；

到目前為止，我們了解到：
給你一個顯示設備，設備分辨率為1920*1080，尺寸為5.5英寸，可以計算出其ppi = 401，根據ppi得知其dpr = 3，
由此可以該設備1px = （3^2）dp，其虛擬像素為1920/3 = 660px，1080/3 = 360px，即虛擬分辨率為360*660；
此時，如果你在代碼設置元素的寬高為360*660到的話，會發現它的實際尺寸就等于腎6Plus的屏幕尺寸；
【ppi】

viewport原理解析

一個很有意思的現象是，當你把上面的代碼在chrome下使用設備模擬方式，模擬腎6Plus的時候，神奇的事情發生了，該元素設置的寬高明明就是手機的寬高，按常理應該占據整個屏幕，實際卻是：

究竟是怎么一回事？，如何解決這一問題呢？

好吧，作為實用主義者的你們（不是我喲），先講解決方案：

在meta標簽有一個viewport的屬性，可以為這個屬性設置width；
腎6Plus默認的width是980px，所以元素寬是360px，實際顯示的尺寸是360px*360/980=132.24px（不信可以自己測試一下喲）；

現在只要將viewport的width設置為360px，那么元素就可以占滿全屏了；

現在就要引入另一個概念：viewport

viewport的原理在于：

先將頁面渲染在一個width為顯示設備默認尺寸的viewport上，如腎6Plus為980px；

然后將viewport等比例縮放至整個手機屏幕上；

例如上例中，元素寬高為360*600px，先將元素渲染在寬度為980px的viewport上，然后等比例縮放在整個手機屏幕上；

viewport就是連接手機屏幕和頁面的中間層

為什么要多此一舉呢？

想象一下，如果沒有中間層，直接將一個頁面寬度為980px的直接縮放至320px，那么里面的DOM節點將會進行重繪，很有可能導致排版錯亂；
viewport的作用是將所有的DOM節點先繪在寬度為980px的viewport上，然后整個viewport統一縮放，這樣就能保證排版的正確性；

關于viewport，涉及兩個概念：

layout viewport：布局viewport，可以理解為放置頁面的幕布

visual vewport：視窗viewport，可以理解為屏幕的視窗
比如：

腎6Plus的visual viewport的寬度為360px，layout viewport為980px；
360px是屏幕視窗的虛擬像素，980px是放置頁面的像素；

回顧一下，前面元素出現的縮放現象：

根據腎6Plus的物理分辨率1920*1080以及5.5英寸的屏幕，計算出ppi = 401-> dpr = 3 -> 虛擬分辨率為640*360px；

畫一個寬度為360px的元素，理應充滿整個手機屏幕，但是由于viewport的作用 -> 360px的元素畫在980px的layout viewport上，然后等比例縮放在360px的visual viewport上-> 最終你看到的就是，360px的元素無法填充整個屏幕；

先前的一個解決辦法是，改變layout viewport，即，讓整個layout viewport就是360px，那么元素將填充整個屏幕；

以上都是世界觀，給人一些概念性的理解，無法實操，下面就是方法論

實際移動端開發，我們只需關注layout viewport，知道每個移動設備提供給我們多大尺寸的幕布，但是移動設備型號那么多，不可能一個個手動設置width呀！！！

動態設置layout viewport

上面的設置表示讓layout viewport總是等于設備寬度，即visual viewport；

【注】細心的童鞋可能會注意到，腎6Plus的虛擬分辨率為什么不是640*360px，具體解答可以參考知乎問答

獲取visual viewport和layout viewport的api

window.innerWidth：表示窗口的寬度（包含滾動條），即visual vewport的寬度
document.body.clientWidth：表示body元素的寬度（不包括border），即layout viewport的寬度

移動端其他初始化設置

intial-scale:頁面首次顯示時，可視區域的縮放級別，取值1.0則頁面按實際尺寸顯示，無任何縮放；
no-scalable：是否允許縮放

一個完整的viewport屬性的設置為：

上述完整的意思是，layout viewport等于設備的寬度，首次顯示頁面時不進行縮放也不允許用戶縮放；

demo

小結

一開始講px/dp/dpr/ppi的意義在于鋪墊背景知識

理解上述知識后，給你一個移動設備的物理分辨率，如iPhone6 Plus19201080以及尺寸5.5inches，可以計算出其ppi為401->dpr = 3，從而測算出手機的虛擬分辨率為640360px；

原則上，你開發一個640*360px的元素就可以填充整個手機屏幕，但是由于viewport機制作用，效果未達預期

由此引出viewport概念，viewport可以分為visual viewport（視窗尺寸）和layout viewport（放置頁面的“幕布“），iPhone6 Plus默認值為980px；

通過meta標簽的viewport屬性，可以動態設置layout viewport，實戰中只需要設置：

你還可以通過window.innerWidth和document.body.clientWidth（前提是不設置body的寬度）分別獲取visual viewport和layout viewport；

GPU云服務器云服務器移動端開發 web移動端開發移動端網站開發 java移動端開發

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/116541.html

移動端開發系列——像素與viewport

摘要：目錄移動端開發的基本觀點像素基礎知識原理解析彈性布局響應式設計的運用移動端的事件庫的使用移動端開發的基本觀點移動端開發的意義移動端用戶使用量市場需求市場供給公司需要移動端開發人才工資高，就業易涌現大波程序猿到了猴年馬月，工資才會目錄移動端開發的基本觀點像素基礎知識 viewport原理解析彈性布局響應式設計 1rem的運用移動端的事件 zepto庫的使用移動端開發的...

lingdududu 2019-08-01 16:21 評論0 收藏0
不要再問我移動適配的問題了

摘要：不要再問我的問題系列一不要再問我的指向問題了二不要再問我跨域的問題了移動端適配的問題，一般來說我們都不會去深究，因為這種東西都是配置一次就再也不用管的了，接到設計圖就按照祖傳套路擼就完事了。不要再問我XX的問題系列：一、不要再問我this的指向問題了二、不要再問我跨域的問題了移動端適配的問題，一般來說我們都不會去深究，因為這種東西都是配置一次就再也不用管的了，接到設計圖就按照祖傳...

Airy 2019-08-30 15:55 評論0 收藏0
不要再問我移動適配的問題了

摘要：不要再問我的問題系列一不要再問我的指向問題了二不要再問我跨域的問題了移動端適配的問題，一般來說我們都不會去深究，因為這種東西都是配置一次就再也不用管的了，接到設計圖就按照祖傳套路擼就完事了。不要再問我XX的問題系列：一、不要再問我this的指向問題了二、不要再問我跨域的問題了移動端適配的問題，一般來說我們都不會去深究，因為這種東西都是配置一次就再也不用管的了，接到設計圖就按照祖傳...

caozhijian 2019-08-02 14:02 評論0 收藏0
不要再問我移動適配的問題了

摘要：不要再問我的問題系列一不要再問我的指向問題了二不要再問我跨域的問題了移動端適配的問題，一般來說我們都不會去深究，因為這種東西都是配置一次就再也不用管的了，接到設計圖就按照祖傳套路擼就完事了。不要再問我XX的問題系列：一、不要再問我this的指向問題了二、不要再問我跨域的問題了移動端適配的問題，一般來說我們都不會去深究，因為這種東西都是配置一次就再也不用管的了，接到設計圖就按照祖傳...

MRZYD 2019-08-23 14:32 評論0 收藏0
Css-移動端適配總結

摘要：這種使用簡單，但是兼容性不太好。這種顏色有陰影，估計過不了設計大佬的那關。最后會把對應的編譯出來，這種兼容性好，就是依賴于插件。這種兼容好，但是會和偽類沖突，也是我司采用的方式。前言工作以后，大部分的業務工作都是基于移動端H5的，開發過程中學習了很多東西，遇到過許多問題，諸如rememcss pxdevice px等，本文純屬個人的歸納總結，如有問題，請指出親噴~ PC端本文主要...

codeGoogle 2019-08-23 16:47 評論0 收藏0