Warning: Undefined array key "HTTP_REFERER" in /www/wwwroot/blog-api.lequ7.com/wp-content/plugins/wp-cors/wp-cors.php on line 28

Warning: Undefined array key "HTTP_ORIGIN" in /www/wwwroot/blog-api.lequ7.com/wp-content/plugins/wp-cors/wp-cors.php on line 29
关于javascript:从输入URL到页面渲染完成 乐趣区的后端

关于javascript:从输入URL到页面渲染完成

63次阅读
没有评论

从输出URL到页面渲染实现

波及网络、浏览器工作原理等常识。

前序常识

浏览器过程构造

Browser过程
  负责协调、主控,包含地址栏、书签、历史栈。

GPU过程
  负责整个浏览器界面的渲染

网络过程
  负责发动接管网络申请

插件过程
  管制网页中应用到的插件 如flash
  
渲染器过程
  默认应用(Process-per-site-instance)模式
  四种过程模式:
    Process-per-site-instance: 拜访不同站点和同一站点的不同页面都会创立新的过程
    Process-per-site: 同一站点应用同一过程
    Process-per-tab: 一个tab应用一个过程
    Single process: 浏览器引擎和渲染引擎共用一个过程

一、URL

蕴含:协定名、域名、端口号、门路、查问或其余片段的一个字符串

二、缓存

浏览器在发动申请之前会查看缓存,别离是强缓存和协商缓存

强缓存

浏览器直接判断http头的 Expirescache-control 中的过期工夫,其中 Expires 为服务器相对工夫,cache-control为绝对工夫。

协商缓存

浏览器通过缓存响应头的last-modifiedEtag并在下次申请头中写入改数据,服务器通过判断申请头中数据来决定是否让浏览器应用缓存。
浏览器通过判断 HTTP状态 是否为 304 来判断是否应用本地缓存。

NDS 解析

  1. 查看浏览器DNS缓存
  2. 查看hosts文件
  3. 操作系统查找本地DNS服务器
  4. 本地DNS查找根服务器(本地DNS缓存IP)

TCP

三次握手

用于确认单方收发是否失常

  1. 第一次握手:建设连贯。客户端确认是否能够对方 接管 能力
  2. 第二次握手:服务器确认客户端 接管 能力
  3. 第三次握手:客户端确认服务器 发送 能力

HTTP/HTTPS申请

HTTP 申请

申请行 + 申请头 + 申请体 的模式 发送信息

申请行

Method Request-URL HTTP-Version CRLF

申请形式 申请门路 申请版本 换行
GET index.html HTTP/1.1

申请头

  • 申请报头容许客户端向服务器传递申请的附加信息和客户端本身的信息。
  • 常见的申请报头有: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Type, Authorization, Cookie, User-Agent等。
  • Accept用于指定客户端用于承受哪些类型的信息,Accept-Encoding与Accept相似,它用于指定承受的编码方式。Connection设置为Keep-alive用于通知客户端本次HTTP申请完结之后并不需要敞开TCP连贯,这样能够使下次HTTP申请应用雷同的TCP通道,节俭TCP连贯建设的工夫。

申请注释

当应用POST, PUT等办法时,通常须要客户端向服务器传递数据。这些数据就贮存在申请注释中。在申请包头中有一些与申请注释相干的信息,例如: 申请的数据格式为json。这时就须要设置Content-Type: application/json。

HTTPS 申请

通过非对称加密生成的对称密钥进行的数据加密的形式

  1. 浏览器携带加密形式申请公钥
  2. 服务器返回公钥
  3. 浏览器通过ca查看证书
  4. 浏览器通过公钥+随机数 生成密钥
  5. 服务器通过私钥查看密钥与随机数
  6. 开始通信

响应

通用头部

Request Url: 申请的web服务器地址
 
Request Method: 申请形式
(Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE)
 
Status Code: 申请的返回状态码,如200代表胜利
 
Remote Address: 申请的近程服务器地址(会转为IP)

1xx:批示信息–示意申请已接管,持续解决。

2xx:胜利–示意申请已被胜利接管、了解、承受。

3xx:重定向–要实现申请必须进行更进一步的操作。

4xx:客户端谬误–申请有语法错误或申请无奈实现。

5xx:服务器端谬误–服务器未能实现非法的申请。

平时遇到比拟常见的状态码有:200, 204, 301, 302, 304, 400, 401, 403, 404, 422, 500

响应报头,响应报文

  • 常见的响应报头字段有: Server, Connection…。
  • 服务器返回给浏览器的文本信息,通常HTML, CSS, JS, 图片等文件就放在这一部分。

浏览器解析渲染

  1. 解析html,生成DOM树
  2. 解析CSS,生成CSS规定树
  3. 合成CSS和DOM树,生成Render树
  4. 布局Render树(layout/reflow),负责各元素尺寸、地位的计算
  5. 绘制render树(paint),绘制页面像素信息
  6. 浏览器将各层信息发送给GPU,GPU将各层合并,显示在屏幕上

解析html标签,生成DOM树

通过语法解析将辨认后的标签进行dom树结构,并创立document对象,并将document作为DOM树的根节点,并一直增加节点。

当遇到图片和CSS这些网络资源,须要通过网络或者缓存进行加载的资源不会阻止html的解析,因为这些资源并不会影响到DOM的生成。

当遇到script标签,因为浏览器并不知道js是否会扭转以后页面的HTML构造( 比方调用了document.write(‘xxx’) 进行批改时以后DOM的解析就变得没有意义了),所以将进行解析DOM转而去加载执行JS资源。

script 并非肯定阻塞HTML解析,只有增加 defer 或者 async 属性就能够防止阻塞导致的DOM生成问题。

defer 使得脚本会在dom残缺构建之后执行;
async 标签使得脚本只有在齐全available才执行,并且是以非阻塞的形式进行的

解析CSS标签,构建CSSOM树

浏览器会把所有的款式解析为款式构造体(包含css款式和浏览器默认款式)

浏览器辨认不了的款式不能解析

ps: CSS尽管不会阻塞HTML解析,然而会阻塞渲染(如js先加载会导致后加载的css被阻塞,最初导致页面的白屏也就是阻塞渲染)

生成渲染树

  1. 计算CSS款式
  2. 构建渲染树
  3. 布局(回流,Layout,Reflow),次要定位坐标和大小,是否换行,各种position overflow z-index属性
  4. 绘制(重绘,Repaint),将图像绘制进去

渲染流程

  1. 主线程 生成Layout Tree 和 确认绘制程序
  2. 主线程 将上述信息传递给合成器线程
  3. 合成器线程将每个图层进行删格化并生成合成器帧
  4. 合成器通过IPC传递给浏览器过程
  5. 浏览器过程将合成器帧传递给GPU并渲染到屏幕上
  6. 当页面发生变化 则反复上述流程

具体流程

浏览器过程中的网络线程将获取到的html通过IPC将数据传递给渲染器主过程,主线程将html解析成DOM树而后进行款式计算,依据DOM树生成好的款式生成Layout Tree,通过遍历Layout Tree 生成渲染程序表,接着遍历LayoutTree生成LayerTree 而后主线程将LayerTree绘制程序信息传递给合成器线程,合成器线程将图层传递给删格线程进行删格化,删格化实现后合成器失去删格线程生成的draw quads图块信息,依据这些信息合成器失去一个合成器帧,并通过IPC传递给浏览器过程,浏览器过程传递到GPU进行渲染。

当扭转元素尺寸、地位时会从新款式计算,布局(Layout)绘制(Paint)以及前面所有流程,即为重排

当扭转元素色彩属性是不会从新触发布局(Layout),然而仍然会从新款式计算,即为重绘

回流与重绘

Layout,也称为Reflow,即回流。个别意味着元素的内容、构造、地位或尺寸产生了变动,须要从新计算款式和渲染树

Repaint,即重绘。意味着元素产生的扭转只是影响了元素的一些外观之类的时候(例如,背景色,边框色彩,文字色彩等),此时只须要利用新款式绘

正文完
 0
评论(没有评论)