브라우저 표시 뒤에 상호 작용 원리

브라우저 표시 뒤에 상호 작용 원리

뇌관

저자 (때문에 강한 사랑 프로그래밍 헤드는 ) 최근에 소개 된 책에 작은 프로그램을 썼습니다. 한 장에서는 실제와 자바 스크립트 DOM 사이의 버퍼 층의 층이다 가상 DOM을 소개하는 것입니다. 를 도입하고 그렇게 인기있는 이유, 세 개의 프런트 엔드 프레임 워크, 애플릿, 당신의 그림자를 볼 수있는 이유. 예 뒤에 원리는 무엇입니까. 브라우저 뒤에 작동 원리에 기초하지, 분명히 가상 DOM 최대 이익을 위해 진짜 이유가 도입 된 것을 확인하기가 어렵습니다.

브라우저를 실행 뒤에 논리를 이해하기 위해, 나는 기사의 매우 높은 금 내용이 아닌 인터넷과 더 혼합, 고르지, 결함, 근본적인는 규범, 당신은 찾을 수의 지식에도 불구하고, 많은 정보를 확인 볼 Tucao해야 쉽게. 다행히,이 문제에 대한, 난 정말이 문서의 해석, 하나를 발견했다. 좋은 기억은 나쁜 서면.

참고 : 모든 URL 짧은 URL 치료 바이두, 및 레이아웃 모양을 용이하게 한 후이입니다.

(축어)

• https://dwz.cn/iv59xbaG  "프런트 엔드 개요 : 뒤에서 통찰력 브라우저 작업"

• https://dwz.cn/b72rXXOy  "브라우저가 작동 : 현대 웹 브라우저의 장면 뒤에."

• https://dwz.cn/tn00LUqY  "브라우저가 작동-뒤에 어떻게 현대적인 웹 브라우저의 장면"

• https://dwz.cn/bb84qh4a  "HTMLLiving 표준 - 2019 최근 업데이트 8월 9일"

• https://drafts.csswg.org/cssom/  "CSS 개체 모델 (CSSOM)"

• https://www.w3.org/TR/css3-conditional"CSS  조건부 규칙 모듈 레벨 3 "

• https://fetch.spec.whatwg.org/  "생활 표준을 가져 오기 - 2019 최근 업데이트 8월 9일"

• https://dom.spec.whatwg.org/"DOM  생활 표준 - 2019 최근 업데이트 8월 9일 "

• http://t.cn/AiTQEiZr"Explore  구글 크롬 뒤에 매직 "

• https://dwz.cn/LtqlF3Qn  "크롬 브라우저의 보안 아키텍처"

• https://dwz.cn/hfEtd7H7  "프로세스가 크롬 공정 분석에서 시작 렌더링"

• https://dwz.cn/siobBJ1k  "레이아웃 엔진"

본문

이 문서에서는 독서 노트에, 우리는 깊이 약간의 원래 순서에 따라 동일합니다. 브라우저의 시장 점유율 회계 : 크롬 63.34 %, 사파리 15.06 %, 파이어 폭스 4.48 %, 삼성 인터넷 3.77 % UC 브라우저 3.58 %의 오페라 위의 브라우저의 2.58 %의 점유율, 그것은, 알 절대보다는 크롬, 그래서 우리는 시험에 그것을 기반으로 할 수 있습니다.

첫째, 브라우저 엔진

인기있는 설명은 엔진 드라이버, 엔진, 핵심 코드는 구성 요소의 집합 또는 확장 컴퓨터의 CPU에 해당하는 소프트웨어 패키지의 존재, 것입니다. 위키 백과의 설명입니다 등등 레이아웃 엔진, 레이아웃 엔진, 렌더링 엔진과 브라우저 엔진. 웹킷 엔진을 사용하여 크롬, 사파리, 모질라는 Gecho 엔진을 사용하여, 때로는 커널을했다. 참조 : Https://Dwz.Cn/Tr3rrt8m

공공의 정의보다도 충분하지만, 브라우저의 작동 메커니즘을 찾으려는 사람들을 위해, 그것은 충분하지 않습니다. 분명히, 그것은 일반적으로 몇 가지 핵심 브라우저 프로그램 (엔진) 집합 적으로 최대라고 그 대신에 모든 핵심으로 그들 중 하나를 사용, 그것은 매우 혼란 스럽다.

충분한 사람이 혼란을 (언급에 유래 물론이 https://dwz.cn/7ccPJcX6),  기사를 인용 한 이스라엘 여성 엔지니어, 브라우저 구성 요소 (7), 사용자 인터페이스 (UI), 브라우저에 나누어 져 엔진, 렌더링 엔진, 네트워킹, 백 - 엔드 사용자 인터페이스, 자바 스크립트 인터프리터 및 데이터 저장.

UI 브라우저 엔진 등 맵 렌더링 엔진의 관계로서

사용하는 각 브라우저 렌더링 / 레이아웃 엔진 및 엔진 JS 테이블

여기가 결국 브라우저 엔진은, 대중 위키 피 디아 설명, 유래 대답하지 않을 것이 분명하다 무엇을 의미하는지, 난 좀 더 신뢰성, 다중 프로세스 아키텍처를 크롬 브라우저의 해석에 따라이 생각 나는 ( 대머리 강력한 프로그래밍 사랑 ) 크롬의 사용은 중국어로 제공, 참조 용으로이 번역 :

하나를 답변 :

나는 설명하기 위해 "엔진"을 사용하는 방법을 모르겠어요. [ "의 멀티 프로세스 아키텍처를 갖는 맥락에서 크롬 브라우저를 사용하여 저를 보자

주요 브라우저 프로세스 : 주요 브라우저 프로세스 관리 렌더러 과정. 렌더러 과정 : 기본적으로 라벨 카드 (크롬)로 이해했다.

악성 웹 콘텐츠, 충돌하거나이를 방지하기 위해, 호스트 시스템을 손상 전체 브라우저의 결과로, 브라우저 프로세스가 각 요청을 처리하는 별도의 렌더링 처리 (렌더러 과정 (탭 프로세스)) 웹 콘텐츠를 의뢰 아마 때문에, 그것을 어떤 사용자 권한 없음 (운영체제 시스템 호출에 대한 즉, 제한된 액세스).

当请求网站时，渲染进程将请求转发到浏览器进程，进而发起对导航网站的网络请求。在Web内容到达之后，浏览器进程将内容发送回渲染进程。渲染器进程解析HTML，CSS文件，准备DOM，CSSOM，维护JS运行时（V8实例）并将内容作为位图格式发送到浏览器进程以在UI上显示它。

浏览器进程将渲染器进程视为黑盒子，期望渲染器进程将某种格式的Web内容转换为所需格式，其中包括几个子组件，布局引擎（进程，layout(chrome)/reflow(mozilla)是其中一个。

因此，浏览器进程处理用户特权资源/请求，例如访问文件系统，网络等，其中沙盒渲染器进程负责将网页转换为浏览器进程可以将其显示在OS窗口管理器中的格式。

这其中涉及到两个概念，一个是浏览器进程，一个是渲染进程。

#####回答二：

我认为答案取决于我们在这里讨论的背景。

背景1：如果你正在和一个只知道网络基本知识的朋友交谈......

此上下文中的浏览器引擎是指为您的浏览器提供内容并负责在屏幕上显示内容的软件。如果您在维基百科中搜索浏览器引擎，它会告诉您流行的浏览器引擎包括Webkit，Gecko，Trident等（https://en.wikipedia.org/wiki/Browser_engine）。

在这种情况下，估计很少有人知道有渲染引擎这个东西存在。

背景2：如果你正在和知道浏览器如何工作的朋友以及他们背后的所有疯狂魔法交谈......

此上下文中的浏览器引擎是指浏览器进程，主要负责管理所有I/o进程和显示UI及跟渲染引擎通信等。

浏览器引擎：在UI和渲染引擎之间编组操作。

这也是正确的。如果你看一下Chromium的架构，你会发现浏览器进程/引擎使用渲染进程来协调页面内容。

此上下文中的渲染引擎是指构造DOM，执行JavaScript和布局网页的程序，例如Webkit，Gecko，Trident。渲染引擎由两个主要组件组成：WebCore包含核心布局功能，JavaScriptCore包含JavaScript解释器V8。

您的朋友似乎是专家，还必须了解渲染过程，该过程负责构建网页。渲染引擎只是渲染过程中的关键部分。

下图显示了Chromium体系结构的高级体系结构概述（Google Chrome开源版本）。如果您想了解更多有关现代浏览器背后的魔力的信息，可以查看以下文章：https://medium.com/@zicodeng/explore-the-magic-behind-google-chrome-c3563dbd2739

二、渲染引擎（呈现引擎）

对文档或其他资源进行解析后，渲染到浏览器窗口显示。它是浏览器的核心部分。通常包含dom解析，css解析，生成render树，layout/reflow，repaint，直至呈现给用户。

三、内容8000个chunck（块）

文中提到“内容的大小一般限制在 8000 个chunck块以内”，解释：Web服务器生成HTTP Response时无法在Header就确定消息大小的，这时一般来说服务器将不会提供Content-Length的头信息，而采用Chunked编码动态的提供body内容的长度。进行Chunked编码传输的HTTP Response会在消息头部设置： Transfer-Encoding: chunked

四、渲染过程

浏览器请求到HTML代码后，在生成DOM的开始阶段，并行发起css、图片、js的请求。CSS文件下载完成后开始构建CSSOM。CSSOM构建完成后和DOM合并生成Render Tree（attachment）。浏览器计算出每个节点在屏幕的位置进行布局。布局完成后，通过显卡，将内容画到屏幕上。JS修改了DOM或者CSS属性后，Layout和Paint也会被重复执行。图片下载完成后也需要调用Layout和Paint来更新网页。

五、dom+cssom -> render tree

从dom，cssom到渲染树（frame树）的过程不同的内核树的概念不太一样的，不过所做的工作都大同小异，就是计算形成若干能用于布局的矩形盒子（宽度、高度和位置等几何信息，该计算过程具体实现在layout或reflow阶段），box模型。

Gecko 将视觉格式化元素组成的树称为“框架树”。每个元素都是一个框架。WebKit 使用的术语是“呈现树”，它由“呈现对象”组成。对于元素的放置，WebKit 使用的术语是“布局”，而 Gecko 称之为“重排”。对于连接 DOM 节点和可视化信息从而创建呈现树的过程，WebKit 使用的术语是“附加”。有一个细微的非语义差别，就是 Gecko 在 HTML 与 DOM 树之间还有一个称为“内容槽”的层，用于生成 DOM 元素。

六、树及DOM节点

树包含 DOM 节点，指的树是由实现了某些DOM 接口的元素构成的。每个元素都有一条原型链，标准定义了每个DOM节点或元素必须要实现的DOM接口（属性，方法，事件）。

七、添加defer，async的脚本预解析

通常html被解析的时候遇到js会阻塞执行，为了优化体验和速度，采用延迟或异步的方式，此时就存在了资源的预解析或异步执行的过程了。

八、共享样式

共享样式数据 WebKit 节点会引用样式对象 (RenderStyle)。这些对象在某些情况下可以由不同节点共享。这些节点是同级关系，并且：

这些元素必须处于相同的鼠标状态（例如，不允许其中一个是“:hover”状态，而另一个不是） 任何元素都没有 ID 标记名称应匹配 类属性应匹配 映射属性的集合必须是完全相同的 链接状态必须匹配 焦点状态必须匹配 任何元素都不应受属性选择器的影响，这里所说的“影响”是指在选择器中的任何位置有任何使用了属性选择器的选择器匹配 元素中不能有任何 inline 样式属性 不能使用任何同级选择器。WebCore 在遇到任何同级选择器时，只会引发一个全局开关，并停用整个文档的样式共享（如果存在）。这包括 + 选择器以及 :first-child 和 :last-child 等选择器。

代码：

<div>
	<ul>
		<li>11</li>
		<li>22</li>
		<li>33</li>
	</ul>
</div>

div ul li{	color: red;	width: 100px;	height: 36px;
}

以上代码就属于符合要求的公共样式。

Dirty 位系统

为避免对所有细小更改都进行整体布局，浏览器采用了一种“dirty 位”系统。如果某个呈现器发生了更改，或者将自身及其子代标注为“dirty”，则需要进行布局。

이마르크이 있습니다 "더러운"와 "아이들이 더러운입니다". "어린이가 더러운"렌더러 자체는 변경되지 않지만 것을 의미하지만, 적어도 하나의 자손 레이아웃을 가질 필요가있다.

약간의 변화가 전 세계적으로 다시 계산 및 레이아웃 발생하는 브라우저 수준에서 우리는 경우에 고려했다. 그래서 가상 DOM 그냥 성능을 향상 할 수 있도록 불필요한 인간 행동의 많은, 재 배열되었다 피할 수있다.

최적화 및 기본 가상 DOM의 최적화

레이아웃이 경우 당신은 다시 계산하지 않고 캐시에서 크기 렌더러를 얻을 수있다 "크기 조정"또는 렌더러 위치 (그리고 크기)의 변화가 트리거. 어떤 경우에는 단지 하위 트리가 수정되었습니다 루트 레이아웃에서 시작 할 필요가 없습니다. 이것은 텍스트 필드에 텍스트를 삽입하는 등 로컬 주변 요소에 영향을주지 않고 변경, (그렇지 않으면 때마다 키보드 레이아웃이 루트에서 시작 트리거) 경우에 적용됩니다.

탈리 Garsiel는 어려운이 문서와 폴 아일랜드어의 매우 깊은, 긴 반복 읽기에 적합한 여러 번 완전히 이해하고, 관련 지식은 철저하게 적어도 반이되었다, 이해, 매우 넓은 브라우저 레이아웃 전문가 및 전문가. 그러나 이것은 의미가 있습니다. 이 문서에서는 의심의 일부 추가 읽기를 할 수 있도록, 많은 장소는 다음, 이해의 깊이 손 대고 시간이 걸릴하지 않습니다가있다.

저자 : 사랑 대머리 강력한 프로그래밍 (JM20110222)

저작권 : 이해하기 워드 하드 소스, 저자를 표시하시기 바랍니다, 감사합니다!