rem布局加载闪烁问题

说明：以下内容来自CSDN,如有侵权,请立刻联系博主（我），我将删除该内容。

原文链接 https://blog.csdn.net/u013778905/article/details/77938784

先上体验地址：http://jiguang.qq.com/jiguang_app/kapian/html/card-query.html?from=singlemessage

扫描二维码：

问题

翻到文章底部（反思1024），查看最新解决方案。

rem布局在加载的时候会出现元素一开始很小，闪烁一下恢复正常大小，这是怎么回事呢？为此，我们来探讨一下！

rem的布局具体不介绍了吧，你应该已经掌握或者会用了。

这里我的设计稿是750px的，以下是我用来动态设置html根元素font-size的代码，这里我设置了最大值100px哈！

!(function(doc, win) {

    var docEl = doc.documentElement,

        resizeEvt = 'orientationchange' in window ? 'orientationchange' : 'resize',

        recalc = function() {

            var clientWidth = docEl.clientWidth;

            if (!clientWidth) return;

            if (clientWidth < 750) {

                docEl.style.fontSize = 100 * (clientWidth / 750) + 'px';

            } else {

                docEl.style.fontSize = '100px';

            }

        };

    if (!doc.addEventListener) return;

    win.addEventListener(resizeEvt, recalc, false);

    doc.addEventListener('DOMContentLoaded', recalc, false);

})(document, window);

我新建了一个common.js文件，把该js代码放里面，然后在</body>前引入

<script src="js/common.js"></script>

写好页面后发布看下，我们会看到html元素先很小，闪烁一下又正常了，虽然不影响功能，但是这给用户的体验是不行的啊，太明显了！

正常应该是：

实际情况是：

解决

模拟弱网环境，通过查看代码发现，DOM在渲染出来的时候，html根元素font-size的大小，js还没有设置进去。如下图

设想一：既然js看上去是执行的晚了，那我们就把js放在head中怎么样？
测试发现结果还是一样！

设想二：是不是通过外链引入js会耗费加载时间，我们直接把这段js放在</body>前怎么样？
测试发现结果还是一样！

设想三：是不是js代码放head中会快点？
测试发现结果还是一样！

算了，不设想了，这里我们就需要清楚，css/js对DOM树渲染的影响了。

CSS（外链或内联）会阻塞整个DOM的渲染（Rendering），然而DOM解析（Parsing）会正常进行
很多浏览器中，CSS会延迟脚本执行和DOMContentLoaded事件
JS（外链或内联）会阻塞后续DOM的解析（Parsing），后续DOM的渲染（Rendering）也将被阻塞
JS前的DOM可以正常解析（Parsing）和渲染（Rendering）

说明：
无论是外链CSS还是内联CSS都会阻塞DOM渲染（Rendering），然而DOM解析（Parsing）会正常进行。这意味着在CSS下载并解析结束之前，它后面的HTML都不会显示。这也是为什么我们把样式放在HTML内容之前，以防止被呈现内容发生样式跳动。当然代价就是显示延迟，所以性能攸关的站点都会内联所有CSS。

很多浏览器中CSS还会延迟脚本执行和DOMContentLoaded事件触发（该事件就是jQuery的dom ready）。

不论是内联还是外链JavaScript都会阻塞后续DOM解析（Parsing），当然后续DOM的渲染（Rendering）也被阻塞了。之所以DOM解析（Parsing）需要暂停，是因为脚本中可能会包含类似document.write的语句，即脚本有可能改变当前DOM树。

值得注意的是JavaScript只会阻塞后续的DOM而非整个DOM，这意味着前面的DOM可以被正确地解析以及渲染。这也是为什么我们把脚本放在页面底部：脚本仍在下载时页面已经可以正常地显示了。

下图可以表明资源加载时会先加载css再加载js。

结论：
从html入手无法解决问题，那我们就从css入手吧！
上面说了，既然我们的css都会选择优先加载，防止跳动，那我们是不是可以一开始就让网页是正常显示的呢，也就是说，我们来设置html的font-size属性，这里我们通过媒体查询，把相对应的设备区间的根元素font-size列举出来，因为我们是750px的设计稿，而且我们的开发方式是1rem=100px（如果你了解rem的话你应该理解），也就是说，在iPhone6的375像素宽的设备上，我们的html根元素font-size大小应该是50px，具体代码如下：

@media (min-width: 320px){html{font-size: 42.6667px;} }

@media (min-width: 360px){html{font-size: 48px;} }

@media (min-width: 375px){html{font-size: 50px;} }

@media (min-width: 384px){html{font-size: 51.2px;} }

@media (min-width: 414px){html{font-size: 55.2px;} }

@media (min-width: 448px){html{font-size: 59.7333px;} }

@media (min-width: 480px){html{font-size: 48px;} }

@media (min-width: 512px){html{font-size: 68.2667px;} }

@media (min-width: 544px){html{font-size: 72.5333px;} }

@media (min-width: 576px){html{font-size: 76.8px;} }

@media (min-width: 608px){html{font-size: 81.0667px;} }

@media (min-width: 640px){html{font-size: 85.3333px;} }

@media (min-width: 750px){html{font-size: 100px;} }

如此解决的话我们发现，一开始DOM还没有渲染完但可以正常展现的时候，html的根元素字体大小的设置来源于媒体查询，如下图；当DOM解析完成，js计算了html的根元素字体大小后，字体大小值来源于js设置的行内样式，计算后的值发挥作用！至此这个问题完美解决。

（请忽略背景图片没加载出来的问题哈）

扩展

到这个时候，你已经解决加载闪烁的问题了，但是运气不好的你还可能遇到一个问题，在某些设备上，会出现页面元素比期望值要小或者大，如下图，偷偷告诉你，这是设备系统字体大小的问题，详见下篇！rem布局在webview中页面错乱

补充 0925

如果你也好奇媒体查询的这些设备宽度节点哪里来的，有没有什么标准，那我会告诉你，我是在chrome的代码调试工具里找的，如下图，在箭头处找到 show media queries 就会显示啦。

当然除了显示媒体查询的节点，你还可以点击其他的选项看看，还有会有新发现的。比如可以显示手机外形，dpr等。是不是挺有意思的，快去试试吧！

反思 1024

碰巧今天是程序员节哈哈哈！

其实之前对这个解决方案一直不是很满意，我写了JS还要写一堆媒体查询，总感觉不对。

这两天我想了下，问题的原因无非就是html一开始没有设置字体大小嘛，那我们就一开始按最常用的iPhone 6 尺寸，设置html的font-size: 50px;好了，这样的话JS动态计算和媒体查询，我们只要选择一套方案就好了，他们两个是不同的适配方案，而且媒体查询的目的就是为了加载css的时候就设置html字体大小，我居然把他们混合起来使用，感觉有点冗余了。

有同学也会问了，设置html的font-size: 50px;就合理了吗？我的回答是，至少变化的范围非常小，以360px宽的设备为例，根字体大小应该是48px；以前相当于是从0px-48px，现在是50px-48px，不会造成很明显的闪烁问题。

至于为什么设置为50px；首先，设计稿是基于750px来设计的，我们重构稿实现的时候根元素大小应该是设置为50px（在规定1rem=100px的前提下）；其次，720px和750px这两个设备尺寸，是安卓和IOS设备中占比比较大的设备尺寸。

最终方案：
1.html{font-size: 50px;}//这个一定写
2.JS动态计算和密集的媒体查询二选一