前端性能优化之浏览器渲染优化 —— 打造60FPS页面 about blog HOT 11 OPEN

灰常nice的文章

from blog.

感谢楼主雄文，学习了~

from blog.

学习了>__<

from blog.

当下一次循环到来时浏览器还没进重排（因为一直处于 JS 阶段） ，为了获取正确的 width ，浏览器就不得不立刻重新 Layout 获取一个最新值，从而失去了浏览器自身的批量更新的优化，这就是强制同步布局。

为什么叫强制呢，大多数浏览器通过队列化修改并批量执行来优化重排过程（就是上面说的异步布局），但是如果触发了强制同步布局 ，每经过一次循环，都会要求浏览器强制刷新队列并要求计划任务立刻执行，这就失去了浏览器对重排的优化。

js 执行过程中，所有涉及到 GUI 更新的操作都会被放置在一个队列，等待 js 线程空闲后，再执行渲染线程。但是如果在 js 执行过程中触发了重排，则会清空队列，强制挂起 js 线程，使用渲染线程做一次回流后再回到 js 线程，好计算出正确的布局相关值。因为回流、线程间通信会有一定的代价，所以才有所谓的 dom 操作性能问题。

不知道这样子理解是否合理？

from blog.

@cyh-93 我也是这么理解的😎

from blog.

@cyh-93 我是这样理解的：
1、正常来说，一次事件循环里所有对dom的操作会合并在一起渲染（对应原文关键词：还没进重排、批量执⾏）

let boxes = document.getElmentsByClassName('.box')
for(let i = 0; i < boxes.length; i++) {
    let width = document.getElementById('table')
    boxes[i].style.color = 'red'
}

2、现在，每次循环一开始就会执行一次重排，换句话说，执行一次对dom的操作就会引起一次重排（对应原文关键词：强制同步布局）

let boxes = document.getElmentsByClassName('.box')
for(let i = 0; i < boxes.length; i++) {
    let width = document.getElementById('table').width
    boxes[i].style.width = width
}

3、如果非得这么做那也没办法，只能用rAF，把上面的一次读写操作放到它的回调里，然后一帧执行一次读写，再经过这一帧正常的渲染后，下一帧就能拿到正确的值（对应原文关键词：推迟到下一帧、正常的Layout）
4、然后呢，必须是先读再写，如果是先写再读，又要发生强制同步布局了

requestAnimationFrame(logBoxHeight);
function logBoxHeight() {
     box.classList.add('super-big');
     // Gets the height of the box in pixels
     // and logs it out.
     console.log(box.offsetHeight);
}

from blog.

文章很受用，精彩。

想问一下您，现在的一些 editor 插件，比如左边写右边预览的 markdown 插件或者集成这些插件的编辑器比如 Typora, HexoCleint (貌似都是基于 Electron)，在输出字数不多的情况下，很流畅，一旦书写的比较多了，那么左边的录入框会异常卡顿，反应超级慢。

请问这方面的问题可以从哪方面拯救一下么？(个人猜测可能是集成的chrome渲染处理逻辑问题)

您对这方面的见解是？还请指点一下。

from blog.

彩彩彩！

from blog.

受教了

from blog.

感觉楼主说rAF的时机有问题，requestAnimationFrame其实是在每帧绘制之前执行的，也就是js event loop -> rAF -> style -> layout -> paint -> composite，以前edge和Safari把rAF放在了paint后面是不符合标准的，但是现在也改回来了。

from blog.

看完收获很大

from blog.