浏览器-09 javascript引擎和Chromium网络栈

语言的运行

C/C++语言

• 使用编译器直接将它们编译成本地代码(机器指令)，这是由开发人员在代码编写完成以后实施;
• 用户只是使用这些编译好的本地代码，这些本地代码被系统的加载器加载执行，由操做系统调度CPU直接执行，无需其它额外的辅助虚拟机等;
• 这一过程基本上是从源代码开始，而后抽象语法树，以后中间表示，最后到本地代码;

Python等脚本语言

• 处理脚本语言一般的作法是开发者将写好的代码直接交给用户，用户使用脚本的解释器将脚本文件加载而后解释执行;
• 固然，如今Python也能够支持将脚本编译生成中间表示;
• 因此对于脚本语言，通常须要开发人员的编译过程；
• 这主要由于使用场景不同，它的目的不是高性能;
• 这一过程是源代码，到抽象语法树，再到解释器解释执行;

Java语言

• 其能够理解为比较明显的两个阶段:
  * 首先是像C++语言同样的编译器，可是，同C++编译器生成的本地代码结果不一样，通过编译器编译以后的是字节码，字节码是平台无关的;
  * 在运行字节码阶段，Java的运行环境也就是Java虚拟机会加载字节码，使用解释执行这些字节码;
  * 同时现代Java虚拟机通常都引入了JIT技术，也就是前面说的将字节码转变成本地代码来提升执行效率;
• 这主要两个阶段，第一阶段对时间要求不严格，第二阶段则对每一个步骤所花费的时间很是敏感，时间越短越好;

JavaScript语言

• 它是一种解释性脚本语言，可是随着众多工程师不断投入资源来提升它的速度，这使得它可以使用了Java虚拟机和C++编译器中众多的技术;
• 同时它的工做方式也在演变:
  * 早期由解释器来解释它们便可，就是将源代码转变成抽象语法树，而后在抽象语法树上解释执行;
  * 随着将Java虚拟机的JIT技术引入，如今的作法是将抽象语法树转成中间表示（也就是字节码），而后经过JIT技术转成本地代码，这可以大大的提升了执行效率;
  * 固然也有些作法直接从抽象语法树生成本地代码的JIT技术，例如V8;
• JavaScript跟Java仍是有如下一些区别：
  * JavaScript是无类型的语言，这使得对于对象的表示和属性的访问上比Java存在比较大的性能损失;
  * Java语言一般是将源代码编译成字节码，这个同执行阶段是分开的，也就是从源代码到抽象语法树到字节码这段时间的长短是无所谓的，主要是尽量的生成高效的字节码便可;而对于JavaScript，这些都是在网页和JavaScript文件下载后同执行阶段一块儿在网页的加载和渲染过程当中来实施的，因此对它们的处理时间也有着很高的要求;

JavaScript引擎主要包括

• 编译器:主要工做是将源代码编译成抽象语法树，而后在某些引擎中还包含将抽象语法树转换成字节码;
• 解释器:在某些引擎中，解释器主要是接受字节码，解释执行这个字节码，而后也依赖来及回收机制等;
• JIT工具:一个可以可以JIT的工具，将字节码或者抽象语法树转换成本地代码;
• 垃圾回收器和分析工具:负责垃圾回收和收集引擎中的信息，帮助改善引擎的性能和功效;

JavaScriptCore引擎和V8引擎

WebKit中的JavaScript引擎

• 在WebKit项目中，最初只有JavaScriptCore引擎;在Blink还独立出来以前，为了支持不一样的JavaScript引擎，WebKit设计了一套接口能够切换使用不一样的JavaScript引擎（事实上，这一接口会下降性能），因此，WebKit当时能够支持两种类型的JavaScript引擎，那就是JavaScriptCore引擎和V8引擎;二者都是基于WebKit所提供的接口来同渲染引擎协同工做;

  JavaScriptCore引擎

• JavaScriptCore引擎是WebKit中默认的引擎;
• 在早期阶段，性能不是特别突出;特别是，它只有解释器来解释执行JavaScript代码,这一效率十分的低效;
• 从2008年开始,JavaScriptCore引擎开始一个新的优化工做;

• JavaScriptCore最简单的处理部分，主要是将源代码翻译成抽象语法树，以后是平台无关的字节码，在最初的版本中，字节码会被JavaScriptCore引擎解释执行;在后面的版本中，逐渐加入了JIT编译器，将热点函数生成本地代码;

V8引擎

• 为了达到高性能的JavaScript代码执行效率从而得到更好的网页浏览效果，它甚至采用直接将JavaScript编译成本地代码的方式;
• 首先它也是将源代码转变成抽象语法树的，这一点同JavaScriptCore引擎同样，以后两个引擎开始不一样；
• 不一样于JavaScriptCore引擎，V8引擎并不将抽象语法树转变成字节码或者其它中间表示，而是经过JIT编译器的全代码生成器从抽象语法树直接生成本地代码，因此没有像Java同样的虚拟机或者字节码解释器;
• 这样作，主要是由于减小这抽象语法树到字节码的转换时间，这一切都在网页加载时候完成，虽然能够提升优化的可能，可是这些分析可能带来巨大的时间浪费;固然，缺点也很明显，至少包括两点：
  * 第一是某些JavaScript使用场景其实使用解释器更为合适，由于没有必要生成本地代码；
  * 第二是由于没有中间表示，会减小优化的机会由于缺乏一个中间表示层;
• 在以后的版本中，V8工程师们引入了Crankshaft编译器，它可以对热点的JS函数进行生成的分析和优化后再生成本地代码，缘由在于不是全部的JavaScript代码都合适作如此深层次的优化，由于优化自己也须要花费必定的时间;

Chromium网络栈

概述

• 主要做用是使用网络来下载各类类型的资源，还须要支持最新的HTML5功能WebSockets ;
• 为了高效的网络机制，Chromium使用了预DNS解析和资源预取等技术，极大的减小了用户等待时间;
• Chromium又引入了SPDY和QUIC等新网络协议，用于减小网络传输时间;

调用栈

• 以HTTP协议为例，在创建TCP的socket链接过程当中涉及的类;
• 首先是URLRequest被上层调用启动请求的时候，它会根据URL的scheme来决定须要建立什么类型的请求,例如http://，file://;还能够是自定义的scheme，例如Android系统的file://assets/;
  * URLRequest建立的是一个URLRequestJob子类的一个对象,为了支持自定义的scheme处理方式，它是利用工厂模式;基本的思路是，用户能够在该类中注册多个工厂，当有URLRequest请求时候，先有工厂检查它是否须要处理该scheme，若是没有，继续交由下一个工厂类;最后，若是没有任何工厂可以处理的话，则交给内置的工厂来检查和处理是不是http://，ftp://或者file://等;
• 其次，当URLRequestHttpJob被建立后，它首先从Cookie管理器中获取跟该URL相关联的信息;以后，一样借助于HttpTransactionFactory建立一个HttpTransaction类的对象来表示开启一个HTTP链接的事务（不一样于数据库中的事务概念;
  * HttpCache类使用本地磁盘缓存机制，若是该请求对应的回复已经在磁盘缓存中，那么无需再创建HttpTransaction来发起链接，直接从磁盘中获取;
  * 若是磁盘中没有，同时若是目前该URL请求对应的HttpTransaction已经创建，那么只要等待它的回复便可;
  * 这些条件都不知足后，实际上才会真正建立HttpTransaction;
• 而后，HttpNetworkTransaction使用HttpNetworkSession来管理链接会话;
  • HttpNetworkSession经过它的成员HttpStreamFactory来创建TCP Socket链接;
  • 以后建立HttpStream对象;HttpStreamFactory将和网络之间的数据读写交给本身新建立的一个HttpStream对象来处理;
• 最后，是套接字的创建;Chromium中的跟服务器创建链接的套接字是StreamSocket，它是一个抽象类;同时，为了支持SSL机制，它还有一个子类就是SSLSocket;

SPDY

• 为了解决HTTP管线化技术的网络延迟和安全性问题;
• 使用SPDY协议的服务器和客户端能够将网络加载的时间减小64%;在HTTP2.0的草案中引入SPDY协议做为基础来编写;
• SPDY协议是一种新的会话层协议，它定义在HTTP协议和TCP协议之间;

• 协议的核心思想是多路复用，仅使用一个链接来传输一个网页中的众多资源;
  * 它本上并无改变HTTP协议，只是将HTTP协议头经过SPDY来封装和传输;
  * 其传输方式也没有发生变化，而后使用TCP/IP协议;
  * 因此，它相对比较容易的布置，服务器只须要插入SPDY协议的解释层，从SPDY的消息头中获取各个资源的HTTP头便可;
  * SPDY协议必须创建在SSL层之上，这是一个比较大的限制，由于有不少网站不必定但愿支持HTTPS;

• SPDY的工做方式有如下四个特征：
  * 利用一个TCP链接来传输不限个数的资源请求的读写流，这与以前的为每一个资源请求都创建一个TCP链接大大不一样，这明显提升了TCP链接的利用率，减小TCP链接的维护成本;
  * 根据资源请求的特性和优先级，SPDY能够调整它们的请求这些资源的优先级，例如对JavaScript资源的优先级很高，服务器优先传输回复该类型的请求;
  * 对这些请求使用压缩技术，大大减小须要传送的字节数;这一思想已普遍应用于各类浏览器中;
  * 当用户须要浏览某个网页的时候，支持SPDY协议的服务器在发送网页内容时候能够尝试发送一些信息给浏览器，告诉后面可能须要哪些资源，浏览器能够提早知道并决定是否须要下载;更极端的状况是，服务器能够主动发送资源;