<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>浏览器渲染过程 on Last Stand</title><link>https://amatsuzero.github.io/LastStand/tags/%E6%B5%8F%E8%A7%88%E5%99%A8%E6%B8%B2%E6%9F%93%E8%BF%87%E7%A8%8B/</link><description>Recent content in 浏览器渲染过程 on Last Stand</description><generator>Hugo</generator><language>zh-cn</language><lastBuildDate>Wed, 16 Jul 2025 00:00:00 +0800</lastBuildDate><atom:link href="https://amatsuzero.github.io/LastStand/tags/%E6%B5%8F%E8%A7%88%E5%99%A8%E6%B8%B2%E6%9F%93%E8%BF%87%E7%A8%8B/index.xml" rel="self" type="application/rss+xml"/><item><title>浏览器渲染过程</title><link>https://amatsuzero.github.io/LastStand/posts/frontend/performance/performance-001/</link><pubDate>Tue, 17 Dec 2024 00:00:00 +0800</pubDate><guid>https://amatsuzero.github.io/LastStand/posts/frontend/performance/performance-001/</guid><description>&lt;h2 id="渲染流程"&gt;渲染流程&lt;/h2&gt;
&lt;p&gt;首先要了解的概念:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;渲染引擎：它是浏览器最核心的部分是 “Rendering Engine”，不过我们一般习惯将之称为 “浏览器内核”&lt;/li&gt;
&lt;li&gt;渲染引擎主要包括的线程：&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;&lt;img loading="lazy" src="https://amatsuzero.github.io/LastStand/posts/frontend/performance/performance-001/image-01.webp"&gt;&lt;/p&gt;
&lt;p&gt;各个线程主要职责：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;GUI渲染线程&lt;/strong&gt;：GUI 渲染线程负责渲染浏览器界面，解析 HTML，CSS，构建 DOM 树和 RenderObject 树，布局和绘制等。当界面需要重绘（Repaint）或由于某种操作引发回流（Reflow）时，该线程就会执行。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;JavaScript引擎线程&lt;/strong&gt;: JavaScript 引擎线程主要负责解析 JavaScript 脚本并运行相关代码。 JavaScript 引擎在一个Tab页（Renderer 进程）中无论什么时候都只有一个 JavaScript 线程在运行 JavaScript 程序。需要提起一点就是，GUI线程与JavaScript引擎线程是互斥的，这也是就是为什么JavaScript操作时间过长，会造成页面渲染不连贯，导致页面出现阻塞的原理。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;事件触发线程&lt;/strong&gt;：当一个事件被触发时该线程会把事件添加到待处理队列的队尾，等待 JavaScript 引擎的处理。 通常JavaScript引擎是单线程的，所以这些事件都会排队等待JS执行。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;定时器触发器&lt;/strong&gt;： 我们日常使用的setInterval 和 setTimeout 就在该线程中，原因可能就是：由于JS引擎是单线程的，如果处于阻塞线程状态就会影响记时的准确，所以需要通过单独的线程来记时并触发响应的事件这样子更为合理。&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Http请求线程&lt;/strong&gt;： 在 XMLHttpRequest 在连接后是通过浏览器新开一个线程请求，这个线程就Http请求线程，它 将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件放到 JavaScript 引擎的处理队列中等待处理。&lt;/li&gt;
&lt;/ul&gt;
&lt;hr&gt;
&lt;p&gt;&lt;strong&gt;有了上述的概念，对接下我们讲渲染流水线会有所帮助&lt;/strong&gt;&lt;/p&gt;
&lt;h2 id="简略版的渲染机制"&gt;简略版的渲染机制&lt;/h2&gt;
&lt;p&gt;很久之前就把浏览器工作原理读完了，看了很多博客，文章，当时简简单单的梳理一些内容,如下👇&lt;/p&gt;
&lt;p&gt;简略版渲染机制一般分为以下几个步骤&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;处理 HTML 并构建 DOM 树。&lt;/li&gt;
&lt;li&gt;处理 CSS 构建 CSSOM 树。&lt;/li&gt;
&lt;li&gt;将 DOM 与 CSSOM 合并成一个渲染树。&lt;/li&gt;
&lt;li&gt;根据渲染树来布局，计算每个节点的位置。&lt;/li&gt;
&lt;li&gt;调用 GPU 绘制，合成图层，显示在屏幕上。&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;&lt;img loading="lazy" src="https://amatsuzero.github.io/LastStand/posts/frontend/performance/performance-001/image-02.webp"&gt;&lt;/p&gt;
&lt;p&gt;接下来大概就是这么说：&lt;/p&gt;
&lt;p&gt;在构建 CSSOM 树时，会阻塞渲染，直至 CSSOM 树构建完成。并且构建 CSSOM 树是一个十分消耗性能的过程，所以应该尽量保证层级扁平，减少过度层叠，越是具体的 CSS 选择器，执行速度越慢。&lt;/p&gt;</description></item></channel></rss>