## 用事實證明viewport scale縮放不會改變rem元素的大小 我們知道，早期淘寶flexible.js使用viewport scale縮放解決高清屏下1px邊框問題的，那么我們問題如下： **縮放頁面的同時不會把其它rem元素也縮放了嗎，除非不傷及無辜，否則就不能用縮放實現0.5px邊框。** 下面我們就來證明，為什么rem元素不受縮放影響（即縮放了，但是rem元素的物理尺寸沒有變化，**rem元素只會在屏幕大小變化時自動縮放適應，利用的是動態的基準值**），證明如下： >[danger] 用于顯示元素的物理像素數量 = 用于顯示元素的點的數量 * 一個點所包含的物理像素數量 上面的公式表示了，元素的大小（物理尺寸）是由用于顯示該元素的物理像素數量決定的。 像素密度不能被改變，也就是物理像素的尺寸是不可改變的，是每個設備固定的。 **viewport scale縮放會使設備獨立像素改變。** 設備獨立像素改變會觸發`resize`事件，導致基準值被重新設置： ``` html.style.fontSize = window.innerWidth / Z + 'px'; ``` 我們放大頁面，scale=2 屏幕的像素密度是固定的，我們css樣式里面寫的rem也是寫死的，現在屏幕的設備獨立像素縮小了scale倍（**點數量減少為原來的1/scale**），相當于是DPR放大了scale倍（雖然設備的DPR不能被修改），**即一個點所包含的物理像素變多了，為原來的scale倍。** > 設備獨立像素會被縮放，這個縮放的計算過程我們不能控制，對我們來說不是透明的，我們根據只能`window.innerWidth`獲取到變化的設備獨立像素的值，這個縮放計算有精度問題，比如只會四舍五入取整，這就導致即使rem元素縮放前后還是會有一些偏差，精確度的問題，下面會說到。 而1px還是原來的一個點，但是這個點所包含的物理像素變化了，所以用px為單位的元素就會被同等縮放。 那rem單位呢？ ```javascript // 初始狀態： rem * (window.innerWidth / Z) // 現在： rem * (window.innerWidth / Z) * 1/scale ``` 注意，在設備獨立像素縮小的時候，基準值也縮小了scale倍，為原來的`1/scale`。 所以元素的px（**元素的點值**），也跟著縮小scale倍，為原來的`1/scale`。 上面已經說過，一個點所包含的物理像素數量變為原來的scale倍了，而現在元素的點數量減少為原來的`1/scale`了，所以剛好抵消，用于顯示元素的物理像素數量沒變。 元素所占的物理像素個數沒變，所以元素的物理尺寸也就沒變化了。 （當然實際情況，我們看到縮放時rem元素物理尺寸前后還是有一點點區別和變化的，這是因為在縮放計算的過程中由于小數精確度引起的誤差導致的，比如四舍五入等等，如果不追求像素級的精確性，這點誤差可以忽略，只要明白原理就可以了，可以認為rem元素沒有變化，不收縮放影響） 所以淘寶用縮放解決高清屏下1px邊框問題是有效的，且對rem元素是無害的。 證明完畢。 ~~~ 其它： 移動端模式調試時，瀏覽器右下角的縮放功能沒有作用（Ctrl+滾輪），調試欄提供的縮放可以使用，但是這只是單純的縮放效果，只是為了方便查看，不會影響任何其它東西，以及任何參數，更不會觸發事件之類的。 非移動端調試模式時（PC模式），viewport設置不起任何作用，任何參數的變化都不起作用，沒有任何效果。 PC模式時（window.devicePixelRatio為1），放大頁面為150%時（瀏覽器右下角的縮放功能），window.devicePixelRatio為1.5（dpr在PC端是可以被改變的，在移動端雖然不能被直接修改，但是viewport scale視口縮放也相當于是間接修改了dpr），window.innerWidth縮小為原來的1/1.5（826/1.5=550.66666666667，它直接給四舍五入取整了，為551）。看來這就相當于移動端時的viewport scale縮放了，同理，rem元素尺寸不受這種縮放影響，上面已經證明過了。 有時候縮放后感覺屏幕有點虛，文字和元素都是虛的，就是有點模糊像是隔著一層霧的那種感覺，這估計也是縮放計算時不精確導致的問題。（蘋果官網也有這種虛的感覺，） scale小于或等于0時就相當于是等于1，跟值為1時是一樣的效果。 ~~~ * * * * * last update：2018-7-21 07:16:23