摘要:最終統籌一下我們要做的事情讓變成和屏幕分辨率一致的寬度根據設備寬度和來指明根元素的值這些操作之后你就可以實現最終的代碼了
首先從屏幕開始說起.
屏幕是由一個一個顯示單元組成的.
1 每一個顯示單元都是物理世界真實存在的;
2 把一個顯示單元的大小稱為一個"物理像素";
3 通常我們所說的 "分辨率", 就是指一塊屏幕顯示單元的個數, 比如
750*1334, 表示這塊屏幕由 750*1334 個顯示單元組成
像素是計算機系統里面的單位, 通常情況下, 我們讓一個像素對應一個顯示單元. 所以有時候, 我們說屏幕高 667px, 實際上就是說, 屏幕的的高有 667個顯示單元的高度之和.
隨著技術的進步, 顯示單元可以做的越來越小, 比如以前是 10mm*10mm 的一個顯示單元, 現在我們可以做到 5mm*5mm 一個顯示單元.
為什么追求顯示單元的小? 因為越小圖像越精細.
但是: 顯示單元的變小, 意味著屏幕的分辨率變大。
這里就牽涉到了一些事情:
假設屏幕的大小不變, 但是分辨率從 A, 變成 2A (也就是顯示單元縮小了一半)
并且: 一個像素對應一個顯示單元, 這個規則始終不變
此時, 你原來寬度為 100px 的一個元素, 在這個 2A 屏幕上渲染出來, 你會明顯的發現:
在視覺上: 這個 100px 明顯比之前小了, 和之前的 50px 的時候一樣大小.
那怎么辦啊, 這樣顯示肯定是不可以的, 所以我們要對這個情況做處理:
1 我們規定, 大小為 n*n 的顯示單元, 是標準的顯示單元, 標準意味著它合乎我們長久的判斷: 100px 在物理世界大概有多大.
2 我們要知道當前屏幕的顯示單元, 和標準顯示單元之間的大小比例,比如說當前屏幕的顯示單元的大小是標準的一半還是 三分之一.
通過 devicePixelRatio 屬性來獲
我們可以認為:
devicePixelRatio 標記是: 標準顯示單元/當前設備的顯示單元
建立在上面的基礎上面, 你就可以動態的調整元素的大小, 比如說某個元素 x 的寬度是 100px;
在 devicePixelRatio = 1 的設備上面寬度是 100px
在 devicePixelRatio = 2 的設備上面寬度就要是 200px;
ok, 那么我們來搞.
根據不同的 devicePixelRatio 來調整元素的樣式.
var box = document.querySelector(".box"); var height = parseInt(getComputedStyle(box).height); var width = parseInt(getComputedStyle(box).width); box.style.height = height * parseInt(window.devicePixelRatio) + "px"; box.style.width = width * parseInt(window.devicePixelRatio) + "px";
這僅僅是一個元素的兩個屬性, 1000個元素, 每個元素 5 個屬性, 就可以讓你哭掉了.
所以這種處理方式肯定是不可以的.
然后我們發現了 rem 單位.
它的簡單解釋:
當你給某個元素A 設置了 height:2rem 的時候 它會找到根節點(html) 的 font-size 值, 比如是 16px 然后拿 16 * 2 = 32px 作為元素A 的最終 height.
這個就可以利用了
1 讓元素使用 rem 作單位
2 然后控制根元素的 font-size 值, 在不同的 devicePixelRatio 下面的時候, 呈現不同的值
比如你可以設置:
devicePixelRatio = 1, font-size(root) = 100px; devicePixelRatio = 2, font-size(root) = 200px;
元素在這個時候, 就會自動響應大小的變化.
好, 開始搞:
var fontSize = 100 * parseInt(window.devicePixelRatio) + "px"; document.documentElement.style.fontSize = fontSize;
嗯, 結果還是不錯的, 在不同的分辨率下面, 我們也能實現頁面相同了.
實際上, 上面的討論, 已經解決了我們的問題:
在相同物理尺寸下的設備, 如何在分辨率不同的情況下, 讓一個 100px 的元素, 它對應的物理世界的
大小, 始終相同?
現在更近一步, 上面的討論, 固定了一個變量: 屏幕尺寸, 現在放開這個變量, 固定屏幕的分辨率這個變量.
這個問題就變成適配問題了:
場景描述:
比如你的一個頁面本來是以 375寬度為基礎做出來的, 那么在設備的寬度變成 320px 的時候,
你的頁面就會出現問題: 擠壓, 變形, 錯亂, 或者超出隱藏, 超出滾動等等操作.
怎么辦啊?
希望的是在 320 也能正常顯示: 讓頁面上的所有元素都縮小一些, 也就ok了. 比如一個元素
在 375 設備上面顯示這么大, 在 320 上面顯示成這么大不就行了.
那么如何縮小?
rem;
你想下, 只要在屏幕的寬度變小的時候, 讓根元素的 font-size 跟著變小, 那么所有使用 rem 作為單位的
元素, 是不是也跟著變小, 目標就達成了.
那么怎么讓 font-size(root) 隨著屏幕的寬度變小而變小啊.
選一對基準值, 比如: 375px/100px; 表示屏幕寬度為 375的時候, font-size(root) 為 100;
每次計算一下就好, 比如發現屏幕的當前寬度為 320, 那么算不出來此時的 font-size(root) 嗎??
算出來不會設置根元素的 font-size 嗎?
好吧, 上面說的暫時都不要試, 先提一個事情.
所有的上面的討論, 實際上都建立在:
當你屏幕的分辨率是 100100 的時候, 你就擁有一份 100100 大小的容器, 用來呈現你的網頁.
比如說, 你的 iPhone7 的分辨率是 6671334, 那么你就擁有一份 6671334 大小的容器來放你的網頁
可惜并不是這樣的.
從 iPhone 發布前夕說起:
開發人員發現, 原本為 pc 開發的網頁 在 iPhone 上面顯示不全, 這部分可以通過滾動條來解決. 但是使用 百分比布局的頁面就坑爹了, 原本在 pc 端瀏覽器上擁有 的 20% 在 iPhone 上面就一點點了, 布局完全亂了, 坑啊. 為了解決這個問題, 開發人員提出了一個的新的玩意: "layout viewport"
我該怎么解釋這個玩意呢.
============== // 這個是你的百分比頁面所基于的寬度 === // 這個是你屏幕的寬度
這樣一來, 頁面肯定會錯亂. 所以提出的 layout viewport 把模型變成這樣:
============== // 這個是你的百分比頁面所基于的寬度 ============= // layout viewport 的寬度 === // 這個是你屏幕的寬度
你的頁面會被放到 layout viewport 這個容器上面, 然后再將 layout viewport 縮小到
和屏幕寬度一樣的大小.
并且允許用戶放大頁面,通過滾動條滑動來瀏覽器全部頁面.
在最初的時候, 這種方式的確解決了 pc 端頁面在手機上瀏覽的問題, 但是隨著移動端的興起,
大量的針對移動端的頁面被制作出來, 也就是模型變成這樣:
=== // 針對移動端做的頁面 ============ // layout viewport === // 屏幕的寬度
這樣很明顯就出現問題了: 你的頁面先放到 layout viewport 上面, 然后又縮小到和屏幕寬度一致
最終顯示出來的, 就是你的頁面明顯被縮小了.
所以我們要解決這個問題, 要把 layout viewport 的大小, 變成和屏幕的寬度一致.
這里假設屏幕的顯示單元始終是標準的顯示單元大小。
怎么讓 layout viewport 變成和屏幕的寬度一致呢?
通過 meta name="viewport" 標簽.
解釋一下:
meta name="viewport" 有一個 content 屬性, 它里面有幾個值, 可以用來對 layout viewport
做處理. content 有如下幾個字段:
initial-scale: 這個值會影響最終 layout viewport 的寬度, 計算公式應該是這樣:
屏幕的分辨率/(devicePixelRatio*initial-scale) = 最終的 layout viewport 的寬度.
屏幕的分辨率我們可以拿到, devicePixelRatio 也可以拿到.
比如 iPhone7, 屏幕分辨率是 750*1334, devicePixelRatio=2, 當你設置 initial-scale=1 的時候
layout viewport 的最終寬度就是 375;
這里有一個點, 我說一下;
我們可以讓 layout viewport 的寬度是任意值, 通過對 initial-scale 的設置.
那我們要設置它為多少呢?
可以設置成 375, 這個寬度, 是以標準顯示單元為單位算出來的寬度
也可以設置成 750, 這樣的話, 你的 1px 就完整對應這個設備的 1 個顯示單元.
我們選擇后者, 因為這個牽涉到 1px border 的實現.
如果設置成這個, 那么你的 initial-scale 始終只要設置成 1/devicePixelRatio 即可,
因為 devicePixelRatio * 1/devicePixelRatio = 1;
還有其他的兩個相關屬性:
maximum-scale: 最大能放大多少
minimum-scale: 最小能放大多少
希望不能縮放, 因為我們的頁面不需要縮放就能正常顯示, 縮放了反而顯示不正確。
最終統籌一下:
我們要做的事情
1 讓 layout viewport 變成和屏幕分辨率一致的寬度
2 根據設備寬度和 devicePixelRatio 來指明根元素的 font-size 值
這些操作之后, 你就可以實現最終的代碼了.
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/112276.html
摘要:另一種就是不縮放,對等問題單獨引入處理方案。彩蛋部分相信大多數同學也是有想法在實際開發中把融入到現有的移動端適配方案中的。 前言 2018年最后的法定假期都已經結束了,我相信大部分正在進行或曾經進行過移動端頁面開發的同學都或多或少的了解過使用rem進行移動端頁面適配的方案以及使用vw的方案,(沒了解過的同學可以參見大漠老師的這兩篇文章 使用Flexible實現手淘H5頁面的終端適配和再...
摘要:另一種就是不縮放,對等問題單獨引入處理方案。彩蛋部分相信大多數同學也是有想法在實際開發中把融入到現有的移動端適配方案中的。 前言 2018年最后的法定假期都已經結束了,我相信大部分正在進行或曾經進行過移動端頁面開發的同學都或多或少的了解過使用rem進行移動端頁面適配的方案以及使用vw的方案,(沒了解過的同學可以參見大漠老師的這兩篇文章 使用Flexible實現手淘H5頁面的終端適配和再...
摘要:隨著移動端的發展,在手機上看電腦端的頁面已成為非常普及現象。方案一固定高度,使其寬度自適應這也是我接觸移動端適配第一次使用的方案。 不知不覺做前端已經兩年了,從PC端,移動端,微信小程序一路走來到今天剛剛開放注冊的快應用(手機廠商對抗小程序的新技能,所以在注冊時用的是qq郵箱的話要去垃圾箱里才能找到注冊郵件),對于前端圈日新月異的磅礴發展對于大前端發展是喜聞樂見的,這次的快應用的手機廠...
摘要:隨著移動端的發展,在手機上看電腦端的頁面已成為非常普及現象。方案一固定高度,使其寬度自適應這也是我接觸移動端適配第一次使用的方案。 不知不覺做前端已經兩年了,從PC端,移動端,微信小程序一路走來到今天剛剛開放注冊的快應用(手機廠商對抗小程序的新技能,所以在注冊時用的是qq郵箱的話要去垃圾箱里才能找到注冊郵件),對于前端圈日新月異的磅礴發展對于大前端發展是喜聞樂見的,這次的快應用的手機廠...
摘要:隨著移動端的發展,在手機上看電腦端的頁面已成為非常普及現象。方案一固定高度,使其寬度自適應這也是我接觸移動端適配第一次使用的方案。 不知不覺做前端已經兩年了,從PC端,移動端,微信小程序一路走來到今天剛剛開放注冊的快應用(手機廠商對抗小程序的新技能,所以在注冊時用的是qq郵箱的話要去垃圾箱里才能找到注冊郵件),對于前端圈日新月異的磅礴發展對于大前端發展是喜聞樂見的,這次的快應用的手機廠...
閱讀 2054·2021-10-08 10:04
閱讀 3079·2021-09-22 10:02
閱讀 2225·2019-08-30 15:56
閱讀 825·2019-08-30 15:54
閱讀 921·2019-08-30 15:54
閱讀 1276·2019-08-30 15:53
閱讀 2508·2019-08-30 11:21
閱讀 3557·2019-08-30 10:56