关于前端:浏览器多进程资源加载

33次阅读

共计 1063 个字符,预计需要花费 3 分钟才能阅读完成。

倡议浏览

浏览器多过程架构
https://segmentfault.com/a/1190000023603263

背景

所有浏览器网络通信都是由浏览器主过程执行。有一些起因:

  • 对立管制各个渲染过程的网络通信
  • 便于管理和保护跨过程的会话、状态治理,如 cookies 和 cache
  • 作为 HTTP/1.1,对于每个 host 连接数有限度,对立管制

架构概览

浏览器多过程利用能够大抵分为三层。
最底层是 Blink 负责渲染页面。再上一层是渲染过程,每一个渲染过程蕴含一个 Blink 实例。最上一层是浏览器过程(主过程)负责管理所有渲染过程,同时治理全局网络拜访。

Blink

它有一个 ResourceLoader 负责获取数据,每一个 ResourceLoader 有一个 WebURLLoader 负责理论散发数据申请。ResourceLoader还实现了 WebURLLoaderClient 协定,这个协定能让渲染过程散发数据,能让 Blink 获取一些事件,从而进行解决。

渲染过程

渲染过程负责实现 WebURLLoader,为WebURLLoaderImpl,它应用每个渲染过程对应的ResourceDispatcher 创立一个惟一的申请(Unique ID),并将这个申请通过 IPC 通信转发给浏览器主过程。当浏览器取得响应后再依据惟一申请 Unique ID 将响应数据返回给指标对象。

浏览器主过程

RenderProcessHost对象拿到渲染过程的转发申请后,将申请转发给全局的 ResourceDispatcherHost,应用指针(具体而言,是ResourceDispatcherHost::Reciver 对象)指向发申请的渲染过程以及辨认到该具体的申请,而后申请被转化成 URLRequest,进一步转化成其外部的URLRequestJob,当URLRequest 取得响应音讯后,再给具体的 ResourceDispatcherHost::Reciver 对象。

Cookies

所有的 cookies 都是由 CookieMonster 对象解决,cookies 是不能被其它浏览器网络栈共享的。因为 cookies 是跨 tabs 的,所以 CookieMonster 是在浏览器主过程中的。页面获取 cookies 比方应用 document.cookie 时,会从渲染过程收回一个同步获取信号至浏览器主过程,此刻若浏览器主过程正在解决 cookies,会暂停 blink 此刻的工作线程。当渲染过程收到浏览器主过程的 I / O 响应时,才会重启 blink 的工作线程并将 cookies 后果返回给 JavaScript 引擎。

正文完
 0