当下的前端工程师可能接触最多的就是chrome浏览器了。但是可能大部分同学不清楚其内部运行的机制，以及这些年浏览器到底进行了哪些优化，才得以支撑互联网世界庞大的业务量，以及给广大用户网上冲浪的极致体验。本文不会去写深入底层的实现，而是想通过描述浏览器的技术演进来知道它的背景，以及明白在开发和使用浏览器应用时遇到的问题的背后原因。

• 为什么现代浏览器相对来说比较稳定，而早期的浏览器极易容易崩溃？
• 为什么现代web应用比较流畅可以做混合应用堪比原生，而早期的web页面会高频卡顿？
• 为什么早在2009年前web网站上各种插件横行，且经常爆出安全问题？

在2007年前后就已经上网的同学应该玩过QQ空间、百度贴吧或者校内网(人人网)等，那个时候的PC浏览器打开页面需要等待好久，手机打开网页速度慢的体感更强。当然在一定程度上也取决于当时的移动网络为2g网络，而PC网络多为有限宽带。网络因素、硬件设备配置等因素我们今天先不做深究，今天我们主要的主题是探讨浏览器本身的技术架构演进过程。

单进程浏览器

在了解单进程浏览器之前，大家需要先了解下什么是进程，什么是线程？这里就不在赘述了大家可以自行了解下进程和线程之后，我们再来一起看下单进程浏览器的架构。

单进程浏览器是指浏览器的所有功能都在同一个进程里运行，这其中包括了网络、插件、JavaScript 运行环境、渲染引擎和页面等。其实在2007年前后，市面上浏览器大部分都是单进程的。单进程浏览器的架构如下图所示：

如此多的功能运行在一个进程里，是导致单进程浏览器不稳定、不流畅和不安全的一个主要因素。下面我就来一一分析下出现这些问题的原因。

不稳定

早期浏览器的视频、游戏需要借助于插件来实现诸如 Flash 播放器等各种强大的功能，但是插件是最容易出问题的模块，并且还运行在浏览器进程之中，所以一个插件的意外崩溃会引起整个浏览器的崩溃。除了插件之外，渲染引擎模块也是不稳定的，通常一些复杂的 JavaScript 代码就有可能引起渲染引擎模块的崩溃。和插件一样，渲染引擎的崩溃也会导致整个浏览器的崩溃。

不流畅

从上面的“单进程浏览器架构示意图”可以看出，所有页面的渲染模块、JavaScript 执行环境以及插件都是运行在同一个线程中的，这就意味着同一时刻只能有一个模块可以执行。比如，下面这个无限循环的脚本：

   function freeze() { 
     while (1) { 
       console.log("freeze"); 
     }
   }
   freeze();

如果让这个脚本运行在一个单进程浏览器的页面里，你感觉会发生什么？因为这个脚本是无限循环的，所以当其执行时，它会独占整个线程，这样导致其他运行在该线程中的模块就没有机会被执行。因为浏览器中所有的页面都运行在该线程中，所以这些页面都没有机会去执行任务，这样就会导致整个浏览器失去响应，变卡顿。这块内容要继续往深的地方讲就到页面的事件循环系统了。除了上述脚本或者插件会让单进程浏览器变卡顿外，页面的内存泄漏也是单进程变慢的一个重要原因。通常浏览器的内核都是非常复杂的，运行一个复杂点的页面再关闭页面，会存在内存不能完全回收的情况，这样导致的问题是使用时间越长，内存占用越高，浏览器会变得越慢。

不安全

这里依然可以从插件和页面脚本两个方面来解释该原因。插件可以使用 C/C++ 等代码编写，通过插件可以获取到操作系统的任意资源，当你在页面运行一个插件时也就意味着这个插件能完全操作你的电脑。如果是个恶意插件，那么它就可以释放病毒、窃取你的账号密码，引发安全性问题。至于页面脚本，它可以通过浏览器的漏洞来获取系统权限，这些脚本获取系统权限之后也可以对你的电脑做一些恶意的事情，同样也会引发安全问题。以上这些就是当时浏览器的特点，不稳定，不流畅，而且不安全。

多进程浏览器

你可以先看看下面这张图，这是 2008 年 Chrome 发布时的进程架构。

从图中可以看出，Chrome 的页面是运行在单独的渲染进程中的，同时页面里的插件也是运行在单独的插件进程之中，而进程之间是通过 IPC 机制进行通信（如图中虚线部分）。

我们先看看如何解决不稳定的问题。由于进程是相互隔离的，所以当一个页面或者插件崩溃时，影响到的仅仅是当前的页面进程或者插件进程，并不会影响到浏览器和其他页面，这就完美地解决了页面或者插件的崩溃会导致整个浏览器崩溃，也就是不稳定的问题。

我提到 Chrome 使用多个渲染器进程。在最简单的情况下，您可以想象每个选项卡都有自己的渲染器进程。假设您打开了 3 个选项卡，每个选项卡都由一个独立的渲染器进程运行。如果一个选项卡变得无响应，那么您可以关闭无响应的选项卡并继续使用其他选项卡的服务,如果所有选项卡都在一个进程上运行，当一个选项卡变得无响应时，所有选项卡都无响应。

对于内存泄漏的解决方法那就更简单了，因为当关闭一个页面时，整个渲染进程也会被关闭，之后该进程所占用的内存都会被系统回收，这样就轻松解决了浏览器页面的内存泄漏问题。最后我们再来看看上面的两个安全问题是怎么解决的。采用多进程架构的额外好处是可以使用安全沙箱，你可以把沙箱看成是操作系统给进程上了一把锁，沙箱里面的程序可以运行，但是不能在你的硬盘上写入任何数据，也不能在敏感位置读取任何数据，例如你的文档和桌面。Chrome 把插件进程和渲染进程锁在沙箱里面，这样即使在渲染进程或者插件进程里面执行了恶意程序，恶意程序也无法突破沙箱去获取系统权限。

有哪些进程存在

不过 Chrome 的发展是滚滚向前的，相较之前，目前的架构又有了很多新的变化。我们先看看最新的 Chrome 进程架构，你可以参考下图：

图中是我从 Chrome/94 浏览器中截图出来的，大家可以看到最新的 Chrome 浏览器包括：1 个 GPU 进程、1 个 V8代理解析工具（v8代码解释器）、1 个NetWork进程、1 个浏览器主进程、多个插件进程(我插件装的太多)、多个渲染进程和备用渲染进程。
下面我们来逐个分析下这几个进程的功能。

• GPU 进程。Chrome 刚开始发布的时候是没有 GPU 进程的。而 GPU 的使用初衷是为了实现 3D CSS 的效果，只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制，这使得 GPU 成为浏览器普遍的需求。最后，Chrome 在其多进程架构上也引入了GPU 进程。
• V8代理解析工具（v8代码解释器）Google的开源高性能JavaScript和WebAssembly引擎，用C编写，它实现ECMAScript和WebAssembly，可独立运行或嵌入到任何C应用程序中，如Chrome和Node.js。
• NetWork进程。主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程里面的，直至最近才独立出来，成为一个单独的进程。
• 浏览器进程。主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。
• 扩展程序(插件进程)。主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响。
• 渲染进程。核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该进程中，默认情况下，Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。
• GUI渲染线程：负责渲染页面，布局和绘制、页面需要重绘和回流时，该线程就会执行、与js引擎线程互斥，防止渲染结果不可预期
• JS引擎线程：负责处理解析和执行javascript脚本程序、只有一个JS引擎线程（单线程）、与GUI渲染线程互斥，防止渲染结果不可预期
• 事件触发线程：用来控制事件循环（鼠标点击、setTimeout、ajax等）当处理一些不能立即执行的代码时，会将对应的任务在其可以触发的时机，添加到事件队列的末端事件循环机制会在JS引擎线程空闲时，循环访问事件队列的头部，如果有函数，则会将该函数推到执行栈中并立即执行
• 定时触发器线程：setInterval与setTimeout所在的线程、定时任务并不是由JS引擎计时的，是由定时触发线程来计时的、计时完毕后，将回调事件放入到事件队列中
• 异步http请求线程：浏览器有一个单独的线程用于处理AJAX请求、当请求完成时，若有回调函数，将回调事件放入到事件队列中。

渲染进程的分配

其时浏览器的渲染进程划分，还会多一个维度，那就是按照站点维度进行划分：

站点隔离是 Chrome 中最近引入的一项功能，它为每个跨站点 iframe 运行单独的渲染器进程。我们一直在讨论每个选项卡模型一个渲染器进程，它允许跨站点 iframe 在单个渲染器进程中运行，并在不同站点之间共享内存空间。在同一个渲染器进程中运行 a.com 和 b.com 似乎没问题。同源策略是网络的核心安全模型；它确保一个站点未经同意无法访问其他站点的数据。绕过此策略是安全攻击的主要目标。进程隔离是最有效的站点分离方式。使用 Meltdown 和 Spectre，我们需要使用流程来分离站点变得更加明显。自 Chrome 67 以来，桌面上默认启用站点隔离，选项卡中的每个跨站点 iframe 都有一个单独的渲染器进程。

启用站点隔离是一项多年的工程努力。站点隔离并不像分配不同的渲染器进程那么简单；它从根本上改变了 iframe 相互通信的方式。在不同进程上运行 iframe 的页面上打开 devtools 意味着 devtools 必须实施幕后工作以使其看起来无缝。即使运行简单的 Ctrl+F 来查找页面中的单词也意味着在不同的渲染器进程中进行搜索。您可以看到浏览器工程师将 Site Isolation 的发布称为重大里程碑的原因。

但也不完全是相同站点就一定会在同一个渲染进程中，不同的tab就一定不在同一个渲染进程中。这个具体的进程分配逻辑取决于Chromium的处理模型(process-models)决定，而Chrome的默认处理模式就是Process-per-site-instance。 Process-per-site-instance :  当你打开一个 tab 访问 a.baidu.com，然后再打开一个 tab 访问 b.baidu.com，这两个 tab 会使用两个进程。如果 b.baidu.com 是通过 a.baidu.com 页面的 JavaScript 代码打开的，这两个 tab 会使用同一个进程，比如下图的例子，可以看到两个 tab 的 processId 是相同的。

除此之外还有三种处理模型【Process-per-site、Process-per-tab、Single process】，大家感兴趣可以查看chromium官方相关介绍。

现阶段存在的缺陷

凡事都有两面性，虽然面向服务的多进程架构模型提升了浏览器的稳定性、流畅性和安全性，但同样不可避免地带来了一些问题：

• 更高的资源占用。因为每个进程都会包含公共基础结构的副本（如 JavaScript 运行环境），这就意味着浏览器会消耗更多的内存资源。
• 更复杂的体系架构。浏览器各模块之间耦合性高、扩展性差等问题，会导致现在的架构已经很难适应新的需求了。

为了更好的均衡各方面诉求，我们来看下 Chrome 为了节省更多内存，所做的服务化。

Chrome 正在经历架构更改以将浏览器程序的每个部分作为服务运行，从而可以轻松拆分为不同的进程或聚合为一个。一般的想法是，当 Chrome 在强大的硬件上运行时，它可能会将每个服务拆分为不同的进程，从而提供更高的稳定性，但如果是在资源受限的设备上，Chrome 会将服务整合到一个进程中，从而节省内存占用。在此更改之前，已在 Android 等平台上使用了类似的方法来合并进程以减少内存使用量。

当然上面所讲的这些并不是问题的全部原因，这些年发展的也并不只是浏览器架构，还有网络协议，基站，芯片，cpu，带宽承载能力等科技领域的发展，才得以让PC/移动互联网体验更好的应用服务我们的生活，我们才得以感受到数字化生活的便利。

参考文档

• https://developers.google.com/web/updates/2018/09/inside-browser-part1
• https://www.chromium.org/developers/design-documents/process-models
• 李兵的《浏览器工作原理与实践》

0、一名初入大学校门的小青年如何选择了未来的路

我的经历

先来一个自我介绍，我毕业于天津农学院人力资源管理专业，毕业之后和朋友一起创办过一个小公司。离开天津之后我来到了杭州，就职于某区块链公司，后来就加入了阿里巴巴-政企云 & 乌鸫科技体验技术前端团队。

首先给大家分享第一个问题：我作为一个初入大学校门的小青年，如何选择了自己未来的路？

想做一个什么样的人

可能很多同学在刚进入大学之后，有些松懈，因为高考过后想给自己放松一下，很少有同学会去想未来想要去做一个什么样的人，或者是想要从事什么样的职业。我觉得大学生走入大学最好是要给自己一个长远的规划，想一想自己未来要做一个什么样的人。当然这个问题可能对于很多人来说是比较难的。

我们不妨换另外一个问题：问一问自己不想做什么。比如，你是不是想毕业之后去做电话销售？或者是去做餐饮销售员？或者是在企业里面做策划运营工作？想想自己不想做什么，最后剩下的这一点就是自己想要做的。

兴趣是什么

第二点是问一问自己：我的兴趣点是什么？

如果说能把自己的兴趣点当成一种职业来做，我个人认为是一件比较幸福的事。至于我，因为我本身是酷爱编程，然后最后把编程做成了自己的一个职业，这些年也感觉很幸福，乐在其中，所以在这方面的成长也会稍微快一些。

明确自身优劣势，制定规划

第三点就是当你明确了自己的方向之后，再去判断一下自身的一些优劣势。

我不知道是不是好多同学和我一样，在上大学的时候可能会认为自己足够优秀或者是能力比较强。后面我有问自己一个问题，觉得自己能力强，我强在什么地方？是不是别人有些东西能做，而我不能做？或者是我能做的东西别人做不到？有没有这种情况出现？如果有的话，那就证明我们的能力是比别人强的。

找到自己的一些劣势或者优点，我们就要去扬长避短，然后把自己的短板补齐，把优势放大，这个时候就需要制定一些计划。

比如，如果你是想从事技术工作，你要规划一下我大一需要学一些什么东西，比如计算机基础，是吧？然后未来如果说你想做前端的话，可能你后面就要去针对前端的一些知识，像 CSS、JS，去做一个很好的计划，然后慢慢去补足。

时间管理

如何保证你这些计划很高效地去执行？你需要有一个时间管理的观念。好多同学进入大学之后，可能有课你就会去上课，但没有课的话可能就会在床上躺着，或者去网吧待着。没有了之前上高中或者上初中时老师和家长的监督，可能时间概念在自己这里就会比较松懈。

我大学时是这么做的，每天早晨会 7:30 左右起床，然后每天看一篇技术博客，上午会去正常的上课，下午是下了课之后会去做一些计算机基础的一些学习。比如我上大学的时候会学一些 Java，然后给自己做好了一些计划，然后还要有一些阶段性的检测，比如两个月或者三个月之后，会给自己做一些小的 demo，仿京东的官网，或者做一个小型的公众号网站，然后给自己做好一个时间管理。

实践参与

第五点是实践参与。如果你的校园里面有一些比较好的展示机会，像社团办一些活动，可能要给活动做一个官网，某某学院会有一些官网的一些更新，如果你能参与进去，我觉得是比较好的。

1、破茧而出，我该如何帮助自己快速适应工作

第二个问题：毕了业之后，如何帮助自己快速适应工作？

机会大于既得利益

对于我来说，我是一个非计算机专业出身的工程师或者是一个程序员，然后我求职的第一点给自己的一个定位就是“机会要大于我的既得利益”。找第一份工作的时候我并没有看重收入，而是看哪一家公司给我的展现平台会比较大，愿意接纳我，并且是我想要从事的岗位，就像前端工程师。

深入学习的能力

第二点，入职了之后，作为一个新人，如何去快速学习，补足自己的一些大学初入职场的一些中间的断层，怎么去快速弥补？

我们这时候也是要去看公司和业务所要涉及的技术面，进行深入的学习，学习一些原理。可能大部分的同学感觉自己能够实现需求，能够实现功能就 ok 了，他并没有去研究。比如像我最开始进入职场时，会关注一些 jQuery 实现原理，比如链式调用它是如何实现的，比如一些查找的方法它是如何实现的。

如果你探究了实现原理，后面会对你学习技术（比如性能优化，或者一些异常 bug 的处理）有很大的帮助。

很多文章会写，不提倡去造轮子。其实我也是比较不提倡造轮子，但是我觉得作为一个工程师，如果说你打算在这个行业长久做下去的话，一定要有一个造轮子的能力。

沉淀方法论和原则

第三点，如何让你的工作更高效，或者是和别人合作起来更轻松？一定要去沉淀自己的一套方法论。比如你和服务端去沟通，或者和客户端去沟通，要站在他们的立场，为他们去考虑，然后去阐述你的观点，这样你说出来话才更有说服力，而不是说一味的站在自己只是一个前端工程师的角度去和他们讨论问题，这样的话会自我设限。比如我讲我前端怎么样比较好，他肯定会站在客户端的角度认为怎么样比较好。

如果说前端怎么能帮他去实现一些东西，我们把整个方案拿给他，把前后端的一个合作方案拿给他的时候，他就更好更方便地去接受你。

危机意识

第四点，在我们在这个行业里面，像我最开始身边有很多同事和我一起去做前端开发，好多人会缺少一种危机意识。比如早两年没有 React 和 Angular 争地的时候，很多同学可能还沉浸在 jQuery 的时代，其实职场里面慢慢已经淘汰这些开发的机制。当然可能天津这块发展是比较缓慢的，北京、上海或者杭州可能早四五年前已经开始用这些比较流行的技术。当然现在可能在所有人看来的话，Vue 和 React 都是人人必备的一些基础技能。

开放的心态

第五点，如何化解危机呢？我是这么去做，保持自己和社区的一些充分交流。当然我也是抱着这种心态参与了社区才认识的，像 Miya 姐、Ak、水歌等等，然后和他们交流的过程中才会了解到除了我工作岗位以及我公司之外，别人是怎么去做的、他们是怎么看待这种技术的发展、这些技术里面蕴含的一些思想是什么样子的......

这时候你会发现你所摄取的东西要远远多于你身边的一些同事，这个时候你就会慢慢地站在主导的地位，去给你身边的同事做一些普及，然后你的影响力就会高，自然而然也会得到领导的器重。

2、在大型团队中工作我遇到了哪些挑战

我去年 9 月份跳槽之后，在大型团队里面（阿里巴巴-政企云 & 乌鸫科技体验技术前端团队）的工作中给我带来一些挑战，我把它当作我职业发展的一个突破。

风险意识

第一点就是风险意识。在此之前，其实可能只有自己对自身危机意识的一些认识，但对于整个项目开发周期迭代，其实是缺少危机意识的。

在我的之前的经历里面，团队之间合作，可能大家更多沟通的是需求、某个功能点的联调方式。在任何需求排下来之后，可能埋头就去干，并没有去从整个链条，包括和别的同学对于整个需求、整个大版本的一个迭代的功能点、风险评估、技术方案的评估、需要花费的时间......都没有这些概念，可能就是埋头直接去做，然后做到哪遇到什么问题再去抛。这样的话就导致整个项目在推进的过程中，会随着你开发的问题、套路，动态地去改变一些技术方案，导致产生一些额外的成本，也给公司带来一些负面的影响，你的项目不能按时交付。

所以到大公司之后，风险意识一定要高。在任何一个版本需求确定下来，第一时间应该做技术方案的评估，拉上服务端客户端，包括一些产品/UED 同事，把后续可能要涉及的风险点、技术方案和大家敲定落实，这样的话在我们独自去开发自己模块的时候，才会降低风险。

推动变化和响应变化

第二点是推动变化。其实第二点和第一点是相辅相成的。推动变化主要是什么？主要是我们作为一个前端工程师，是产品推向用户使用的最后一道关口，在日常工作中，产品和 UED 同事都很难去想象到一个产品功能在交互过程当中的任何细节，很难去想全。这时候我们作为前端开发者，应该想得比他们更多。

站在用户的角度，我们想象一下用户真正需要的是什么样的一个东西，到底什么样的产品是对用户有价值的。这个时候我们可以去站在用户的视角去推动产品的一些变化，这样的话也就避免了产品投入到市场之后，由于用户反馈所带来的变化。

前端开发者去推动变化，也可以提高我们在团队中的一些影响力和话语权。我们可以把更多的时间去放在一些基础建设和赋能上面。

不自我设限

第三点，不自我设限。刚刚其实在第二点里面有稍微的阐述，就是不能把自己简简单单只定位为一个技术人员，我们更像是为一个最终的产物负责，只不过是在产物过程中，会有我们不同的同学去分工协作。我们要在第一时间拿到这个东西的时候，去和各个方面去拉通，去评估，以确保最终交付给产品的是我们共同期望的最完美的一个展现方式，或者一个最完美的展现的产品。

技术赋能业务

第四点，**技术不仅仅是为了服务某一个项目，而是说我们要赋能业务，同时在我们实现某个项目中所产生的业务价值，又能继续反哺到我们日常的开发和生产中，这个才是真正的价值所在。**像一些开源的大厂，他们所开发的一些开源产品也是在这种思想下去做的。

比如我要实现一个上传的功能，那这个上传功能不仅仅简单说是为了完成我这个项目里面的上传功能，而是说我把它抽离出来，做成上传的能力——放在我这个产品里面可以用，同时我上传能力又可以赋能给别的同学，或者是我们接下来要负责的另外一个项目。

其实在前端来看的话，可能就是面向模块化编程或者面向组件化编程的一个思想。当我们把技术一个一个的功能模块抽离出来之后，后面的生产其实对我们来说就比较轻松，我们就可以把不同的模块拼装到不同产品里面，后面迭代就会变得更加快速，我们就可以抽出更多的时间去做更多有意义的事情。

视角的转变

第五点，来到阿里之后我有一些视角的转变。之前我对待任何一个项目，可能作为技术人员就是为了完成这个项目而去完成。到阿里之后呢，任何工程师或者是我自身来说，我感觉要做的东西不仅仅是为了把某个项目做完，而是说这个项目本身是有什么样的价值。

我本身的工作能够给我身边的同学带来哪些价值？最后这个产品交付给用户，给用户带来是哪些价值？如果说价值比较高的话，即使这个项目有一定的延期，其实后面得到的结果也是好的，因为我们后面给用户呈现的是一个最完美的东西。最后一点其实要去思考的就是这个东西给社会带来什么样的价值？任何一个长久的东西都是有它长远存在的意义和价值。

3、大厂的前端技术体系是如何搭建的

我想给大家介绍一个前端技术体系是如何搭建的，会从以下三个问题去给大家做一个简单介绍。

第一个问题是大厂的前端都是忙些啥？是不是大家理解中的搭系统搭页面就 ok 了？

第二个问题可能是很多人可能目前还没有意识到的，是不是我看了 Vue 源码或者是 React 源码，我的前端发展就到头了？答案肯定是否定的。

第三点，如果大家有兴趣来到我们团队，可能会想去了解我们团队需要什么样的人。以上三点会通过接下来的一个短片，由我们部门的前端负责人去给大家做一个简单的介绍。

4、快乐生活

最后一点我想要和大家简单说的，技术人员经常被调侃“是直男”、“情商低”，我觉得其实大家在研究技术的同时，还可以多参加一些娱乐活动，比如参加一些比赛，打乒乓球，参加一些科技展，或者是去旅游，我觉得都是丰富自己生活的方式。

如果大家在接下来的时光里有什么问题，可以联系我，和我进行简单的交流。或者是大家想加入我们团队，也可以加我微信（xiaoqiang0672），我会帮助大家进行内推。

这就是今天的简单分享，谢谢大家。