cjl-df

浏览器概述及多进程简介

1. 浏览器简介

• 概述

  分类：   现在主要有五大主流浏览器: Chrome(webkit->Blink), Internet Explorer(Trident), Firefox(Geoko), 
          Safari(webkit) and Opera(webkit->blink).
          移动端上是Android Browser,iPhone, Opera Mini and Opera Mobile, UC Browser, 
          the Nokia S40/S60 browsers,除了Opera，这些浏览器都是基于
          WebKit内核的（目前可能有变）。
    
  功能：   根据W3C制定的一系列规范，从服务端请求并渲染资源
    
  普遍外观：地址栏，前进后退，书签，刷新及取消，主页，插件
    
  深层结构：下边主要介绍———渲染引擎及JS引擎
    
  工作方式：多进程
  

  

• 组成

  用户界面（User Interface)  ：包括地址栏、前进/后退按钮、书签菜单等。除了浏览器主窗口显示的您请求的页面外，其他
                             显示的各个部分都属于用户界面。
    
  浏览器引擎（Browser engine）：在用户界面和呈现引擎之间传送指令。
    
  呈现引擎（Rendering engine）：负责显示请求的内容。如果请求的内容是 HTML，它就负责解析 HTML 和 CSS 内容,
                              并将解析后的内容显示在屏幕上。
    
  网络（Networking） ：         用于网络调用，比如 HTTP 请求。其接口与平台无关，并为所有平台提供底层实现。
    
  用户界面后端（UI backend）：   用于绘制基本的窗口小部件，比如组合框和窗口。其公开了与平台无关的通用接口，
                              而在底层使用操作系统的用户界面方法。
    
  JavaScript 解释器（JS Interpreter）：用于解析和执行 JavaScript 代码。
    
  数据存储（Datapersistence）：这是持久层。浏览器需要在硬盘上保存各种数据，例如 Cookie，storage。
                             新的 HTML 规范 (HTML5) 定义了“网络数据库”，这是一个完整
                             但是轻便）的浏览器内数据库。
  

• 浏览器多进程

  知道了浏览器是多进程后，再来看看它到底包含哪些进程：（为了简化理解，仅列举主要进程）

  Browser进程：浏览器的主进程（负责协调、主控），只有一个。作用有
              负责浏览器界面显示，与用户交互。如前进，后退等
              负责各个页面的管理，创建和销毁其他进程
              将Renderer进程得到的内存中的Bitmap，绘制到用户界面上
              网络资源的管理，下载等
    
  第三方插件进程：每种类型的插件对应一个进程，仅当使用该插件时才创建
    
  GPU进程：      最多一个，用于3D绘制等
    
  浏览器渲染进程（浏览器内核）（Renderer进程，内部是多线程的）：默认每个Tab页面一个进程，互不影响。
                主要作用为页面渲染，脚本执行，事件处理等
    
  强化记忆：     在浏览器中打开一个网页相当于新起了一个进程（进程内有自己的多线程）
  

• 重点是浏览器内核（渲染进程）

  浏览器的渲染进程是多线程的，包含如下线程

  • GUI渲染线程

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

  • 引擎线程

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

  • 事件触发线程

    1 归属于浏览器而不是JS引擎，用来控制事件循环（可以理解，JS引擎自己都忙不过来，需要浏览器另开线程协助）
    
    2 当JS引擎执行代码块如setTimeOut时（也可来自浏览器内核的其他线程,如鼠标点击、AJAX异步请求等），
      会将对应任务添加到事件线程中
      
    3 当对应的事件符合触发条件被触发时，该线程会把事件添加到待处理队列的队尾，等待JS引擎的处理
      
    4 注意，由于JS的单线程关系，所以这些待处理队列中的事件都得排队等待JS引擎处理（当JS引擎空闲时才会去执行）
    

  • 定时触发器线程

    1 传说中的setInterval与setTimeout所在线程
      
    1 浏览器定时计数器并不是由JavaScript引擎计数的,（因为JavaScript引擎是单线程的, 
      如果处于阻塞线程状态就会影响记计时的准确）
     
    3 因此通过单独线程来计时并触发定时（计时完毕后，添加到事件队列中，等待JS引擎空闲后执行）
      
    4 注意，W3C在HTML标准中规定，规定要求setTimeout中低于4ms的时间间隔算为4ms。
    

  • 异步http请求线程

    1 在XMLHttpRequest在连接后是通过浏览器新开一个线程请求
      
    2 将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将这个回调再放入事件队列中。
      再由JavaScript引擎执行。
    

  

2. Browser进程和浏览器内核（Renderer进程）的通信过程

首先，应该对浏览器内的进程和线程都有一定理解了，那么接下来，再谈谈浏览器的Browser进程（控制进程） 是如何和内核通信的，这点也理解后，就可以将这部分的知识串联起来，从头到尾有一个完整的概念。 如果自己打开任务管理器，然后打开一个浏览器，就可以看到：任务管理器中出现了两个进程（一个是主控进程， 一个则是打开Tab页的渲染进程）， 然后在这前提下，看下整个的过程：(简化了很多)

• Browser 进程收到用户请求，首先需要获取页面内容（譬如通过网络下载资源）， 随后将该任务通过RendererHost接口传递给Render进程

• Renderer进程的Renderer接口收到消息，简单解释后，交给渲染线程，然后开始渲染

  • 渲染线程接收请求，加载网页并渲染网页，这其中可能需要Browser进程获取资源和需要GPU进程来帮助渲染

  • 当然可能会有JS线程操作DOM（这样可能会造成回流并重绘）

• 最后Render进程将结果传递给Browser进程

• Browser进程接收到结果并将结果绘制出来

3. 梳理浏览器内核中线程之间的关系

到了这里，已经对浏览器的运行有了一个整体的概念，接下来，先简单梳理一些概念

• GUI渲染线程与JS引擎线程互斥

  由于JavaScript是可操纵DOM的，如果在修改这些元素属性同时渲染界面（即JS线程和UI线程同时运行），
  那么渲染线程前后获得的元素数据就可能不一致了。
  
  因此为了防止渲染出现不可预期的结果，浏览器设置GUI渲染线程与JS引擎为互斥的关系，当JS引擎执行时GUI线程会被挂起，
  GUI更新则会被保存在一个队列中等到JS引擎线程空闲时立即被执行。
  

• JS阻塞页面加载

  从上述的互斥关系，可以推导出，JS如果执行时间过长就会阻塞页面。
  
  譬如，假设JS引擎正在进行巨量的计算，此时就算GUI有更新，也会被保存到队列中，等待JS引擎空闲后执行。
  然后，由于巨量计算，所以JS引擎很可能很久很久后才能空闲，自然会感觉到巨卡无比。
  
  所以，要尽量避免JS执行时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞的感觉。
  

• WebWorker，JS的多线程？

  前文中有提到JS引擎是单线程的，而且JS执行时间过长会阻塞页面，那么JS就真的对cpu密集型计算无能为力么？
  
  所以，后来HTML5中支持了Web Worker。
  
  MDN的官方解释是：
  
  Web Worker为Web内容在后台线程中运行脚本提供了一种简单的方法。线程可以执行任务而不干扰用户界面
  
  一个worker是使用一个构造函数创建的一个对象(e.g. Worker()) 运行一个命名的JavaScript文件 
  
  这个文件包含将在工作线程中运行的代码; workers 运行在另一个全局上下文中,不同于当前的window
  
  因此，使用 window快捷方式获取当前全局的范围 (而不是self) 在一个 Worker 内将返回错误
  这样理解下：
  
  创建Worker时，JS引擎向浏览器申请开一个子线程（子线程是浏览器开的，完全受主线程控制，而且不能操作DOM）
  JS引擎线程与worker线程间通过特定的方式通信（postMessage API，需要通过序列化对象来与线程交互特定的数据）
  所以，如果有非常耗时的工作，请单独开一个Worker线程，这样里面不管如何翻天覆地都不会影响JS引擎主线程，
  只待计算出结果后，将结果通信给主线程即可，perfect!
  
  而且注意下，JS引擎是单线程的，这一点的本质仍然未改变，Worker可以理解是浏览器给JS引擎开的外挂，
  专门用来解决那些大量计算问题。
  
  其它，关于Worker的详解就不是本文的范畴了，因此不再赘述。
  

• WebWorker与SharedWorker

  既然都到了这里，就再提一下SharedWorker（避免后续将这两个概念搞混）
  
  WebWorker只属于某个页面，不会和其他页面的Render进程（浏览器内核进程）共享
  
  所以Chrome在Render进程中（每一个Tab页就是一个render进程）创建一个新的线程来运行Worker
  中的JavaScript程序。
  SharedWorker是浏览器所有页面共享的，不能采用与Worker同样的方式实现，因为它不隶属于某个Render进程，
  可以为多个Render进程共享使用
  
  所以Chrome浏览器为SharedWorker单独创建一个进程来运行JavaScript程序，在浏览器中每个相同的
  JavaScript只存在一个SharedWorker进程，不管它被创建多少次。
  看到这里，应该就很容易明白了，本质上就是进程和线程的区别。SharedWorker由独立的进程管理，
  WebWorker只是属于render进程下的一个线程