客户端容器

浏览器的架构

浏览器架构演进

1.单进程架构：所有模块运行在同一个进程里，包括网络，插件，Javascript运行环境

2.多进程架构：主进程,网络进程，渲染进程，GPU进程，插件进程（独立沙盒）

3.面向服务架构（多进程架构的升级）:将原来的UI，数据库，文件，设备，网络等，作为一个独立的基础服务(进程之间访问需要事先定义好接口，通过IP通信来进行交互）

浏览器架构对比

架构类型	扩展性	安全性	稳定性	流畅度
单进程架构	低	低	低	卡顿
多进程架构	中（耦合度）	高（独立沙箱）	高（相互隔离）	流畅（独立的渲染进程）
面向服务架构	高	高	高	流畅

浏览器架构-任务管理器

浏览器架构-多进程分工

进程名称	进程描述
浏览器（主进程）	主要负责页面展示逻辑，用户交互，子进程·管理；包括地址栏，书签，前进，后退，收藏夹等
GPU进程	负责UI绘制，包含整个浏览器全部UI
网络进程	网络服务进程，负责网络资源加载
标签页（渲染进程）	控制tab内所有内容，将Html，Css和JavaScript转化为用户可交互的网页
插件进程	控制网站运行的插件，比如flash，ModHeader等
其他进程	如上图所示：适用程序Storage/Network/Audio Service等基础服务

思考：

为什么会有单进程架构：硬件限制（内存昂贵）；节约资源

面向服务架构是否会代替多进程架构：会，谷歌2016年在多进程架构上进行演进，优势：在性能较好的设备上可以做成面向服务架构，性能差的设备上退化成多进程架构（节约资源）

渲染进程

常见浏览器内核

内核	浏览器	JS引擎	补充说明
Trident	IE4-11	JScript，Chakra	出生于1994年，IE8以前使用JScript，IE9开始使用Chakra引擎
Gecko	Firefox	SpiderMonkey	Gecko内核主要用在Firefox浏览器上，同事是一个跨平台的内核，支持在Windows，BSD，Linux，Mac OS X中使用
Webkit	Safari，Chrome（早起），Android浏览器	JavaScriptCore	由Apple公司技术团队开发，并在2005年开源
Blink	Chrome，Opera	V8	Google基于Wenkit开发的内核，在Webkit的基础上加入多进程，沙箱等技术，于2013年开源
Edge	Edge	Chakra	2015年有微软发布们用于edge浏览器上，由于性能较差，运行不稳定等原因，2018年微软将Edge浏览器内核迁移到Chromium
Trident+Webkit（Blink）	国产浏览器QQ，360,搜狗，UC等	都有都有	双核，早期银行系统都是在IE上进行开发，想要支持银行系统切换到Trident内核，想要体验就切到Webkit内核（集成模式）

渲染进程-多线程架构

内核是多线程实现，主要负责页面渲染，脚本执行，事件处理，网络请求等

线程	功能
JS引擎	负责解析JS脚本，运行js程序，每个渲染进程下面只有一个ja引擎线程，与GUI渲染线程互斥，如果JS任务执行事件过长，会导致页面卡顿
GUI渲染	负责渲染浏览器界面，解析html，css构建dom树和render树，布局，绘制，和js引擎线程互斥，GUI更新还会在js引擎空闲时立即执行
定时器触发	定时器所在线程，setTimeout，serInterval计时完毕后，将回调添加到事件队列，等待js引擎执行
网络线程	在XHR，Fetch等发起请求后新开一个网络线程请求，如果设置了回调函数，在状态变更时，将回调放入事件队列，等待js引擎执行
事件触发	由宿主环境提供，用于控制时间循环，不断地从时间队列里取出任务执行

JS引擎VS渲染引擎（相互独立2）

1.解释执行JS

2.XML解析生成渲染树，显示在屏幕

3.桥接方式通信

渲染进程-多线程工作流程

1.网络线程负责加载网页资源

2.JS引擎解析js脚本并执行

3.JS解析引擎空闲时，渲染线程立即工作

4.用户交互，定时器操作等产生回调函数放入队列中

5.事件线程进行事件循环，将队列里的任务取出交给JS引擎执行

Chrome运行原理

Chrome运行原理-如何展示网页

浏览器地址输入URL后发生了什么

浏览器的主进程（输入处理---->开始导航------>读取响应（服务器）------->寻找渲染进程）

渲染进程（资源加载，加载子资源，执行脚本---构建DOM,CSSOM,渲染树----布局----绘制，构建图层绘制图层----合成--展示完成）

通过IPC告诉主进程完成展示

Chrome运行原理-输入处理

1.用户Url框输入内容后，UI线程会判断输入的是一个URL地址还是一个query查询条件

2.如果是URL,直接请求站点资源

3.如果是query，将输入发送给搜索引擎

Chrome运行原理-开始导航

1.当用户按下回车，UI线程通知网络线程发起一个网络请求来获取站点内容

2.请求过程中，tab处于loading状态

Chrome运行原理-读取响应

1.网络线程接受到HTTP响应后，先检查响应头的媒体类型（MIME Type）

2.如果想赢主题是一个HTML文件，浏览器将内容交给渲染进程处理

3.如果拿到的是其他类型文件，比如Zip，exe等则交给下载管理器处理

Chrome运行原理-寻找渲染进程

1.网络线程做完所有检查后，会告知主进程数据已准备完毕，主进程确认后为这一个站点寻找一个渲染进程

2.主进程通过IPC消息告知渲染进程去处理本次导航

3.渲染进程开始接受数据并告知主进程自己已开始处理，导航结束，进入文档加载阶段

渲染进程-资源加载

1.收到主进程的消息后，开始加载HTML文档

2.除此之外，还需要加载子资源，比如一些图片，CSS样式文件以及JavaScript脚本

渲染进程-构建渲染树

1.构建DOM树，将HTML文本转化成浏览器能够理解的结构

2.构建CSSOM树，浏览器同样不认识CSS，需要将CSS代码转化为可理解地CSSOM

3.构建渲染树，渲染树是DOM树和CSSOM树的结合

渲染进程-页面布局

1.根据渲染树计算每个节点的位置和大小

2.在浏览器页面区域绘制元素边框

3.遍历渲染树，将元素以盒模型的形式写入文档流

渲染进程-页面绘制

1.构建图层：为特定的节点生成专用图层

2.绘制图层：一个图层分成很多绘制指令，然后将这些指令按顺序组成一个绘制列表，交给合成线程

3.合成线程接受指令生成图块

4.栅格线程将土块进行栅格化(位图）

5.展示在屏幕上

前端性能perfoormance

1.时间都花在哪里

2.什么情况下卡顿

首屏优化

1.压缩，分包，删除无用代码

2.静态资源分离

3.JS脚本非阻塞加载

4.缓存策略

5.SSR

6.预置loading，骨架屏

渲染优化

1.GPU加速（透明度）

2.减少回流，重绘

3.离屏渲染

4.懒加载

JS优化

1.防止内存泄漏（全局变量）

2.循环尽早break

3.合理使用闭包

4.减少Dom访问（Dom变量缓存起来）

5.防抖，节流

6.Web Workers

跨端容器

为什么需要跨端

1.开发成本，效率

2.一致性体验

3.前端开发生态

有哪些跨端方案

Webview
小程序
RN/WeeX
Lynx
Flutter

WebView

1.网页视图，用具加载网页URL并展示其内容的控件

2.可以内嵌在移动端App内，实现前端混合开发，大多数混合框架都是基于Webview的二次开发，比如lonic，Cordova

优势：一次开发，处处使用，学习成本低，随时发布，及时更新，不用下载安装包，移动设备性能不断提升，性能有保障，通过JSBridge和原生系统交互，实现复杂功能

使用原生能力：

1.JavaScript调用Native

API注入：Native获取JavaScript环境上下文，对其挂载的对象或者方法进行拦截
使用Webview URL Scheme跳转拦截
IOS上window.webkit.messageHandler直接通信

2.Native调用JavaScript

直接通过webview暴露的API执行JS代码
IOS webview.stringByEvaluatingJavaScriptFromString
Android webview.evaluateJavascript

JSBridge

小程序（轻应用时代）基于浏览器内核完全重构了一个内置的解析器，配合一些定义开发语言标准

1.微信，支付宝，百度小程序，小米直达号

2.渲染层-webview

3.双线程，多webview架构

4.数据通信，Native转发

React Native/WeeX

1.原生组件渲染

2.React/Vue框架

3.virtual dom

4.JSBridge

Lynx（水平渲染）

1.Vue

2.JS Core/V8

3.JSBinding

4.Native UI/Skia

Flutter（看起来一致）

1.wideget

2.dart vm

3.skia图形库

跨端容器-通用原理

1.UI组件

2.渲染引擎

3.逻辑控制引擎

4.通信桥梁

5.底层API抹平表现差异

跨端方案的对比

小程序缓存资源

总结