前端发展历史

早期时代（1990-）

Web 1.0 时代，非常适合创业型小项目，不分前后端，经常 3-5 人搞定所有开发。页面由 JSP、PHP 等工程师在服务端生成，浏览器负责展现。基本上是服务端给什么浏览器就展现什么，展现的控制在 Web Server 层。

这种模式的好处是简单明快，适合小型项目。
但是，业务总会变复杂，此时会遇到这种情况：

• JSP等代码可维护性越来越差。

JSP 非常强大，可以内嵌 Java 代码。
这种强大使得前后端的职责不清晰，JSP 变成了一个灰色地带。
经常为了赶项目，为了各种紧急需求，会在 JSP 里揉杂大量业务代码。
积攒到一定阶段时，往往会带来大量维护成本。

所以，为了提高代码的可维护性。为了让前后端分工更合理高效。提出了MVC。

后端为主的MVC时代

为了降低复杂度，以后端为出发点，有了 Web Server 层的架构升级，比如 Structs、Spring MVC 等，这是后端的 MVC 时代。

后端MVC时代，服务器返回的都是HTML页面，并且是渲染后返回给用户。绝大部分后端服务器，都做一件事情：接收用户发来的请求，返回一段响应内容。

工作原理：

• M指数据库 文件等；V指HTML模板；C则是HTTP请求路由 搜索引擎 数据分析 文件服务等。
• 用户在浏览器进行了一些操作，发送请求给后端。
• Controller先从model获取数据，再获取HTML内容，将数据填入HTML，生成view，再返回给用户。

这说的是后端 MVC模式，前端还有一个MVC。

这种模式依然有弊端，前后端职责依旧纠缠不清。

从web的诞生到2005，一直处于后端重前端轻的状态。此时前端页面想要获取后台数据需要刷新整个页面，用户体验糟糕。

AJAX带来的SPA时代（2005）

这种模式下，前后端的分工非常清晰，前后端的关键协作点是 Ajax 接口。

但回过头来看看的话，这与 JSP 时代区别不大。复杂度从服务端的 JSP 里移到了浏览器的 JavaScript，浏览器端变得很复杂。类似 Spring MVC，这个时代开始出现浏览器端的分层架构：

对于SPA应用，有几个很重要的挑战：

• 前后端接口的约定。
• 前端开发的复杂度控制。SPA 应用大多以功能交互型为主，JavaScript 代码过十万行很正常。大量 JS 代码的组织，与 View 层的绑定等，都不是容易的事情。

前端为主的MVVM时代（2010）

MVVM是Model-View-ViewModel的简写。即模型-视图-视图模型。

[模型]指后端传递的数据。[视图]指看到的页面。[视图模型]连接view和model的桥梁。view和model不能直接联系。

当view更新时，即用户操作视图，viewModel通过dom事件监听能够监听到视图的变化,然后通知model做改动;

当model更新时，viewModel可以监听数据的变动，然后通知view做更新。

好处：

• 前后端职责很清晰。前端工作在浏览器端，后端工作在服务端。清晰的分工，可以让开发并行，测试数据的模拟不难，前端可以本地开发。后端则可以专注于业务逻辑的处理
• 前端开发的复杂度可控。前端代码很重，但合理的分层，让前端代码能各司其职。

不足之处：

• 代码不能复用。比如后端依旧需要对数据做各种校验，校验逻辑无法复用浏览器端的代码。如果可以复用，那么后端的数据校验可以相对简单化。
• 全异步，对 SEO 不利。往往还需要服务端做同步渲染的降级方案。
• 性能并非最佳，特别是移动互联网环境下。

Node全栈时代（2009）

随着 Node.js 的兴起，JavaScript 开始有能力运行在服务端。

在这种研发模式下，前后端的职责很清晰。对前端来说，两个 UI 层各司其职：

1、Front-end UI layer 处理浏览器层的展现逻辑。通过 CSS 渲染样式，通过 JavaScript 添加交互功能，HTML 的生成也可以放在这层，具体看应用场景。

2、Back-end UI layer 处理路由、模板、数据获取、cookie 等。通过路由，前端终于可以自主把控 URL Design，这样无论是单页面应用还是多页面应用，前端都可以自由调控。后端也终于可以摆脱对展现的强关注，转而可以专心于业务逻辑层的开发。

前端时间轴

• 1990年，Tim 以超文本语言 HTML 为基础在 NeXT 电脑上发明了最原始的 Web 浏览器。
• 1994年11月，网景公司成立，并发布Mosaic Netscape 1.0 beta 浏览器，后改名为 Navigator。
• 1994 W3C诞生。
• 1995年网景推出JavaScript。
• 1996年微软发布JScript并内置于IE3。JavaScript与JScript存在差异。导致程序员开发的网页无法同时兼容IE和Navigator浏览器。IE开始抢夺Navigator的市场份额，导致了第一次浏览器大战。
• 1996年11月，网景将JavaScript提交到ECMA以便将其国际标准化。
• 1997年6月，ECMAScript1.0推出。
• 1998.6 ECMAScript 2规范发布。
• 1999.12 ECMAScript 3 规范发布。此后10年，基本没有发生变动。ECMAScript 3 成为当今主流浏览器最广泛使用和实现的语言规范基础。
• 2001.5 W3C 推出了 CSS 3.0 规范草案
• 2004年11月。火狐浏览器诞生。第二次浏览器战争开始。（第一次浏览器战争以IE的完胜告终，垄断浏览器市场，并且IE不遵循W3C标准）
• 2005年 AJAX诞生。局部刷新页面。
• 第二次浏览器战争中，随着以 Firefox 和 Opera 为首的 W3C 阵营与 IE 对抗程度的加剧，浏览器碎片化问题越来越严重，不同的浏览器执行不同的标准，对于开发人员来说这是一个噩梦。
• 为了解决浏览器兼容性问题，Dojo、jQuery、YUI、ExtJS、MooTools 等前端 Framework 相继诞生。前端开发人员用这些 Framework 频繁发送 AJAX 请求到后台，在得到数据后，再用这些 Framework 更新 DOM 树。
• 其中，jQuery 独领风骚，几乎成了所有网站的标配。
• 2008，HTML5草案发布。
• 2008.12 Chrome浏览器诞生，并搭配JavaScript引擎V8（V8是被设计用来提高网页浏览器内部JavaScript执行的性能）。
• 2009.12 ECMAScript 5.0 规范发布。
• 2009 Node.js诞生。
• 2010年起，Angular ，Vue， React MVVM框架诞生。
• 2015 年 6 月，ECMAScript 6.0 发布。

引擎V8与JavaScript

代码的概念

• 高级语言代码。
  高级语言又主要是相对于汇编语言而言的，它是较接近自然语言和数学公式的编程，基本脱离了机器的硬件系统，用人们更易理解的方式编写程序。编写的程序称之为源程序。java，c，c++，C#等都是高级语言。
• 汇编语言。
  汇编语言作为一门低级语言，对应于计算机或者其他可编程的硬件。它和计算机的体系结构以及机器指令是强关联的。不同的汇编语言代码对应特定的硬件。
• 字节码。
  字节码严格来说不算是编程语言，而是高级编程语言为了种种需求（可移植性、可传输性、预编译等）而产生的中间码。
• 机器码。
  机器码是一组可以直接被CPU执行的指令集，
  每一条指令都代表一个特定的任务，或者是加载，或者是跳转，亦或是计算操作等等。属于最低级的语言。

高级语言的分类

• 编译型语言。把做好的源程序全部编译成二进制代码的可运行程序。然后，可直接运行这个程序。执行效率高，但依赖编译器。代表性语言：C，C++。

• 解释型语言。把做好的源程序翻译一句，然后执行一句，直至结束。代表性语言：JavaScript。

这里要注意的是：
1- 解释型语言的源代码不能直接翻译成机器语言，而是先翻译成中间代码，再由解释器对中间代码进行解释运行。源代码>>中间代码>>机器语言。
2- 解释型语言程序只有在运行的时候才翻译成机器语言，每执行一次就翻译一次。

一句话描述编译与解释。
编译 Compile：把整个程序源代码翻译成另外一种代码，然后等待被执行，发生在运行之前，产物是另一份代码。
解释 Interpret：把程序源代码一行一行的读懂然后执行，发生在运行时，产物是运行结果。

高级语言如何转化为计算机能看懂的语言？

• 如果高级语言是编译型的。编译器会把源代码直接翻译成二进制的计算机可直接运行的机器语言，然后CPU就可以直接按指令执行。
• 如果高级语言是解释型的。以JavaScript为例，尽管是解释型语言，但具有编译特性，比如会先进行变量，函数的提升声明，再逐条进行解释。

编辑器/编译器/解释器/IDE的区别。

• 编辑器。
  编写文字或代码的应用软件。如记事本。
• 编译器。
  将一种语言（通常为高级语言）翻译成另外一种语（低级语言）言的程序。这个转换的过程通常的目的是生成可执行的程序。
• 解释器。
  解释器是一种计算机程序，它直接执行由编程语言或脚本语言编写的代码，并不会把源代码预编译成机器码。可以把解释器看成一个黑盒子，我们输入源码，它就会实时返回结果。
  不同类型的解释器，黑盒子里面的构造不一样，有些还会集成编译器，缓存编译结果，用来提高执行效率（例如 Chrome V8 也是这么做的）。
  解释器通常是工作在「运行时」，并且对于我们输入的源码，是一行一行的解释然后执行，然后返回结果。
• IDE。集成开发环境。集成了编辑器，编译器，链接器等功能。VSCode，Eclipse等都是。

V8出现的原因

随着web相关技术的发展，JavaScript承担的工作越来越多，所以需要一个更为强大的JS引擎去快速的解析和执行JavaScript脚本。所以v8出现了。

浅谈v8引擎解释JavaScript的过程

• V8引擎可以将JavaScript编译为原生的机器码，并且使用如内联缓存等方法提高性能。（JavaScript虽然是解释型高级语言，但具有编译性）
• 而其他JavaScript引擎采用的方法是转化为字节码或解释执行。

工作过程（编译阶段+运行阶段）

• 源代码被解析器转化为抽象语法树（AST）
• 使用JIT编译器的全代码生成器从AST直接生成本地可执行代码。

V8的垃圾回收机制

• 出现原因。
  内存泄漏是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。闭包会造成内存泄露。
• 回收方法（引用计数法）
  顾名思义，让所有对象实现记录下有多少“程序”在引用自己，让各对象都知道自己的“人气指数”。

var a = new Object(); // 此时'这个对象'的引用计数为1（a在引用）
var b = a; // ‘这个对象’的引用计数是2（a,b）
a = null; // reference_count = 1
b = null; // reference_count = 0 
// 下一步 GC来回收‘这个对象’了

浏览器内核，渲染引擎，JS引擎

• 浏览器内核分为两个部分：渲染引擎，JS引擎。
• 由于JS引擎越来越独立，浏览器内核就倾向于单指渲染引擎。

渲染引擎是一种对HTML文档进行解析并将其显示在页面上的工具。（说白了，就是按照HTML代码在界面上绘制各种控件图形）

• 常见引擎
  • 渲染引擎
    • firefox使用gecko引擎
    • IE使用Trident引擎
    • 2015年微软推出自己新的浏览器，原名叫斯巴达，后改名edge,使用edge引擎
    • chrome\safari\opera使用webkit引擎
    • 3年chrome和opera开始使用Blink引擎
  • JS引擎
    • 老版本IE使用Jscript引擎
    • IE9之后使用Chakra引擎
    • edge浏览器仍然使用Chakra引擎
    • firefox使用monkey系列引擎
    • safari使用的SquirrelFish系列引擎
    • Opera使用Carakan引擎
    • chrome使用V8引擎。nodeJs其实就是封装了V8引擎

浏览器中的进程与线程

线程与进程

一个进程就是一个程序的运行实例。详细解释就是，启动一个程序的时候，操作系统会为该程序创建一块内存，用来存放代码、运行中的数据和一个执行任务的主线程，我们把这样的一个运行环境叫进程。

线程是依附于进程的，而进程中使用多线程并行处理能提升运算效率。多线程可以并行处理任务，但是线程是不能单独存在的，它是由进程来启动和管理的。

进程与线程关系：

• 进程中的任意一线程执行出错，都会导致整个进程的崩溃。
• 线程之间共享进程中的数据。
• 当一个进程关闭之后，操作系统会回收进程所占用的内存。
• 进程之间的内容相互隔离。（沙盒）

仅仅打开了 1 个页面，为什么有 4 个进程？

因为打开 1 个页面至少需要1 个浏览器(Browser)主进程、1 个 GPU 进程以及 1 个渲染进程，如果打开的页面有运行插件的话，还需要再加上 1 个插件进程。

• 浏览器主进程作用。
  • 负责浏览器的界面显示，与用户交互，如前进，后退等
  • 负责各个页面的管理，创建和销毁其它进程
  • 将Rendered进程得到的内存中的Bitmap,绘制到用户界面上
  • 网络资源的管理，下载
• 插件进程。
  • 每种类型的插件对应一个进程，仅当使用该插件时才创建。
• GPU进程。
  • 最多一个，用于3D绘制等。
• 渲染进程。
  • 页面渲染，脚本执行，事件处理等

浏览器的多进程优点

• 避免单个page crash影响整个浏览器
• 避免第三方插件crash影响整个浏览器
• 方便使用沙盒模型隔离插件等进程，提高浏览器稳定性
• 如果为单进程的话，若其中一个页面崩了会影响到整个浏览器。

浏览器的渲染进程

通过以上内容，可以得知，当浏览器开一个页面时。至少会开辟出四个进程（浏览器主进程，GUP进程，插件进程，渲染进程）

对于普通的前端操作来说，最重要的渲染进程：页面的渲染，js的执行，事件的循环等都在这个进程内执行。

浏览器是多进程的，浏览器的渲染进程是多线程的。

GUI渲染线程

• 负责渲染浏览器界面，解析HTML,CSS,构建DOM树和RenderObject树，布局和绘制等。
• 当界面需要重绘或由于某种操作引发回流时，该线程就会执行。
• 注意，GUI渲染线程与JS引擎线程是互斥的，当JS引擎执行时GUI线程会被挂起（相当于冻结了）,GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行。

JS引擎线程

• 也称为JS内核，负责处理JavaScript脚本程序。（例如V8引擎）。
• JS引擎线程负责解析JavaScript脚本，运行代码。
• JS引擎一直等待着任务队列中任务的到来，然后加以处理，一个Tab页（render进程）中无论什么时候都只有一个JS线程在运行JS程序。JavaScript是单线程的。
• 同样注意，GUI渲染线程与JS引擎线程是互斥的，所以如果JS执行的时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞。

GUI渲染线程详细操作

• 解析HTML生成DOM树
• 解析CSS生成CSSOM规则树
• 将DOM树与CSSOM规则树合并在一起生成渲染树
• 遍历渲染树开始布局，计算每个节点的位置大小信息
• 将渲染树每个节点绘制到屏幕

重绘repaint与回流reflow

• 重绘。屏幕的一部分重画，不影响整体布局。比如某个CSS的背景色变了，但元素的几何尺寸和位置不变。
• 回流。意味着元件的几何尺寸变了，我们需要重新验证并计算渲染树。

其他常见问题

• GUI线程与JS引擎线程是互斥的。 为什么要互斥？因为js引擎会操作dom，如果不互斥，会出现一遍构建dom树一边将dom节点删除的情况。
• JS会阻塞页面加载。 所以JavaScript代码应该放在页面的底部，最后执行。否则解析JavaScript时间长会白屏。
• 头部引入的CSS会先执行吗？ 头部引入的CSS由单独的线程异步下载的，所以如果头部碰到引入的CSS，会将其存入队列中，等到dom树解析完才会执行。

输入url到浏览器渲染完成经历的过程（详细版）

• 浏览器地址栏输入地址。(www.xx.com)

• 如果没有输入完全，浏览器会帮你补齐你的协议号和端口。

• 接着浏览器分析这串地址的协议号，域名，端口。与高速缓存里存放的域名进行一一对比。

• 若相同，则直接拿到IP地址。

• 若不同，则去本地域名服务器寻找。有则拿到IP地址。

• 若还是没有，则直接去根域名服务器寻找。此时根域名服务器要么给出IP地址，要么指出该去往哪个域名服务器寻找。直到找到IP地址。这个过程叫做DNS解析。

• 拿到IP地址后，需要与之通信。于是，通过三次握手建立TCP连接。

  • 客户端发送一个包给服务端表示我想请求连接。
  • 服务端收到请求后，回发客户端一个包表示我已经确认收到你的请求。
  • 客户端再发送一个包，表示握手结束。

• 客户端发送请求报文。

• 服务端处理请求报文发送响应报文。

• 浏览器收到响应报文，渲染进程开始渲染页面。

  • 解析HTML生成DOM树。
  • 解析CSS生成CSSOM树。
  • 将DOM树和CSSOM树合并在一起生成渲染树。
  • 遍历渲染树开始布局，计算每个节点的位置大小等信息。
  • 将渲染树每个节点绘制到屏幕。

• 浏览器渲染完成，通过四次挥手关闭连接。

  • 浏览器发送包，请求断开连接。
  • 服务端发送包给客户端，表示我已经收到你的请求。
  • 服务端再次发送包给客户端，表示我也想断开连接。
  • 客户端发送包给服务端，表示我已经收到你的关闭请求。接着就关闭连接，通信结束。

参考文章

• 前端历史演变概述
• 前端发展简史
• 关于编译器和解释器
• 浏览器内核、渲染引擎、JS引擎简介
• 浏览器的线程和进程
• 浏览器渲染机制
  csdn.net/freekiteyu/article/details/79927047)
• 关于编译器和解释器
• 浏览器内核、渲染引擎、JS引擎简介
• 浏览器的线程和进程
• 浏览器渲染机制
• 浏览器渲染机制的原理和过程