## 用事实证明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