知乎问题：为什么很多web项目还是使用 px，而不是 rem？

阅读过几篇关于 px rem 的文章，感觉 rem 很强大。但是自己接触到的公司项目全部都使用 px，想知道为什么。是我司技术更新落后了吗？

我们当然有在用 vw 和 vh，但是只是在 layout 层级，组件层使用 px。

人数赞同最多的回答

先抛出观点：

本文建议读者不要使用flexible或者其他修改viewport致使viewport width不等于device-width的方案（因为这会导致一些bug）
本文建议读者不要使用以rem或者小程序rpx来实现等比缩放为主的布局手段，而使用面向逻辑像素px为主，面向等比缩放的vx和vxxx（vw/vh/vmax/vmin）为辅助的布局单位，搭配一些flex等布局手段
本文建议读者一般情况遵循：同样观看距离情况下，大屏看的更多而不是大屏看的更大的设计最佳实践来进行布局，并且以这种最佳实践作为理论依据来传递给设计师（当然你觉得等比缩放才是合理的，请看其他回答，该回答不适合你）
本文没有鼓吹读者使用响应式布局，也没有鼓吹读者盲目忽略兼容性使用vx和vxxx，同时也没有反对读者使用rem这个单位本身原有的定义来实现一些布局

吐槽

你们老是鼓吹rem的，醒醒吧，别再看网上大片大片的rem文章

flexible方案已经废坑了，已经废坑了，已经废坑了

对，flexible已经不维护了，原因自己看flexible的github

px没有问题，用rem来实现自适应才有问题（因为它是vx，vxxx单位的备胎），能问这种问题的人，应该认真研究一下viewport。

下面简单介绍下上面的几个知识点：

①：flexible.js

rem是相对于根元素<html>，这样就意味着，我们只需要在根元素确定一个px字号，则可以来算出元素的宽高。1rem=16px(浏览器html的像素，可以设定这个基准值），假如浏览器的html设为64px，则下面的元素则1rem=64px来运算。

阿里团队开源的一个库flexible.js作用就是通过rem和px之间的换算，把设计稿从px转到rem。兼容自适应各种移动端设备。

flexible.js关键代码（通过js来调整html的字体大小，而在页面中的制作稿则统一使用rem这个单位来制作）：

;(function(win,lib) {
    var doc = win.document;
    var docEl = doc.documentElement;
    var metaEl = doc.querySelector('meta[name="viewport"]');
    var flexibleEl = doc.querySelector('meta[name="flexible"]'var dpr = 0;
    var scale = 0var tid;
    var flexible = lib.flexible || (lib.flexible = {});
    
    if (metaEl) {
        console.warn('将根据已有的meta标签来设置缩放比例');
        var match = metaEl.getAttribute('content').match(/initial\-scale=([\d\.]+)/ (match) {
            scale = parseFloat(match[1]);
            dpr = parseInt(1 / scale);
        }
    } else  (flexibleEl) {
        var content = flexibleEl.getAttribute('content' (content) {
            var initialDpr = content.match(/initial\-dpr=([\d\.]+)/);
            var maximumDpr = content.match(/maximum\-dpr=([\d\.]+)/ (initialDpr) {
                dpr = parseFloat(initialDpr[1]);
                scale = parseFloat((1 / dpr).toFixed(2));    
            }
             (maximumDpr) {
                dpr = parseFloat(maximumDpr[1));    
            }
        }
    }

    if (!dpr && !scale) {
        var isAndroid = win.navigator.appVersion.match(/android/gi);
        var isIPhone = win.navigator.appVersion.match(/iphone/var devicePixelRatio = win.devicePixelRatio;
         (isIPhone) {
            // iOS下，对于2和3的屏，用2倍的方案，其余的用1倍方案
            if (devicePixelRatio >= 3 && (!dpr || dpr >= 3)) {                
                dpr = 3;
            } if (devicePixelRatio >= 2 && (!dpr || dpr >= 2)){
                dpr = 2else {
                dpr = 1;
            }
        }  {
             其他设备下，仍旧使用1倍的方案
            dpr = 1;
        }
        scale = 1 / dpr;
    }

    docEl.setAttribute('data-dpr',dpr);
    if (!metaEl) {
        metaEl = doc.createElement('meta');
        metaEl.setAttribute('name','viewport');
        metaEl.setAttribute('content','initial-scale=' + scale + ',maximum-scale=' + scale + ',minimum-scale=' + scale + ',user-scalable=no' (docEl.firstElementChild) {
            docEl.firstElementChild.appendChild(metaEl);
        } var wrap = doc.createElement('div');
            wrap.appendChild(metaEl);
            doc.write(wrap.innerHTML);
        }
    }

     refreshRem(){
        var width = docEl.getBoundingClientRect().width;
        if (width / dpr > 540) {
            width = 540 * dpr;
        }
        var rem = width / 10;
        docEl.style.fontSize = rem + 'px';
        flexible.rem = win.rem = rem;
    }

    win.addEventListener('resize',() {
        clearTimeout(tid);
        tid = setTimeout(refreshRem,300);
    },false);
    win.addEventListener('pageshow',1)">(e) {
         (e.persisted) {
            clearTimeout(tid);
            tid = setTimeout(refreshRem,1)">);
        }
    },1)">);

    if (doc.readyState === 'complete') {
        doc.body.style.fontSize = 12 * dpr + 'px';
    }  {
        doc.addEventListener('DOMContentLoaded',1)">(e) {
            doc.body.style.fontSize = 12 * dpr + 'px';
        },1)">);
    }
    

    refreshRem();

    flexible.dpr = win.dpr = dpr;
    flexible.refreshRem = refreshRem;
    flexible.rem2px = (d) {
        var val = parseFloat(d) * this.rem;
        if (typeof d === 'string' && d.match(/rem$/)) {
            val += 'px';
        }
        return val;
    }
    flexible.px2rem = var val = parseFloat(d) / typeof d === 'string' && d.match(/px$/)) {
            val += 'rem' val;
    }

})(window,window['lib'] || (window['lib'] = {}));

从上面的代码，主要是改变了dpx和document的font-size大小。大小为docEl.getBoundingClientRect().width / 10 + 'px';

详细可参考地址：《flexible.js 布局详解》

css里边px到底是什么

都9102了

都不知道px是viewport像素，

不是物理像素，不是逻辑像素，不是渲染像素

这里简单解释一下viewport像素，物理像素，逻辑像素，渲染像素

首先物理像素，逻辑像素，渲染像素的关系

下图是部分iphone设备的逻辑像素（下图为像素，其实应该翻译为点 Points），渲染像素，物理像素的指标，看了应该清晰这三者之间的关系

物理像素（physical pixel）就是反映显示屏的硬件条件，反映的就是显示屏内部led灯的数量，可以简单理解，一组三色led代表一个物理像素，当然根据屏幕物理属性以及处理led的方法不一样。强调这是物理的，因为这是一个纯硬件指标。比如我把屏幕锯了一半，物理像素就只有一半。

注：LED，发光二极管，是一种固态的半导体器件，它可以直接把电能转化为光能。

渲染像素（render pixel），则是在系统内部对物理像素的分配进行再一次的调整，在pc上，渲染像素其实就是设置里边的分辨率。对于显示设备，系统为显示设备提供渲染尺寸，由显示设备的“缩放引擎”（带存储器阵列的数字视频处理器）处理。这种“缩放引擎”一般内部有一系列的合理分辨率和一个推荐分辨率。一般推荐分辨率就是最大渲染像素，也是设备的物理分辨率（为了最佳表现）。这是一个软硬件（偏硬）结合的缩放方案。由于部分设备不能设置渲染像素，所以下文部分场景为了简化模型，直接跳过渲染像素，直接等同于物理像素

逻辑像素/点（device point / device pixel / point ），是为了调和距离不一样导致的差异，将所有设备根据距离，透视缩放到一个相等水平的观看距离之后得到的尺寸，是一个抽象的概念，这个单位就是ios开发的px，安卓开发的dp。对于pc，包括win（8+） linux，mac，由各自系统的或者对应软件（比如webview内部）提供的图像界面处理引擎处理进行缩放

在win上，可以通过显示设置缩放比例来调整部分应用的逻辑像素。对于linux，可以通过x和wayland的缩放比例来调整

但是，由于这个是一个纯软件的方案，如果部分软件不遵循开发规则，或者使用老旧的api，就会导致逻辑像素不合理，导致缩放问题。例如win10中部分旧的软件在高分屏的设备会导致界面偏小。因为他们实际是使用的是渲染像素而不是逻辑像素

各种设备，手机，平板，笔记本等逻辑像素

手机：逻辑像素在3xx-4xx（短边）之间

平板：10寸平板7xx-8xx（短边）

笔记本：13寸 1280 （长边）

24寸显示屏：1920（长边）

你会发现如果设置width=device-width下，无论是否高分屏，在浏览器得到的screen.width仍然符合上述的尺寸

逻辑像素的引入，简单来说，就是为了消除了不同屏幕观看距离和不同ppi（见下文）之间的差异，衍生出来的一个虚拟的尺寸

ppi（pixel per inch） 每英寸像素，指的是屏幕在每英寸的物理像素，更高的ppi意味着屏幕的清晰度更佳。

所谓高分屏，其实就是指ppi大于同类设备的屏幕。比如对于桌面设备，大于96ppi。对于移动设备，大于160ppi

所谓视网膜屏，其实就是指在该观看距离内超出人类的辨认能力的屏幕。比如对于桌面设备，大于192ppi。对于移动设备大于326ppi

ppi，对于移动设备而言，一般来说ppi以160为一个档次

也就是假设一个ppi160，2寸x3寸的屏幕，物理像素应该是320x480。同理ppi320，同样尺寸的屏幕，物理像素是640x960

由于它们尺寸一致，假设它们观看距离一致，那么消除掉ppi的影响，他们的逻辑像素是一致的

也就是

逻辑像素长度 = 物理像素长度 * 160 / ppi

得出都是 320 x 480

当然，由于生产标准不一致，不可能做到绝对的160ppi作为标准，所以ppi的等级划分是动态的

dpr （device point ratio / device pixel ratio） 渲染像素与逻辑像素的比例。由于渲染像素一般等于逻辑像素，如果ppi是以160为基准的话，那么 dpr = ppi / 160

多少倍屏或者多少x（三倍屏，3x，意思就是3dpr），一般来说就是说的是这个值

viewport像素又是什么，它本质是DIP（Device Independent Pixels），中文意思设备无关像素，是与上述所有像素都无绝对逻辑关系的一个单位。其实是浏览器内部对逻辑像素进行再处理的结果，简单来理解就是调整逻辑像素的缩放来达到适应设备的一个中间层

对于pc，viewport是不生效的，所以在pc上，px其实就是逻辑像素（chrome）。但是逻辑像素是与软件实现有关的，所以会出现一些问题。比如在win上，对于部分国产马甲浏览器，viewport内部没有适配系统的缩放等级，导致渲染的内容过小

如果你像评论区的某些看客一样麻木认为pc的px就是物理像素，那么你可能就不知道怎么解决了，甚至百度半天都找不到答案

比如这个问题

谷歌浏览器的100％显示和搜狗125％显示大小相同？

面向逻辑像素开发的基本开发流程

1. 在head 设置width=device-width的viewport
2. 在css中使用px
3. 在适当的场景使用flex布局，或者配合vw进行自适应
4. 在跨设备类型的时候（pc <-> 手机 <-> 平板）使用媒体查询
5. 在跨设备类型如果交互差异太大的情况，考虑分开项目开发

那么viewport width=device-width是什么意思，其实就是让viewport的尺寸等于逻辑像素的尺寸

关于px的疑问

那有朋友就问，不同设备的物理像素是不一样的呀，我怎么实现不同物理像素的布局，如果设计师给你一张图，怎么将它转为我想要的在css里边的px

首先，你要读懂设计师给你设计图的意图，一般国内的设计师，给出手机版的设计图，一般是750px，注意这里的px，并不是我们的px（逻辑像素），其实是物理像素，因为设计师是根据iphone6或者同等设备来进行设计的，那么要知道iphone6的逻辑像素其实是 375，dpr是2，那么拿到手的设计稿，转换为逻辑像素，就得除以2，我们叫这种设计图，叫两倍图

同理，如果是375 + 375 + 375大小，那么我们就得除以3，叫三倍图

如果设计团队有使用墨刀或者蓝湖，你可以在两者里边设置你的查看尺寸，得到我们需要的逻辑像素

如果设计师不用蓝湖等工具，给你的并不是375的倍数怎么办，我先说办法，原因你们自己琢磨，我不细致分析

最简单的方法，设计师给你的图的物理宽度w，除以一个数x，如果得的出来的商在360 - 414之间，那么你换算的公式为【你在设计图测量出来的物理像素数除以x】，那么dpr就是x，也就是x倍图

那么朋友又会问，不同设备逻辑像素也不一样呀

对，不一样，但问题为什么我们要将它们弄成一样？其实，不一样，才是合理的。我暂且不说原因，原因后面的文章解释

那么不一样的情况，怎么布局？那就靠你们技术手段，flex，流式布局，vw等

总结

设计师给的设计稿都是物理像素（比如750px）,我们实际处理的是移动端的屏幕尺寸px是逻辑像素（比如iphone6的逻辑像素是375）；由于PC端viewport是不生效的，所以pc端的px就是逻辑像素（chrome）
ppi（pixel per inch）每英寸像素，指的是屏幕在每英寸的物理像素，更高的ppi意味着屏幕的清晰度更佳。对于移动设备而言，一般来说ppi以160为一个档次。
dpr （device point ratio / device pixel ratio）渲染像素与逻辑像素的比例。由于渲染像素一般等于逻辑像素，如果ppi是以160为基准的话，那么 dpr = ppi / 160.
逻辑像素长度 = 物理像素长度 * 160 / ppi，也即是逻辑像素长度 = 物理像素长度 * 1/dpr;

知乎问题地址及详细答案：《为什么很多web项目还是使用 px，而不是 rem？》

知乎问题：为什么很多web项目还是使用 px，而不是 rem？

人数赞同最多的回答

吐槽

css里边px到底是什么

面向逻辑像素开发的基本开发流程

关于px的疑问

总结

相关文章