221

readme.md

@@ -6,7 +6,7 @@
 
 前端界的好文精读，每周更新！
 
-最新精读：<a href="./前沿技术/219.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%B7%B1%E5%85%A5%E4%BA%86%E8%A7%A3%E7%8E%B0%E4%BB%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E4%B8%80%E3%80%8B.md">219.精读《深入了解现代浏览器一》</a>
+最新精读：<a href="./前沿技术/221.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%B7%B1%E5%85%A5%E4%BA%86%E8%A7%A3%E7%8E%B0%E4%BB%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E4%B8%89%E3%80%8B.md">221.精读《深入了解现代浏览器三》</a>
 
 素材来源：[周刊参考池](https://github.com/ascoders/weekly/issues/2)
 
@@ -177,6 +177,8 @@
 - <a href="./前沿技术/217.%E7%B2%BE%E8%AF%BB%E3%80%8A15%20%E5%A4%A7%20LOD%20%E8%A1%A8%E8%BE%BE%E5%BC%8F%20-%20%E4%B8%8B%E3%80%8B.md">217.精读《15 大 LOD 表达式 - 下》</a>
 - <a href="./前沿技术/218.%E7%B2%BE%E8%AF%BB%E3%80%8ARust%20%E6%98%AF%20JS%20%E5%9F%BA%E5%BB%BA%E7%9A%84%E6%9C%AA%E6%9D%A5%E3%80%8B.md">218.精读《Rust 是 JS 基建的未来》</a>
 - <a href="./前沿技术/219.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%B7%B1%E5%85%A5%E4%BA%86%E8%A7%A3%E7%8E%B0%E4%BB%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E4%B8%80%E3%80%8B.md">219.精读《深入了解现代浏览器一》</a>
+- <a href="./前沿技术/220.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%B7%B1%E5%85%A5%E4%BA%86%E8%A7%A3%E7%8E%B0%E4%BB%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E4%BA%8C%E3%80%8B.md">220.精读《深入了解现代浏览器二》</a>
+- <a href="./前沿技术/221.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%B7%B1%E5%85%A5%E4%BA%86%E8%A7%A3%E7%8E%B0%E4%BB%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E4%B8%89%E3%80%8B.md">221.精读《深入了解现代浏览器三》</a>
 
 ### 设计模式
 

前沿技术/220.精读《深入了解现代浏览器二》.md

@@ -0,0 +1,77 @@
+[Inside look at modern web browser](https://developers.google.com/web/updates/2018/09/inside-browser-part2) 是介绍浏览器实现原理的系列文章，共 4 篇，本次精读介绍第二篇。
+
+## 概述
+
+本篇重点介绍了 **浏览器路由跳转后发生了什么**，下一篇会介绍浏览器的渲染进程是如何渲染网页的，环环相扣。
+
+在上一篇介绍了，browser process 包含 UI thread、network thread 和 storage thread，当我们在浏览器菜单栏输入网址并敲击回车时，这套动作均由 browser process 的 UI thread 响应。
+
+接下来，按照几种不同的路由跳转场景，分别介绍了内部流程。
+
+### 普通的跳转
+
+第一步，UI thread 响应输入，并判断是否为一个合法的网址，当然输入的也可能是个搜索协议，这就会导致分发到另外的服务处理。
+
+第二步，如果第一步输入的是合法网址，则 UI thread 会通知 network thread 获取网页内容，network thread 会寻找合适的协议处理网络请求，一般会通过 [DNS 协议](https://en.wikipedia.org/wiki/Domain_Name_System) 寻址，通过 [TLS 协议](https://en.wikipedia.org/wiki/Transport_Layer_Security) 建立安全链接。如果服务器返回了比如 301 重定向信息，network thread 会通知 UI thread 这个信息，再启动一遍第二步。
+
+第三步，读取响应内容，在这一步 network thread 会首先读取首部一些字节，即我们常说的响应头，其中包含 [Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types) 告知返回内容是什么。如果返回内容是 HTML，则 network thread 会将数据传送给 renderer process。这一步还会校验安全性，比如 [CORB](https://www.chromium.org/Home/chromium-security/corb-for-developers) 或 [cross-site](https://en.wikipedia.org/wiki/Cross-site_scripting) 问题。
+
+第四步，寻找 renderer process。一旦所有检查都完成，network thread 会通知 UI thread 已经准备好跳转了（注意此时并没有加载完所有数据，第三步只是检查了首字节），UI thread 会通知实力化 renderer process 进行渲染。为了提升性能，UI thread 在通知 network thread 的同时就会实力化一个 renderer process 等着，一旦 network thread 完毕后就可以立即进入渲染阶段，如果检查失败则丢弃提前实例化的 renderer process。
+
+第五步，确认导航。第四步后，browser process 通过 IPC 向 renderer process 传送 stream（[精读《web streams》](https://github.com/ascoders/weekly/blob/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF/214.%E7%B2%BE%E8%AF%BB%E3%80%8Aweb%20streams%E3%80%8B.md)）数据。此时导航会被确认，浏览器的各个状态（比如导航状态、前进后退历史）将会被修改，同时为了方便 tab 关闭后快速恢复，会话记录会被存储在硬盘。
+
+额外步骤，加载完成。当 renderer process 加载完成后（具体做了什么下一篇会说明），会通知 browser process `onLoad` 事件，此时浏览器完成最终加载完毕状态，loading 圆圈也会消失，各类 onLoad 的回调触发。注意此时 js 可能会继续加载远程资源，但这都是加载状态完成后的事了。
+
+### 跳转到别的网站
+
+当你准备跳转到别的网站时，在执行普通跳转流程前，还会响应 [beforeunload](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload_event) 事件，这个事件注册在 renderer process，所以 browser process 需要检查 renderer process 是否注册了这个响应。注册 `beforeunload` 无论如何都会拖慢关闭 tab 的速度，所以如无必要请勿注册。
+
+如果跳转是 js 发出的，那么执行跳转就由 renderer process 触发，browser process 来执行，后续流程就是普通的跳转流程。要注意的是，当执行跳转时，会触发原网站 `unload` 等事件（[网页生命周期](https://developers.google.com/web/updates/2018/07/page-lifecycle-api#overview_of_page_lifecycle_states_and_events)），所以这个由旧的 renderer process 响应，而新网站会创建一个新的 renderer process 处理，当旧网页全部关闭时，才会销毁旧的 renderer process。
+
+也就是说，即便只有一个 tab，在跳转时，也可能会在短时间内存在多个 renderer process。
+
+### Service Worker
+
+[Service Worker](https://developers.google.com/web/fundamentals/primers/service-workers) 可以在页面加载前执行一些逻辑，甚至改变网页内容，但浏览器仍然把 Service Worker 实现在了 renderer process 中。
+
+当 Service Worker 被注册后，会被丢到一个作用域中，当 UI thread 执行时会检查这个作用域是否注册了 Service Worker，如果有，则 network thread 会创建一个 renderer process 执行 Service Worker（因为是 js 代码）。然后网络响应会被 Service Worker 接管。
+
+但这样会慢一步，所以 UI thread 往往会在注册 Service Worker 的同时告诉 network thread 发送请求，这就是 [Navigation Preload](https://developers.google.com/web/updates/2017/02/navigation-preload) 机制。
+
+本文介绍了网页跳转时发生的步骤，涉及 browser process、UI thread、network thread、renderer process 的协同。
+
+## 精读
+
+也许你会有疑问，为什么是 renderer process 而不是 renderer thread？因为相比 process（进程）相比 thread（线程），之间数据是被操作系统隔离的，为了网页间无法相互读取数据（mysite.com 读取你 baidu.com 正在输入的账号密码），浏览器必须为每个 tab 创建一个独立的进程，甚至每个 iframe 都必须是独立进程。
+
+读完第二篇，应该能更深切的感受到模块间合理分工的重要性。
+
+UI thread 处理浏览器 UI 的展现与用户交互，比如当前加载的状态变化，历史前进后退，浏览器地址栏的输入、校验与监听按下 Enter 等事件，但不会涉及诸如发送请求、解析网页内容、渲染等内容。
+
+network thread 也仅处理网络相关的事情，它主要关心通信协议、安全协议，目标就是快速准确的找到网站服务器，并读取其内容。network thread 会读取内容头做一些前置判断，读取内容和 renderer process 做的事情是有一定重合的，但 network thread 读取内容头仅为了判断内容类型，以便交给渲染引擎还是下载管理器（比如一个 zip 文件），所以为了不让渲染引擎知道下载管理器的存在，读取内容头必须由 network thread 来做。
+
+与 renderer process 的通信也是由 browser process 来做的，也就是 UI thread、network thread 一旦要创建或与 renderer process 通信，都会交由它们所在的 browser process 处理。
+
+renderer process 仅处理渲染逻辑，它不关心是从哪来的，比如是网络请求过来的，还是 Service Worker 拦截后修改的，也不关心当前浏览器状态是什么，它只管按照约定的接口规范，在指定的节点抛出回调，而修改应用状态由其它关心的模块负责，比如 `onLoad` 回调触发后，browser process 处理浏览器的状态就是一个例子。
+
+再比如 renderer process 里点击了一个新的跳转链接，这个事情发生在 renderer process，但会交给 browser process 处理，因为每个模块解耦的非常彻底，所以任何复杂工作都能找到一个能响应它的模块，而这个模块也只要处理这个复杂工作的一部分，其余部分交给其它模块就好了，这就是大型应用维护的秘诀。
+
+所以在浏览器运行周期里，有着非常清晰的逻辑链路，这些模块必须事先规划设计好，很难想象这些模块分工是在开发中逐渐形成的。
+
+最后提到加速优化，Chrome 惯用技巧就是，用资源换时间。即宁可浪费潜在资源，也要让事物尽可能的并发，这些从提前创建 renderer process、提前发起 network process 都能看出来。
+
+## 总结
+
+深入了解现代浏览器二介绍了网页跳转时发生的，browser process 与 renderer process 是如何协同的。
+
+也许这篇文章可以帮助你回答 “聊聊在浏览器地址栏输入 www.baidu.com 并回车后发生了什么事儿吧！”
+
+> 讨论地址是：[精读《深入了解现代浏览器二》· Issue #375 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/375)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/221.精读《深入了解现代浏览器三》.md

@@ -0,0 +1,93 @@
+[Inside look at modern web browser](https://developers.google.com/web/updates/2018/09/inside-browser-part3) 是介绍浏览器实现原理的系列文章，共 4 篇，本次精读介绍第三篇。
+
+## 概述
+
+本篇宏观的介绍 renderer process 做了哪些事情。
+
+浏览器 tab 内 html、css、javascript 内容基本上都由 renderer process 的主线程处理，除了一些 js 代码会放在 web worker 或 service worker 内，所以浏览器主线程核心工作就是解析 web 三剑客并生成可交互的用户界面。
+
+### 解析阶段
+
+首先 renderer process 主线程会解析 HTML 文本为 DOM（Document Object Model），只译为中文就是文档对象模型，所以首先要把文本结构化才能继续处理。不仅是浏览器，代码的解析也得首先经历 Parse 阶段。
+
+对于 HTML 的 link、img、script 标签需要加载远程资源的，浏览器会调用 network thread 优先并行处理，但遇到 script 标签就必须停下来优先执行，因为 js 代码可能会改变任何 dom 对象，这可能导致浏览器要重新解析。所以如果你的代码没有修改 dom 的副作用，可以添加 async、defer 标签，或 JS 模块的方式使浏览器不必等待 js 的执行。
+
+### 样式计算
+
+只有 DOM 是不够的，style 标签申明的样式需要作用在 DOM 上，所以基于 DOM，浏览器要生成 CSSOM，这个 CSSOM 主要是基于 css 选择器（selector）确定作用节点的。
+
+### 布局
+
+有了 DOM、CSSOM 仍然不足以绘制网页，因为我们仅知道结构和样式，但不知道元素的位置，这就需要生成 LayoutTree 以描述布局的结构。
+
+LayoutTree 和 DOM 结构很像了，但比如 `display: none` 的元素不会出现在 LayoutTree 上，所以 LayoutTree 仅考虑渲染结构，而 DOM 是一个综合描述结构，它不适合直接用来渲染。
+
+原文特别提到，LayoutTree 有个很大的技术难点，即排版，Chrome 专门有一整个团队在攻克这个技术难题。为什么排版这么难？可以从这几个例子中体会冰山一角：盒模型间碰撞、字体撑开内容导致换行，引发更大区域的重新排版、一个盒模型撑开挤压另一个盒模型，但另一个盒模型大小变化后内容排版也随之变化，导致盒模型再次变化，这个变化又导致了外部其它盒模型的布局变化。
+
+布局最难的地方在于，需要对所有奇奇怪怪的布局定式做一个尽量合理的处理，而很多时候布局定式间规则是相互冲突的。而且这还不考虑布局引擎的修改在数亿网页上引发未知 BUG 的风险。
+
+### 绘图
+
+有了 DOM、CSSOM、LayoutTree 就够了吗？还不行，还缺少最后一环 PaintRecord，这个指绘图记录，它会记录元素的层级关系，以决定元素绘制的顺序。因为 LayoutTree 仅决定了物理结构，但不决定元素的上下空间结构。
+
+有了 DOM、CSSOM、LayoutTree、PaintRecord 之后，终于可以绘图了。然而当 HTML 变化时，重绘的代价是巨大的，因为上面任何一步的计算结果都依赖前面一步，HTML 改变时，需要对 DOM、CSSOM、LayoutTree、PaintRecord 进行重新计算。
+
+大部分时候浏览器都可以在 16ms 内完成，使 FPS 保持在 60 左右，但当页面结构过于复杂，这些计算本身超过了 16ms，或其中遇到 js 代码的阻塞，都会导致用户感觉到卡顿。当然对于 js 卡顿问题可以通过 `requestAnimationFrame` 把逻辑运算分散在各帧空闲时进行，也可以独立到 web worker 里。
+
+### 合成
+
+绘图的步骤称为 rasterizing（光栅化）。在 Chrome 最早发布时，采用了一种较为简单的光栅化方案，即仅渲染可是区域内的像素点，当滚动后，再补充渲染当前滚动位置的像素点。这样做会导致渲染永远滞后于滚动。
+
+现在一般采用较为成熟的合成技术（compositing），即将渲染内容分层绘制与渲染，这可以大大提升性能，并可通过 CSS 属性 `will-change` 手动申明为一个新层（不要滥用）。
+
+浏览器会根据 LayoutTree 分析后得到 LayerTree（层树），并根据它逐层渲染。
+
+合成层会将绘图内容切分为多个栅格并交由 GPU 渲染，因此性能会非常好。
+
+## 精读
+
+### 从渲染分层看性能优化
+
+本篇提到了浏览器渲染的 5 个重要环节：解析、样式、布局、绘图、合成，是前端开发者日常工作中对浏览器体感最深的部分，也是优化最长发生在的部分。
+
+其实从性能优化角度来看，解析环节可以被替代为 JS 环节，因为现代 JS 框架往往没有什么 HTML 模版内容要解析，几乎全是 JS 操作 DOM，所以可以看作 5 个新环节：JS、样式、布局、绘图、合成。
+
+值得注意的是，几乎每层的计算都依赖上层的结果，但并不是每层都一定会重复计算，我们需要尤其注意以下几种情况：
+
+1. 修改元素几何属性（位置、宽高等）会触发所有层的重新计算，因为这是一个非常重量级的修改。
+2. 修改某个元素绘图属性（比如颜色和背景色），并不影响位置，则会跳过布局层。
+3. 修改比如 transform 属性会跳过布局与绘图层，这看上去很不可思议。
+
+对于第三点，由于 transform 的内容会提升到合成层并交由 GPU 渲染，因此并不会与浏览器主线程的布局、绘图放在一起处理，所以视觉上这个元素的确产生了位移，但它和修改 `left`、`top` 的位移在实现上却有本质的不同。
+
+所以站在浏览器开发者的角度，可以轻松理解为什么这种优化不是奇技淫巧了，因为本身浏览器的实现就把布局、绘图与合成层的行为分离开了，不同的代码底层方案不同，性能肯定会不同。你可以通过 [csstriggers](https://csstriggers.com/) 查看不同 css 属性会引发哪些层的重计算。
+
+当然作为开发者还是可以吐槽，为什么浏览器不能 “自动把 `left` `top` 与 `transform` 的实现细节屏蔽，并自动进行合理的分层”，然而如果浏览器厂商做不到这一点，开发者还是主动去了解实现原理吧。
+
+### 隐式合成层、层爆炸、层自动合并
+
+除了 `transform`、`will-change` 属性外，还有很多种情况元素会提升到合成层，比如 `video`、`canvas`、`iframe`，或 `fixed` 元素，但这些都有明确的规则，所以属于显示合成。
+
+而隐式合成是指元素没有被特别标记，但也被提升到合成层的情况，这种情况常见发生在 `z-index` 元素产生重叠时，下方的元素显示申明提升到合成层，则浏览器为了保证 `z-index` 覆盖关系，就要隐式把上方的元素提升到合成层。
+
+层爆炸是指隐式合成的原因，当 css 出现一些复杂行为时（比如轨迹动画），浏览器无法实时捕捉哪些元素位于当前元素上方，所以只好把所有元素都提升到合成层，当合成层数量过多，主线程与 GPU 的通信可能会成为瓶颈，反而影响性能。
+
+浏览器也会支持层自动合并，比如隐式提升到合成层时，多个元素会自动合并在一个合成层里。但这种方式也并不总是靠谱，自动处理毕竟猜不到开发者的意图，所以最好的优化方式是开发者主动干预。
+
+我们只要注意将所有显示提升到合成层的元素放在 `z-index` 的上方，这样浏览器就有了判断依据，不用再担惊受怕会不会这个元素突然移动到某个元素的位置，导致压住了那个元素，于是又不得不把这个元素给隐式提升到合成层以保证它们之间顺序的正确性，因为这个元素本来就位于其它元素的最上方。
+
+## 总结
+
+读完这篇文章，希望你能根据浏览器在渲染进程的实现原理，总结出更多代码级别的性能优化经验。
+
+最后想要吐槽的是，浏览器规范由于是逐步迭代的，因此看似都在描述位置的 css 属性其实背后实现原理是不同的，虽然这个规则体现在 W3C 规范上，但如果仅从属性名是很难看出来端倪的，因此想要做极致性能优化就必须了解浏览器实现原理。
+
+> 讨论地址是：[精读《深入了解现代浏览器三》· Issue #379 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/379)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）